GH GambleHub

Sandkästen und Testumgebungen

TL; DR

Robuste Sandbox = vollständige Isolation, synthetische/anonymisierte Daten, realistische Simulatoren externer Systeme, vorhersehbare Sids und Zeitreisen, integrierte Idempotenz und Webhooks, transparente Limits und Metriken. Prod ist unerreichbar, die Schlüssel rotieren, Promotion nur auf Checklisten.


1) Karte der Umgebungen und ihrer Rolle

UmgebungDas ZielDer ZugangDie DatenDie Zuverlässigkeit
Local/DevSchnelle EntwicklungDie IngenieureSynthetik/minimale FixturenDie Niedrige
CI/TestEinheit/Integration/VertragstestsCI/CDawtossidyDie Mittlere
Stage/Pre-prodEndmontage, RückschrittDie BeschränkteAnonymisierte SnapshotsDie Hoche
Public SandboxExterne Partner/HändlerGate + LimitsNur SynthetikDie Mittlere
ProdKampf-SSO/strikter ZugriffDie RealenMaximum

Regel: Sandbox ≠ Prod. Jede Kommunikation erfolgt über einseitige Simulatoren ohne Zugriff auf reale Gelder/Spiele/persönliche Daten.


2) Daten: Synthetik, Anonymisierung, Sitzen

Standardsynthetik. Pass-/Kartendatengeneratoren, gültige, aber nicht finanzielle PANs (Test BINs), Live-Wett- und Saldomuster.
Anonymisierung für die Bühne: Tokenisierung von Identifikatoren, differentielle Privatsphäre für Aggregate, Entfernung seltener Kombinationen.
Sids und Determinismus: Ein Team - ein Zustand.

bash make db-reset && make db-seed ENV=sandbox SEED=2025_11_03

Zeitreise: globale „Stunde“ der Umgebung für Termin-/Verfallstests.


3) Simulatoren und Stecker (stubs)

Zahlungen/Banken/PSP

Auth/Capture/Refund/Payout со сценариями: `approved`, `declined_insufficient`, `3ds_required`, `timeout`, `duplicate`.
PSP Webhooks: Signierte HMACs, Retrays, Verzögerungen und „Dirty Internet“.

KYC/AML/Sanctions

Ответы: `clear`, `pep_match`, `sanction_hit`, `doc_mismatch`, `manual_review`.
Unterstützung von Idempotenz und Rate Limits wie in prod.

Spieleanbieter/Katalog

Lobby, Fichy, RTP/Runden - Pseudo-Zufallsgenerierung, überschaubare „Auszahlungen/Flops“ für UX-Fälle.

Option: Schalter „Strenge“ des Simulators (happy-path vs chaos).


4) Webhooks im Sandkasten

HMAC-Signaturen (v1), Header 'X-Event-Id', 'X-Timestamp', Fenster ≤ 5 Minuten.
Retrays mit exponentiellem Backoff, DLQ und Replay.
Konsole „umleiten“ und Versuchsprotokolle.

Pseudo:
pseudo
POST /psp/webhooks
Headers: X-Signature, X-Timestamp, X-Event-Id
Body: { event_id, type, data, attempt }

5) Idempotenz und Determinismus

Alle Mutationen akzeptieren den 'Idempotency-Key'.
Die Simulatoren speichern das Ergebnis nach Schlüssel (TTL 24-72 h).
„Seed-Determinismus“: mit dem gleichen Eingang - das gleiche Ergebnis (für wiederholbare Tests).


6) Sicherheit und Zugang

Isolierung von Netzwerken/VPCs, einzelne Geheimnisse und Domänen ('sandbox. example. com`).
RBAC/ABAC: Die Rollen „Partner“, „qa“, „dev“, Token-Fischadler sind minimal.
Rate-limits and quotes: fair share per-tenant/key, verständlich '429 '/' Retry-After'.
Geheimnisse nur in KMS/Vault; regelmäßige Rotation.
Verbot realer Zahlungen auf Code/Config-Ebene (Feature-Flag Hard Block).


7) API Gateway und Beobachtbarkeit in der Sandbox

Dieselben Richtlinien: OAuth2/OIDC/JWT, CORS, WAF, DDoS-Profil.
Metriken: p50/p95/p99, 4xx/5xx, Hit-Rate-Limits, Latenz-Webhooks, idempotente Hits.
Logs/Traces: ohne PII; Korrelation 'trace _ id'.
Dashboard „Sandbox Health“: Aptime, Webhook-Warteschlangen, Simulator-Fehler.


8) Ficha-Flaggen, Versionen und Kompatibilität

Aufnahme in die Sandbox → stage → prod.
SemVer für API; Deprecation/Sunset Banner im Swagger/Redoc Sandkasten.
Persisted queries für GraphQL-Vitrinen (falls vorhanden).


