Buyer API acceptance pack

iGaming platform API integration checklist

A production acceptance framework for APIs that create player, payment, wallet, bonus, casino, sportsbook, control, and reporting effects. It tests what happens after a timeout or duplicate—not only whether a sample request returns 200.

Start the acceptance sequence Download acceptance CSV

10 control domains30 atomic requirements6 failure-aware outcome statesUpdated 2026-08-13

HTTP success is not business acceptance

The accepted result is the durable business state, its authoritative record, and its reconciliation—not a transport status. Every write must remain recoverable when the client never receives the response.

Integration acceptance sequence

Start with the business effect, finish with retirement

Run the same sequence for every decision-critical interface. Keep requirement IDs intact from supplier response through test evidence, exception, contract schedule, and production sign-off.

Step 1
Freeze the business operation
Name the player or financial effect, authoritative system, terminal states, legal entity, environment, and maximum uncertainty window before discussing endpoints.
Step 2
Contract message and state
Version schemas, identifiers, precision, time, enums, errors, idempotency, ordering, authorization, and outcome lookup as one contract.
Step 3
Inject transport failure
Test timeout, disconnect, duplicate, delay, reordering, throttling, dependency failure, process restart, failover, and restore.
Step 4
Prove business convergence
Compare both systems of record using independent control totals and resolve seeded breaks through replay or compensating entries.
Step 5
Validate production differences
Close every sandbox gap with a bounded production smoke, monitoring, go/no-go threshold, rollback, and evidence bundle.
Step 6
Contract change and exit
Set compatibility, notice, dual-run, deprecation, full and delta export, transition support, costs, and retirement proof before launch.

Outcome-recovery matrix

A client timeout creates uncertainty, not failure. The API must expose one of these business states by the original operation ID so the buyer can wait, retry, reconcile, or escalate without creating another effect.

Swipe horizontally to view all columns.

API business outcome, client action, and proof required after an uncertain request
Business state	Meaning	Safe client action	Required proof
Not received	The provider has durable proof that no operation was accepted.	A retry may reuse the same operation and idempotency key.	Lookup returns not received; no business or ledger record exists.
Processing	The operation is accepted but has no terminal business outcome.	Poll or await the documented event; do not issue a new operation.	Stable operation ID, bounded age, owner, and terminal-state path.
Succeeded	The operation and its exact business effect are durably committed.	Return the stored outcome on replay and reconcile downstream effects.	Original response, authoritative record, correlation, and control totals.
Rejected without effect	Validation, policy, or business rules rejected the operation before any effect.	Correct the request or stop; retry only when the stable error code permits it.	Stable error, field or rule, no-effect marker, and audit record.
Reversed or compensated	An effect occurred and a separate recorded action neutralized or changed it.	Consume both events; never rewrite the original outcome locally.	Linked original and compensating IDs, ledger effects, reason, and approval.
Unknown	The provider cannot yet establish whether an effect occurred.	Hold a second business action, escalate, and reconcile using the same operation ID.	Visible exception, accountable owner, investigation target, and repair path.

Atomic integration requirements

30 tests across 10 control domains

Each domain has a gate. An interface is not accepted when its happy path passes but the business outcome, recovery, evidence, or retirement path remains ambiguous.

Download CSV

Domain 01

Authentication and authorisation

Bind every machine and user action to a tenant, environment, purpose, scope, and revocable credential.

Gate: No shared production credential, unscoped token, or undocumented emergency bypass.

AU-01

Credential and token lifecycle

Document issuance, storage, exchange, lifetime, refresh, rotation, revocation, compromise, and emergency access for every credential type.

Accept when

Short-lived runtime tokens and separately controlled long-lived credentials can be rotated without code changes or service interruption.

Evidence

Sequence diagram, credential inventory, key-management policy, rotation and revocation output.

Fail when

A leaked credential cannot be revoked promptly or remains valid across tenants or environments.

AU-02

Least privilege and tenant isolation

Define scopes and resource checks for brand, market, product, account, operation, and support role.

Accept when

The same request is denied when any tenant, environment, role, or resource boundary is changed without permission.

Evidence

Scope catalogue, authorization matrix, negative-test output, privileged-access review.

Fail when

Possession of a valid token permits cross-tenant reads, writes, or administrative action.

AU-03

Request integrity and replay resistance

Protect sensitive requests with transport security and, where risk requires it, signed payloads, nonces, timestamps, and bounded replay windows.

Accept when

