PSD2 Test Bank
The main purpose of the PSD2 test bank is to enable the testing of the three different SCA methods embedded, decoupled and redirect.
In addition it supports the management of the consent that is returned after a successful login to test the Consent-API.
To access the PSD2 test bank in the playground environment select Demo Bank in the bank search. In the "bank login method" selection, choose Demo Bank PSD2.
PSU: The payment service user, the consumer who is owning the bank account.
SCA: Strong customer authentication that requires the PSU to enter data from a second device or communication channel.
OTP: One time password that is required to sign or approve a transfer or a consent, often via an additional SCA.
Bank Login Keywords
The keywords below can be used during the bank login of the PSD2 test bank. Everything else that does not match a specific keyword, will start an embedded happy-case.
Embedded Flow
Entering the following values as a username in the bank login step instructs the underlying systems to execute different scenarios that can happen at banks for embedded SCAs:
| Username | Functionality |
|---|---|
| acin-demo-data | will return more and realistic looking transaction data in the transaction call |
| bank-technical | will pretend that there was a technical error on the bank side |
| bank-maintenance | will pretend that the bank is currently in maintenance mode |
| configuration-expected | will pretend that the user's account is not properly configured |
| embedded | will ask for an OTP in the next step |
| invalid | will present the current form again and shows a form validation error |
| invalid-transactions-timerange | will pretend that the requested timerange is not supported |
| slow | will force all requests to be very slow |
| technical | will pretend that there was a technical error |
| validate-ip | will throw an exception if the provided IP adress was not valid |
| validate-ip-no-v6 | will throw an exception if the provided IP adress was not valid or a IPv6 was provided |
| wrong | will pretend that the credentials were wrong and a login to the bank was denied |
Decoupled Flow
Entering the following values as a username in the bank login step instructs the underlying systems to execute different scenarios that can happen at banks for decoupled SCAs:
| Username | Functionality |
|---|---|
| decoupled | will start a decoupled SCA with state PROCESSING and automatically completes the authorization request after a random amount of polls |
| decoupled-abort | will start a decoupled SCA and automatically fails the authorization request with a recoverable user error of type login after a random amount of polls |
| decoupled-failed | will start a decoupled SCA and automatically fails the authorization request with a unrecoverable bank maintenance error after a random amount of polls |
| decoupled-loading | will start a decoupled SCA that automatically completes the authorization request after a random amount of polls and slow followup requests |
| decoupled-long | will start a decoupled SCA with state PROCESSING and automatically completes the OTP request randomly after at least 4 polls |
| decoupled-transfer | will start a decoupled SCA for a subsequent transfer flow as the very first step (=> transfer flow immediately returns state PROCESSING) |
| decoupled-transfer-from-account-in-get | will start a decoupled SCA similar to "decoupled-transfer", with the key difference being no "from" account object returned in the first payment confirmation. To get the "from" account, a followup GET payment call needs to be performed |
| decoupled-transfer-impossible-delete-{STATE} | will start a decoupled SCA with an extended polling duration. If you attempt to delete the payment during polling, the delete will fail with a PAYMENT_WRONG_STATE exception, or PAYMENT_WRONG_STATE_REJECTED if {STATE} is rejected. Replace {STATE} in the username with one of the following transfer states which will be returned from get payment calls after the delete attempt: completed-debtor, completed-creditor, authorized, created, canceled, rejected |
Redirect Flow
Entering the following values as a username in the bank login step instructs the underlying systems to execute different scenarios that can happen at banks for SCAs with redirection to the bank's website:
| Username | Functionality |
|---|---|
| redirect | will start a redirect SCA with state CONSUMER_INPUT_NEEDED + type redirect and an URL that points to the Klarna demo bank |
| redirect-next | will start a second redirect SCA after the first one is canceled on the Klarna demo bank (result=canceled) |
| redirect-transfer | will start a redirect SCA for a subsequent transfer flow as the very first step (=> transfer flow immediately returns state CONSUMER_INPUT_NEEDED + type redirect) |
| redirect-twice | will trigger two subsequent redirect flows without any PSU interaction in-between |
| redirect-form | will start a redirect SCA followed by an embedded SCA (form) to complete the authorization |
| redirect-decoupled | will start a redirect SCA followed by a decoupled SCA to complete the authorization |
Consent
Entering the following values as a username in the bank login step instructs the underlying systems to control the consent that is returned by the PSD2 test bank:
| Username | Functionality |
|---|---|
| create-valid-consent | will create a full consent, the default consent is missing some fields which are often not available for real banks, like the PSU-id |
| create-invalid-consent | will create an invalid consent that triggers an error on subsequent calls towards the Consent-API |
| create-payment-with-tokens | will return a transfer_token and a transfer_id which can be used to fetch the current state of a payment via the consent transfer-state API |
OTP Keywords
The keywords below can be used during the OTP approval of the PSD2 test bank, e.g. for a second SCA to sign a transfer. Everything else that does not match a specific keyword, will start an embedded happy-case.
Entering the following values as an OTP in the OTP step instructs the underlying systems to execute different scenarios that can happen at banks. These values are mainly a subset of the keywords that can also be used for the bank login:
| OTP | Functionality |
|---|---|
| wrong | will pretend that the OTP was wrong and the transfer won't be signed |
| invalid | will present the current form again and shows a form validation error |
| remit-denied | will pretend that the transfer amount exceeds the available amount on the bank account (=> user error) |
| decoupled | will start a decoupled SCA with state PROCESSING and automatically completes the OTP request after a random amount of polls |
| decoupled-long | will start a decoupled SCA with state PROCESSING and automatically completes the OTP request randomly after at least 4 polls |
| decoupled-abort | will start a decoupled SCA and automatically fails the OTP request with a recoverable user error of type login after a random amount of polls |
| decoupled-failed | will start a decoupled SCA and automatically fails the OTP request with a unrecoverable bank maintenance error after a random amount of polls |
| redirect | will start a redirect SCA for the OTP with state CONSUMER_INPUT_NEEDED + type redirect and an URL that points to the Klarna demo bank |