Pay by Bank (Europe) for API only

Accept Pay by Bank (Europe) payments using our APIs, and build your own payment form to have full control over the look and feel of your checkout page.

Before you begin

Before starting your Pay by Bank (Europe) integration:

1. Make sure that you have set up your back end implementation.

2. Contact our Support Team to add Pay by Bank (Europe) in your test Customer Area.

Build your payment form

You can optionally configure your payment form to include a list of issuing banks for Pay by Bank (Europe).

In some regions, like Germany, there are so many banks that you cannot show a list of issuing banks. Shoppers are redirected to our open banking partner Tink to select their bank.

In other regions, like the United Kingdom, you can let shoppers pre-select their bank before redirecting them to Tink, by showing the list of issuing banks in your payment form. If you don't show the list of issuing banks, shoppers select their bank after being redirected to Tink.

In markets where issuer selection is supported, the list of issuing banks is included in the /paymentMethods response.

Show a list of issuer IDs

If issuer selection is supported:

1. Make a /paymentMethods request specifying the correct countryCode (for example, GB) and amount.currency (for example, GBP).
2. From the paymentMethods response, get a list of available issuing banks from the object with type: paybybank.
3. Show the list of issuing banks to the shopper.
4. After the shopper selects a bank, include the issuer ID when you make the payment request.

For more information, refer to the API-only integration guide.

For the UK, where you can show the issuer list in the payment form, the list may include the following banks:

Make a payment

1. Make a /payments request, specifying:

   Parameter	Required	Description
   countryCode		The shopper's country in a two-letter country code format. For example, GB
   returnUrl		URL to where the shopper should be redirected back to after they complete the payment. This URL can have a maximum of 1024 characters.
   paymentMethod.type		paybybank
   paymentMethod.issuer		The issuer ID of the shopper's selected bank. This is only supported in regions where you can show the issuer list.
   shopperLocale		The language that the redirection page (hosted by Tink) should be rendered in. The page can be in the country's language (for example, de-DE for Germany) or in en-US.

2. In the /payments response, note the action object. This contains the information needed to redirect the shopper.

Handle the redirect

1. To complete the payment, redirect the shopper to the action.url returned in the /payments response.

   When using the HTTP GET method:
   For security reasons, when displaying the redirect in the app, we recommend that you use SFSafariViewController for iOS or Chrome Custom Tabs for Android, instead of WebView objects. Also refer to the security best practices for WebView.

2. After the shopper is redirected back to your website, check the payment result by making a POST /payments/details request, specifying:

   • details: object that contains the URL-decoded redirectResult returned when the shopper was redirected back to your site.

3. In the response note the following:

   • resultCode: use this to present the result to your shopper.
   • pspReference: our unique identifier for the transaction.

Present the payment result

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

The resultCode values you can receive for Pay by Bank (Europe) are:

resultCode	Description	Action to take
Authorised	The payment was successful.	Inform the shopper that the payment has been successful. You will receive the funds in 2-3 days.
Cancelled	The shopper cancelled the payment while on their bank's website.	Ask the shopper whether they want to continue with the order, or ask them to select a different payment method.
Error	There was an error while the payment was processed.	Inform the shopper that there was an error processing their payment. The response contains a refusalReason, indicating the cause of the error.
Pending or Received	The shopper has completed the payment but the final result is not yet known. It may take minutes or hours to confirm this.	Inform the shopper that you received their order, and are waiting for the payment to be completed. You will receive the final result of the payment in an AUTHORISATION webhook. If the transaction is not authorised within 30 minutes, the offer will close. Optionally, you can be informed of this through an OFFER_CLOSED webhook.
Refused	The payment was refused by the shopper's bank.	Ask the shopper to try the payment again using a different payment method.

If the shopper closed the browser and failed to return to your website, wait for webhooks to know the outcome of the payment:

eventCode	success field	Description	Action to take
AUTHORISATION	false	The payment failed.	Cancel the order and inform the shopper that the payment failed.
AUTHORISATION	true	The shopper successfully completed the payment.	Inform the shopper that the payment has been successful and proceed with the order.

Recurring payments

We support recurring transactions for Pay by Bank (Europe) through SEPA Direct Debit.

We strongly recommend that you ask explicit permission from the shopper if you intend to make future recurring payments. Being transparent about the payment schedule and the charged amount reduces the risk of chargebacks.

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.
• storePaymentMethod: true
• shopperReference: your unique identifier for the shopper (minimum length three characters). Do not include personally identifiable information (PII), such as name or email address.
• recurringProcessingModel: Subscription or UnscheduledCardOnFile

  From Checkout v70, recurringProcessingModel is a required parameter when creating or using a token.

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 a payment with a token

For each recurring payment for this shopper, make a SEPA payment to the /payments endpoint, specifying:

• paymentMethod.type: sepadirectdebit
• paymentMethod.storedPaymentMethodId: The pspReference from the RECURRING_CONTRACT webhook. You can also get this value using the /listRecurringDetails endpoint.
• shopperReference: The shopper ID you provided when you created the shopper token.
• shopperInteraction: ContAuth.

• recurringProcessingModel: Subscription or UnscheduledCardOnFile.

  From Checkout v70, recurringProcessingModel is a required parameter when creating or using a token.

For more information about the shopperInteraction and recurringProcessingModel fields, refer to Tokenization.

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 shopper's account passed the verifications by the issuer and our Pay by Bank (Europe) partners, and that the bank transfer was initiated successfully. However, the payment can still fail for the following reasons:

• The shopper cancelled the transaction. Some banks 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 payment. For example, if the shopper completes a payment on a Saturday, the bank might only process it on Monday. If the shopper has withdrawn funds in the meantime, the payment can fail due to insufficient funds.

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 various scenarios, such as approved payments, authentication errors, and payments cancelled by the shopper. See the Tink documentation for screenshots that can help you navigate the flow. You can check the status of test payments in your Customer Area > Transactions > Payments.

Before you can accept live Pay by Bank (Europe) payments, you need to add Pay by Bank (Europe) in your live Customer Area.

UK test credentials

For the UK, where you can show the issuer list in the payment form, we provide the following test issuer IDs:

Bank name	Issuer ID
Tink Demo Bank	uk-demobank-open-banking-handoff
Tink Demo Bank	uk-demobank-open-banking-redirect
Tink Demo Bank	uk-demobank-open-banking-redirect-aispis
Tink Demo Bank	uk-demobank-open-banking-redirect-extendable

To test different scenarios, use those test issuer IDs and the following scenario-specific credentials:

Approved
Username: u02792141
Password: udy509

Authentication error
Username: u82559259
Password: dfo473

Temporary error
Username: u18312037
Password: eyj733

See also