Routage de paiement et failover

Routage de paiement et failover

1) Pourquoi est-ce nécessaire

Conversion : le bon choix de canal/PSP par BIN/banque/géo/risque augmente le taux Auth de 5-15 pp

Coût : le choix dynamique par « succès × commission » réduit le taux effectif de 10 à 30 bps.
Durabilité : isolation des chutes PSP/3DS/banques ; la poursuite des admissions et des paiements en cas de défaillance partielle.
Conformité/RG : mise en œuvre flexible des limites, des limites géographiques, des auto-exceptions et des règles de sanctions directement dans le routage.

2) Architecture cible (couches)

1. Checkout Layer - localisation des devises/méthodes, découverte APM, 3DS UX.
2. Payment Orchestrator (Rule Engine) - routage, retri intelligent, idempotence, circuit-breaker.
3. Risk/KYT Engine - device/behavior, sanctions/RER, velocity, limites RG, politique 3DS.
4. Compliance Hub - KYC, fournisseurs de sanctions, affordability/limites, audits.
5. Wallet & Ledgers sont des ledgers monétaires et de jeux, des bonus-passifs, des multivalts.
6. Reconnaissance et reporting - T + 0/T + 1 rapprochements, codes reason, registres fiscaux.
7. Observability & Security - métriques/logs/traces, alertes, RBAC, segmentation PCI.
8. Data/ML - score de risque, prédiction de la conversion par les banques/méthodes.

3) Modèle de données et idempotence

Payment Intent (PI) : objet unique pour le dépôt/paiement avec les champs : amount, currency, method, geo, BIN, risk_score, rg_limits, route_history, idempotency_key, état.
Idempotence : chaque hop (PSP-A → PSP-B) est réalisé avec un seul idempotency_key ; la répétition des appels ne change pas l'état du ledger.
Route Journal : un journal de route et de réponse (PSP id, reason code, latency, 3DS-flow, fee), est nécessaire pour A/B et la formation des modèles.

4) Algorithme de routage (référence)

4. 1 Réception (Acquisition)

1. Pré-score : GEO, BIN/IIN, banque émettrice, appareil, chèque, risque, statut RG.
2. Filtres Complaens : sanctions/RER, blocs géo, âge/auto-exclusion.
3. Règles de coût/succès : score = w1· AuthRate + w2· (− Fee) + w3· Santé − penalties.
4. Politique 3DS : TRA/whitelisting/step-up sur le risque, choix challenge vs frictionless.
5. Sélection d'itinéraire : PSP-A → (sur les pannes/erreurs) → PSP-B → une autre méthode (APM/open banking).
6. Smart Retry : changement de mode 3DS, MID, mcc/fallback, time-bekoff par code reason (05/51/62 ≠ 91/96).
7. Post-processing : entrée dans la Route Journal, mise à jour des balances.

4. 2 Paiements (Payouts)

1. Priorité : vitesse (instant/proche-instant) ↔ coût ↔ disponibilité.
2. KYT/AML/RG : velocity, modèles de « contournement », limites, source de fonds, listes d'exceptions.
3. Routage : card-to-card OCT/RTP/Faster Payments/SEPA Instant/Pix/UPI.
4. Failover : queued payouts en cas d'indisponibilité de la banque/PSP, drain périodique de la file d'attente.
5. Confirmation : webhooks signés qui compensent les transactions en cas de divergences.

5) Modèles de failover

5. 1 Circuit-breaker

Local (sur PSP) : se déclenche en error_rate↑, latency↑, spike in declines (issuer-specific).
Global (par méthode) : en cas d'échec de l'industrie (par exemple, ACS/3DS d'une grande banque).
États : Closed → Open → Half-open ; les délais et seuils sont définis par segments GEO/BIN.

5. 2 Active-Active vs Active-Passive

Active-Active : PSP/méthodes parallèles ; équilibrage par règles/valeur ; le meilleur RTO/RPO.
Active-Passive : économies sur les commissions/support, mais plus longtemps que le RTO ; est bon pour les GEO/méthodes secondaires.

5. 3 Degradation Modes

Désactiver les méthodes de risque élevé, transférer une partie du trafic vers open banking/APM.
Force 3DS challenge-all pour les BIN/banques « en feu ».
Limite de temps sur les montants/fréquences (RG + risque).

6) Travailler avec le 3DS/SCA (dynamiquement)

Frictionless par défaut à faible risque/petits chèques, challenge à haut risque.
Exceptions PSD2 : LVA, MOTO, MIT - dans l'orchestre, pas dans l'application.
Fallback : lorsque l'ACS se dégrade, augmentez le taux de défi ou déplacez temporairement le trafic vers une méthode alternative (open banking).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Intégration avec antifrod/KYT/RG

Avant le routage - scoring (device, comportement, proxy/VPN, risque BIN, historique).
Dans le routage, sélectionnez 3DS/canal/PSP par risk_score.
Avant le paiement - KYT/velocity/anti-arb (rapide win→withdraw, cartes multiples, appareils associés).
Les limites RG et l'auto-exclusion sont des règles d'arrêt « strictes » au niveau de l'orchestre.

8) Observabilité et données

