Use Case #3: As a TPP, I use my own licence, and I manage bank selection and my own 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.

Bank Selection Considerations

As the business/merchant, it's up to you decide how the customer 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 customer-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 (2-step).

  • requires_source_account – If a bank requires you to capture the customer’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 customer initiates the payment on the business/merchant website.

    Important: If you are responsible for payment confirmation — and the source account number is required by the customer-selected bank — it is up to you to capture the source account number from the customer 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.

    Note: Here, the business/merchant can choose to receive the bank authorisation URL directly from the bank. This option can be configured for you by Token on request.

  5. The business/merchant creates redirect URL with request_id for bank authorisation and redirects the customer.

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

  6. The customer is taken to bank URL to authenticate and confirm payment.

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

  8. Business/merchant redeems the token.

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

    Note: At this point, the payment is complete.

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

  11. Token returns the updated transfer status.

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

    Important: If you are responsible for payment confirmation — and the source account number is required by the customer-selected bank — it is up to you to capture the source account number from the customer 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.

    Note: Here, the business/merchant can choose to receive the bank authorisation URL directly from the bank. This option can be configured for you by Token on request.

  5. The business/merchant creates redirect URL with request_id for bank authorisation and redirects the customer.

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

  6. The customer is taken to bank URL to authenticate and confirm payment.

  7. Token sends the transfer_id and transfer status in a callback to the business/merchant.

    Note: The payment is now complete.

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