🎯 Les données de la transaction et le taux d'acceptation

Pourquoi les données pèsent sur l'acceptation

Une demande d'autorisation est un message (ISO 8583 sur les réseaux, JSON côté API PSP) qui remonte du commerçant à l'émetteur via l'acquéreur et le scheme, en 300 ms à 2 s. L'émetteur ne voit ni le site ni le client. Il ne voit que les champs du message, plus l'historique de la carte. Sa décision (approuver, refuser ou exiger une authentification) est le produit d'un scoring temps réel alimenté par ces champs.

La grande table des données de transaction

Les données de la transaction sont les champs transmis dans le message d'autorisation et, le cas échéant, dans le message d'authentification qui le précède. La table qui suit donne, pour chaque donnée transmissible dans une transaction e-commerce, son statut, qui la consomme dans la chaîne et son impact concret sur le taux d'acceptation. La mention « conditionnel » y a un sens précis. Elle désigne une donnée obligatoire dans certains contextes seulement, selon le scheme, le canal et le type de transaction.

Comment l'émetteur score : la prime à la cohérence

Le scoring d'autorisation est l'évaluation, par l'émetteur, du risque que présente une transaction avant qu'il ne se prononce. Côté émetteur, chaque autorisation traverse un moteur de règles et un modèle de scoring. Trois familles de données les alimentent. La première est le message lui-même. La deuxième est l'historique du porteur, avec ses habitudes, ses devices et ses marchands fréquentés. La troisième réunit des scores mutualisés fournis par les schemes, soit Visa Advanced Authorization, score de risque de 1 à 99 attaché à chaque autorisation, et Mastercard Decision Intelligence. Le commerçant ne contrôle que la première famille, mais elle conditionne les deux autres, parce que des champs riches nourrissent le matching avec l'historique.

• Cohérence géographique : pays du BIN ↔ IP ↔ adresse de facturation ↔ adresse de livraison ↔ devise ;
• Cohérence d'identité : nom porteur ↔ nom sur l'email ↔ historique de la carte chez ce marchand ;
• Cohérence temporelle : heure locale plausible (timezone navigateur vs IP), vélocité raisonnable (pas 4 pays en 1 h) ;
• Cohérence de marquage : ECI aligné avec le CAVV, indicateurs MIT alignés avec l'absence de CVV, montant aligné avec le type d'opération.

Bonnes pratiques « issuer-friendly »

{
  "amount": { "value": 8990, "currency": "EUR" },   // centimes, devise de la carte
  "paymentMethod": {
    "type": "networkToken",                          // DPAN plutôt que PAN
    "number": "4895370000000000",                    // network token Visa
    "expiryMonth": "03", "expiryYear": "2028",
    "cryptogram": "AgAAAAAAAIR8CQrXcIhbQAAAAAA="     // TAVV fourni par le TSP
  },
  "shopper": {
    "email": "marie.dupont@example.fr",              // email ancien = signal fort
    "telephoneNumber": "+33612345678",
    "ipAddress": "92.184.100.23"                     // IP residentielle FR
  },
  "billingAddress":  { "street": "12 rue de la Paix", "city": "Paris",
                       "postalCode": "75002", "country": "FR" },
  "deliveryAddress": { "street": "12 rue de la Paix", "city": "Paris",
                       "postalCode": "75002", "country": "FR" },
                                                     // livraison = facturation : +score
  "browserInfo": {                                   // device data 3DS2
    "userAgent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_5...)",
    "language": "fr-FR", "timeZoneOffset": -120,
    "screenWidth": 390, "screenHeight": 844,
    "javaEnabled": false, "colorDepth": 24
  },
  "shopperStatement": "MODETEX*ROBE PARIS",          // soft descriptor lisible
  "shopperInteraction": "Ecommerce",                 // CIT (pas un MIT)
  "threeDS2RequestData": { "challengeIndicator": "noPreference" }
}
// Chaque champ optionnel rempli reduit l'incertitude de l'emetteur.
// Coherence FR partout : BIN FR + IP FR + adresses FR + EUR -> frictionless probable.

Un dernier facteur d'acceptation tient à la qualité de la relation acquéreur-émetteur. Les grands PSP entretiennent des programmes bilatéraux avec les principaux émetteurs. Ces programmes portent sur le partage de signaux et sur la calibration des règles de décision. À mix de trafic égal, deux acquéreurs affichent parfois 2 à 4 points d'écart d'acceptation sur les mêmes émetteurs. Cet écart se mesure, et sa vérification passe par un POC conduit avant la signature du contrat.

Le retry intelligent : rejouer sans se faire sanctionner

Une re-présentation, ou retry, consiste à soumettre de nouveau une demande d'autorisation après un refus de l'émetteur. Les schemes classent les codes réponse en deux familles. Les refus définitifs couvrent la carte perdue, la carte volée et le compte clos, que l'émetteur n'approuvera jamais. Les refus temporaires couvrent la provision insuffisante, l'indisponibilité du système et le plafond atteint. Rejouer un refus définitif reste sans effet, se facture et dégrade la réputation du MID. Rejouer un refus temporaire au moment opportun récupère plusieurs points de revenu, enjeu particulièrement sensible sur les modèles par abonnement.

• Classer chaque refus : définitif / temporaire / soft decline / technique ;
• Soft decline → re-soumission immédiate avec 3DS ;
• Technique (91, timeouts) → retry immédiat, cascade multi-acquéreur si disponible ;
• Temporaire (51, 05) → planifier : J+1, J+3, dates de salaire, plafond 3-4 tentatives ;
• Avant tout retry sur 54/05 : interroger l'account updater et basculer sur network token si possible ;
• Définitif (41, 43, 57, MAC 03) → arrêt immédiat, notifier le client, proposer un autre moyen de paiement.

Mesurer le taux d'acceptation : auth rate vs conversion

L'expression « taux d'acceptation » recouvre plusieurs métriques distinctes, qui portent le même nom sans se calculer de la même façon. Deux prestataires qui mesurent chacun la sienne produisent des chiffres non comparables sur un même trafic, et la confusion la plus courante porte sur deux de ces métriques. Le taux d'autorisation traduit la décision de l'émetteur. La conversion de paiement inclut l'abandon au challenge 3DS et les erreurs techniques.

100  checkouts inities
 -4   abandons formulaire (UX, moyens de paiement absents)     -> 96
 -2   rejets anti-fraude marchand (pre-autorisation)           -> 94
 -6   abandons ou echecs 3DS (challenge non complete)          -> 88
 -7   refus emetteur (05, 51, 54...)                           -> 81
 +2   recuperes par retry / soft decline re-soumis en 3DS      -> 83

Auth rate brut        : ~87 %   (83 approbations / 95 demandes : 88 premieres
                                 tentatives + 7 retries)
Auth rate net         : ~94 %   (83 ventes / 88 tentatives uniques arrivees
                                 en autorisation)
Conversion checkout   :  83 %   (83 paiements / 100 checkouts)
=> Trois chiffres differents, tous "taux d'acceptation" dans une reunion.