To be able to use your PSD2 license with the finAPI APIs, please refer to the necessary steps to register the certificate with us and complete the TPP registration of the banks to which you plan to connect.
For more information, please refer to Licensed customers
Pre-requisites
Step 1 - Create a payment
To initiate a SEPA Credit Transfer or SEPA Instant Credit Transfer, trigger Create money transfer endpoint. Provide IBAN to indicate the sender account.
POST /payments/moneyTransfers
There are some payment data validations that we recommend being implemented to avoid bank payment rejections. Please refer to Payment Data Validation.
Note: for Direct Debits initiation, please refer to Initiate a Payment from an Account - no Web Form (Licensed Customers Only) as standalone Direct Debit initiation is not supported.
Step 2 - Submit payment
Execute Submit payment service:
POST /payments/submit
The payload and the flow varies based on the SCA approach offered by the bank (in the API: properties of the bank interface (bank.interface.properties).
Some banks have implemented the Embedded SCA approach, where the user credentials and the second factor can be submitted to the bank via the TPP.
Some banks will require a redirect to the bank server to complete the authentication and second-factor verification, this is the so-called Redirect SCA.
Some banks allow authorization with the Decoupled SCA approach, where users could authenticate and authorize a transaction via the mobile app or an authorisation device.
The combination of different SCA approaches is also possible. For example Embedded + Decoupled: a user will provide the login credentials to a TPP and then a push notification will be sent to the mobile application.
Please make sure your application is able to dynamically handle all variations.
Please refer to the API specification for more details.
It is mandatory to indicate the interface that should be used for the payment submission.
If you are not familiar with the interfaces which are supported by finAPI, please check Interfaces .
Please see below the examples of the flows for each SCA approach: Redirect, Embedded and Decoupled.
Redirect approach
|
Step |
Request/response example |
|---|---|
|
Step #1
Mandatory request fields
Explanation The client application submits the payment along with the user bank credentials if they are required by the bank interface. |
|
|
Step #2
How to recorecognize step Field Mandatory response fields of
Explanation The API builds a redirect URL that will route the end-user to a page on the bank side, where the user can complete the authentication process. In this step, the client’s application should store values from |
|
|
Step #3
The client application should redirect the end-user to the given redirectUrl. Example
|
|
|
Step #4
When the end-user successfully completes the authentication process on the bank’s side, he is redirected to the URL given in step #1. Additionally, the bank adds some more data to the URL (as query parameters). But the most important part for the client application is this Example
|
|
|
Step #5
Mandatory request fields
Explanation The client application submits a query string as a value of
|
|
|
Step #6
The API completes the payment initiation process and returns a payment resource. |
|
Embedded approach
|
Step |
Request/response example |
|---|---|
|
Step #1
Mandatory request fields
Explanation The client application submits the payment along with the user bank credentials if they are required by the bank interface. |
|
|
Step #2
How to recognise the step Field Mandatory response fields of
Explanation If the bank decides, it responses with a list of available two-step procedures (aka SCA methods - Strong Customer Authentication methods). And then the client application should ask the end-user to choose one of the offered two-step procedures. |
|
|
Step #3
Mandatory request fields
Explanation The client application asks the end-user to choose a two-step procedure and then submits it to the API. Value of |
|
|
Step #4
How to recognise the step Field Mandatory response fields of
*Note: feel free to use the flicker code template prepared by finAPI: Flicker Code Template Explanation When the two-step procedure is chosen (either by the bank or by the end-user), the API responds with details for the end-user. The client application should show this info to the end-user and ask for an answer.
|
|
|
Step #5
Mandatory request fields
Explanation The client application asks for the challenge response and submits it back to the API. Value of |
|
|
Step #6
The API completes the payment initiation process and returns a payment resource. |
|
Decoupled Approach
|
Step |
Request/response example |
|---|
|
Step |
Request/response example |
|---|---|
|
Step #1
Mandatory request fields
Explanation The client application submits the payment along with the user bank credentials if they are required by the bank interface. |
|
|
Step #2
How to recognise the step Field Mandatory response fields of
Explanation If the bank decides, it responses with a list of available two-step procedures (aka SCA methods - Strong Customer Authentication methods). And then the client application should ask the end-user to choose one of the offered two-step procedures. |
|
|
Step #3
Mandatory request fields
Explanation The client application asks the end-user to choose a two-step procedure and then submits it to the API. Value of |
|
|
Step #4
How to recognise the step Field Mandatory response fields of
Explanation If the chosen two-step procedure was of a decoupled type, the API responds with this error. The client application should notify the end-user that the bank will send a notification. |
|
|
Step #5
Mandatory request fields
Explanation The client application asks the API to check the status of the authentication process. Value of |
|
|
Step #6
How to recognise the step Field Mandatory response fields of
Explanation The API returns this error if the authentication is still not completed on the bank side. The client application should continue repeating step #5 while the API returns this error.
|
|
|
Step #6
The API completes the payment initiation process and returns a payment resource. |
|
Step 3 - Get the Payment status (Optional)
If upon completion of the steps described in Step 2 above, the status of the payment initiation is still PENDING, there is a chance that the bank has not returned the final payment status yet or there was an error when trying to obtain the payment initiation status and several attempts will be made in the background to obtain it (for more details, please refer to How to get the payment initiation status).
You can call Get payments to obtain the latest payment status.
Step 4 - Delete User (Optional)
If for your use-case you do not need to save the user to re-use it later, we recommend that you delete the user once the payment initiation has been finalized via Delete the authorized user endpoint:
DELETE /users