Getting transactions

This feature of the API is the corner stone of any integrator’s implementation, as it allows to retrieve the transactions for all the accounts linked to a given user.

Key concepts

Asynchronous API

The Accounts API is asynchronous, meaning if you call this endpoint, it will not act as a passthrough to the bank to existing transactions in real-time. Instead, you will retrieve the transactions we have at our disposal in our database at the moment of your request.

User Centric API

The Accounts API is user centric, which means that every connection, and it’s subsequent transactrions, are inevitably related to an user. Without creating an user, a connection cannot be created. On the contrary, if an user is deleted, the connection that is related to it is deleted as well, along with all it’s subsequent transactions.

Retrieving transactions with dedicated enpoint

Data format and filtering

For performance reasons, the number of transactions you can request at once is limited to 500 (100 being the default value).

When calling the endpoint GET transactions, the transactions in the response are :

• Paginated (Read more about the pagination)
• Sorted by import date ascending
• Then by ID Descending

Transactions can be filtered with various criterias, such as :

• The status (Parameters ‘included_statuses' or 'excluded_statuses')
• The amount (Parameters ‘amount', or 'min_amount', or 'max_amount')
• Account types (Parameter ‘account_type')
• Etc.

The full list of parameters is available here

Synchronisation : on demand vs. automatic By default, Linxo Connect performs a daily synchronization but it can also be performed on demand through the API.

Balance types and transaction statuses

How the banks are computing the balance

A bank can compute the balance in 2 ways :

• Instant Balance : takes into account all the executed transactions, whether they are accounted or not. This excludes the so-called "planned" transactions, or the transactions not executed yet (scheduled transfers, monthly direct debits, etc.)
• Book Balance: takes into account only the so-called "booked" transactions. This excludes, among others, checks cashed but not yet deposited on the account, "scheduled" transactions and card balances.

Balance Types in the API

In the current version of the STET APIs, there are 3 balance types:

• CLBD = closing booked (Book Balance)
• XPCD = expected (Instant Balance)
• OTHR = other (should only be used for CARD accounts (accounts materialising credit cards)

This information can be retrieved on the endpoint GET /accounts

Transaction Statuses in the API

The most used statuses are :

• BOOK = booked (accounted transactions)
• PDNG = pending (unrecorded transactions impacting the instantaneous balance)
• OTHR = other (unrecorded transactions with no impact on the balance)

These statuses can also be retrieved :

• EXPIRED - Authorization expired. This status is not part of the STET API.
• REJECTED - The transaction was rejected. This status is not part of the STET API.
• CANCELLED - The transaction was cancelled. This status is not part of the STET API.
• REFUNDED - The transaction has been refunded. This status is not part of the STET API.

✅ Link between balance types and transaction statuses

Transaction status	Included in CLBD balance	included in XPCD balance
BOOK	✅	✅
PDNG	❌	✅
OTHR	❌	❌

Transaction types

The different transaction types returned by the API are as follows ;

• CREDIT - Default type when it is not possible to determine the type of a revenue entry.
• DEBIT - Default type when it is not possible to determine the type of a disbursement of money.
• INTEREST - Interest on a bank account.
• DIVIDEND - Payment of a company to its shareholders.
• BANK_FEE - Fees on a bank account.
• DEPOSIT - Deposit of money in an agency.
• ATM - Withdrawing money from an ATM.
• POINT_OF_SALE - Payment with a credit card.
• CREDIT_CARD_PAYMENT - Month-end debit on a deferred card.
• INTERNAL_TRANSFER - Transfer of money between two bank accounts of the same connection.
• POTENTIAL_TRANSFER - Default type when it is not possible to determine the source or destination of a transfer.
• CHECK - Transaction made by check.
• ELECTRONIC_PAYMENT - The transaction is a documentary collection.
• CASH - Transaction carried out using a physical currency (notes and coins).
• DIRECT_DEPOSIT - Deposit of money made by a payer directly into the payee's bank account.
• DIRECT_DEBIT - Transaction in which one person (or company) withdraws funds from another person's bank account.
• REPEATING_PAYMENT - Recurring direct debit.
• OTHER - When a transaction does not correspond to any of these types.

Transactions history

Differences between Webscraping and DSP2 API

The way our system retrieves the transactions available on the bank side depends on :

• The canal on which the transactions are retrieved (Webscraping or DSP2 API).
• If using the DSP2 API : the number of transactions the banks API allows to retrieve.

Tipically, when synchronizing via Webscraping (or Embedded), our system tries to retrieve all the transactions available on the banks website interface. In consequence, the average transactions history may vary from a bank to another.

On the other hand, the DSP2 API (or Redirect) canal strictly depends on the banks APIs specifications. In the case of a new connection (after the SCA has been performed), some banks may allow the TPPs to retrieve transactions that occured during the last 13 months, whereas some other allow access for only 90 days. For documentation purposes, we have listed the maximum history depth for various banks groups in the table below :

Maximum History Depth via DSP2 API | Bank | Maximum Depth | | ------ | ------ | |Crédit Agricole|13 months| |BNP|13 months| |BRED|2823 days| |SG|396 days| |LCL|90 days| |CM Arkéa Group|365 days| |CIC-CM Group|184 days| |Caisse d'Epargne|90 days| |Boursorama|360 days| |Amex|90 days| |Qonto|No limitation| |Manager One|No limitation|

Limitations

The vast majority of the banks do not update their transactions in real-time. As a consequence, our system is retrieving the bank transaction only once a day. This automatic process starts around 4AM (Paris Time) and finishes before noon. Thus, we do advise our partners to use the Webhook mechanism in order to be informed as soon as soon as new transactions are made available by the banks.