Tampered, expired, replayed, and wrongly targeted requests fail without a side effect and remain auditable.

Evidence

TLS and signing profile, clock policy, replay tests, rejection audit records.

Fail when

A captured request can be replayed or redirected to create another effect.

Domain 02

Contracts and versioning

Make compatibility a testable contract instead of an assumption attached to a URL version.

Gate: No production integration without machine-readable schemas and an explicit compatibility policy.

VR-01

Machine-readable contract

Publish request, response, event, error, enum, nullability, precision, timestamp, identifier, and pagination rules in versioned schemas.

Accept when

Generated validation rejects undocumented shapes and examples pass against the same schema used in CI.

Evidence

OpenAPI, AsyncAPI, JSON Schema or equivalent, examples, schema-validation output.

Fail when

A decision-critical field exists only in prose, a sample, or implementation behaviour.

VR-02

Compatibility classification

Classify additive, behavioral, enum, validation, precision, default, and removal changes and state which require a new version.

Accept when

The provider and buyer test the same compatibility rules, including unknown fields and unknown enum values.

Evidence

Compatibility policy, change examples, producer and consumer contract-test output.

Fail when

A nominally additive change can break a deployed consumer without notice.

VR-03

Consumer contract gate

Run provider schemas and representative payloads against every supported buyer consumer before release.

Accept when

A breaking producer change is blocked or enters an agreed migration path before production publication.

Evidence

Consumer inventory, contract-test matrix, CI result, approved exception and expiry.

Fail when

The provider cannot identify which deployed consumers a change may break.

Domain 03

Idempotency and outcome recovery

Ensure retries do not create another financial or player-state effect and clients can recover an uncertain result.

Gate: No financial write API without a stable operation identity and deterministic replay result.

ID-01

Stable operation identity

Define idempotency key ownership, scope, canonical request fingerprint, uniqueness, and conflict behavior per mutating operation.

Accept when

The same key and same request return the original outcome; the same key with a changed request is rejected.

Evidence

Contract fields, storage model, duplicate and conflict test output.

Fail when

A retry can produce a second debit, credit, wager, grant, payout, or account transition.

ID-02

Replay window and durability

Set outcome retention from the maximum client retry and dispute window, including behavior after archival, failover, and restore.

Accept when

The stored outcome survives node loss and restore for the full contracted replay period.

Evidence

Retention policy, replicated storage design, restore and late-retry tests.

Fail when

The idempotency record expires while the underlying transaction can still be retried or disputed.

ID-03

Unknown-outcome lookup

Provide a lookup by buyer operation ID when the client times out before receiving a terminal result.

Accept when

The client can distinguish not received, processing, succeeded, rejected, reversed, and unknown without issuing a blind duplicate.

Evidence

Operation-status contract, state machine, timeout recovery trace.

Fail when

A timeout forces the buyer to guess whether the transaction took effect.

Domain 04

Ordering, retry, and deduplication

Make asynchronous delivery converge under duplicates, delays, partition, and reordering.

Gate: No event consumer may depend on undocumented global ordering or exactly-once transport claims.

OD-01

Ordering domain

Name the entity or partition within which order is guaranteed and include event ID, aggregate ID, sequence, occurred-at, and emitted-at semantics.

Accept when

Consumers detect a gap or stale event and can hold, fetch, or reconcile rather than applying it blindly.

Evidence

Partition model, event schema, gap and out-of-order test output.

Fail when

Final state changes with transport delivery order.

OD-02

Bounded retry and backoff

Define retryable operations, attempt limit, exponential backoff, jitter, timeout budget, dead-letter path, and manual replay authority.

Accept when

A dependency outage does not create a retry storm and every exhausted item enters a visible owned queue.

Evidence

Retry policy, load test, dead-letter record, replay approval and audit sample.

Fail when

Retries exceed the end-to-end timeout, amplify load, or disappear after exhaustion.

OD-03

Consumer deduplication

Persist processed event identity and result for at least the provider's maximum redelivery and replay period.

Accept when

Duplicate delivery before and after consumer restart has no second business effect and returns the same acknowledgement.

Evidence

Dedup store design, retention, restart and replay test output.

Fail when

A consumer restart or replay resets duplicate protection.

Domain 05

Errors, timeouts, and rate limits

Let clients decide safely whether to correct, retry, wait, reconcile, or escalate.

Gate: No generic success or failure envelope that hides transaction state or retry safety.

ER-01

Stable error taxonomy

