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.

Requirements

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 do not 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/region in a two-letter country code format. For example, GB. The countryCode is not required, but we recommend implementing it because of future enhancements.
   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 local 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, taking into account the following recommendations:

   • When using the HTTP GET method:
     For security reasons, when showing 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.

   • Redirection for mobile integrations:
     For mobile integrations, we strongly recommended that you redirect the shopper to the default browser of their device. Redirecting to the default browser ensures the best compatibility, handling of multi-factor authentication, app-to-app redirection, and error handling.

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:

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

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.

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.

Test credentials

Use the relevant test credentials and test issuer IDs, where available.

UK

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

When you send a test payment and are redirected to our open banking partner Tink, log in with the following test credentials for the UK:

For an Approved test scenario, you will see two checking accounts. Select the first checking account (ending in 285) for payment amounts greater than GBP 150, or the second checking account (ending in 327) for amounts less than GBP 150.

Germany

When you send a test payment and are redirected to our open banking partner Tink, log in with the following test credentials for Germany:

France

When you send a test payment and are redirected to our open banking partner Tink, log in with the following test credentials for France:

See also