🚫 Les refus de paiement et leur traitement

Anatomie d'un refus

Un refus de paiement désigne la réponse négative renvoyée à une demande d'autorisation ou à un ordre présenté sur un rail. L'établissement qui détient les fonds du payeur prend la décision, puis la transmet sous la forme d'un code de deux ou trois caractères. Ce code n'expose presque jamais le motif retenu. Il indique surtout ce qui peut être tenté ensuite. Le traitement se joue donc sur la réversibilité du refus, et non sur son pourquoi, qui reste hors de portée du marchand dans la plupart des cas.

Une demande de paiement traverse plusieurs maillons avant d'atteindre l'émetteur. Chacun d'eux peut la rejeter. La chaîne compte six points de rejet distincts, dont trois se situent chez le marchand ou chez son prestataire. Le code visible ne désigne pas le maillon qui a tranché. L'attribution par défaut de tout refus à l'émetteur constitue l'erreur de diagnostic la plus fréquente. Un indicateur qui agrège les six maillons dans une même moyenne ne permet pas de les séparer.

La répartition des refus entre ces maillons se mesure, à condition d'instrumenter chaque étage du tunnel et pas seulement sa sortie. Un moteur de risque qui bloque 6 % du trafic avant tout envoi au réseau élève mécaniquement le taux d'autorisation affiché par ce réseau. Les tentatives écartées n'atteignent jamais l'émetteur. Le chiffre d'affaires correspondant disparaît sans qu'aucun code réseau en garde la trace. Le marchand, qui lit un taux d'autorisation flatteur et un chiffre d'affaires en retrait, interroge son acquéreur et perd deux semaines. Le rejet venait de son propre moteur.

Soft decline et hard decline : une distinction de praticiens

Les expressions « soft decline » et « hard decline » désignent, dans le vocabulaire des praticiens, un refus temporaire et un refus définitif. Aucune norme ne les définit. Le couple ne figure ni dans ISO 8583, ni dans les règles de Visa, ni dans celles de Mastercard, et il vient entièrement de l'usage professionnel. Il classe les refus selon leur réversibilité, une propriété qui ne se confond pas avec la gravité du motif. Un refus pour provision insuffisante est bien plus banal qu'un refus pour carte expirée, et les deux appellent pourtant des traitements opposés.

Trois familles suffisent à couvrir la matière, et la partition en deux laisse dans le même ensemble des refus qui appellent des gestes différents. La première famille réunit les refus qu'un délai suffit à lever. La deuxième réunit ceux qui exigent une modification de l'instrument ou du message avant tout nouvel envoi. La troisième réunit ceux qu'aucune tentative ultérieure ne lèvera.

• Réversible par le temps. L'instrument est valide, le payeur est solvable demain. Carte 51, prélèvement AM04, solde insuffisant en mobile money. La tentative suivante se calendarise ; elle ne se rejoue pas dans la minute.
• Réversible par une action. L'instrument ou le message doit changer avant tout nouvel envoi. Carte 54 sur une carte réémise, 65 ou 1A quand une authentification est exigée, AC01 sur un compte mal saisi. Rejouer à l'identique reproduit le refus.
• Irréversible. Le refus vaut pour toutes les routes et toutes les dates. Carte 41, 43, 59, prélèvement AC04 ou MD07, instruction réseau interdisant la reprise. Toute nouvelle tentative consomme un compteur et coûte des frais.

Ces catégories deviennent un enjeu commercial dès qu'un prestataire les produit à la place du marchand. Un prestataire qui restitue la mention « soft decline » sans le code d'origine impose sa propre lecture au marchand, et cette lecture n'est pas auditable. Deux prestataires classent rarement le même code dans la même famille. Le classement relève du marchand, qui doit pour cela recevoir la donnée brute intacte.

ISO 8583 : ce que la norme fixe, ce que les réseaux réécrivent

