SEPA Direct Debit Drop-in integration

Our Android Drop-in renders SEPA Direct Debit in your payment form, where shoppers provide their account holder name and IBAN, and then review and confirm the payment.

Before you begin

This page explains how to add SEPA Direct Debit to your existing Android Drop-in integration. The Android Drop-in integration works the same way for all payment methods. If you haven't done this integration yet, refer to our Drop-in integration guide.

Before starting your SEPA Direct Debit integration:

1. Make sure you have set up your back end implementation.
2. Contact our Support Team, and ask them to add SEPA Direct Debit to your account.

Show SEPA Direct Debit in your payment form

Drop-in uses the countryCode and the amount.currency from your /paymentMethods request to show the available payment methods to your shopper.

To show SEPA Direct Debit in your payment form, you need to specify in your /paymentMethods request:

• countryCode: Country where SEPA Direct Debit is supported. For example, NL.
• amount.currency: EUR

Make a payment

When the shopper proceeds to pay, Drop-in returns the paymentComponentData.paymentMethod.

1. Pass the paymentComponentData.paymentMethod to your server.

2. From your server, make a /payments request, specifying:

   • paymentMethod: The paymentComponentData.paymentMethod from your client app.

The /payments response contains:

• resultCode: Received.
• pspReference: Adyen's unique reference number for the payment.

Check the payment result

Drop-in provides the actionComponentData in your shopper's app.

1. Pass the actionComponentData.details to your server.

2. From your server, make a /payments/details request containing the actionComponentData.details to check the payment result.

Present the payment result

Use the  resultCode that you received in the /payments response to present the payment result to your shopper.

The resultCode values you can receive for SEPA Direct Debit are:

resultCode	Description	Action to take
Received	The payment was successfully received.	You will receive a AUTHORISATION webhook when the status of the payment has been updated. If successful, you will receive the funds in 2 days.
Authorised	The payment was successfully completed.	Inform the shopper that the payment was successful.

Recurring payments

If you have a recurring or subscription business model we recommend tokenizing the shopper's payment details. When you create a shopper token from a SEPA payment, we store their payment details with the token. The token can be used to make recurring payments for the shopper.

You can create a shopper token and then make subsequent recurring payments with the token using the  /payments endpoint.

Create shopper token

To create a token, include in your /payments request:

• amount: The transaction must have a minimum value of EUR&nbsp0.01.
• recurringProcessingModel: Subscription, CardOnFile, or UnscheduledCardOnFile
• storePaymentMethod: true
• shopperReference: Your unique identifier for the shopper (minimum length three characters).

When the payment is settled, you receive a RECURRING_CONTRACT webhook containing:

• eventCode: RECURRING_CONTRACT
• originalReference: The pspReference of the initial payment.

• pspReference: This is the token that you need to make recurring payments for this shopper.

  Make sure that your server is able to receive RECURRING_CONTRACT as part of your standard webhooks. You can enable the RECURRING_CONTRACT event code in the webhook settings page.

Make recurring payment

For each recurring payment for this shopper, make a SEPA payment with a  /payments call, and additionally include:

• storedPaymentMethodId: The pspReference from the RECURRING_CONTRACT webhook.

  You can also get this value by using the /listRecurringDetails endpoint.

• shopperReference: The shopper ID you provided when created the shopper token.
• shopperInteraction: ContAuth.
• recurringProcessingModel: Subscription or UnscheduledCardOnFile.

For more information about the shopperInteraction and recurringProcessingModel fields, refer to Recurring transaction types.

If the payment was successfully received the response will contain a Received resultCode and a pspReference, which is our unique identifier for this transaction. You can track whether the payment was successful using webhooks.

Chargebacks

If a shopper for some reason wants the funds from a payment returned, they can ask their bank for a refund. This is referred to as a chargeback.

For SEPA, the chargeback process gives significant consumer rights to the shopper. They have:

• Eight weeks to dispute a SEPA payment without providing a reason.
• Thirteen months to dispute an unauthorised or incorrect SEPA payment when they provide evidence to their bank.

A SEPA chargeback notification can indicate that:

• The shopper disputed the charge.
• There were insufficient funds in the shopper's bank account.
• The bank account was inactive.
• Direct debit is blocked on this bank account, either in general or for this creditor specifically.
• There was a technical error.

For a list of detailed SEPA chargeback reasons and reason codes, see Dispute reason codes.

A chargeback webhook contains:

• pspReference: Adyen's unique reference associated with the payment request.
• eventCode: CHARGEBACK.
• reason: Reason for the chargeback.
• success: true.

Here is an example of a webhook that indicates a SEPA chargeback because there were insufficient funds in the shopper's bank account.

{
   "live":"false",
   "notificationItems":[
      {
         "NotificationRequestItem":{
            "additionalData":{
               "chargebackReasonCode":"AM04",
               "modificationMerchantReferences":"",
               "chargebackSchemeCode":"sepadirectdebit",
               "defensePeriodEndsAt":"2021-05-06T22:09:50+02:00",
               "defendable":"false",
               "disputeStatus":"Lost"
            },
            "amount":{
               "currency":"EUR",
               "value":1000
            },
            "eventCode":"CHARGEBACK",
            "eventDate":"2021-05-06T22:09:50+02:00",
            "merchantAccountCode":"YOUR_MERCHANT_ACCOUNT",
            "merchantReference":"YOUR_REFERENCE",
            "originalReference":"9913333333333333",
            "paymentMethod":"sepadirectdebit",
            "pspReference":"9915555555555555",
            "reason":"AM04:InsufficientFunds",
            "success":"true"
         }
      }
   ]
}

For more information on the chargeback process, refer to Dispute management.

Test and go live

Before making live SEPA payments, use the following Account Names and IBANs to test your integration.

Account Name	IBAN	Country
A. Klaassen	NL13TEST0123456789	NL
B. Klaassen	NL36TEST0236169114	NL
C. Klaassen	NL26TEST0336169116	NL
D. Klaassen	NL16TEST0436169118	NL
E. Klaassen	NL81TEST0536169128	NL
F. Klaassen	NL27TEST0636169146	NL
G. Klaassen	NL39TEST0736169237	NL
H. Klaassen	NL82TEST0836169255	NL
I. Klaassen	NL72TEST0936169257	NL
J. Klaassen	NL46TEST0136169112	NL
K. Klaassen	NL70TEST0736160337	NL
L. Klaassen	NL18TEST0736162437	NL
M. Klaassen	NL92TEST0736163433	NL
A. Schneider	DE87123456781234567890	DE
B. Schneider	DE92123456789876543210	DE
C. Schneider	DE14123456780023456789	DE
D. Schneider	DE36444488881234567890	DE
E. Schneider	DE41444488889876543210	DE
F. Schneider	DE60444488880023456789	DE
G. Schneider	DE89888888881234567890	DE
H. Schneider	DE94888888889876543210	DE
I. Schneider	DE16888888880023456789	DE
A. Pacini	IT60X0542811101000000123456	IT
A. Grand	FR1420041010050500013M02606	FR
A. Martin	ES9121000418450200051332	ES
W. Hurth	AT151234512345678901	AT
H. Gasser	CH4912345123456789012	CH
R. Paulsen	DK8612341234567890	DK
B. Dalby	NO6012341234561	NO
A. Bak	PL20123123411234567890123456	PL
A. Andersson	SE9412312345678901234561	SE

You can check the status of SEPA test payments in your Customer Area > Transactions > Payments.

Before you can accept live SEPA Direct Debit payments, you need to submit a request for SEPA Direct Debit in your live Customer Area.

See also