Tokenization des cartes et flux PAN-safe

1) Pourquoi Tokenization et qu'est-ce que PAN-safe

• minimiser le scope DSS PCI (et le coût du contrôle),
• réduire le risque de fuites,
• améliorer l'autorisation (auto-sélection, COF, one-click),
• simplifier le routage multi-PSP et les débits répétés.

Un flux PAN-safe est un tel script utilisateur et serveur où le PAN n'apparaît qu'à l'intérieur d'un périmètre de confiance isolé (valt/TSP/PSP iframe) et ne traverse jamais votre beckend/logi/bus d'événements en plein air.

2) Types de tokens et cycle de vie

2. 1 jetons Vault (privés)

Généré par votre token-valt ou par un fournisseur de coffre-fort tiers.
Attachés au PAN, mais la conformité réversible n'est stockée que dans la valte (HSM).
Utilisé pour le routage vers n'importe quel PSP/akawayer (flexibilité).
Plus : indépendance vis-à-vis des régimes ; Moins : nécessite votre propre valte compliant.

2. 2 jetons réseau (circuits ; Visa/Mastercard/AmEx TSP)

Émis par les réseaux via les FST ; sont souvent accompagnés d'un device-/merchant-binding et d'un cryptogramme.
L'autorisation est améliorée : au-dessus du taux approval, moins de frod-falls-positifs.
Prend en charge la mise à jour automatique lors du transfert de la carte.
Moins : prise en charge PSP/processeur et couverture des marchés.

2. 3 jetables (single-use) et réutilisables (COF)

Single-use : pour le débit unique/initiation SCA.
COF (Card-on-File) : pour les abonnements, les retraits, les paiements répétés.

2. 4 Cycle de vie

1. Initialisation : le front ne reçoit pas de champs de paiement de votre domaine (champs hébergés/iframe TSP/PSP).
2. Tokenization : PAN → token (vault ou network), sortie de cryptogramme (si nécessaire).
3. Stockage : token et métadonnées (données BIN, schéma, durée, domaine binding).
4. Utilisation : autorisation/captures/retraits par token.
5. Rotation/mise à jour : auto-updates (réseau), carte updater (vault/PSP).
6. Révocation/suppression : à la demande de l'utilisateur (GDPR/DSR) ou selon la politique de rétractation.

3) Modèles architecturaux PAN-safe

3. 1 Couche client (web/mobile)

Hosted fields/iFrame SDK de PSP/TSP : Le PAN est introduit en dehors de votre DOM.
Votre frontende ne reçoit qu'un jeton + attributs non critiques (les 4 derniers chiffres, BIN-meta).
Le SCA/3DS démarre par l'intermédiaire du fournisseur ; vos serveurs obtiennent un résultat/verdict.

3. 2 Service « Payments Orchestrator »

Ne voit pas le PAN ; il opère avec des tokens.
Implémente : routage (primaire/secondaire PSP), clés d'identité, retries/backoff, routage intelligent (par BIN/régions/conversion).
Maintient les règles et les tests de santé de la PSP (SLI/SLO).
Peut detokenize-proxy (seulement comme une navette de service à l'intérieur d'un périmètre de confiance à la valte).

3. 3 Token-valt (si le sien)

HSM-backend, cryptage compatible FIPS.
Isolation réseau/segmentation, AAA (MFA/least privilège), journaux d'audit, rotation clé.
API : tokenize (), detokenize (), rotate (), purge () avec ACL/Scopes fins.
Prise en charge du format-preserving encryption (FPE) - optionnel si vous avez besoin d'un stockage « masqué » visuellement.

3. 4 Pneumatique d'événement et DWH

Seuls les tokens et les métadonnées sécurisées sont présents dans les événements.
Link d'autorisation ↔ capchura/refand via payment_id (pas PAN).
Le PAN et le CVV sont interdits dans les dépôts BI.

4) Flux (diagrammes de texte)

4. 1 COF primaire (enregistrement de carte)

1. User → Hosted Fields (PSP/TSP iframe) entre le PAN.
2. PSP/TSP renvoie → token (+ device binding/cryptogram).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP : 'auth' par token (3DS challenge possible).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service : nous gardons « token » et meta.

Le PAN n'apparaît nulle part dans vos services.

4. 2 Rééchelonnement/abonnement

1. Scheduler/Business → Orchestrator: `charge(token, amount)`.
2. Orchestrator → PSP: `capture/auth`.
3. PSP → Orchestrator : résultat + arn/rrn.
4. Orchestrator → Ledger/Reconciliation.

4. 3 Failover и smart-routing

Règle : 'IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Pour les jetons réseau, assurez-vous que les deux PSP prennent en charge leur acceptation ; Sinon, gardez une liaison binaire (réseau + vault).

5) 3DS et SCA dans le circuit PAN-safe

Le 3DS2 est lancé à partir du SDK hôte ; vos serveurs acceptent les alias des statuts (frictionless, challenge, failure).
Associez le verdict 3DS à l' payment_id ; stocker les artefacts transactionnels (ARes, CRes refs) sans le PAN.
Pour les recrutements (MIT/recurring/unscheduled COF) - marquer correctement les drapeaux de transaction (type MIT, référence CIT initiale).

6) Politique de sécurité, de conformité et de données

