A timeout is an uncertain outcome
An integration can lose the response after a system accepts work. Creating a fresh request at that point can record the same activity again. A useful retry policy keeps the original identity, records the observed outcome and gives the operator a way to investigate uncertainty. Apply the policy separately to the ledger request and the external payment instruction.
The Ledger Rocket approach
Ledger Rocket financial events have idempotent identifiers. Its posting path handles a repeated financial request through that identity, while a newly accepted event’s posting set commits as one atomic result. Your source mapping must keep the identifier stable across retries of that request.
Work through these cases
- Submit the same request again and check both the event outcome and account balances.
- Test a lost response and a concurrent repeat from the integration.
- Verify that a genuinely new transaction receives a distinct identity.
Discuss your flow
Bring the integration’s timeout and retry rules. Follow one request from the source reference to the ledger identifier and verify the balance after each attempt.
Book a demo