Use Case #1: As a TPP, I use Token's licence, bank selection, and consent pages

Tip: If this use case does not apply to you and you wish avoid spending valuable time on something you won't use, please go back and select the use case that does apply to you. Remember, you can always return here later should your use case requirements change.

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 payments 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.

These respective flows can be enumerated as follows.

Auth PLUS Transfer Initiated Payment Flow

In concert with the diagram above, the steps comprise:

  1. The customer initiates the payment on your business/merchant 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 customer to the constructed token request URL. This takes the user to the Token web app.

    Note: If the country is specified in the token request, Token presents the customer with the Token web app's bank selection page, filtered by country. From the list displayed, the customer 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 customer 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 customer with an empty text box on the payment confirmation page, where they must enter their source account number before continuing.

  5. Customer is now redirected to bank URL to authenticate and confirm payment.
  6. Token returns token_id in a callback to business/merchant.
  7. Business/merchant redeems the token.
  8. Token sends the transfer_id to business/merchant.

    Note: At this point, the payment is complete.

  9. Business/merchant calls getTransfer to determine the status of the transfer.
  10. Token returns the updated transfer status.
  11. The business/merchant displays the transfer status to the customer.

Auth AND Transfer Initiated Payment Flow

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

  1. The customer initiates the payment on the business/merchant 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 customer to the constructed token request URL. This takes the user to the Token web app.

    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.

  5. Customer is now redirected to bank URL to authenticate and confirm payment.
  6. Token sends the transfer_id and transfer status in a callback to the business/merchant.

    Note: The payment is now complete.

  7. Business/merchant calls getTransfer to determine the status of the transfer.
  8. Token returns an updated transfer status.
  9. The business/merchant displays the transfer status to the customer.