ACH and PAD Consent Types
What is a Consent Type?
A consent type is a property submitted as part of the Mandate Request within a Billing Request. Consent types represent the type of authorization the payer is consenting to. Currently, this feature is only available to ACH and PAD schemes.
There are three main consent types:
Consent type | Definition |
One-off (single for PAD) | A one-off Authorization involves a debit initiated by the merchant based on the payer's authorization for a one-time transfer of funds from the payer's account. |
Recurring | A Recurring Authorization involves setting up processing of payments at regular intervals without any action needed from the payer. This is based on the payer’s debit authorization, which is provided to the merchant. |
Standing (sporadic for PAD) | A Standing Authorization allows the payer to pre-approve future transactions that require the merchant’s action to initiate. The payer will be informed about how they can authorize these transactions, which may include a phone call, online action, or a text message. |
Submitting consent types during Billing Request creation
Through the submission of consent types, more details about the authorisation can be captured during the creation of the Billing Request, displayed to the payer in their payment flow, and stored for record keeping.
Examples:
POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "ach",
"consent_type": "one_off"
},
}
}POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "ach",
"consent_type": "recurring"
},
}
}POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "ach",
"consent_type": "standing"
},
}
}POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "pad",
"consent_type": "sporadic"
},
}
}Request Types
When defining a consent_type as part of your mandate_request, you can also combine this with other request types: payment_request, subscription_request and instalment_schedule_request. When a consent type is combined with a request type, payment details can be shown to the payer. Once the Billing Request is authorised successfully, the mandate and any requested resources are also created. This minimizes the number of API requests that need to be made for resource creation after authorization. In addition, the consent type and associated payment details are propagated to the mandate, and can be viewed on the Mandate PDFs. The use of consent types combined with request types enhances the payer experience and enables the storage of compliant mandate data.
Examples:
POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "pad",
"consent_type": "single"
},
"payment_request": {
"description": "Registration Fee",
"amount": 2000,
"scheme": "pad",
"currency": "CAD"
}
}
}POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "ach",
"consent_type": "recurring"
},
"subscription_request": {
"amount": 2996,
"currency": "USD",
"name": "Monthly Magazine",
"interval_unit": "monthly",
"day_of_month": "3",
"count": 10,
"payment_reference": "test ref",
"metadata": {}
}
}
}When using the recurring consent type, it is possible to specify the payment_method within the constraints of the mandate_request. This is a free text field used to specify information about the payments. The information could include how the payments are calculated (particularly useful for variable payments) or any other useful information.
POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "pad",
"consent_type": "recurring",
"constraints": {
"payment_method": "calculated by your consumption of electricity"
}
}
}
}Combining Multiple Request Types
If you use a recurring consent type, you can combine a payment_request with an instalment_schedule_request or a subscription_request
Examples:
POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"mandate_request": {
"scheme": "pad",
"consent_type": "recurring"
},
"payment_request": {
"description": "Registration Fee",
"amount": 2000,
"scheme": "pad",
"currency": "CAD"
},
"subscription_request": {
"amount": 5000,
"currency": "CAD",
"name": "Gold Plan",
"interval_unit": "monthly",
"day_of_month": "1",
"count": 10,
"payment_reference": "test ref"
}
}
}POST https://api.gocardless.com/billing_requests HTTP/1.1
{
"billing_requests": {
"payment_request": {
"description": "registration fee",
"amount": 2000,
"scheme": "ach",
"currency": "USD"
},
"mandate_request": {
"scheme": "ach",
"consent_type": "recurring"
},
"instalment_schedule_request": {
"currency": "USD",
"instalments": [
{
"amount": "10000",
"charge_date": "2024-11-25"
},
{
"amount": "10000",
"charge_date": "2024-12-25"
}
],
"name": "Test instalment",
"total_amount": "20000",
"metadata": {},
"payment_reference": "test ref",
"retry_if_possible": false
}
}
}The table outlines all possible combinations of consent types and request types.
Consent type | Mandate Request | One-off payment request | Subscription request | Instalment schedule request |
One-off | ✅ | ❌ | ❌ | |
One-off | ✅ | ✅ | ❌ | ❌ |
Recurring | ✅ | |||
Recurring and payment method | ✅ | |||
Recurring | ✅ | ✅ | ❌ | |
Recurring | ✅ | ✅ | ✅ | ❌ |
Recurring | ✅ | ❌ | ✅ | |
Recurring | ✅ | ✅ | ❌ | ✅ |
Standing | ✅ | ❌ | ❌ | |
Standing | ✅ | ✅ | ❌ | ❌ |
Enforcement
After the Billing Request is fulfilled, and the mandate and associated payment resources are created, certain enforcement rules will apply. The enforcement rules apply regardless of how the resources were created (through Billing Request or core endpoints).
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 at a time | 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 at a time | 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 or completed subscription | User tries to create an instalment schedule against a recurring authorization that already has an active or completed subscription |
Recurring | cannot have a subscription attached to the authorization when there’s already an active or finished instalment schedule | User tries to create a subscription against a recurring authorization that already has an active or 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 |
What's next?
Create your first Billing Request with consent types by checking out the property details in our API Reference.