Comment connecter les fournisseurs via API : handshake, certification, sandbox

Texte intégral de l'article

💡 18+. Le matériel est d'ingénierie et d'application, pas un appel à jouer. Par « fournisseur », on entend RGS/studio en direct/jackpot/service ; sous « plateforme » - PAM/portefeuille/caisse/bonus/RG.

1) Carte d'intégration : de la demande à la production

Étapes :

1. Presale et Due Diligence : juristes, géo/licences, compatibilité du contenu et politiques RG.

2. Handshake et sécurité : délivrance d'accès sandbox, échange de clés (mTLS/HMAC), inscription à Schema Registry.

3. Technique : nous confirmons le modèle de domaine (sessions/bets/settlements/événements), l'idempotence, les codes d'erreur.

4. Intégration sandbox : émulateurs portefeuille/PSP/RG, joueurs de test, scénarios de « pluie » et prises.

5. Certification : test obligatoire, signature des protocoles, charge et cas de chaos.

6. Staging/UAT : configis de combat sans argent réel, trafic canarien.

7. Go-Live : compagnie de clés, activation des drapeaux fich, surveillance SLO, préparation post-incident.

2) Handshake : authentification, autorisation, traçage

2. 1 Échange de secrets et de scoops

mTLS (certificats per brand/region) et/ou OAuth2 Client Credentials.

Signature du corps de la requête HMAC/EdDSA (ajoute non-repudiation).

Скоупы: `sessions:write`, `bets:write`, `settlements:write`, `events:publish`.

2. 2 Titres obligatoires

"X-Trace-Id'est une trace de bout en bout.

`X-Brand-Id`, `X-Region`, `X-Provider-Id`.

« X-Idempotency-Key » - pour toutes les opérations write.

2. 3 Contrôle sanitaire (avant code)


GET /health
→ 200 {"status":"ok","version":"1. 7. 2","time":"2025-10-23T10:00:00Z"}

3) Sandbox : qu'y a-t-il et comment l'utiliser

Composition de l'environnement :

Émulateur de portefeuille ('/wallet/debit	credit	rollback ') avec idempotence et retards.
RG-hooks ('/rg/check ',' rg. limit. hit ') et les profils de test (auto-exclusion/limites).
Faux agrégateur/jackpot pour les contributions/déclencheurs.
Fake KYC/AML réponses (allow/deny/pending).
Pneu d'événement (Kafka/Pulsar) avec les tops de test et Schema Registry.

Harmonie avec la réalité :

Des versions similaires des schémas et des limites de taux, comme dans la vente.
Temporisation, prises de livraison, out-of-order - intégrés avec des boutons d'émulation.

Jeu de joueurs/devises de test :


p_demo_1 (EUR), p_demo_2 (USD), p_blocked_rg (denied), p_low_balance

4) Modèle de ressources et contrat minimum

4. 1 Création d'une session


POST /v1/sessions
{
"player_id":"p_demo_1",  "game_id":"studio:slot_forge_02",  "currency":"EUR",  "locale":"de-DE"
}
→ 201 {"session_id":"s_456","expires_at":"2025-10-23T19:10:00Z"}

4. 2 Autorisation de taux (hold)


POST /v1/bets/authorize
Headers: X-Idempotency-Key: bet_r_8c12_1
{
"session_id":"s_456",  "bet_id":"b_001",  "round_id":"r_8c12",  "amount":{"amount":2. 00,"currency":"EUR"}
}
→ 200 {"status":"authorized","hold_id":"h_zz1"}

4. 3 Settlment (résultat du tour)


POST /v1/bets/settle
Headers: X-Idempotency-Key: settle_r_8c12_1
{
"bet_id":"b_001",  "round_id":"r_8c12",  "win":{"amount":14. 60,"currency":"EUR"},  "bonus_state":{"in_bonus":true,"freespins_left":7}
}
→ 200 {"status":"credited","settlement_id":"st_77"}

4. 4 Erreurs (schéma unique)


409
{"code":"DUPLICATE","message":"Bet already authorized","retryable":false,"trace_id":"tr_a1b2"}

5) Événements et schémas : Sans cela, vous ne passerez pas la certification

Repères de base :

`session. started	ended`, `bet. authorized	settled	rolled_back`, `bonus. issued	consumed`, `wager. progress. updated`, `wallet. debit.`, `wallet. credit.`, `rg. limit. hit`, `rg. reality_check`.

Exemple Avro/JSON Schema (fragment 'bet. settled`):

json
{
"event_type":"bet. settled",  "schema_version":"1. 2. 0",  "event_id":"uuid",  "occurred_at":"2025-10-23T16:21:05Z",  "tenant_id":"brand-7",  "region":"EU",  "player_id":"p_demo_1",  "trace_id":"tr_a1b2",  "payload":{
"round_id":"r_8c12",   "bet":{"amount":1. 00,"currency":"EUR"},   "win":{"amount":14. 60,"currency":"EUR"},   "in_bonus":true
},  "idempotency_key":"bet_r_8c12_1"
}

Règles : évolution backward-compatible, test de « duplications et événements tardifs », lot par 'tenant _ id/player _ id'.

6) Certification d'intégration : exactement ce qui est vérifié

