Banking is a complex process, with interactions taking place between many different systems. As part of this process, transactions go through different stages of progression until a final result is achieved (e.g. a purchase is attempted, one or more suppliers are queried, protective protocols are initiated, all of which resulting in a final approval or denial).

Theoretically, a transaction goes through a linear set of stages in order (e.g. authorization -> authentication -> settlement). In reality, although these stages are be processed in order, our system may receive updates on these stages out of order (e.g. a settlement is received before an authorization). Due to this, we employ a set of resolution protocols to resolve a "canonical transaction history".

When these protocols resolve a conflict:

• a new transaction is generated containing the canonical and accurate transaction data
• the conflicting transactions are marked as duplicates and deprecated
• the conflicting transactions have their canonical_transaction_id set to that of the new transaction

If a direct lookup is done for a duplicated transaction, you will receive a redirect to the canonical transaction. Note that there may be multiple redirections depending on how conflicts were resolved.

In the event that a conflict is unable to be resolved and a canonical transaction was not generated the incorrect transaction will be deprecated. When retrieving transactions, any deprecated transactions will not appear in the response list. If you do a direct lookup for a deprecated transaction you will receive the information regarding this transaciton, with the deprecated boolean flag set to true, and the status set to Deprecated.

FAQ

What happens when you request a deduplication?

Upon request we are able to complete a deduplication on individual cards or across your business. In this case, all existing transactions for the card or business are deprecated, and a new set of canonical transactions are generated with the correct data. The deprecated transactions are then matched to the canonical transactions if possible, with them being set as duplicate and redirecting to the new canonical transactions.

📘

Note that deduplications will treat all existing transactions as incorrect or duplicate. This may result in correct transactions being marked as duplicate/deprecated with their associated new canonical transaction containing the same data.