A browser success page is not a complete payment reconciliation.
Request retries and duplicate notifications need separate controls.
Resolve an unknown result before starting a new payment attempt.
Technical procurement guidance. Stripe documentation illustrates interface behaviours; it is not a recommendation of Stripe for gambling or evidence that a provider accepts a particular business or market.
Payment acceptance scenarios
| Scenario | Action | Evidence required |
|---|---|---|
| Duplicate success notification | Deliver the same confirmed €50 event twice | One eligible €50 wallet credit; duplicate recorded without a second credit |
| Unknown request outcome | Interrupt the response after provider acceptance | Existing reference resolved; no uncontrolled second payment |
| Out-of-order notifications | Deliver a delayed earlier event after confirmation | State does not regress incorrectly; provider state can be reconciled |
| Reversal after confirmation | Process an authenticated reversal | Linked correction and consistent balance under the agreed reversal policy |
The correct accounting entries and availability rules depend on your product, contract and legal obligations; approve those before executing the test.
Give one payment a durable identity
Our starting design is an internal payment reference that connects the customer instruction, provider transaction, wallet journal entry and settlement line. Keep amount and currency immutable for that instruction. Distinguish a retry of the same instruction from a genuinely new customer payment. If the customer refreshes the page or support reopens a case, the same reference should reveal the existing outcome rather than silently creating a second money movement.
Ask what the provider actually guarantees
Stripe documents idempotency keys for supported API requests and explains that repeating a key returns the saved result once execution has begun. This is a concrete example of retry semantics, not a universal rule across providers. For the provider you are buying, obtain its key scope, retention window, parameter-mismatch behaviour and treatment of unsuccessful requests. Put those answers into the integration specification.
Treat event delivery as a separate problem
Stripe also documents duplicate webhook deliveries and says event delivery order is not guaranteed. Its guidance includes signature verification and tracking processed events. The operational lesson is to test the actual provider’s delivery contract. An idempotent outbound request does not automatically make an inbound notification handler, wallet posting or downstream reconciliation idempotent.
Model unknown as an explicit state
Suppose a €50 request times out after the provider has accepted it. A timeout says the caller did not receive a usable response; it does not establish that payment failed. In our proposed workflow, mark the result unresolved, query or reconcile the existing provider reference, and control retries according to the documented contract. Keep any player-facing message accurate while the state is unknown. Do not show spendable funds merely because the browser has returned to a success URL.
Reconcile at three boundaries
First compare provider-confirmed transactions with internal payment instructions. Next compare each eligible confirmed transaction with exactly one wallet journal effect. Finally compare provider settlement reports with the bank or settlement account, separately identifying fees, reserves, reversals and timing differences. These checks answer different questions. A balanced wallet does not prove that external cash settled, and a bank receipt does not prove that each customer was credited correctly.
Buy the exception workflow, not only the happy path
Before accepting an integration, run the scenarios below with the delivery team and finance owner. Capture IDs, timestamps, state transitions and evidence of the final balance. Set a reconciliation frequency and escalation target suited to the business, then measure unresolved counts and age. Restrict manual adjustments, document their reason and keep an audit trail. Confirm separately that the provider, funding method and proposed flow are permitted for the exact legal entity and market.
Sources and scope
Technical procurement guidance. Stripe documentation illustrates interface behaviours; it is not a recommendation of Stripe for gambling or evidence that a provider accepts a particular business or market. Sources reviewed 2026-10-18; check the linked originals for later changes.
Stripe API — Idempotent requestsStripe — Webhook delivery and verificationCompare the same requirements across suppliers and record evidence, tests and unresolved gaps. The editable workbook starts with no supplier results or approvals.
Get the free supplier evaluation worksheetThis educational guide is independent, free to access and designed as a practical starting point. Regulatory and legal requirements should always be confirmed with the relevant authority and qualified advisers.
Our evidence methodology