The transaction id returned by the /transactions API is generated as a deterministic hash of selected fields from the bank's response. It is not stored — it is recalculated on every API call. This design ensures that the same underlying bank transaction consistently returns the same id, even if mutable or Token-generated fields (such as createdAtMs) change between fetches.
Known Limitation
Because the hash is calculated from a limited set of bank-provided fields, it is possible for two distinct bank transactions to share identical values across all hashed fields. When this occurs, the hash function produces the same id for both transactions.
In summary:
- The transaction
idis a transaction hash — stable for the same transaction, but not guaranteed to be unique across different transactions. - Adding additional fields to the hash (e.g.
amount) would change IDs for all previously-fetched transactions, breaking integrations that rely onidas a stable primary key. - Certain fields (e.g.
createdAtMs) are intentionally excluded because they are Token-generated rather than bank-sourced, and including them would introduce instability.
Workaround
If you encounter duplicate transaction IDs, we recommend implementing deduplicating logic using a composite key — combining the transaction id with one or more additional fields returned in the response.