6. 1 Scripts fonctionnels (minimum)

La répétition de la requête 'authorize/settle' avec la même 'X-Idempotency-Key' → la même réponse.

Out-of-order : « settle » est arrivé sans « authorize » → une défaillance correcte.

Chaînes rollback lorsque le portefeuille/réseau tombe.

RG-pieds : auto-exclusion/limite de perte/temps → interdire le pari.

Bonus/Wager : contribution par type de jeu, max bet, deadline.

6. 2 Charges

p95 'bet/settle' dans les budgets (par exemple '<200-300 ms'), pas de « tempêtes » de rétrograves.

Les flux d'événements atteignent BI ≤ 5 min.

6. 3 Cas de chaos

Doublages de livraison, retards outbox/CDC, « tomber » de la région, settlement partiel.

6. 4 Documents de suivi

Protocole de test Timcode/trace-id.

Rapport SLO (latency/error/lag).

Résumé de la sécurité (clés, rotations, accès, Vault/HSM).

7) La versification et la migration

HTTP : '/v1/... 'dans le chemin, événements :' schema _ version 'dans le corps.

BouVer : mineur - ajout de champs optionnels ; major uniquement via le nouveau préfixe '/v2/'.

Deprecation headers : 'Deprecation', 'Sunset', miroir d'utilisation dans le dashboard.

Drapeaux fich : « double écriture » des événements (« v1 » et « v2 ») sur la période de transition.

8) Sécurité et conformité

Les signatures mTLS + S2S, les jetons à courte durée de vie, les tampons limités.

Zero-trust : stratégies réseau, clés per-brand/region.

Data residency & PII : stockage et logs dans la région ; RLS/masquage.

Audit WORM : modifications des limites, profils RTP, jackpot configues.

RG/AML : feux stop synchrones au taux/paiement ; Rapport SAR/STR.

9) Sortie en prod : liste de contrôle de lancement

Avant d'activer le trafic

Rotation des secrets sandbox → clés prod.

Les dashboards p95/p99, error-rate, queue-lag, settle-lag sont inclus.

Alertie SLO : breach par latency/error/lag, sursaut 'DUPLICATE/IDEMPOTENCY _ MISMATCH'.

Plan DR : RPO ≤ 5 min, RTO ≤ 30 min ; « bouton rouge » : stop aux nouvelles sessions.

Canaris

1 à 5 % du public/jeux/géo ; rollback automatique en cas de violation de SLO.

Après-surveillance 24-72 heures, rapprochements ledger/rapports.

10) Anti-modèles (drapeaux rouges)

Publier des événements en contournant outbox/CDC.

L'absence de 'X-Idempotency-Key' sur les opérations write.

Édition manuelle des balances/réseaux dans la base de données.

Clés uniques pour plusieurs marques/régions.

BI et rapports réglementaires sur les OBD OLTP de combat.

Dégradation zéro : La chute du fournisseur fait tomber le portefeuille/la plate-forme.

11) Chèques-feuilles

Pour le fournisseur

J'envoie toujours 'X-Trace-Id' et 'X-Idempotency-Key'.
Je supporte la répétition avec la même clé sans effets secondaires.
Je publie des événements sur les schémas de Registry ; Je garde 'schema _ version'.
Retraits avec backoff et déduplication implémentés.
Les pieds RG et les restrictions de bonus sont respectés en temps réel.
Accès et secrets - per brand/region, rotation personnalisée.

Pour la plateforme

Outbox/CDC sur tous les trajets monétaires ; trace de fin à fin.
SLO-dashboards : p95/99, error-rate, queue-lag, settle-lag.
Deprection/Sunset process, double écriture des événements sur les migrations.
Exercice DR/xaoc, gestion des incidents et post mortem.
Modes de dégradation : 'no new sessions', désactivation promo/jackpot.

12) Exemple de playbook d'intégration « minimum » (TL ; DR)

1. Signer le NDA/contrat → délivrer des accès sandbox et des schémas.

2. Échanger les certificats mTLS/HMAC ; démarrer 'provider _ id'.

3. Concilier les endpoints minimums : 'sessions', 'bets/authorize', 'bets/settle', 'rollback'.

4. Connectez-vous au bus Sandbox et Registry ; chasser les cas fonctionnels/chaos.

5. Passez le protocole de certification : Logs, trace-id, rapport SLO.

6. Commuter les clés à la prod, allumer le canari, observer SLO.

7. Enregistrer des métriques post-release et des « leçons » dans changelog.

Une connexion de fournisseur réussie n'est pas seulement une API, mais un processus contrôlé : handshake sécurisé, sandbox réaliste, certification rigoureuse, observabilité et règles claires d'interopérabilité. En suivant les invariants décrits (idempotence, outbox/CDC, RG/AML-pieds, SLO et DR), vous accélérez les intégrations, évitez les incidents monétaires et obtenez des sorties prévisibles - sans surprise pour les joueurs, les régulateurs et les entreprises.