Codes de réponse de l'émetteur et traitement

1) Pourquoi comprendre les codes de réponse

Le code de réponse de l'émetteur définit l'action suivante : répéter, répéter avec le SCA/3DS, router différemment, ne pas répéter ou escalader l'utilisateur. Une classification correcte des codes augmente le taux d'approbation (RA), réduit le coût et réduit la proportion de transactions controversées.

2) Taxonomie des codes (représentation générale)

• Succès

« 00 » - Approved (ou « 85 » dans des implémentations distinctes).

Soft declines (conditions temporaires/corrigeables)

`51` — Insufficient funds.
'91' - Issuer ou switch inoperative (indisponibilité temporaire).
'96' - Maladie du système (erreur générale).
« 62/65 » - Restrictions/Exceeds withdrawal frequency (limites, seuils journaliers).
« R1/R3 » ou codes de circuit soft-decline par SCA requis/3DS needed.

Hard declines (raisons permanentes/définitives pour cette tentative)

'05' - Do not honor (souvent en fait dur, sinon marqué comme SCA-soft).
`14` — Invalid card number.
`54` — Expired card.
`57` — Transaction not permitted to cardholder.
`59` — Suspected fraud.
`43/41` — Stolen/Lost card.
« 03/04/13 » - Invalid merchant/withdrawal/amount (erreur de paramètres).

3) Matrice des solutions (règles de traitement)

Ci-dessous, la matrice pratique « code → action » pour le commerce électronique (MCC 7995), où le 3DS2/SCA et le COF/MIT sont critiques.

4) Pleybooks rétrograves et backoff

Idempotence : chaque répétition doit avoir une clé d'idempotence et enregistrer la machine d'état des tentatives.

4. 1 Modèle général backoff (soft)

1er échec → répétition dans 10-15 min

2ème → dans 1-2 h

3ème → après 24 h, puis arrêt

Si soft-decline = SCA required → immédiatement 3DS2 sans attendre.

4. 2 Répétitions pour les abonnements (MIT/COF)

Une file d'attente MIT séparée (ne gêne pas le CIT).
Backoff exponentiel + jitter (dispersion aléatoire) pour éviter une « tempête » à 00:00.
Stocker le lien vers le CIT initial (liability/PSD2).

5) Routage intelligent par code/BIN/PSP

Si '91/96' sur des grappes BIN spécifiques, passer à la PSP-B qui a plus de RA pour ces émetteurs.
Pour '05' après 3DS - essayez network token + un autre PSP (parfois la sensibilité de l'antifrod de l'émetteur aide).
Maintenez la table de stabilité : Émetteur × PSP × mode 3DS → AR/latency.

IF code in {91,96} AND bin_country == "X" THEN route = PSP_B
ELSE IF code == SCA_REQUIRED THEN enforce_3DS = true
ELSE IF code == 05 AND was_3DS == false THEN retry_with_3DS
ELSE IF code in HARD THEN stop_and_prompt_alternative

6) Relation avec le 3DS/SCA

Soft-decline en raison de SCA reconnaître sans ambiguïté et ne pas dépenser des tentatives sur les retraits « aveugles ».
Sur le CIT démarrer l'EMV 3DS 2. x; les MIT suivants sont sans SCA lorsque les références sont correctes.
Passer un maximum de contexte (device, compte age, velocity) - augmente la probabilité de frictionless.

7) modèles UX pour augmenter la conversion

Statuts compréhensibles : « Fonds insuffisants », « La banque est temporairement indisponible », « Une confirmation est requise auprès de la banque ».
Bouton Répéter avec minuteur (pour '91/96').
Offre alternative : A2A/portefeuille local, montant partiel, autre PSP.
Les abonnements sont des notifications douces avec « mettre à jour le mode de paiement » (link sur card updater).

8) Controverses et charjbecks : ce qui est important par les codes

3DS success (ECI/CAVV) réduit le risque de frod/charjbec et transfère la responsabilité.
Les codes « 59/41/43 » sont à haut risque : préparez des preuves et des antifrods.
'05' sans 3DS va souvent dans « pas d'autorisation du titulaire » ; la répétition avec 3DS réduit le risque de dispute.
Conserver les artefacts : dsTransID/ECI/CAVV, logs SCA, preuve de la prestation du service.

9) Composants architecturaux de traitement

Payments Orchestrator : règles, idempotence, state-machine, routage intelligent, réinitialisation 3DS.
Le BIN-service : le pays/schéma/type de la carte → la politique роутинга et les limites.
3DS Server : version 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
Mise à jour de la carte : VAU/ABU/mises à jour de l'acquis.
Observability : métriques AR/Loss reasons, alertes sur les surtensions '05/91/96'en coupe BIN/émetteurs.

10) Métriques et alertes

• AR par code et par groupe (soft/hard).
• Soft-decline → avec succès Retrace % (total et avec 3DS).
• La proportion de '05' après 3DS (anormalement élevée → on regarde le routage/antifrode).
• « 91/96 » par BIN/pays (SLO sur l'accessibilité des émetteurs/PSP).
• Temps jusqu'à la répétition réussie (p50/p95).
• Cost per approved txn (compte tenu des tentatives répétées).

• Spike '91/96'> X % en 15 min dans le groupe BIN.
• '05' croissance> Y % après le succès de 3DS.
• Succès des rétroactifs

11) Erreurs fréquentes

L'absence de distinction SCA-soft vs général « 05 ».
Plusieurs répétitions sans idempotence → des prises dans le ledger.
Ignorer les restrictions géographiques et les limites de l'émetteur ('62/65').
Logage PAN/CVV au lieu de tokens (violation PCI).
« Un PSP pour tous les cas » sans itinérance par émetteur.

12) Chèque de mise en œuvre

• Dictionnaire de code mapping (ISO/schémas/PSP) → taxonomie unique (soft/hard/SCA).
• State machine et idempotence pour les tentatives (clés, TTL).
• Politiques d'arrière-plan et limites de tentative (séparées pour le CIT/MIT).
• Passage en 3DS2 avec SCA-soft ; conservation des artefacts.
• Routage intelligent par BIN/pays/émetteur et santé PSP.
• Dashboards AR/declines et alertes par épingles de codes.
• Modèles UX pour les raisons de refus et les alternatives proposées.
• Intégration avec card updater et network tokens.
• Pleybooks de disputes par groupes de causes.
• Politiques PCI : PAN-safe, masquage, logging sans données sensibles.

13) Résumé

Les codes de réponse sont la « langue » de l'émetteur. Traduisez-le en actions compréhensibles : où répéter, où aller immédiatement en 3DS, où changer de PSP, et où s'arrêter et offrir une alternative. Un orchestrateur robuste avec une classification soft/hard correcte, des règles de backoff, un routing intelligent et une observabilité augmente régulièrement la conversion et réduit le coût des transactions traitées dans iGaming.