Separate validation, authentication, authorization, conflict, duplicate, dependency, capacity, timeout, and internal failures with stable codes.

Accept when

Every error code has side-effect state, retry safety, operator action, player-message boundary, and correlation ID.

Evidence

Error catalogue, example payloads, client handling tests.

Fail when

The client must parse free text or cannot tell whether an effect occurred.

ER-02

End-to-end timeout budget

Allocate connection, request, queue, dependency, and retry budgets inside the player-journey deadline.

Accept when

Client cancellation and server completion behavior are defined, and an uncertain write remains recoverable by operation ID.

Evidence

Timeout budget, cancellation semantics, slow-dependency and late-completion tests.

Fail when

Upstream timeout occurs while hidden downstream work can still create an untraceable effect.

ER-03

Rate-limit and backpressure contract

Publish limit dimensions, windows, burst rules, headers, queue behavior, retry-after semantics, and capacity-change process.

Accept when

The buyer can throttle before rejection, prioritize critical flows, and recover without synchronized retry spikes.

Evidence

Quota table, response headers, load and recovery test output, capacity review process.

Fail when

A shared or undisclosed limit allows low-priority traffic to block financial or control actions.

Domain 06

Sandbox parity and production readiness

Use a test environment that can prove production behavior, failure handling, and operational readiness.

Gate: A happy-path demo environment cannot substitute for production acceptance.

SB-01

Parity declaration

List every difference in schema, auth, limits, timing, dependencies, data, features, certificates, topology, and failure behavior between sandbox and production.

Accept when

Each difference has an owner, risk decision, compensating production test, and closure evidence.

Evidence

Environment comparison matrix, exception register, production validation plan.

Fail when

A launch-critical behavior is unavailable for test and has no controlled production proof.

SB-02

Deterministic failure fixtures

Provide controlled cases for delay, timeout, duplicate, reordering, decline, reversal, malformed payload, rate limit, and dependency outage.

Accept when

Fixtures reproduce documented states and correlation data without manual supplier intervention.

Evidence

Fixture catalogue, expected results, automated acceptance output.

Fail when

The buyer cannot exercise a critical exception before launch.

SB-03

Production smoke and rollback

Define minimal production tests, data controls, approvals, monitoring, go/no-go, abort threshold, and cleanup.

Accept when

A bounded live validation proves connectivity, identity, monitoring, reconciliation, and rollback before traffic ramp.

Evidence

Production test script, approvals, evidence bundle, rollback and cleanup records.

Fail when

Production differences are discovered only after unrestricted player traffic begins.

Domain 07

Observability and incident evidence

Trace a buyer operation across every synchronous call, event, queue, and downstream business effect.

Gate: No integration goes live if either party can see only its own edge of a failed transaction.

OB-01

End-to-end correlation

Propagate buyer operation ID, provider request ID, trace ID, aggregate ID, and external reference without exposing secrets or personal data.

Accept when

Support can retrieve the full transaction path from any one approved identifier.

Evidence

Header and event contract, distributed trace, support lookup demonstration.

Fail when

A transaction cannot be joined across API, queue, ledger, and external processor records.

OB-02

Journey metrics and alerts

Measure success, failure, timeout, latency, saturation, queue age, retries, duplicates, reconciliation breaks, and business terminal states.

Accept when

Alerts use journey impact and tested thresholds, not only infrastructure health.

Evidence

Metric dictionary, dashboards, alert rules, synthetic and failure-injection output.

Fail when

Services appear healthy while player transactions are failing or stranded.

OB-03

Evidence access and retention

Define which logs, traces, payload metadata, audit records, and incident artifacts each party can retrieve, for how long, and in what format.

Accept when

A joint investigation can be completed inside the escalation target without unrestricted personal-data access.

Evidence

Access matrix, retention policy, redaction rules, timed investigation exercise.

Fail when

Required evidence expires, is inaccessible, or exposes data beyond the approved purpose.

Domain 08

Reconciliation and exception ownership

Detect business-state divergence even when every API call returned success.

Gate: No financial integration without independent control totals and a replay-safe exception process.

RC-01

Independent control totals

Compare counts and amounts by stable keys, currency, status, product, and cut-off between both sides of each financial boundary.

Accept when

Opening plus movements equals closing, and both parties can reproduce the same population and cut-off.

Evidence

Control-total definitions, sample files, signed reconciliation output.

Fail when

Reconciliation depends on one party's derived dashboard total.

RC-02

Bounded exception queue

