Technical Bulletin — Update on Payment Flows

This bulletin outlines important changes you’ll need to make if you plan to connect to: - Banks outside the UK (excluding the Republic of Ireland) - Banks in Germany and Austria

Two distinct payment flow categories are being introduced:

• Auth PLUS Transfer Initiated Payments – transfer token redemption initiated by the TPP
• Auth AND Transfer Initiated Payments – transfer token redemption initiated by the bank

The changes discussed in this update are designed to standardise the user experience across different permutations in the payment flow imposed by various banks throughout Europe. The changes that will impact your implementation largely depend on how you currently integrate with Token.

In general, if you take payments from across the UK and Europe, you will need to support both payment flows. If you take payments from within a single country only, it may be possible to support only one flow, although this is largely bank-dependent as described is due course below. In all cases, you will be wise to double-check each bank’s particular requirements.

Click on one of the following links to go directly to the use case that applies to you: 1. I use Token’s licence, bank selection, and consent pages 2. I use Token’s licence and consent pages 3. I use my own licence, and I handle bank selection and consent pages

Use Case #1: I use Token’s licence, bank selection, and consent pages

Important: If this use case does not apply to you, please select the one that does.

Overview

For some banks, the business/merchant must confirm payment initiation after the PSU has authenticated with their bank. This is called the Auth Plus Transfer Initiated Payment Flow or 2-step paymnts and is reflected in the following diagram.

Other banks automatically initiate payment after the PSU is authenticated by the bank. This is called the Auth AND Transfer Initiated Payment Flow or 1-step payments and is reflected in the next diagram.

The respective flows can be enumerated as follows.

Auth PLUS Transfer Initiated Payment Flow

In concert with the diagram above, the steps comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

2. The business/merchant creates and stores the token request, specifying the amount, currency, debtor name, and (optionally) country.

3. Token returns the request_id.

4. The business/merchant redirects the PSU to the constructed token request URL. This takes the PSU to the Token web app.

5. The business/merchant requests a bank authorisation URL from Token.

6. The business/merchant redirects the PSU to the bank authorisation URL.

Note: If the country is specified in the token request, Token presents the PSU with the Token web app’s bank selection page, filtered by country. From the list displayed, the PSU must select the bank they want to use to make the payment. Should the source account number be required by the selected bank, you can capture the source account number from the PSU in your UI. Token will display it on the payment confirmation page (pictured below) of the Token web app. If you did not capture the source account number, Token will present the PSU with an empty text box on the payment confirmation page where they must enter their source account number before continuing.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token returns token_id in a callback to business/merchant.

3. Business/merchant redeems the token.

4. Token sends transfer_id to business/merchant.

Note: At this point, the payment is complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns the updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Auth AND Transfer Initiated Payment Flow

In concert with the diagram above, the steps for this flow comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

2. The business/merchant creates and stores the token request, specifying the amount, currency, debtor name and, optionally, country.

3. Token returns the request_id.

4. The business/merchant requests the bank authorization URL from Token.

5.The business/merchant redirects the PSU to the bank authorisation URL.

Note: If the country is specified in the token request, Token presents the PSU with the Token web app’s bank selection page, filtered by country. From the list displayed, the PSU must select the bank they want to use to make the payment. Should the source account number be required by the selected bank, you can capture the source account number from the PSU in your UI. Token will display it on the payment confirmation page (pictured below) of the Token web app. If you did not capture the source account number, Token will present the PSU with an empty text box on the payment confirmation page where they must enter their source account number before continuing.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token sends the the transfer_status and transfer_id in a callback to the business/merchant.

Note: The payment is now complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns an updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Use Case #2: I use Token’s licence and Token’s consent pages

Important: If this use case does not apply to you, please select the one that does.

Overview

For some banks, the business/merchant must confirm payment initiation after the PSU has authenticated with their bank. This is called the Auth Plus Transfer Initiated Payment Flow or 2-step paymnts and is reflected in the following diagram.

Other banks automatically initiate payment after the PSU is authenticated by the bank. This is called the Auth AND Transfer Initiated Payment Flow or 1-step payments and is reflected in the next diagram.

Bank Selection Considerations

In order to know which payment flow to use, you’ll need to know which bank the customer intends to use and which of the two flows the user-selected bank supports. As the business/merchant, it’s up to you decide how the PSU makes their bank selection in accordance with your particular UX/UI framework.

You should first determine which set of bank features you support. You can generate a list of banks that support the features you choose to support by calling the SDK’s getBanks method and setting the bankFeatures parameter for the features you need. You can also call the getBanks method with the bank_id of the PSU-selected bank for information about that specific bank (found in the Bank object).

The following fields may also be useful in determining which banks and payment flows to use:

• requires_one_step_payment – If a bank supports the bank-initiated payment flow, this bankFeatures field will be set to true. If not true, this bank supports the business/merchant-initiated flow.

• requires_source_account – If a bank requires you to capture the PSU’s source account number, this bankFeatures field will be set to true.

Note: The information provided here is preliminary, indicating changes to come. Actual changes and their impact will be communicated upon the updated SDK’s release to production.

At this juncture, the respective flows can be enumerated as follows.

Auth PLUS Transfer Initiated Payment Flow

