Network status and business status are separate integration states. A request can time out after the receiving system has committed a transaction, while a successful HTTP response can contain a rejected business result. The integration preserves enough identity and evidence to distinguish these cases.
Last reviewed: 2026-08-10
Use the request and transaction identifiers defined by the project specification. The same business operation keeps its original identity across client retries and timeout recovery.
For each money-changing operation, preserve:
- the merchant-side business identifier;
- the API request or trace identifier;
- the platform transaction and game-round identifiers when returned;
- request time, response time, and the final known state;
- the balance or ledger effect that the system accepted.
Exchange operational evidence through the designated support path with sensitive fields redacted. Diagnostic logs should retain only the time, result code, trace identifier, and masked business identifiers needed for investigation; do not record keys, full signatures, tokens, player details, or complete transaction payloads.
These controls must be confirmed in the final project protocol and tested before production. This public guide does not state that the server has already enabled them:
- define the accepted timestamp skew, require nonce uniqueness, and reject expired or replayed requests;
- authorize endpoint, wallet, player, and record access at the merchant boundary;
- set rate, concurrency, pagination, and transaction-value limits with observable alerts;
- keep signing keys in the designated server-side secret store and separate test from production credentials;
- test expired timestamps, reused nonces, concurrent duplicates, unauthorized access, and limit enforcement.
An integration should distinguish at least these outcomes:
| Outcome | Safe next question |
|---|---|
| Request was rejected before processing | Is the error retryable after correcting the input or configuration? |
| Request succeeded with a known business result | Has the result been recorded exactly once in the local ledger? |
| Request timed out or the connection failed | Can the original state be queried before any retry? |
| Callback was repeated | Return the previous result and apply the transaction exactly once. |
| Records disagree | Which system owns the authoritative record, and what evidence is needed to escalate? |
A blanket automatic retry is unsafe for money movement. Define retry behavior by operation and known state:
- Preserve the original business identity.
- Check whether the original result is already known locally.
- Use the configured query or reconciliation path for uncertain outcomes.
- Retry only when the protocol and current state allow it.
- Escalate rather than guessing when two authoritative-looking records disagree.
The merchant ledger, wallet transaction records, game records, and callback logs answer different questions. Reconciliation should compare them using stable identifiers and a bounded time range, then record both the difference and its resolution.
A useful reconciliation report includes counts and amounts by final state, unresolved identifiers, the oldest unresolved time, and the owner of the next action. Credentials remain in the secret store, and player data is minimized.
- Send the same business operation more than once and verify one business effect.
- Interrupt the client after submission and recover the original transfer outcome under the same business identity.
- Delay or repeat a wallet callback and verify the returned result remains consistent.
- Reject an operation for insufficient or invalid state and confirm that the ledger remains unchanged.
- Compare the game record, wallet record, and merchant ledger for a bounded test session.
- Exercise the agreed manual fallback and escalation route.
Add these scenarios to the integration checklist before launch review.