--- title: PayTo slug: payments/payto description: Enable PayTo payments in Unaric Payments for Australia to offer convenient bank account payments. image: https://cdn.images.archbee.com/10Nod6Ww95R3dPr0k0TCJ/7OWWGFIi1Qk3BxYloWUX0_unaric-payments.png createdAt: 2025-07-28T23:09:44.703Z --- PayTo is a real-time payment system supported by Unaric Payments through GoCardless from version 2.32 (Summer 2025). :::hint{type="info"} 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. ::::WorkflowBlock :::WorkflowBlockItem ### 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*. ::: :::WorkflowBlockItem ### 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. ::: :::WorkflowBlockItem ### 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*. ::: :::WorkflowBlockItem ### 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. ::: :::WorkflowBlockItem ### 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](https://support.gocardless.com/hc/en-au/articles/17579393142300-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](https://support.gocardless.com/hc/en-au/articles/17579393142300-PayTo-FAQs), [PayTo guide](https://docs.gocardless.com/docs/collect-payments/recurring-payments/payto) and [Billing Request API reference](https://docs.gocardless.com/docs/api-reference/billing-request). ### 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 :::::::WorkflowBlock :::WorkflowBlockItem ### 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. ::: :::WorkflowBlockItem ### Create the PayTo PSP connection 1. Navigate to the **Unaric Payments Setup** tab. 2. Under your chosen **Merchant Group**, click the **New PSP Connection** button. 3. Set these parameters: - **PSP**: *GoCardless.* - **Mode**: *PayTo.* 4. Click **Create PSP Connection**. 5. Enter your GoCardless credentials. 6. Create your Payment and/or Authorisation records with PayTo included in the Payment Route Options. ::: :::WorkflowBlockItem ### 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. 1. In Salesforce Setup, go to **Objects and Fields > Picklist Value Sets > Payment Route Options**. 2. Click **New**, enter *PayTo* and save. 3. In Object Manager, open the **Unaric Payment**, **Unaric Payments Authorisation** and **Unaric Payments Refund objects**. For each, go to **Record Types > Inbound**. 4. 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. ::: ::::::WorkflowBlockItem ### 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**.** :::::Tabs ::::Tab{title="Unaric Payments Authorisation"} :::hint{type="warning"} 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** :::: ::::Tab{title="Unaric Payment"} :::hint{type="info"} These fields are required only for standalone payments. Otherwise, values default from Authorisation records. ::: - **PayTo Description** - **PayTo Purpose Code** :::: ::::: :::::: ::::::: ## Create payments 1. Create your **Authorisation **or** Payment record** with PayTo in the **Payment Route Options** field. 2. Populate the required **PayTo fields** on the **Authorisation/Payment record**. These include: - **Description** :::hint{type="info"} 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) ** :::hint{type="info"} 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. ::: :::hint{type="info"} 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**. ::: 3. 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. :::hint{type="success" indent="3"} For **Purpose Code**, choose the one that best describes the payment. See GoCardless' [Billing Request API reference](https://docs.gocardless.com/docs/api-reference/billing-request) for the codes PayTo accepts. ::: 4. For **combined Authorisation and Payment**, set PayTo **Description** and** Purpose Code** on both records, and they **must match**. 5. 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. :::hint{type="success"} The PayTo payment flow redirects to a GoCardless-hosted interface. As such, if embedded in your web journey, align styling with GoCardless branding guidelines. ::: :::hint{type="warning"} 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* :::