9) CI/CD и promotion

1. Build/Unit →

2. Contract/Mock tests (OpenAPI/Protobuf/GraphQL SDL) →

3. Integration gegen Simulatoren →

4. Stage Regression (Anon. Schnappschüsse) →

5. Canary в prod.

Gate-Checkliste Promotion: unten in § 12.


10) UAT-Szenarien für Partner (in der Sandbox)

Zahlungen: auth/capture/refund/payout mit Webhooks und PSP-Fehlern.
KYC/AML: alle Zustände + manuelle Eskalation.
Idempotency: Wiederholte „Idempotency-Key“ → das gleiche Ergebnis.
Rate-Limit: Korrekte Verarbeitung von '429'.
Zeitfenster: Token-Verfall, 'Retry-After', Zeitreisefälle.
Webhooks: Signaturen/Retrays/DLQ, manuelle Replay und Dedup.


11) Datenpolitik und Datenschutz

Bewahren Sie niemals echte PAN/KYC-Docks in einer Sandbox/Bühne auf.
Anonymisierung: Maskierung, Entfernung direkter Identifikatoren, synthetische Korrelation.
TTL-Speicherung von Protokollen und Webhook-Körpern ≤ routinemäßig.


12) Checklisten

12. 1 Neue Sandbox starten

  • Isoliertes Netzwerk/Basis/Cache/Objektspeicher
  • Secrets created in KMS/Vault, Zugriff nach Rolle
  • PSP/KYC/Spiele-Simulatoren sind degeneriert und versioniert
  • Swagger/Redoc + Postman Sammlung (Sandkasten Endpunkte)
  • Webhooks: HMAC, Retry, DLQ, Replay-Konsole
  • Rate/Quota Profile, Deprecation/Sunset Banner (falls vorhanden)
  • Dashboards und Alerts (Latenz, 5xx, 429, DLQ)

12. 2 Promotion release (stage→prod)

  • Vertragliche Diff-Prüfungen (ohne Breaking)
  • Lastp95/p99 normal auf der Bühne
  • Webhooks bestanden UAT, Idempotenz ok
  • Die Ficha-Flaggen sind vorbereitet, es gibt einen Rollback-Plan
  • Changelog, Migrationsführer und Mailing an Partner

13) Antipatterns

Eine Sandbox, die „heimlich“ Prod-Dienste/Basen berührt.
Echte Karten-/Passdaten in der Stage/Sandbox.
Simulatoren ohne Webhooks/Retrays sind nur ein „Happy Trail“.
Keine Idempotenz → doppelte Auszahlungen/Wetten.
Ein gemeinsames HMAC-Geheimnis für alle Partner.
Es gibt keine Grenzen und keine transparenten 429/Retry-After.


14) Mini-Schnipsel

.env. Sandbox (Beispiel)

dotenv
API_BASE=https://sandbox.api.example.com
OAUTH_ISS=https://sandbox.idp.example.com
PSP_SIM_URL=https://sandbox.psp-sim.example.com
KYC_SIM_URL=https://sandbox.kyc-sim.example.com
WEBHOOK_SECRET_ROTATION_DAYS=90
FEATURE_FORCE_SANDBOX_PAYMENTS=1

OpenAPI-Fragment (Sandbox-Server)

yaml servers:
- url: https://sandbox.api.example.com/v1 description: Public Sandbox

Pseudocode der Idempotenz

pseudo if store.exists(idem_key): return store.get(idem_key)
res = do_business()
store.set(idem_key, res, ttl=72h)
return res

PSP-Simulator-Trigger

json
{ "scenario": "payout", "case": "declined_insufficient", "payout_id": "p_123" }

15) Beobachtbarkeit und Sandbox SLO

Uptime sandbox API ≥ 99. 5% (das Schaufenster der Integrationen darf nicht fallen).
Webhooks p95 ≤ 3 s bis 2xx bei normaler Belastung.
Fehlerbudget 5xx des Gateways ≤ 0. 1%.
Das Dockingportal ist verfügbar und mit dem Vertrag synchronisiert.


16) Governance

Eigentümer der Umgebung (SRE/Plattform) und steward API (Verträge).
RFC-Prozess für Breaking-Änderungen, Deprecation/Sunset Kalender.
Separate Limits/Quoten und „Fair-Use“ -Pricing für die öffentliche Sandbox.


Zusammenfassung

Eine Sandbox ist ein Entwicklerprodukt und keine „Kopie der Basis“. Geben: strenge Isolation, synthetische Daten, vollwertige Simulatoren mit Webhooks und Retrays, Determinismus durch Sids und Zeitreisen, Ficha-Flaggen und transparente Grenzen. Binden Sie alles mit Verträgen, Überwachung und Governance zusammen - und Ihre Integrationen werden schnell, sicher und vorhersehbar und Releases werden schmerzlos.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.