ISO 8583 est la norme internationale qui décrit le format des messages échangés entre systèmes de paiement lors d'une transaction par carte. Dans un message d'autorisation, le verdict tient dans un champ unique, le DE39, auquel la version de 1987 donne deux caractères alphanumériques. Cette version reste massivement déployée. La révision ISO 8583-1:2003 porte le champ à trois caractères. Les deux formats coexistent dans le parc mondial, et la conversion de l'un vers l'autre occupe une partie de l'activité des processeurs. La norme publie une table de valeurs, tout en réservant des plages à l'usage privé et national, d'où sont sorties toutes les divergences.

MTI  : 0110                reponse a une demande d'autorisation
DE38 : ------              code d'autorisation : vide si refus
DE39 : 05                  code reponse : le verdict, deux caracteres
DE44 : 2 M                 resultats additionnels : controle d'adresse, CVV2
DE48 : ...84=02...         champ prive : chez Mastercard, le Merchant Advice Code
DE54 : ...                 soldes restitues par l'emetteur, quand il les fournit
DE62 : ...                 champ prive du reseau : motifs internes, indicateurs

A conserver systematiquement a cote du DE39 :
  le reseau qui a repondu, la version ISO utilisee (2 ou 3 caracteres),
  le code d'instruction s'il existe, le resultat d'authentification 3-D Secure,
  l'identifiant de tentative et l'identifiant de route.

La table ISO donne au 65 le sens d'un plafond de fréquence dépassé. Mastercard a réaffecté cette valeur à l'exigence d'authentification forte apparue avec la DSP2. Visa a retenu une autre voie, la valeur 1A, absente de la table numérique d'origine et hors de toute plage prévue pour ce sens. Les deux réseaux répondent ainsi au même besoin réglementaire par deux valeurs incompatibles, que le marchand doit traiter l'une et l'autre.

Une seconde couche de réécriture intervient côté acquéreur, beaucoup de processeurs normalisant les réponses avant de les restituer. Cette normalisation vise à offrir un jeu de codes homogène à travers les réseaux. Elle fait disparaître l'information qui distingue 65 de 61, ou 1A de 05. L'usage consiste à faire préciser par écrit si l'acquéreur applique un remappage, et à obtenir le champ d'origine à côté du champ normalisé.

Les codes propriétaires : chaque réseau parle sa langue

Un code propriétaire est une valeur de refus définie par un réseau de cartes en dehors de la table ISO. Chaque scheme publie sa propre table dans ses règles, à ses adhérents. Aucun dictionnaire mondial ne les rassemble. Un marchand qui accepte six marques traite donc six vocabulaires, dont certains ne sont pas publics. La liste ci-dessous couvre les réseaux qu'un acquéreur international rencontre, avec leur exploitant et leur année de lancement.

Mastercard fournit, en plus du verdict, une instruction explicite, le Merchant Advice Code, qui indique ce que le marchand a le droit de faire après l'échec. Cette valeur porte une consigne de reprise. Elle ne renseigne pas le motif du refus. De toute la réponse d'autorisation, elle est la donnée la plus directement actionnable, et celle que les intégrations omettent le plus souvent.

• 01 signale que de nouvelles informations de compte existent : interroger le service de mise à jour avant toute reprise.
• 02 autorise une reprise plus tard : la cause est temporaire, le calendrier s'applique.
• 03 interdit de réessayer : toute tentative ultérieure est une infraction aux règles, facturée.
• 21 annonce l'annulation du paiement récurrent : l'abonnement doit être arrêté côté marchand, pas simplement mis en échec.

Hors carte : ISO 20022, ACH, UPI et les rails poussés

Les rails autres que la carte disposent chacun de leur propre jeu de codes de refus. Le prélèvement européen rejette avec des codes ISO 20022 de quatre caractères. L'ACH américain renvoie des codes commençant par la lettre R, quand UPI répond avec des valeurs propres à la NPCI. Pix passe par des messages ISO 20022 placés sous les règles du Banco Central do Brasil. Aucun de ces vocabulaires ne se traduit exactement dans un autre.