Classify missing, duplicate, amount, currency, status, timing, and reference breaks with age, materiality, owner, action, and approval.

Accept when

Every break remains visible to closure and manual adjustment requires dual control and linked evidence.

Evidence

Exception schema, aging dashboard, sample investigation, adjustment audit.

Fail when

Breaks are silently netted, overwritten, or closed without evidence.

RC-03

Repair and replay

Define whether each break is corrected by replay, compensating transaction, source correction, or approved accounting adjustment.

Accept when

Repair is idempotent, preserves original history, updates every dependent view, and re-enters reconciliation.

Evidence

Repair runbook, authorization, replay output, post-repair control totals.

Fail when

Repair requires direct data editing or creates a second unexplained break.

Domain 09

Data export and portability

Make operational, audit, and migration data complete, intelligible, and usable without supplier tooling.

Gate: Dashboard access or a one-time opaque dump is not an exit-ready export.

EX-01

Full and incremental export

Provide full and delta exports for entities, transactions, state history, audit, reference data, media, and open obligations.

Accept when

The buyer can reproduce a selected state at a cut-off and continue deltas without gaps or duplication.

Evidence

Dataset inventory, schemas, sample full/delta files, watermarks and manifests.

Fail when

A required state exists only in a UI, derived report, or proprietary binary.

EX-02

Integrity and lineage

Include stable identifiers, relationships, time semantics, units, precision, enumerations, checksums, counts, totals, and schema version.

Accept when

Automated validation detects missing files, broken references, duplicate keys, and control-total differences.

Evidence

Data dictionary, manifest, checksum and referential-integrity test output.

Fail when

The buyer cannot prove export completeness or relate history to current state.

EX-03

Exit service level

Contract request, preparation, delivery, delta cadence, correction, access, transition support, cost, and deletion timing.

Accept when

A rehearsed export completes within the required migration window and open items retain a settlement path.

Evidence

Exit schedule, priced service levels, rehearsal output, issue and correction log.

Fail when

Export timing or format makes the contractual transition window unachievable.

Domain 10

Deprecation and change control

Move consumers safely before old behavior is removed, including emergency and regulator-driven changes.

Gate: No unilateral breaking change without notice, migration evidence, and a bounded exception path.

DP-01

Notice and support window

Define notice by change class, supported versions, security exceptions, regulator-driven exceptions, and buyer acknowledgement.

Accept when

The notice clock starts only when schemas, migration guidance, test access, and material behavior changes are available.

Evidence

Deprecation policy, version calendar, sample notice, acknowledgement record.

Fail when

A version can be retired before the buyer can test and deploy its replacement.

DP-02

Dual-run and equivalence

Support a bounded period where old and new behavior can be compared using the same test population and control totals.

Accept when

Differences are classified, owned, resolved, or explicitly accepted before traffic moves.

Evidence

Dual-run plan, comparison output, exception decisions, cutover approval.

Fail when

Cutover relies on a schema comparison without business-outcome equivalence.

DP-03

Cutover and retirement proof

Define traffic ramp, rollback, old-client detection, support escalation, final export, credential revocation, and endpoint retirement.

Accept when

No supported consumer uses the old contract, rollback remains possible through the agreed point, and residual access is revoked.

Evidence

Consumer telemetry, go/no-go record, rollback test, retirement and revocation evidence.

Fail when

The old endpoint is removed while active consumers or unreconciled transactions remain.

Pre-launch API gates

Treat these as eligibility conditions. A deadline does not convert an unknown transaction state, missing reconciliation, or untested export into an acceptable integration risk.

Every mutating request has a buyer-owned operation ID, an idempotency rule, and a safe unknown-outcome lookup.
Authorization is tested negatively across tenant, brand, market, product, resource, role, and environment boundaries.
Events converge after duplicates, gaps, process restart, out-of-order delivery, and replay; transport is never assumed exactly once.
Error and timeout contracts state whether a business effect occurred and whether retry is safe.
Rate limits protect critical player and financial operations from lower-priority traffic and synchronized retries.
Sandbox differences are explicit and every critical exception has a deterministic fixture or bounded production test.
Both parties can trace, reconcile, repair, export, migrate, and retire the integration without direct data editing.

Place the API inside the full platform decision

The interface contract cannot decide which system owns player and financial truth. Resolve that architecture first, then test wallet, service, migration, and contractual consequences around the same operation IDs and control totals.

Platform architecture framework Wallet protocol tests Reliability evidence Implementation plan Migration and export acceptance RFP integration and IP controls