Direct debit
| Scheme | SEPA | Bacs |
|---|---|---|
| Region | Eurozone | UK |
| Currencies | EUR | GBP |
| Refunds | Supported | Supported |
| Disputes | Supported – | Supported – |
Introduction
Direct debit is a term used to describe a preauthorized bank debit from a user’s bank account. Payments are authorized by the user by way of a mandate, which is an authorization from the user to their bank to allow the future debits by the collecting party.
Mangopay provides a hosted digital mandate form that users can confirm. Users can cancel a mandate at any time with their bank.
Each country or region operates its own direct debit scheme which governs the infrastructure and mechanisms of payment, for example rules about the mandate and advance notice before each payment.
Mangopay offers two schemes:
SEPA Direct Debit (SDD) Core
Scheme operated by the European Payments Council (EPC) for collecting payments in the Eurozone in EUR.
An IBAN-type Bank Account is required for the mandate.
Bacs Direct Debit
Scheme operated by Pay.UK in the UK for collecting payments in the UK in GBP.
A GB-type Bank Account is required for the mandate.
The user’s bank must be participating in the relevant scheme, which is not always the case. It may also be that the scheme rules prevent the use of certain account types.
Mangopay does not offer the SEPA B2B scheme.
How it works
The steps for setting up a direct debit and collecting payments are described below. For more guidance on testing direct debits, including mock values, see Testing – Payment methods.
Register the user's bank account
Using the Id of the user as the UserId path parameter, register their bank account using the relevant endpoint. The scheme of the mandate is determined automatically by the type of bank account you create.
- For the SEPA scheme, use the POST Create an IBAN Bank Account endpoint.
- For the Bacs scheme, use the POST Create a GB Bank Account endpoint.
In response, the bank account’s Active property should be true and its Id allows you to create the mandate.
Create the mandate
Create the mandate using the POST Create a Mandate endpoint, using the bank account’s Id as the BankAccountId and defining a ReturnURL to which the user is returned after confirming the mandate.
Let the user confirm the mandate
In the response to the mandate creation request, the API returns a RedirectURL to which you must redirect the user so they can validate the mandate. After confirming, the user is returned on the URL you provided for ReturnURL.
Note – Mandate expires after 1 hour
The user must validate the mandate within 1 hour, otherwise it expires and a new mandate must be created.
The Mandate’s Status changes from CREATED to SUBMITTED, indicating that it has been submitted to the issuing bank. It becomes ACTIVE:
- After the first successful pay-in for SEPA
- After a few days (usually 3) for Bacs
Set up webhooks for the MANDATE_SUBMITTED and MANDATE_ACTIVE event types to receive webhook notifications.
Request the first pay-in
Once the mandate’s Status is SUBMITTED, request the first pay-in using the POST Create a Direct Debit PayIn endpoint, specifying the Id of the mandate as the MandateId.
Wait for the pay-in to be processed
Due to the nature of direct debits, payments take a few days to clear – see processing times below.
The wallet is credited when the pay-in’s Status changes to SUCCEEDED.
You can be notified of this by setting up a webhook for the PAYIN_NORMAL_SUCCEEDED event type.
You can then use the GET View a PayIn endpoint to confirm the successful payment and other details.
Request subsequent pay-ins
You can continue requesting direct debit pay-ins as agreed with the user until the mandate is:
- Canceled - The user or the platform has canceled the mandate (Mandate
StatusbecomesFAILED) - Expired - No pay-ins were made against the mandate in the last 24 months, which makes it expire (Mandate
StatusbecomesEXPIRED)
You can be notified if this happens by setting up webhooks for mandate event types.
Pay-in processing times
When a direct debit pay-in is created, the API returns a ChargeDate. The charge date is used to provide advance notice to the user of the future charge, and is set at midnight (00:00) on the given day.
When the issuer confirms the scheduled payment, the pay-in Status changes to SUCCEEDED and the wallet is credited. The user’s account is usually debited the following day, but it depends on their bank.
Timings
The following table describes the timings relative to the pay-in’s ChargeDate in . Note that for Bacs, the first pay-in against a mandate takes an extra day as shown.
| SEPA | Bacs | ||
|---|---|---|---|
| First pay-in | Subsequent pay-ins | ||
| Pay-in creation cutoff | D-1, 5:30 am CET | D-4, 4:00 pm GMT | D-3, 4:00 pm GMT |
Pay-in ChargeDate | D | D | D |
Pay-in SUCCEEDED | D+1 | D+1 | D+1 |
| Total business days | 3 | 6 | 5 |
Note – Timings are typical durations
The time it takes for a specific payment to be cleared depends on the issuing bank and the scheme.
The timings given here are a strong general indication but never a certainty.
You should also create pay-ins well in advance of the cutoff to ensure expected processing.
Example
The following table provides an example in terms of weekdays:
| SEPA | Bacs | ||
|---|---|---|---|
| First pay-in | Subsequent pay-ins | ||
| Pay-in creation cutoff | Fri, 5:30 am CET | Tue, 4:00 pm GMT | Wed, 4:00 pm GMT |
Pay-in ChargeDate | Mon | Mon | Mon |
Pay-in SUCCEEDED | Tue | Tue | Tue |
| Total business days | 3 | 6 | 5 |
Email notifications
Mangopay notifies the user by email (to the user’s Email parameter) when a mandate is first confirmed and when a pay-in is created.
While Mangopay’s emails can’t be customized, it is possible to deactivate them so you can put in place your own flow in accordance with scheme rules.
Bacs specificities
Note that for Bacs:
- NatWest, RBS, HSBC, Metro, and Nationwide banks don’t show the platform trading name on bank statements – only Mangopay is displayed.
- Mandates can’t be created on accounts where multiple signatures are required (e.g. business accounts).
Late failures, chargebacks and refunds
In direct debits, a late failure occurs when the issuing bank fails to inform the collecting party that the funds could not be collected as scheduled (for example if the account is closed or has insufficient funds). As a result, the pay-in Status is SUCCEEDED but the funds are not subsequently debited from the account.
When a late failure happens, Mangopay creates a Dispute object (and corresponding Repudiation) in the same way as for a regular .
The Dispute DisputeReasonType parameter indicates the reason for the late failure:
LATE_FAILURE_BANKACCOUNT_CLOSEDLATE_FAILURE_BANKACCOUNT_INCOMPATIBLELATE_FAILURE_BANKACCOUNT_INCORRECTLATE_FAILURE_CONTACT_USERLATE_FAILURE_INSUFFICIENT_FUN
Usually, late failures occur:
- Within 5 days for the SEPA scheme
- Within 2 or 3 days for the Bacs scheme
Note – Refunds not possible within 7 days
For direct debits, you must wait 7 calendar days before initiating a refund. This is because of the possibility that a late failure occurs, which would create a conflict on a pay-in that has already been refunded.
If you attempt to initiate a refund within 7 calendar days of the pay-in’s CreationDate, the refund fails with the error 001405. In Sandbox, you can avoid this limitation using the available mock value for testing.
Besides late failures, a dispute can also be created if a user requests a chargeback on a direct debit payment with their bank.
The resulting disputes are always non-contestable and are possible:
- For up to 8 weeks for the SEPA scheme.
- Indefinitely for the Bacs scheme.