Le rail américain est le seul à borner explicitement l'exposition du créancier par des ratios chiffrés. Les Nacha Operating Rules fixent un taux de retours non autorisés de 0,5 %, un seuil d'enquête de 3 % sur les retours administratifs et de 15 % sur l'ensemble des retours. Le dépassement de ces seuils relève de l'institution d'origine, qui ferme le rail au préavis de son choix, sans intervention d'un régulateur. Le taux de refus fonctionne donc, sur ce rail, comme une condition d'accès au service, et non comme un indicateur de performance.

UPI présente une difficulté liée au nombre d'intervenants. Une transaction traverse l'application tierce, la banque sponsor, le switch de la NPCI, la banque du payeur et celle du bénéficiaire. Le code renvoyé n'identifie pas toujours l'intervenant à l'origine de l'échec. La NPCI publie pour cette raison des statistiques de refus par banque, en séparant les échecs techniques des refus de gestion. Cette publication expose la part d'échecs imputable à chaque banque, et aucun autre rail n'offre à ce jour une donnée équivalente.

Les rails poussés par le payeur forment une dernière famille, dans laquelle l'ordre de paiement est émis par le client. PromptPay est exploité par National ITMX sous mandat de la Bank of Thailand depuis 2017, PayNow par BCS pour le compte de l'Association of Banks in Singapore depuis la même année. DuitNow est opéré par Payments Network Malaysia (PayNet) depuis 2018, avec sa norme DuitNow QR de 2019, tandis que QRIS est imposé par Bank Indonesia avec l'ASPI depuis 2019. Le marchand n'y émet aucune demande d'autorisation. Il présente un moyen d'initiation, le plus souvent un code QR, puis attend la notification de règlement.

La relance : ce que les règles autorisent, ce qu'elles facturent

La relance désigne la présentation d'une nouvelle demande après un refus, sur le même instrument et pour la même créance. Les réseaux l'ont bornée, chiffrée et tarifée à partir de 2021. La mesure fait suite à des années pendant lesquelles certains marchands rejouaient des refus définitifs des dizaines de fois par carte. Les réseaux justifient ces limites par la capacité d'autorisation que consomme chaque tentative, et par l'usure qu'infligent les tentatives répétées à la relation entre l'émetteur et son client.

• Compter les tentatives par instrument et par marchand, tous prestataires confondus. Un montage multi-acquéreur ne remet aucun compteur à zéro.
• Fixer un plafond interne inférieur à celui du réseau, appliqué par le code et non par une consigne d'équipe.
• Journaliser la cause de chaque tentative, pas seulement son résultat. Sans cela, aucune politique de relance ne peut être évaluée après coup.
• Espacer les représentations sur les refus de provision. Rejouer dans la minute ne change rien à l'état du compte et consomme le quota.
• Distinguer la relance technique, qui se compte en secondes, de la relance commerciale, qui se compte en jours et relève du produit.

Ce que le refus coûte, et pourquoi personne ne le voit

Le coût d'un refus se compose d'un revenu non encaissé et de dépenses induites. Le refus est, à ce titre, le seul poste du paiement qui n'apparaisse sur aucune facture : aucun relevé, aucun avis de règlement, aucune ligne de commission ne le mentionne. À trafic constant, un point de taux d'autorisation gagné vaut un pour cent de chiffre d'affaires encaissé. Un comité qui négocie deux points de base de marge acquéreur pendant six semaines travaille donc sur une variable dont l'enjeu est souvent dix fois inférieur à celui du taux d'acceptation.

Le coût se répartit sur quatre postes, dont trois échappent au reporting du paiement. Le premier se lit sans effort. Les trois autres se logent dans le produit, dans le marketing et dans le service client, où le rattachement à un code réponse n'est pas établi.

