GH GambleHub

Sandbox et environnement de test

TL; DR

Bac à sable fiable = isolation complète, données synthétiques/impersonnelles, simulateurs réalistes de systèmes externes, sièges prévisibles et voyage-temps, idempotence intégrée et webhooks, limites transparentes et métriques. La prod est hors de portée, les clés tournent, la promotion n'est que sur les chèques.


1) Carte des environnements et de leurs rôles

L'environnementObjectifAccèsDonnéesFiabilité
Local/DevDéveloppement rapideIngénieursSynthétiques/fixités minimalesBas
CI/TestTests unitaires/d'intégration/contractuelsCI/CDАвтосидыMoyenne
Stage/Pre-prodAssemblage final, régressionLimitéeSnapshots anonymesHaut
Public SandboxPartenaires externes/merchantsGate + limitesSeulement synthétiqueMoyenne
ProdDe combatSSO/accès strictLes vraisMaximum

Règle : sandbox ≠ prod. Toute communication - via des simulateurs unidirectionnels sans accès à des fonds réels/jeux/données personnelles.


2) Données : Synthétique, anonymisation, assise

Synthétique par défaut. Générateurs de données de passeport/carte, PAN valides mais non financiers (BIN test), modèles de taux et de bilan « vivants ».
Anonymisation pour stage : Tokenization des identifiants, confidentialité différentielle pour les agrégats, suppression des combinaisons rares.
Les sides et le déterminisme : une équipe est un état.

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

Time-travel : une « heure » globale de l'environnement pour les tests de dedline/expatriation.


3) Simulateurs et bouchons (stubs)

Paiements/banques/PSP

Auth/Capture/Refund/Payout со сценариями: `approved`, `declined_insufficient`, `3ds_required`, `timeout`, `duplicate`.
Webhooks PSP : signé HMAC, retraits, retards et « internet sale ».

KYC/AML/Sanctions

Ответы: `clear`, `pep_match`, `sanction_hit`, `doc_mismatch`, `manual_review`.
Support de l'idempotence et des limites de taux comme dans prod.

Fournisseurs de jeux/catalogue

Lobby, fiches, RTP/rounds sont une génération pseudo-aléatoire gérée par « paiements/échecs » pour les cas UX.

Option : commutateur de « rigueur » du simulateur (happy-path vs chaos).


4) Webhooks dans un bac à sable

Signatures HMAC (v1), en-têtes "X-Event-Id'," X-Timestamp ", fenêtre ≤ 5 minutes.
Retrai avec backoff exponentiel, DLQ et replay.
La console « remodeler » et les logs de tentative.

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

5) Idempotence et déterminisme

Toutes les mutations prennent 'Idempotency-Key'.
Les simulateurs stockent le résultat par clé (TTL 24-72 h).
« Seed-déterminisme » : à la même entrée, le même résultat (pour les tests répétés).


6) Sécurité et accès

Isolation réseau/VPC, secrets et domaines individuels ('sandbox. example. com`).
RBAC/ABAC : les rôles "partner", "qa", "dev", скопы des jetons sont minimaux.
Taux-limites et quotas : juste part per-tenant/clé, compréhensible « 429 »/« Retry-After ».
Secrets uniquement dans KMS/Vault ; rotation régulière.
Interdire les paiements réels au niveau code/configh (feature-flag hard block).


7) API Gateway et l'observation dans la sandbox

Mêmes politiques : Profil de OAuth2/OIDC/JWT, CORS, WAF, DDoS.
Métriques : p50/p95/p99, 4xx/5xx, limites hit-rate, webhooks latins, succès idempotent.
Logis/remorques : sans PII ; corollation 'trace _ id'.
Dashboard « La santé du bac à sable » : aptyme, files d'attente de webhooks, erreurs de simulateurs.


8) Drapeaux de ficha, versions et compatibilité

Incluez la fiche dans la sandbox → stage → prod.
BouVer pour l'API ; bannière Deprecation/Sunset à Swagger/Redoc sandbox.
Queries persistantes pour GraphiqueQL-vitrine (le cas échéant).


9) CI/CD и promotion

