Payment Platform (XS2A.pay)
With this platform, payments can be set up with one time access to the online bank account. You will also be able to take into account important risk and fraud criteria (so-called security check) which we can set individually based on your needs.
Tink Germany is acting as a purely technical service provider and will not be involved in the actual flow of money. The money is transferred directly from the users's bank account to the provider's designated receiving account.
At the initial call by the provider, the basic information of the payments (amount, currency, purpose, receiving account) to be executed on the online banking account is specified. The user is then requested to interact (login to online banking). After successful login, account selection and TAN entry by the user, if applicable, the security check is carried out and the SEPA Credit Transfer is then initiated in the background. As a result, a list of all successfully initiated transactions or details of individual transactions can subsequently be called up.
All authentication in our API is done via HTTP basic authentication.
HTTP
POST /v1/payments HTTP/1.1
Host: api.xs2a.com
Content-Type: application/json
Authorization: Basic base64("api:YOUR_API_KEY_GOES_HERE")
Cache-Control: no-cache
The first step is to configure a payment object that defines what our API needs to do in the process of the payment afterward.
HTTP
POST /v1/payments HTTP/1.1
Host: api.xs2a.com
Content-Type: application/json
Authorization: Basic base64("api:YOUR_API_KEY_GOES_HERE")
Cache-Control: no-cache
{
"amount": 35,
"currency_id": "EUR",
"purpose": "Order No. 123456",
"recipient_iban": "DE04888888880087654321",
"recipient_holder": "MyCompany Inc."
}
As result, you will get a
wizard_session_key and a transaction value. JSON
{
"wizard_session_key": "m5A65Cy2lwI1rOXxuvwU4MM47b4tDaV0ME9By6It",
"transaction": "10001-xv-LEz8-oct7"
}
You need to use these values in the next steps so you should store them in your system related to the user.
This step depends on the integration variant you want to use. In all variants, the
wizard_session_key and the transaction value is used later.After the payment is finished successfully you can retrieve information about the transaction from our API. Please note that some of this information is also provided in the webhook therefore this step is optional.
HTTP
cURL
GET /v1/payments/{transaction-id} HTTP/1.1
Host: api.xs2a.com
Content-Type: application/json
Authorization: Basic base64("api:YOUR_API_KEY_GOES_HERE")
Cache-Control: no-cache
You will receive detailed information about the payment.
JSON
{
"id": "xp_fSdkfjS2R2S5x1pu",
"transaction": "10001-xp-abcd-abcd",
"sender_holder": "Holder Customer",
"sender_iban": "DE62888888880012345678",
"sender_bic": "TESTDE88XXX",
"sender_bank_name": "Testbank",
"sender_country_id": "DE",
"recipient_holder": "Holder",
"recipient_iban": "DE62888888880012345678",
"recipient_bic": "TESTDE88XXX",
"recipient_bank_name": "Testbank",
"recipient_country_id": "DE",
"purpose": "Purpose",
"amount": 5,
"currency_id": "EUR",
"testmode": "1",
"payment_status": "RECEIVED",
"metadata": {},
"merchant_id": "",
"object": ""
}
In cases where you might have information about the reconciliation status of the transaction we kindly ask you to inform us via our manual overwrite status functionality for status lost and received.
Set to received
Set to lost
POST /v1/payments/{transaction-id}/received HTTP/1.1
Host: api.xs2a.com
Content-Type: application/json
Authorization: Basic base64("api:YOUR_API_KEY_GOES_HERE")
Cache-Control: no-cache
POST /v1/payments/{transaction-id}/loss HTTP/1.1
Host: api.xs2a.com
Content-Type: application/json
Authorization: Basic base64("api:YOUR_API_KEY_GOES_HERE")
Cache-Control: no-cache
We also offer a reconciliation service from our side, to get more information please follow the link below.
If you need to be sure, before a payment is initiated, that your user's name is also the same as the account holders name of the provided account, we can check the provided name against the account holder of the selected reference account in the bank connection. When making the request, only the first name and surname to be checked/validated must be provided. As a result, you will be informed whether there is a match or not.
The name matching logic is a combination of a precisely developed rule set in combination with an algorithm. It is sufficient if one of the requested first and last names are found as the account holder of the reference account. This means, for example, if a request is made with only one of the first and/or last names, a match can still be assumed for both individual accounts with several first names as well as for joint accounts.
Samples for a name matching :
first_name | last_name | account holder |
Maximilian Hartmut | Mustermann | Maximilian Mustermann |
Maximilian | Mustermann | Maximilian und Erika Mustermann Maximilian |
In some cases, it might be very important to match the full name very exactly. Therefore we offer additionally to the pinned holder name check log the "true match" functionality. This extends the pinned holder logic by a very strict decision taking, in particular for typos, letter turners and truncated names.
Last modified 1yr ago