> ## Documentation Index > Fetch the complete documentation index at: https://docs.mangopay.com/llms.txt > Use this file to discover all available pages before exploring further. # Direct debit export const LogoBacs = ; export const LogoSepa = ; export const WorkingDay = ({content}) => {content} ; export const Chargeback = ({content}) => {content} ;

Scheme	SEPA Core	Bacs
Region	Eurozone	UK
Currencies	EUR	GBP
[Refunds](#late-failures%2C-chargebacks-and-refunds)	Supported, after 7 days and within 13 months	Supported, after 7 days and within 13 months
[Disputes](#late-failures%2C-chargebacks-and-refunds)	Supported – Non-contestable	Supported – Non-contestable

## 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: 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. 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. ### IBAN compatibility 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. For SDD, Mangopay only supports the SEPA Core scheme and not the SEPA B2B scheme. Furthermore, the IBAN must be accepted as part of the SEPA Core scheme. Some European countries, notably Denmark and Sweden, operate different local direct debit schemes and IBANs from these countries (starting `DK` or `SE`) may not be supported. ## 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](/testing/payment-methods#direct-debit). 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 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. For SDD, IBANs that are not SEPA Core are not accepted ([read more](#iban-compatibility)). 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](/webhooks/event-types#direct-debit-mandates) to receive [webhook notifications](/webhooks). 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`. Due to the nature of direct debits, payments take a few days to clear – see [processing times](#pay-in-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. 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 `Status` becomes `FAILED`) * Expired - No pay-ins were made against the mandate in the last 24 months, which makes it expire (Mandate `Status` becomes `EXPIRED`) 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_CLOSED` * `LATE_FAILURE_BANKACCOUNT_INCOMPATIBLE` * `LATE_FAILURE_BANKACCOUNT_INCORRECT` * `LATE_FAILURE_CONTACT_USER` * `LATE_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 full 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. A refund is possible from 00:00:01 UTC on the 8th day following the day of the pay-in's `CreationDate`, so if the pay-in was created on a Monday (at any time), the refund can be requested on the Tuesday of the following week. If you attempt to initiate a refund within 7 full calendar days, the refund fails with the error [001405](/errors/codes/001405). In Sandbox, you can avoid this limitation using the available [mock value for testing](/testing/payment-methods#direct-debit). Refunds are possible for 13 months following the initiation transaction's `CreationDate`, after which time the initial transaction is [archived](/api-reference/overview/data-availability-periods) and a refund is no longer possible. 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. Read more about disputes **→** ## Related resources Learn how to process a SEPA direct debit payment The Direct Debit PayIn object Learn about testing direct debits