We are aware of a known issue that may cause transaction_ids to change between requests for transactions.
Why does this happen?
TrueLayer generate unique transaction from a number of fields returned by the provider's API, including, but not limited to:
- Timestamp
- Description
- Amount
- The provider's internal ID
Unfortunately — due to factors outside TrueLayer's control — some of these fields are subject to change. This may happen for a number of reasons, including:
- Amendments to the provider's records, e.g. foreign exchange settlement or an adjustment
- Fraud prevention checks which may also amend a field
- Idiosyncracies of various legacy banking infrastructures
What are we doing about it?
TrueLayer have been working closely with all of our providers to identify fields that can be used to generate unique and immutable transaction_ids.
Where these fields are not available - we are advocating for improvements that will allow us to implement this in the future.
Providers that support immutable transaction_ids now return a normalised_provider_transaction_id field.
How should I handle this?
If the provider you're using does not support normalised_provider_transaction_id, the best way to avoid listing duplicates in your system is to overwrite previously cached transactions instead of merging them.
This solution also helps in cases where transaction_ids change from pending transactions to settled.