1. Build/Unit →

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

3. Intégration contre les simulateurs →

4. La régression de la scène (anon. snapshots) →

5. Canary в prod.

Gate checklist promotion : ci-dessous en § 12.


10) Scénarios UAT pour les partenaires (dans le bac à sable)

Paiements : auth/capture/refund/payout avec webhooks et erreurs PSP.
KYC/AML : tous les statuts + escalade manuelle.
Idempotence : la répétition 'Idempotency-Key' → le même résultat.
Rate-limit : traitement correct '429'.
Fenêtres temporelles : expiation de tokens, 'Retry-After', cas time-travel.
Webhooks : signatures/retrai/DLQ, replay manuel et dedup.


11) Politique de données et vie privée

Ne jamais stocker de vrais docks PAN/KYC dans un sandbox/stage.
Anonymisation : masquage, suppression des identifiants directs, corrélation synthétique.
TTL de stockage des logs et des corps des webhooks ≤ réglementé.


12) Chèques-feuilles

12. 1 Lancement d'un nouveau bac à sable

  • Réseau isolé/base/cache/stockage d'objets
  • Secrets créés dans KMS/Vault, accès par rôle
  • Les simulateurs PSP/KYC/jeux sont prédécoupés et versionnés
  • Collection Swagger/Redoc + Postman (sandbox endpoints)
  • Webhooks : HMAC, retry, DLQ, replay console
  • Profils de taux/quota, bannières Deprecation/Sunset (le cas échéant)
  • Dashboards et alertes (latinité, 5xx, 429, DLQ)

12. 2 Promotion release (stage→prod)

  • Contrôles de type contrat (sans breaking)
  • Charge p95/p99 normale sur la scène
  • Les webhooks ont passé l'UAT, idempotence ok
  • Les drapeaux de ficha sont préparés, le plan de retrait est
  • Changelog, guide de migration et infolettre aux partenaires

13) Anti-modèles

Un bac à sable qui touche « secrètement » les services prod/bases.
Données réelles de carte/passeport dans stage/sandbox.
Les simulateurs sans webhooks/rétracteurs sont un « sentier heureux » seulement.
Absence d'idempotence → double paiement/taux.
Un secret HMAC commun pour tous les partenaires.
Pas de limites et de 429/Retry-After transparentes.


14) Mini-extraits

.env. sandbox (exemple)

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

Tranche OpenAPI (serveur sandbox)

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

Pseudo-code d'idempotence

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

Déclencheurs de simulateur PSP

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

15) Observabilité et SLO du bac à sable

Uptime sandbox API ≥ 99. 5 % (la vitrine des intégrations ne doit pas tomber).
Webhooks p95 ≤ 3 s jusqu'à 2xx sous charge normale.
Error budget 5xx de la passerelle ≤ 0. 1%.
Le portail est disponible et synchronisé avec le contrat.


16) Governance

Propriétaire de l'environnement (SRE/Platform) et API steward (contrats).
Processus RFC pour le breaking-change, calendrier Deprecation/Sunset.
Limites/quotas séparés et prix « fair-use » pour le bac à sable public.


Résumé

Le bac à sable est un produit pour les développeurs, pas une « copie de base ». Donnez : isolation stricte, données synthétiques, simulateurs complets avec webhooks et retraits, déterminisme à travers les cids et les voyages-temps, drapeaux ficha et limites transparentes. Attachez tout avec des contrats, de l'observation et de la governance - et vos intégrations deviendront rapides, sûres et prévisibles, et les sorties seront indolores.

Contact

Prendre contact

Contactez-nous pour toute question ou demande d’assistance.Nous sommes toujours prêts à vous aider !

Commencer l’intégration

L’Email est obligatoire. Telegram ou WhatsApp — optionnels.

Votre nom optionnel
Email optionnel
Objet optionnel
Message optionnel
Telegram optionnel
@
Si vous indiquez Telegram — nous vous répondrons aussi là-bas.
WhatsApp optionnel
Format : +code pays et numéro (ex. +33XXXXXXXXX).

En cliquant sur ce bouton, vous acceptez le traitement de vos données.