PCI DSS scope : front sans PAN, beckend sans PAN ⇒ estimation simplifiée (SAQ-A/variations). S'il y a sa propre valte/désintoxication - l'agrégat est plus élevé (SAQ-D).
Rotation HSM/clé : rotation périodique des clés maîtres, double contrôle, connaissance split.
GDPR/DSR : suppression du token et des métadonnées associées à la demande de l'utilisateur (le PAN restant inconnu).
Logs/remorques : déguisements rigoureux, détecteurs de fuites (DLP), assainissement lors de la sérialisation des erreurs.
Segmentation : valte dans le segment dédié ; l'accès est uniquement par mTLS et tokens à courte durée de vie (STS).

7) Intégration avec PSP/akawayers

7. 1 Ensemble minimum de capacités PSP pour PAN-safe

Sites hébergés/SDK avec tokenization.
Acceptez les tokens réseau (si possible) et/ou exportez les tokens vault.
Carte updater, marquage COF, drapeaux MIT.
3DS server + orchestration SCA.
Webhooks avec livraison et signature idempotent.

7. 2 Architecture multi-PSP

Abstraction du « connecteur » dans Orchestrator (unification des champs).
Tableau « poids/priorités » + pings santé.
Table de politique BIN (schéma, région, produit, risque).
PSP de secours pour les routes critiques (SLA fallback).

8) Mise à jour des cartes et durabilité des tokens

Tokens réseau : mises à jour automatiques au moment du transfert (mieux pour LTV).
Vault tokens : utilisez card updater (via PSP/3rd-party).
Suivi des dates d'expiration, notification à l'utilisateur, retraits souples (backoff exponentiel + jitter).
Lier COF à un compte-id, et non à un utilisateur PII, pour un transfert simple.

9) Retraits, erreurs et idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Catégorisation des erreurs : hard (code decline constant) vs soft (timeout, network, risk pending).
Backoff : 1m → 10m → 1h → 24h avec bordure supérieure et annulation avec hard-decline.
Déduplication webhooks : stockez les transitions de event_id et de statut (state machine).

10) Reconnaissance et finances

Menez un Ledger de paiement sans PAN : 'payment _ id', 'psp _ txn _ id', 'arn/rrn', 'token _ id', statuts.
L'ingestion quotidienne de fichiers rec de PSP/akawyer ; les sommes, les commissions, les chargbacks.
Piplines séparées pour refunds/voids/chargebacks ; harmonisation avec la facturation/comptabilité.
KPI par PSP/pays/BIN Tabs.

11) Métriques et objectifs (KPI)

Sécurité/conformité

% des services qui ne voient jamais le PAN (objectif : 100 %).
PCI scope level (ci-dessous - mieux).

Business

Approval Rate (AR) par type de token (network vs vault).
Taux de récupération COF, proportion de méthodes auto-mises à jour.
D + 0/D + 1 écarts de reconsilation (objectif : → 0).

Technique

Temps de tokenisation p95.
Part des transactions via fallback PSP.
Kol-in de désintoxication (objectif : minimiser, seulement à l'intérieur de la valte).

12) Anti-modèles fréquents

Logique PAN/CVV dans les exceptions.
Formulaires clients sans champs hébergés.
Envoyer le PAN via votre bus API « temporairement ».
Mélange de tokens de différents domaines sans politique explicite (risk).
Pas de carte de routage (tous les paiements « en un seul PSP »).
Stockage d'artefacts 3DS avec PII redondant.

13) Plan de mise en oeuvre (par étapes)

1. Frontende : intégrer les sites hébergés/SDK, supprimer vos propres formulaires de paiement.
2. Choix PSP/TSP : Nous confirmons la prise en charge du network tokens, 3DS2, webhooks, card updater.
3. Orchestrator : couche d'abstraction sur PSP, règles de routage, idempotency, retries.
4. Valt (en option) : nous choisissons managed-vault ou nous construisons le nôtre (HSM, ACL, rotations).
5. Données/événements : interdiction du PAN dans le bus et le DWH ; implémenter le gate DLP dans CI/CD.
6. Conformité : mettre à jour la zone PCI, les procédures, les journaux d'audit, les tests de masquage.
7. Observabilité : métriques AR/LSR/latency selon PSP, alertes de dégradation, dashboards.
8. Économie : Test A/B de network vs vault tokens par AR/frod/coût, optimisation du flow.

14) Chèque PAN-safe

• Entrez le PAN uniquement dans iframe/sites hébergés.
• Beckend n'accepte jamais le PAN/CVV.
• Les tokens sont cryptés dans le stockage, les clés dans le HSM, la rotation est activée.
• Les 3DS2 et les SCA sont correctement marqués (CIT/MIT/COF).
• Routage multi-PSP et failover testés.
• Carte updater (réseau/PSP) incluse.
• Logs/remorques/décharges - sans PAN (masques/désinfectants).
• Reconnaissance et chargeback-piplines sans PAN.
• Les politiques de suppression de token du RGPD ont été mises en œuvre.
• Les métriques et les alertes couvrent la qualité du token-flow.

15) Glossaire bref

PAN : numéro de carte.
Token (vault/network) : un substitut PAN sécurisé.
TSP : Token Service Provider (service de token réseau).
COF/MIT/CIT : stockage de carte/initiative de merchant/initiative de client.
HSM : module de sécurité matérielle.
SCA/3DS2 : authentification forte/protocole d'authentification par carte.

16) Résumé

Tokenization est la technique de base pour réduire les risques PCI, la croissance du taux d'approche et le routage flexible des paiements dans iGaming. Combinez les tokens réseau (par conversion et mise à jour automatique) avec les tokens vault (par contrôle et indépendance), construisez un flow PAN-safe avec les champs hébergés, l'orchestrateur, la gestion des clés et l'observation transparente de l'autorisation à la reconnaissance. Cela donnera une sécurité, une échelle et une monétisation prévisibles.