Our Apis

Account information

Overview

The Accounts API enables you to get the payment accounts that are eligible for the relevant Arkea payment service user and retrieve transaction history and real-time balances from the Arkea payment service user.

Test It !

The sandbox page describes how to obtain access token for a particular use case. Once you have 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) 
    • 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 of the response
      But because the header is specified as "required" in OpenAPI specification you will have to specify any value
  • Click on “Execute” to send the request

The API can off course be used with the 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

Implementation notes

STET version compatibility: 1.4.1.3 (partial - see below)

Extended transaction history is not yet supported, i.e. history including transactions older than 90 days.
There is no operation identification of the transaction (resourceId) displayed in the transactions endpoint.
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.

 [DECRECATED - Please use dateFrom and dateTo parameters] A negative option to the page query parameter has been added to transactions route:

  • This parameter is an add-on from STET specification and facultative. It uses as a reverse chronological order.
  • Negative value '-1’ is used to retrieve forecasted transactions for personal bank account and must not be used with parameter dateTo.

When using query parameters page for transactions:

  • This parameter is not availaible for forecasted transactions

When using query parameters dateFrom and dateTo:

  • 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 a single request, in this case you should use one request to get past transactions and a second one to get future transactions.
  • You cannot use the same date in dateFrom and dateTo (for a single request).
  • When searching in futur transactions, only the parameter dateTo is supported, when using dateFrom parameter, the service will respond a 400
  • Forecasted transactions are limited to 45 days for card operations. This parameter also get you loans, direct debits and bank transfers up to 5 days.

Change log

March 2019: sandbox delivery

API reference