Fetch and upate transactions

There are 2 relevant use cases for fetching and updating transactions. These are

  1. fetching transactions for a one-time assessment, and
  2. fetching and updating transactions for an on-going service.

This integration guide helps you to do either in the most efficient way to minimise authentication while optimise for retrieval of transaction data.

Fetch transactions

There are different approaches to fetch the transactions of one or multiple accounts.

  1. If you want transactions from only 1 particular account (assuming the user has one or multiple to choose from) then we suggest to use a single transaction flow.

  2. If you want transactions from multiple accounts (potentially all accounts the user has access to) then we suggest to start with an accounts flow and iterate over the accounts which have the flag capabilities.transactions.available set to true with the transaction flow.

Both approaches will get you as much transaction data as possible. This means, if you plan to update the transactions after that, we recommend to then update only the last few days in any subsequent request.

In this integration guide we will focus on the 2. approach.

Update transactions on a regular basis

NOTE: The consent_id and consent_token are required for updating transactions.

For updating transactions it is noteworthy to think of the right time span to update. Typically a transaction is processed within 1 to 3 business days. This means you get most newly added transactions if you request the last 3 business days. Since there are exceptions which can take longer it can be beneficial to update the last 7 days on private accounts and the last 90 days on business and/or corporate accounts.

Consent requests are error prone and we recommend to have a look at our guide to avoid early consent invalidation.

Change of the transaction_id for already processed Transactions

There can be cases where an already processed transaction changes in its attributes, e.g. reference or counter_party. For example a credit card transaction for a car rental is listed as processed but is only fully processed 2 weeks after it was first listed. This will likely result in a new transaction_id.

If you update the transaction history and come across a new transaction_id in a date range you previous already processed then this can either be

  1. a newly processed transaction or
  2. an already processed transaction with a changed transaction_id.

Identify potential Duplicates (case 2)

The best way to distinguish between these two cases is to compare the apparently new transaction with already processed transactions on your side from the same day (transaction.date).

Say you compare the new transaction (new) with an existing transaction (existing) from the same day based on the

  • recipient (counter_party.iban),
  • amount (amount.amount), and
  • bank references (bank_references.*).

If new.recipient equals existing.recipient and new.amount = existing.amount but the transaction_id is different the transactions might still be the same. This follows the idea that a transaction on the same date to the same recipient for the same amount is rather unlikely. You can further compare new.bank_references with existing.bank_references and search for a match amongst the 3 different types of references (note: not all types are always available). If that is the case you can almost certainly say that new is an already existing transaction with a changed transaction_id. We recommend to transform any reference into lower case and remove white-spaces before comparing them.

Therefore you should replace or merge the existing transaction with the new transaction.

Why doesn't Klarna provide consisent transaction_ids?

Banks do not always provide consistent ids for their transactions and so we try our best to compensate for that by generating a transaction_id. But since we don't store transaction data, we can't compare them across requests, sessions or consents. The transaction_id we provide is generated on-the-fly and mostly based on the transaction.reference and therefore changes if the reference changes.

results matching ""

    No results matching ""