A transaction hash identifies a submitted transaction. The backend still needs to confirm what happened before crediting a ledger or releasing an order.
While working on a multi-chain gateway, I kept returning to when each person can act on a payment state.
What each state needs to tell us
- The customer needs to know whether to wait or retry.
- The merchant needs to know whether to release the order.
- The backend needs verified evidence before updating the ledger.
- QA needs acceptance criteria for each transition.
Submission, confirmation, failure, and settlement need distinct meanings in the interface, webhook handler, and support process.
Detection and settlement
Client-side detection provides quick feedback when funds appear. Settlement requires a verified server-side signal, with checks for the network, token, recipient, amount, transaction status, and duplicate processing.
Acceptance criteria I would write
- Give each payment request a unique reference and expiry.
- Check the selected token and network before signing.
- Record the transaction hash without marking it settled.
- Define separate responses for delays, failures, and duplicates.
- Verify a webhook before it updates the ledger.
- Prevent retries from crediting the same payment twice.
The CryptoRails lifecycle note covers the documented deposit and consolidation flow. These are generalised requirements; internal details and performance results remain confidential.