· Protocolzone
When a platform calls an operator’s wallet, a timeout leaves an important question unanswered: did the debit fail, or did it succeed and lose its reply? Retrying both situations in the same way can create a second financial action.
Our wallet integration code treats that uncertainty as a separate state. This is an engineering account of the implemented design, not a published customer rollout or a claim about transaction volumes.
Record the instruction before dispatch
The gateway stores the instruction before making the external call. That gives recovery logic a record to inspect if the process stops while a request is in flight. Recording only the response would leave the most difficult case with the least evidence.
Guarded state updates distinguish work awaiting dispatch from work already sent. The implementation checks whether it acquired the right to act on that record before making the call.
Keep an uncertain debit distinct
For this wallet contract, an uncertain debit is not sent again automatically. It enters an unknown state and is handed to rollback handling. Credits and rollbacks have their own retry behaviour, with stable identifiers carried through the attempts.
The distinction depends on the remote wallet’s contract. A rollback needs a defined meaning even when the original response never arrived, and duplicate requests must have a defined response. These are integration requirements to agree with the wallet provider, not assumptions a retry library can settle.
Limit work by tenant
The implementation also bounds concurrent wallet calls separately for each tenant. A slow dependency consumes that tenant’s allowance instead of occupying all of one shared allowance.
This reduces one route by which a slow operator can affect others. It does not remove the need to size and monitor shared connection pools, memory and message processing capacity.
What this means for platform development
Multi-tenancy reaches beyond adding a tenant identifier to a table. It affects external calls, recovery state, concurrent work and operational responsibility. Those boundaries belong in the design of the platform and its integrations.
For a new integration, agree the outcomes before writing the happy path: success, explicit rejection, uncertain response, duplicate request and recovery after a restart. Then test the actual provider against that contract.
Discuss your platform integrations.
- multi-tenancy
- integration
- reliability