ACH & PAD Authorization Types
Authorization types
The Billing Requests API enables submission of authorization (consent) types. This makes it easy to use the API to create and manage compliant ACH and PAD authorizations entirely on platform. This functionality is not yet available in the GoCardless dashboard.
The authorization types are:
| Authorization type | Definition | Example | Payment types supported |
| Open | Flexible and open-ended, allowing the merchant to charge payments as and when they need to in accordance with their agreement with the payer. | Charging for a software subscription plus add-on services, “card on file” | All |
| Recurring | A recurring payment will be debited from the payer’s account at regular intervals without any additional action needed from them. | Subscription to a magazine or news site | Subscriptions, instalments |
| Standing (sporadic) | Future payments will only be debited from the payer following their pre-approval. They will be informed about how they can approve these transactions, which may include a phone call, online confirmation, or a text message. | Invoicing for accountancy services | One-off |
| One-off (single) | A one-time payment will be debited from the payer’s account. | Purchasing a car with one payment | One-off |
Which authorization type should I use?
It’s important you choose the right authorization (consent) type for how you want to bill your customers.
As a rule of thumb, if you need flexibility in how you bill your customers you should use Open authorizations. If using the Open authorization type, it is your responsibility to display, collect and record information from the payer as outlined below.
If the way you bill customers is predictable and straightforward, consider using a recurring, standing, or one-off authorization. This way we will collect and record all the information needed to ensure your authorization is compliant, and will ensure that payments you collect are in accordance with the authorization (for example, you would only be able to charge one payment against a one-off authorization).
This table shows which authorization type will best meet your needs for charging your customers:
| Open | Recurring | Standing | One-off | |
| Number of payments | Multiple | Multiple | Multiple | One |
| Billing amount | Will change often | Will rarely/never change | Will change often | - |
| Charge date and frequency | May change | Will not change | May change | - |
| You are likely to charge the customer for additional products or services in future | ✅ | ❌ | ✅ | |
| Your customer will need to pre-approve each payment individually | ❌ | ❌ | ✅ | |
| You want to be able to charge a one-off payment upfront (e.g. joining fee) | ✅ | ✅ | ✅ |
This flow chart is another way to visualise which authorization type is best for billing your customers:
How to ensure a compliant Open authorization
If using the Open authorization type you must do the following in order to ensure your authorization is compliant.
This means making sure your payer is aware of the amount, and number and/or frequency of any debits in advance of the debit as required by NACHA for ACH authorizations and the H1 rule for PAD authorizations.
You must retain a readily and accurately reproducible record evidencing how you made your customers aware of the payment terms for two years from the date that the authorization is revoked or terminated.
How to use authorization types
If you are using custom payment pages, refer to our custom payment page requirements (ACH here, PAD here) to learn what needs to be shown on your payment page(s).
If you use hosted payment pages, the pages will display all required information for the authorization type you submit.
You can submit the authorization (consent) type when creating a Billing Request using the “consent_type” field. If you do not submit a value for this field, it will be an Open authorization by default.
To create a payment at the same time you can combine a mandate request authorization type with: a payment request, subscription request or instalment request. If you want to create a payment later you can do this later. If you are using our hosted payment pages, submitting an authorization type and creating a payment within the same Billing Request provides upfront information to your payer, giving them transparency on the payments they will make, instilling trust in your brand.
We recognise that there can be a one-off payment (e.g. registration fee) in addition to a subscription or instalment schedule, so it is possible to combine these payment requests.
All possible combinations
The table shows all possible combinations of authorization types and request types. When authorization type only is specified, it will still be displayed to payers on the payment flow, and payments can be attached after the Billing Request is fulfilled.
| Authorization type | Authorization type only | One-off payment request | Subscription request | Instalment schedule request |
| One-off | ✅ | |||
| One-off | ✅ | |||
| Recurring | ✅ | |||
| Recurring + method* | ✅ | |||
| Recurring | ✅ | |||
| Recurring | ✅ | ✅ | ||
| Recurring | ✅ | |||
| Recurring | ✅ | ✅ | ||
| Standing | ✅ | |||
| Standing | ✅ |
*free text field to specify information about the payments. It could be a payment calculation method or other useful information
Enforcement of authorization
To ensure your authorization is compliant we will ensure that payments you collect are in accordance with the authorization type and payment information. Certain enforcement rules will apply, based on certain triggers.
| Authorization type | Rule | Trigger |
| One-off | can only have one active payment | User tries to create another payment against a one-off authorization that already has an active or fulfilled payment |
| One-off | cannot have subscriptions or instalment schedules attached | User tries to create a subscription or instalment schedule against a one_off authorization |
| Recurring | can only have one active subscription | User tries to create another subscription against a recurring authorization that already has an active or completed subscription |
| Recurring | can only have one instalment schedule | User tries to create another instalment schedule against a recurring authorization that already has an active or finished instalment schedule |
| Recurring | can only have a subscription or instalment schedule attached after authorization is created | User tries to create a payment against a recurring authorization that has an active subscription or instalment schedule attached after the authorization is created |
| Recurring | cannot have an instalment schedule attached to the authorization when there’s already an active/completed subscription | User tries to create an instalment schedule against a recurring authorization that already has an active/completed subscription |
| Recurring | cannot have a subscription attached to the authorization when there’s already a active/finished instalment schedule | User tries to create a subscription against a recurring authorization that already has an active/finished instalment schedule |
| Recurring | cannot attach a subscription and instalment schedule to the same recurring authorization | User tries to create a subscription against a recurring authorization when there is already an active or completed instalment schedule attached, or vice versa. |
| Recurring | cannot attach a payment to a recurring authorization if it already has an active (or completed) subscription / instalment schedule | User tries to create a payment against a recurring authorization that already has an active (or completed) subscription / instalment schedule |
| Standing | Cannot have a subscription or instalment schedule attached | User tries to create a subscription or instalment schedule against a standing authorization |
Example of using a recurring authorization
1. Create billing request
Billing Request created with a mandate (authorization) request (recurring consent type) and a subscription request.
POST https://api.gocardless.com/billing_requests
{
"billing_requests": {
"mandate_request": {
"currency": "USD",
"scheme": "ach",
"consent_type": "recurring"
},
"subscription_request": {
"amount": 50,
"currency": "USD",
"name": "Gold Plan",
"interval_unit": "monthly",
"day_of_month": "1",
"payment_reference": "Test Reference"
}
}
}
2. Create your payment pages
If using custom payment pages:
Build custom pages in line with our custom payment page requirements (ACH here, PAD here) and connect them to our API.
If using hosted payment pages:
Billing Request Flow created from Billing Request
POST https://api.gocardless.com/billing_request_flows
{
"billing_request_flows": {
"links": {
"billing_request": "{{brq_id}}"
}
}
}
3. Direct payers to your payment pages
The payer is able to view the payment details and authorize it.
If using hosted payment pages:
Billing Request Flow authorization URL sent to payer and payer accesses the link.
4. Subscription is created
Following the payer’s authorization, the authorization and subscription are created.