General Information #
The Consent registration for using 10n Payments accounts goes through three steps.
Step 1: API INPUT Parameters
The application should send a request for consent registration of 10n payments account (IBAN, currency), for which operations the consent will be valid – detailed information, balance, transactions, as well as data on when the consent is valid (validUntil respectively available the accounts specified in it, how many times a day (frequencyPerDay) can be accessed information about each account.
Step 2: Consent Authentication by the customer
The customer authenticate via his operational SCA App that he allow his 10n payment’s account to be used in TPP/AISP.
IMPORTANT: Wallet and Strong Customer Authentication Apps are paired with the mobile phone number provided by the customer during onboarding. Based on this phone number connected to the customer’s IBAN, PSD2 HUB Calls the 10n Payment SCA Engine to authenticate the customer.
NOTE: If this does not happen within a defined time interval relative to the registration, the content is marked as Rejected, and the accounts on it are not available. The time is currently set on 20 minutes.
STEP 3: Generate CONSENT ID in PSD2 HUB
Based on the REQUEST provided in STEP1, and after successful authentication, PSD2 HUB generate the consent ID and provides the ID to the TPP/AISP in RESPONSE to the REQUEST in STEP1.
Based on consent ID TPP/AISP can check its status and detailed information. The consent statuses now are:
- Received
- Valid
- Rejected
The characteristic of PSD2 is that each registered consent is accessed through a unique ID generated by the server-side of the PSD2 implementation – all accounts, accounts, payments first pass phase registration, then authorization phase and finally can be used through this ID.
In addition, each PSD2 API reference must carry a unique reference number in an X-Request-ID header, with the answer echoing in the same header. In case of an error in the response body, there may be a JSON with the error text, for example:
{
"code": 404,
"description": "There is no consent with that ID!"
}
End-point url
#
http://[ip]:[port]/psd2/v1/consents
Method: POST
HEADERS #
- X-Request-ID = [request-id]: Required header, a unique request ID (GUID).
- Content-Type: application/json: Required header.
- PSU-ID: [user-id]: User identifier received upon login, required.
Request #
{
"access": {
"balances": [
{
"iban": "BG53TEPJ401310010XXXXX",
"currency": "BGN"
}
],
"transactions": [
{
"iban": "BG53TEPJ401310010XXXXX",
"currency": "BGN"
}
],
"accounts": [
{
"iban": "BG53TEPJ401310010XXXXX",
"currency": "BGN"
}
]
},
"validUntil": "2020-01-01",
"frequencyPerDay": "4"
}
Response
#
{
"consentStatus": "Received",
"consentId": "697e95aa-8508-4bba-8efc-1e3259a763f4",
"_links": {
"self": {
"href": "/v1/consents/697e95aa-8508-4bba-8efc-1e3259a763f4"
},
"status": {
"href": "/v1/consents/697e95aa-8508-4bba-8efc-1e3259a763f4/status"
},
"startAuthorisationWithPsuAuthentication": {
"href": "/v1/consents/697e95aa-8508-4bba-8efc-1e3259a763f4/authorisations"
}
}
}
Remarks #
The account/IBAN to be registered can appear in one of the three lists of accounts: balances, transactions, and accounts. Presence in one of the three lists indicates valid transactions with that account – respectively – balance inquiry, transaction list, and account detail information. If an account appears in balances and/or transactions – it means that it is implicitly included in the list for detailed information – accounts.
ConsentId field should be sent as header Consent-ID value in subsequent operations with this consent – authentication, status etc.
self – link for detailed information in GET request for this consent, then the links for accessing the resources/accounts themselves are displayed (accounts are accessed not by IBAN, but by their generated IDs for this consent)
status – link to get the status of the consent.
startAuthorisationWithPsuAuthentication – basic link for authentication of the account.
Snippet #