Mesurer : un taux ne se pilote pas, un mix se pilote

La mesure du refus repose sur deux objets distincts, un taux global et une distribution de codes. La variation du taux global n'ouvre par elle-même aucune action, puisqu'elle ne précise ni le segment qui a bougé, ni le code dont le poids a augmenté, ni si l'écart dépasse le bruit statistique. La distribution des codes, elle, désigne le segment et le code dans l'heure. Une hausse concentrée sur 65 et 1A désigne un périmètre d'exemption trop large, une hausse de 54 sur les seuls abonnements un parc de coordonnées vieillissant, une rafale de 14 sur des montants minuscules une attaque.

Par tentative, conserves tels quels :
  code_origine          valeur exacte renvoyee, non remappee
  reseau                Visa, Mastercard, UnionPay, RuPay, TROY, Elo...
  version_iso           2 ou 3 caracteres : change le sens de la valeur
  code_instruction      Merchant Advice Code, ou vide si le reseau n'en produit pas
  resultat_auth         issue 3-D Secure, ou absence d'authentification
  bin_emetteur          6 a 8 premiers chiffres : la maille de diagnostic reelle
  pays_emission         distinct du pays du client
  canal                 premiere transaction, coordonnee stockee, recurrent, wallet
  rang_tentative        1, 2, 3... sur le meme instrument et le meme marchand
  route                 acquereur et identifiant de contrat utilises

Ratios derives, calcules par code et par segment :
  part_du_code          poids dans l'ensemble des refus
  taux_recuperation     tentatives suivantes abouties / tentatives relancees
  part_non_mappee       refus tombant dans l'etat inconnu -- une dette, pas une categorie

La segmentation minimale tient en six axes : BIN de l'émetteur, pays d'émission, type de carte, canal, tranche de montant, présence d'authentification. Un taux global agrège ces six axes, et une anomalie limitée à un seul segment y devient une variation de faible amplitude. Une chute concentrée sur deux BIN, tous les autres segments restant plats, désigne un incident d'émetteur, quand une chute transverse à une heure précise désigne un déploiement. Ces deux profils appellent des traitements différents, et un chiffre agrégé les confond. Seule la segmentation les distingue.

Améliorer : les leviers, dans leur ordre de rendement

Les leviers d'acceptation se classent par effort croissant, et l'ordre dans lequel ils sont activés détermine le résultat obtenu. Deux d'entre eux relèvent d'un paramétrage et produisent un effet mesurable en quelques semaines, là où un troisième demande du développement. Le dernier engage une structure juridique et des mois de travail, pour le gain le plus important sur un flux international. Commencer par ce dernier levier immobilise plusieurs mois avant tout résultat, alors que les leviers de paramétrage produisent un effet dans l'intervalle. C'est l'erreur la plus coûteuse du domaine.

Deux pratiques courantes produisent l'effet inverse de celui recherché. La première consiste à désactiver l'authentification pour « débloquer » un flux. Le taux d'autorisation monte pendant quelques jours, puis la fraude et les contestations augmentent, et le coût dépasse le gain avant la fin du trimestre. La seconde consiste à empiler les tentatives sur un refus structurel, ce qui récupère très peu de transactions et remplit les compteurs de surveillance des réseaux.

• Traiter d'abord les refus concentrés : deux BIN qui pèsent 20 % du volume valent tous les réglages globaux réunis.
• Mesurer chaque changement contre un groupe de contrôle. Un taux qui monte après un déploiement ne prouve pas que le déploiement en est la cause.
• Fixer un n minimal par segment avant d'ouvrir un ticket : un écart de trois points sur deux cents transactions n'existe pas statistiquement.
• Escalader les incidents d'émetteur par l'acquéreur, avec l'heure exacte, le BIN et la comparaison à la même heure sept jours plus tôt.
• Réviser la table de correspondance des codes à chaque publication de règles des réseaux, et la dater.