Go-live

Complete every item on this page before you open real customer traffic. Use the checklist to gather integration-specific evidence and catch wallet, access and operational failures. Nothing here is new machinery: it is the contract from Callbacks, Request signatures, and Idempotency, checked end to end.

Before you start

• Your integration is validated through a human-run, budgeted ordinary API/wallet test: real sessions, real callbacks, real settlement, as walked through in Getting started and Environments.
• You have read the error reference and handle every code your integration can meet.
• The platform is reachable from your side:

curl -sS https://api.aggregator.gg/health

{"status": "ok"}

The health endpoint is /health at the API origin, outside the /v1 prefix; /v1/health does not exist and returns 404. Wire /health into the uptime monitor you point at the platform.

Money path checks

Callback endpoint handles all three transaction types.

• A paid bet debits amount; is_free: true preserves the real-money balance.
• win credits by amount and returns the updated balance.
• refund reverses only the original recorded debit once; a grant-funded bet does not create a cash refund.
• Every response matches the response contract; the platform validates the schema and flags malformed responses.

Idempotency holds across restarts.

• You atomically store the wallet movement and original response under trusted integration/organization context, provider_code and transaction_id.
• A repeated scoped transaction identity gets the original status and body replayed with no second wallet movement.
• The dedup store is persistent; an idempotency check that lives only in process memory dies with the process, and the platform retries failed callbacks.

Round lifecycle is tracked.

• You store round_id for every transaction, and mark rounds complete on finished: true.
• You do not accept new bets for a finished round.
• Validate the trusted session/player context of an unmatched win and follow the agreed provider lifecycle. Free-round win-only settlement is supported; other unknown or ambiguous movements need reconciliation, not an invented credit.

Balances are exact.

• All balance arithmetic is integer minor units or a decimal type; no floating point anywhere near money.
• Bet: new_balance = old_balance - bet_amount, never below zero (decline instead, per Declining a bet).
• Win: credit the accepted amount once. Refund: reverse the original recorded debit, with no new cash credit for a free bet.
• The balance you return matches your stored balance after the operation.

Security checks

Every callback is verified.

• You read X-SIGNATURE on every inbound callback and compute HMAC-SHA256 over the raw body with your callback_secret.
• Comparison is constant-time; invalid or missing signatures are rejected with 401.
• The callback_secret is stored securely and never appears in logs or error messages.
• An unverified endpoint means an attacker who learns the URL can mint player credits; this is the single most important control on the page. Snippets: Request signatures.

Transport is real HTTPS.

• The callback_url starts with https://; the certificate is CA-issued, unexpired, covers the exact hostname, and does not expire within the next 30 days.
• HTTP URLs and private IPs are rejected by SSRF validation (E6002) anyway; do not fight it, fix the URL.

Operational checks

Errors degrade gracefully.

• A dead database returns 503, not a stack trace or an HTML error page.
• An unknown transaction_type returns 400 with a clear JSON error.
• Parsing is forward-compatible: unexpected extra fields in a callback are ignored, not fatal.
• Routine diagnostics contain HTTP status, fixed allowlisted codes and your local correlation ID. Keep wallet audit evidence in access-controlled storage; do not log raw bodies, secrets or upstream messages.
• Verify the full retry split: eligible 5xx/transport failures have bounded retries, 3xx/4xx are terminal, and malformed 200 or other 2xx stop automatic redelivery with an unknown outcome.

The endpoint is fast enough.

• Under normal load: under 2 seconds at p95. Under peak: under 5 seconds at p99.
• You load-tested the endpoint against those targets; 5 seconds is the platform timeout, and a slow callback shows the player an error.

Monitoring exists before launch, not after.

• Alerts on callback endpoint downtime (health check or synthetic probe).
• Alerts on elevated error rate (5xx above 1%).
• Alerts on unusual transaction patterns: refund spikes, unusually large bets.
• A runbook or on-call rotation covers callback failures outside business hours.
• The platform publishes its own status at status.aggregator.gg: subscribe there for platform incidents, and build your monitoring on top of it, not instead of it. Your callback endpoint and wallet are yours to watch.

Compliance checks

Self-exclusion is enforced.

• On E3004 (player_self_excluded) you do not start a session for the player.
• Self-excluded players see no games and no play button.
• Self-exclusion events are logged for audit.
• Have your compliance team verify the self-exclusion controls required for your operation and jurisdiction.

Launch sequence

1. Run the full test suite within confirmed access, credits and spending limits, including the cabinet readiness check, tamper and replay tests, and the failure-mode table from Getting started, step 6.
2. Review this checklist with your engineering and compliance teams. Two readers catch what one skips.
3. Confirm the cabinet configuration: the agg_ key you deploy with, the callback_url, and the callback_secret are the values production will use.
4. Reconcile your wallet ledger against GET /v1/transactions. Reconcile paid movements, free bets, zero legs and refunds by their scoped identities and delivery evidence. Some zero cash legs settle internally; free zero wins can still arrive. Platforms need brand-level evidence because this endpoint has no brand selector. Drift found here is a race, a missed transaction, or a duplicate; fix it before customer traffic, when it is cheap.
5. Confirm purchase and launch deliberately. Check the server-confirmed paid purchase and matching credited balance in the cabinet. A welcome grant, quote or transaction hash is insufficient. Review applicable backend launch conditions; a local readiness advisory or green badge alone is not approval. Open traffic gradually. Watch your first 100 real-money transactions closely: latency, error rate, and reconciliation.

Step check: all five items have a name and a date next to them, and item 4 came out clean on the agreed test scenarios within the approved budget, including replay, decline, free-round and recovery cases that apply to your integration.

Common failures

Failure modes to cover before launch:

Failure	Root cause	Prevention
Double-credited wins	Missing idempotency check on retried callbacks	Money path checks: idempotency
Balance drift	Floating-point arithmetic on money values	Money path checks: balances
Callback timeouts	Unindexed database queries in the hot path	Operational checks: speed, load-test first
Forged callbacks accepted	Signature verification not implemented	Security checks: verification
Stuck rounds	finished flag not tracked, rounds never close	Money path checks: round lifecycle
Certificate expiry	TLS cert expired the week after go-live	Security checks: transport; set a renewal reminder