In concert with the diagram above, the steps comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

   Important: If you are responsible for payment confirmation — and the source account number is rerquired by the PSU-selected bank — it is up to you to capture the source account number from the PSU in your UI.

2. The business/merchant creates and stores the token request, specifying the amount, currency; conditionally specifying the debtor name; the bank_id, and (optionally) the source account number.

3. Token returns the request_id.

4. The business/merchant requests the bank authorisation URL from Token.

5. The business/merchant then redirects the PSU to the bank authorisation URL.

Note: Should the source account number be required by the user-selected bank, you can capture the source account number from the PSU in your UI. Token will display it on the payment confirmation page (pictured below) of the Token web app. If you did not capture the source account number, Token will present the PSU with an empty text box on the payment confirmation page where they must enter their source account number before continuing.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token returns token_id in a callback to the business/merchant.

3. Business/merchant redeems the token.

4. If transfer token redemption is successful redeemed, the business/merchant receives a transfer_id.

Note: At this point, the payment is complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns the updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Auth AND Transfer Initiated Payment Flow

In concert with the diagram above, the steps for this flow comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

   Important: If you are responsible for payment confirmation — and the source account number is rerquired by the PSU-selected bank — it is up to you to capture the source account number from the PSU in your UI.

2. The business/merchant creates and stores the token request, specifying the amount, currency, debtor name, bank_id and, optionally, country.

3. Token returns the request_id.

4. The business/merchant requests the bank authorization URL from Token.

5.The business/merchant redirects the PSU to the bank authorisation URL.

Note: Should the source account number be required by the selected bank, you can capture the source account number from the PSU in your UI. Token will display it on the payment confirmation page (pictured below) of the Token web app. If you did not capture the source account number, Token will present the PSU with an empty text box on the payment confirmation page where they must enter their source account number before continuing.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token sends the the transfer_status and transfer_id in a callback to the business/merchant.

Note: The payment is now complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns an updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Use Case #3: I use my own licence, and I manage bank selection and my own consent pages

Important: If this use case does not apply to you, please select the one that does.

Overview

For some banks, the business/merchant must confirm payment initiation after the PSU has authenticated with their bank. This is called the Auth Plus Transfer Initiated Payment Flow or 2-step paymnts and is reflected in the following diagram.

Other banks automatically initiate payment after the PSU is authenticated by the bank. This is called the Auth AND Transfer Initiated Payment Flow or 1-step payments and is reflected in the next diagram.

Bank Selection Considerations

As the business/merchant, it’s up to you decide how the PSU makes their bank selection in accordance with your particular UX/UI framework.

You should first determine which set of bank features you support. You can generate a list of banks that support the features you choose to support by calling the SDK’s getBanks method and setting the bankFeatures parameter for the features you need. You can also call the getBanks method with the bank_id of the PSU-selected bank for information about that specific bank (found in the Bank object).

The following fields may also be useful in determining which banks and payment flows to use:

• requires_one_step_payment – If a bank supports the bank-initiated payment flow, this bankFeatures field will be set to true. If not true, this bank supports the business/merchant-initiated flow.

• requires_source_account – If a bank requires you to capture the PSU’s source account number, this bankFeatures field will be set to true.

Note: The information provided here is preliminary, indicating changes to come. Actual changes and their impact will be communicated upon the updated SDK’s release to production.

At this juncture, the respective flows can be enumerated as follows.

Auth PLUS Transfer Initiated Payment Flow

In concert with the diagram above, the steps comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

   Important: If you are responsible for payment confirmation — and the source account number is rerquired by the PSU-selected bank — it is up to you to capture the source account number from the PSU in your UI.

2. The business/merchant creates and stores the token request, specifying the amount, currency, debtor name, bank_id and, optionally, the debtor account.

3. Token returns the request_id.

4. The business/merchant requests the bank authorisation URL from Token.

5. The business/merchant then redirects the PSU to the bank authorisation URL.

Note: Should the source account number be required by the selected bank, you must capture the source account number from the PSU in your UI.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token returns token_id in a callback to the business/merchant.

3. Business/merchant redeems the token.

4. If transfer token redemption is successful, the business/merchant receives a transfer_id.

Note: At this point, the payment is complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns the updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Auth AND Transfer Initiated Payment Flow

In concert with the diagram above, the steps for this flow comprise:

1. The PSU initiates the payment on the business’/merchant’s website.

   Important: If you are responsible for payment confirmation — and the source account number is rerquired by the PSU-selected bank — it is up to you to capture the source account number from the PSU in your UI.

2. The business/merchant creates and stores the token request, specifying the amount, currency, debtor name, bank_id and, optionally, the debtor account.

3. Token returns the request_id.

4. The business/merchant requests the bank authorization URL from Token.

5.The business/merchant redirects the PSU to the bank authorisation URL.

Note: Once again, should the debtor account number be required by the selected bank, you must capture the account number from the PSU in your UI.

1. PSU is taken to bank URL to authenticate and confirm payment.

2. Token sends the the transfer_status and transfer_id in a callback to the business/merchant.

Note: The payment is now complete.

1. Business/merchant calls getTransfer to determine the status of the transfer.

2. Token returns an updated transfer status.

3. The business/merchant displays the transfer status to the PSU.

Copyright © 2019 Token, Inc. All Rights Reserved