Métriques en temps réel : auth_rate, decline_reason mix, p95 latency, PSP health, 3DS success, payout time, queue depth.
Alerties : seuils par banques/méthodes, écheveau avec pages de statut externes.
A/B & Lerning : mise à jour des poids de routage en fonction de la conversion/coût ; groupes de contrôle sans rétrogrades à étalonner.

9) KPI et objectifs de référence

Taux auth (cartes) : EU 85-92 %, US 80-88 %, LATAM 70-85 % (sans orchestration - bord inférieur).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Instant Payouts : ≥ 70 % des chèques « légers ».
Efficacité de routage (conversion ÷ coût) : + 5-10 % par baseline pour le trimestre suivant le tuning.
Circuit-break RTO : <2 min pour commutation ; RPO : 0 (idempotence).
Chargeback rate: < 0. 5 % par compte (dépend du produit/GEO).

10) Pleybooks d'incidents (triche)

10. 1 Declines massives par banque émettrice

1. Confirmer spike par BIN/issuer.
2. Ouvrir le circuit-breaker local → redistribuer vers alt-PSP/méthode.
3. Augmenter le taux de défi pour les BIN touchés, inclure smart retry.
4. Communication vers les canaux de statut ; RCA avec les données reason codes.

10. 2 La chute 3DS/ACS

1. Détail sur la croissance timeouts/ » soft decline ».
2. Transférer une partie du trafic vers open banking/APM ; inclure « challenge-all » lorsque l'ACS est vivant.
3. Réduire le risque-chèque (limites de montant/vitesse), renforcer la surveillance.

10. 3 Instabilité du PSP

1. L'alert santé a fonctionné → open breaker.
2. Transfert vers des PSP/MID de secours ; interdiction des méthodes « lourdes » à haute latence.
3. Récupération par half-open avec canaris (1-5 % du trafic), puis gradation.

10. 4 Retards de paiement

1. Virement vers des paiements queued avec des priorités (VIP, montant limite).
2. Transfert de la pièce sur d'autres rails (RTP/FPS/SEPA Instant/Pix).
3. Notifications transparentes aux joueurs ; escalade manuelle> X heures.

11) SLA et ancres contractuelles (ce qu'il faut au PSP)

Disponibilité : ≥ 99. 95 % de réception ; p95 latency < 3 c; webhooks < 60 c.
Incidents : TTA ≤ 15 min, contournement (MID/APM), RCA ≤ 5 jours.
Données : codes de reason crus, détails sur les banques, retours de tokens ≤ 10 jours à la sortie.
Finances : limitation des réserves/holdback, fees transparents (incl. 3DS/network tokens), cap sur les indemnités FX.
Sécurité : PCI-AOC, signatures webhooks, rotations clés, SOC 2/ISO 27001 (de préférence).

12) Modèles régionaux

EC/UK : PSD2/SCA ; cartes + open banking (SEPA Instant/FPS). Forte orchestration 3DS, TRA et whitelisting.
États-Unis : cartes + ACH ; priorité aux paiements instantanés (push-to-card, RTP). Les circuits Charjbek sont obligatoires.
LATAM : Pix (BR), SPEI (MX), PSE (CO) ; APM-heavy; focus sur device risk et document-KYC.
Turquie/CA : transferts locaux/portefeuilles ; circuit de sanctions/AML renforcé, limites de montant/vitesse.
Asie/Inde : UPI/porte-monnaie électronique ; des règles de velocity strictes ; routage par les banques émettrices.

13) Chèques-feuilles de mise en œuvre

Architecture/données

• Paiement Intent + idempotence sur tous les hops.
• Route Journal, codes reason crus, webhooks signés.
• Séparation argent/ledgers de jeu ; les transactions compensatoires.

Routage/règles

• Rule-engine par GEO/BIN/issuer/risque/coût.
• Smart retry avec time-becoff et changement de 3DS/MID.
• Circuits-breakers locaux et mondiaux ; canary-retour.

Risque/conformité

• Intégration risk/KYT/RG avant et après le routage.
• Sanctions/REER, âge/auto-exclusion - comme filtres "durs'.
• Limites de velocity/montants ; Journal des décisions.

Observabilité/SLA

• Dashboards par Auth Rate, latency, decline mix, payout time.
• Alertes selon les seuils ; runbooks sur les incidents.
• SLA dans le contrat, QBR et amendes en cas d'infraction.

14) Pseudo-code de stratégie (pour l'équipe)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Économie et optimisation A/B

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B : minimum de 10k transactions/branche, 2 à 4 semaines ; enregistrer par banques/méthodes.
Optimiser les poids d'AuthRate vs Fee par GEO/Saisonnalité ; contrôler la « distorsion » dans les rails coûteux mais de conversion.

16) Ce qui est important de se souvenir

Orchestrateur + règles + données - le cœur de la durabilité des paiements et de la conversion.
L'idempotence/Payment Intent élimine le double débit et simplifie l'échec.
Circuit-breakers et canary-back assurent une stabilisation rapide sans « balançoire ».
Les SLA contractuelles et les données transparentes de PSP ne sont pas une option, mais une exigence.
Les rails régionaux (open banking, RTP, Pix/UPI) sont souvent meilleurs que les cartes en vitesse/coût - à prendre en compte dans le routage.