Open banking Drop-in integration

On this page, you can find additional configuration for adding open banking to your Drop-in integration.

Before you begin

Before starting your open banking integration:

1. Contact our Support Team to add open banking in your test Customer Area.

2. Make sure you've integrated Drop-in v5.27.0 or later.

API reference

Select which endpoint you're integrating:

Drop-in configuration

Optional configuration

You can add the following optional configuration:

Parameter name	Description	Default
showImage	Set to false to remove the bank logos from the open banking form.	true
issuer	Set to an issuer ID to preselect a specific bank.	No bank is preselected.
highlightedIssuers	Set to the issuer IDs for banks you want to show on top of the dropdown menu. Added in v5.1.0	All issuers are shown in the dropdown.
placeholder	The string you want to show as the dropdown menu text. Custom translation configuration overrides this value.	Select your bank

If you want to add optional configuration, include this in a configuration object. The following example shows how to configure Drop-in to remove the bank logos, and preselect Bank of Scotland:

const openBankingConfiguration = {
  showImage: false, // Optional. Set to **false** to remove the bank logos from the open banking form.
  issuer: "uk-bankofscotland-oauth2" // Optional. Set this to an **id** of an open banking issuer to preselect it.
};

Include the openBankingConfiguration object when creating a configuration object for Drop-in:

List of issuer IDs

For the UK, where you can show the issuer list in the payment form, the available banks are listed below:

Recurring payments

We support recurring transactions for open banking through SEPA Direct Debit. To make recurring payments, you need to:

1. Create a shopper token.
2. Use the token to make future payments for the shopper.

Create a token

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

• amount: The transaction must have a minimum value of EUR 0.01.
• recurringProcessingModel: Subscription 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 a payment with a token

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

In rare scenarios, it is possible that you do not receive the funds even after receiving a successful AUTHORISATION webhook. The successful AUTHORISATION webhook means that the payment has passed the verifications that the issuer and our open banking partners run on the shopper account, and that the bank transfer was initiated successfully. However, the payment can still fail for the following reasons:

• The shopper cancelled the transaction. Banks in some countries (including Germany and Poland) allow shoppers to cancel bank transfers until midnight of the day of the transaction.
• Some banks process transactions with a delay and do not block the funds for an authorized open banking payment. For example, if the shopper completes a open banking payment on a Saturday, the bank might only process it on Monday. If the shopper has withdrawn sufficient funds in the meantime, the payment will fail.

In these cases, Adyen is not informed that the transaction failed. We also don't know whether the bank might still process it later.

On our side, the status of the payment is SentForSettle until we receive the funds. You can check the status of the payment in your Customer Area.

If we have not received the funds after 8 weekdays, the status of the payment becomes Settled, then Chargeback, and you receive a CHARGEBACK webhook.

In case we receive the money after this point, you receive a CHARGEBACK_REVERSED webhook.

Test and go live

We recommend that you test each scenario before you go live. Check the status of test payments in your Customer Area > Transactions > Payments.

Before you can accept live open banking payments, contact our Support Team to add open banking in your live Customer Area.

UK

We provide different test issuers for testing open banking payments, including testing for failed or cancelled payments. Select the test issuer name, for example Demo Open Banking Redirect (payment cancelled), to simulate a cancelled payment scenario.

Germany

When you are redirected to the Tink environment, choose Tink Demo Bank > Open banking > Authentifikator-App Demo Bank > Weiterleiten and log in with these credentials to simulate different payment outcomes:

Approved
Username: u02792141
Password: udy509

Authentication error
Username: u82559259
Password: dfo473

Temporary error
Username: u18312037
Password: eyj733

See the Tink documentation for screenshots that can help you navigate the flow.

See also