Account information 1.4.2
OverView
The Accounts API enables you to get the payment accounts that are eligible for the relevant Arkea Payment Service User (PSU) and retrieve transaction history and real-time balances from the Arkea payment service user.
Test It !
The sandbox page describes how to obtain an access-token for a particular use case. Once you have the access-token you will be able to quickly test the API in the API Reference section below.
- Under "API Reference" , expand the endpoint description you want to test and click on “Try it out”
- Fill the fields of the request and body (if any)
- the access-token has to be specified in the Authorization header (Bearer scheme)
For instance : "Bearer ygzVxruT52IkFZw5GOAYAq82ZFaH" - Signature and X-Request-ID headers are not used out of the production mode and they won’t be any in the response
But because the header is specified as "required" in OpenAPI specification you will have to specify any value
- the access-token has to be specified in the Authorization header (Bearer scheme)
- Click on “Execute” to send the request
The API can off course be used with same access-token outside this page with or without a mutual TLS connection.
Go Live !
The production mode is available, you can see how it works here
Functional details
Functional details
STET version compatibility: 1.4.2
Extended transaction history is not yet supported, i.e. history including transactions older than 90 days.
There is no technical incremental identification of the transaction (entryReference) displayed in the transactions endpoint.
Only Accounting Balance (CLBD) and Instant Balance (XPCD) are reported in the balances endpoint.
On GET/../transactions request, the field afterEntryReference is optional and will not be supplied.
Only the REDIRECT approach (app2web) is implemented at this stage.
A page query parameter has been added to transactions route.
It specifies the value of the fragment of result.
When using query parameters dateFrom and dateTo: dateFrom=2022-06-27T00:00:00
Only the date is taken into account (we do not take into account hours or seconds);
Date defines on dateFrom and dateTo query parameters is the transactionDate of the transactions;
You cannot search from a range of transactions defined in the past and in the future, in this case you should use one request to get past transactions and a second one to get future transactions.
When searching in past transactions, you can not use the parameter DateTo alone, you must specify also the DateFrom parameter
When searching in futur transactions, only the parameter dateTo is supported, when using dateFrom parameter, the service will respond a 400