PayTo
PayTo is a real-time payment system supported by Unaric Payments through GoCardless from version 2.32 (Summer 2025).
PayTo is in AUD only and is for Australian bank accounts.
Why use PayTo instead of BECS direct debit
PayTo offers many advantages over BECS direct debit:
- The customer approves it in their bank, so the agreement is verified straight away rather than relying on bank details typed into a form.
- Payments are real time, so you get confirmation of success or failure much faster than with BECS. Funds usually settle the next business day.
- It is the future of Australian bank payments. Australian banking is discussing decommissioning BECS in the near future.
- You don't lose customers whose bank doesn't support it. In cases where PayTo is not supported, Unaric Payments automatically falls back to BECS direct debit.
How it works
PayTo runs on Australia’s New Payments Platform (NPP), so payments are processed 24/7 and settle in near real time, including on weekends and public holidays.
PayTo payments work through agreements, which work like a direct debit mandate, but the customer approves it digitally with their own bank and can see it there. Once the agreement is active, you can take one-off or recurring payments within the limits the customer agreed to.
Approval
The customer gets a prompt in their banking app, and some banks also send a push notification or SMS. Once they approve, the Authorisation moves to In Force.
Fallback
If the customer's bank doesn't support PayTo, GoCardless sets up a BECS direct debit instead. The record keeps PayTo as Payment Route Options but shows Direct Debit as Payment Route Selected.
Besides, you can move an existing PayTo customer to direct debit. Create a new Authorisation with Direct Debit in Payment Route Options and send them the link. Your GoCardless account must have a Direct Debit PSP connection set up.
Customer control
The customer can see, pause or cancel the agreement in their bank. A paused agreement shows in Salesforce as Cancelled with suspended by payer as description, and no payments can be taken on it. If the customer resumes it in their bank, it goes back to In Force.
Payments
Each payment is sent through GoCardless and the result comes back to the Payment record in Salesforce. Payment results usually arrive quickly, but a delay at GoCardless or the bank can leave a payment in Submitted for collection for longer.
Refunds
PayTo payments are refund the same way as any other GoCardless payment. GoCardless pays PayTo refunds as BECS credits in a daily batch, so they aren't instant. For current timings, see GoCardless' PayTo FAQs.
Mandate limits
Every payment on a PayTo agreement, scheduled or extra, must fit within the limits the customer approved. To change them, the customer has to approve a new or amended agreement in their bank.
Limit | Unaric Payments field | What it does |
|---|---|---|
Maximum amount per payment | PayTo Maximum Amount Per Payment | Caps every single payment. A payment above it is rejected. |
Payments per period | PayTo Period + PayTo Maximum Number of Payments | Caps how many payments you can take per day, week, month, or year. Extra payments count towards it. |
Flexible period | PayTo Period = Flexible | No fixed day, week, month, or year. Maximum Number of Payments is still required in Salesforce and is sent to GoCardless with it. |
GoCardless also applies its own PayTo rules on top of these limits, such as a maximum amount per transaction and which limit types PayTo supports. These are set by GoCardless and can change, so check the current details in their PayTo FAQs, PayTo guide and Billing Request API reference.
Extra payments on top of a schedule
An ad hoc payment is checked exactly like a scheduled one. If a scheduled payment has already used the period's allowance, an extra payment in the same period can be rejected. An amount over the cap fails with an error like payment_request must not be greater than max_amount_per_payment.
Best practices
- Set the per-payment cap to cover your largest expected charge, not just the regular amount.
- If you expect top-ups, set Maximum Number of Payments with room for extras. Period and Maximum Number of Payments are both required, so Unaric Payments always sends a payment-count limit.
- Before taking an extra payment, check the agreement's cap and how many payments you've already taken that period.
- To change limits on an existing agreement, the customer must approve a new or amended agreement. Create a new Authorisation and send them the link.
Setup
Prerequisites
- GoCardless account with PayTo enabled and your GoCardless credentials.
- Unaric Payments 2.32 or later. If you schedule recurring PayTo payments, use 2.32.5 or later on the Summer release line, or 2.37 or later. These versions copy the PayTo Description and Purpose Code from the authorisation onto scheduled payments.
- An online customer journey. Customers must approve PayTo in their banking app, so you need to send them the paypage link, for example on your website or by email. Consequently, PayTo can’t be taken over the phone (MOTO).
- The scheduled payment job running, if you use Payment Schedules. Scheduled payments are only created and sent when that job runs.
- A Direct Debit PSP connection, if you want to move PayTo customers to BECS direct debit yourself.
Create the PayTo PSP connection
- Navigate to the Unaric Payments Setup tab.
- Under your chosen Merchant Group, click the New PSP Connection button.
- Set these parameters:
- PSP: GoCardless.
- Mode: PayTo.
- Click Create PSP Connection.
- Enter your GoCardless credentials.
- Create your Payment and/or Authorisation records with PayTo included in the Payment Route Options.
Add PayTo to the picklists (upgrades only)
PayTo was introduced in Unaric Payments v.2.32. If upgrading from a previous version, you need to add it to picklists manually.
- In Salesforce Setup, go to Objects and Fields > Picklist Value Sets > Payment Route Options.
- Click New, enter PayTo and save.
- In Object Manager, open the Unaric Payment, Unaric Payments Authorisation and Unaric Payments Refund objects. For each, go to Record Types > Inbound.
- Edit Payment Route Options and Payment Route Selected, move PayTo to Selected Values and save. Optionally, use the dropdown box below to set a default value.
Add the PayTo fields to page layouts (upgrades only)
As with picklists, if you're upgrading from a version previous to v.2.32 you need to update the Page Layouts of Unaric Payments Authorisation and Unaric Payment objects to include PayTo fields.
Except for Start Date and End Date, all fields are mandatory for PayTo mandates.
- PayTo Description
- PayTo Start Date
- PayTo End Date
- PayTo Maximum Amount Per Payment
- PayTo Maximum Number of Payments
- PayTo Period
- PayTo Purpose Code
Create payments
- Create your Authorisation or Payment record with PayTo in the Payment Route Options field.
- Populate the required PayTo fields on the Authorisation/Payment record. These include:
- Description
The customer sees the Description when they approve, so make it clear and recognisable. Choose the limits carefully, because they can't be changed later (see Mandate limits).
- Purpose Code
- Maximum Amount Per Payment
- Period
- Maximum Number of Payments
- Start and End Dates (optional)
If you leave Start Date blank, the agreement starts when the customer approves it. If you leave End Date blank, it stays open until it’s cancelled.
Dates can’t be in the past, Start Date can’t be after End Date, and you can’t set an End Date without a Start Date.
- For Payments with In Force Authorisations, you can omit the PayTo Description and Purpose Code on the Payment (they will be inherited). If included manually, they must match the attached Authorisation.
For Purpose Code, choose the one that best describes the payment. See GoCardless' Billing Request API reference for the codes PayTo accepts.
- For combined Authorisation and Payment, set PayTo Description and Purpose Code on both records, and they must match.
- Send the customer the eCommerce URL. The PayTo option will appear on the PayPage. When they choose PayTo, they will be redirected to a GoCardless-hosted page, with their name, email and company name filled in from the record. They then approve the agreement in their banking app.
The PayTo payment flow redirects to a GoCardless-hosted interface. As such, if embedded in your web journey, align styling with GoCardless branding guidelines.
As PayTo is still being rolled out and adopted, if the bank doesn't support it yet, GoCardless will automatically revert to using the older, established BECS Direct Debit system for that payment. If so, the payment details will switch to:
- Payment Route Option = PayTo
- Payment Route Selected = Direct Debit