🎛️ L'orchestration des paiements

Pourquoi un marchand cesse d'avoir un seul prestataire

La multiplication des prestataires désigne la pratique par laquelle un marchand contracte avec plusieurs acquéreurs pour encaisser les ventes d'un même catalogue. Elle apparaît dès la deuxième frontière franchie. Un vendeur limité à un seul pays encaisse sans difficulté auprès d'un prestataire unique. Le premier motif de cette multiplication est la couverture, autrement dit l'ensemble des méthodes de paiement qu'un prestataire sait effectivement traiter. Aucun acquéreur ne se branche avec la même profondeur sur Pix au Brésil, sur UPI en Inde, sur QRIS en Indonésie, sur BLIK en Pologne et sur M-PESA au Kenya. Un catalogue annonçant deux cents méthodes en couvre une bonne partie par des accords de revente auprès de tiers, et non par un branchement direct sur le rail.

Trois autres motifs interviennent ensuite, dans cet ordre. Le taux d'acceptation varie d'un prestataire à l'autre sur un trafic identique, parce que l'émetteur ne voit ni le même présentateur ni les mêmes données. Le coût varie parce que l'acquisition domestique évite les surcharges transfrontalières et la conversion de devise. La résilience vient au dernier rang, seule des quatre à ne se mesurer qu'après l'incident. Tant qu'aucune route n'est tombée, le marchand ne dispose d'aucune mesure du comportement de son dispositif de secours.

Anatomie d'une couche d'orchestration

Une couche d'orchestration désigne un intermédiaire logiciel placé entre la boutique et les prestataires de paiement. Elle expose au marchand une interface unique et traduit chaque demande vers le rail retenu. Le routage n'en constitue qu'une fonction sur six. Son objet central est le contrat d'abstraction offert au marchand. Celui-ci consiste en un objet de paiement unique, un cycle de vie unique et un vocabulaire d'états unique, quel que soit le rail employé dessous. Le reste des fonctions découle de cette promesse, dont la tenue se heurte à la diversité des cycles de vie propres à chaque rail.

• Catalogue de méthodes : ce qui existe, où, dans quelle devise, sous quel connecteur, et ce qui est indisponible à l'instant de l'affichage ;
• Coffre de credentials : cartes chiffrées, jetons réseau, mandats de prélèvement, alias de portefeuille, tenus hors des prestataires ;
• Moteur de règles : routage, cascade, demandes d'exemption, plafonds par méthode, modifiables sans redéploiement applicatif ;
• Normalisation : un modèle d'objet et une taxonomie d'états communs à tous les rails, le code d'origine restant systématiquement joint ;
• Observabilité : le journal de toutes les routes envisagées, et pas seulement de celle qui a été retenue ;
• Réconciliation : agrégation de fichiers de règlement hétérogènes, rapprochement jusqu'au versement bancaire reçu.

Router par le coût et par le taux d'acceptation

Le routage sélectionne, pour chaque transaction, la combinaison de prestataire et de paramètres qui maximise une fonction objectif définie par le marchand. Cette fonction est la marge nette attendue. Elle multiplie la probabilité d'approbation par le montant du panier, puis retranche le coût de la route et la perte de fraude attendue. Le taux d'acceptation n'en constitue qu'un terme sur trois. Deux routes affichant 92 % d'acceptation ne produisent pas la même marge lorsque l'une coûte trente points de base de plus que l'autre. Une route dont l'acceptation progresse de deux points parce qu'elle laisse passer des transactions frauduleuses détruit de la valeur, les frais de litige s'ajoutant au montant du panier perdu. Un pilotage fondé sur le seul taux d'acceptation produit ainsi des décisions fausses.

# E[marge] = P(approbation | route, bin, montant) x (panier - cout_route)
#          - P(fraude nette | route, signaux) x (panier + frais_de_litige)

candidats = []
for route in routes_eligibles(methode, devise, pays_emetteur):
    if not route.sante_ok:              # circuit breaker : erreurs techniques
        continue                        # au-dela du seuil sur 5 min -> route retiree

    p_ok  = modele.proba_approbation(route, bin, montant, heure_locale)
    cout  = route.interchange + route.scheme_fees + route.marge + route.fx
    p_frd = modele.proba_fraude(route, signaux_device, signaux_compte)

    score = p_ok * (panier - cout) - p_frd * (panier + frais_de_litige)
    candidats.append((score, route))

choisie = max(candidats)[1]
journaliser(candidats)                  # TOUTES les routes, pas seulement la retenue

# Sans le journal des routes ecartees et de leur score, aucun contrefactuel
# n'est calculable ensuite : on ne saura jamais ce qu'aurait donne l'autre
# chemin, et le modele de routage ne pourra pas etre reevalue honnetement.

Trois décisions de configuration portent l'essentiel du gain. Elles précèdent l'intervention de tout modèle statistique. La première consiste à acquérir dans le pays d'émission de la carte, et la deuxième à régler dans la devise du porteur. La troisième consiste à présenter la marque domestique lorsque la carte en porte une. Ces trois décisions relèvent du contrat et du paramétrage, et non de l'apprentissage automatique. Un modèle n'intervient ensuite que pour départager des routes déjà équivalentes, et il affine une décision prise ailleurs sans constituer un levier de premier ordre.

Failover, cascade et retry différé

Le failover, la cascade et le retry différé portent des noms voisins et désignent trois réponses distinctes à l'échec d'une tentative de paiement. Le failover répond à l'indisponibilité d'une route et bascule la tentative vers une route de secours. La cascade répond à un refus reçu de l'émetteur et représente immédiatement la transaction auprès d'un second prestataire. Le retry différé répond à un refus d'origine économique, tel qu'une provision insuffisante. La nouvelle tentative est reportée à une date ultérieure, la cause pouvant disparaître avec l'approvisionnement du compte. Leur confusion produit deux erreurs symétriques. Le marchand abandonne des ventes qui auraient abouti après un délai, ou accumule des tentatives qui déclenchent les pénalités prévues par les réseaux.

• Compter les tentatives par carte et par marchand, tous prestataires confondus : les plafonds des réseaux s'appliquent à travers les acquéreurs, jamais acquéreur par acquéreur. Visa borne les tentatives à quinze par carte sur trente jours glissants ;
• Lire le Merchant Advice Code de Mastercard avant de décider : 01 signale que de nouvelles informations de compte existent, 02 autorise une reprise ultérieure, 03 et 21 l'interdisent ;
• Journaliser la cause de chaque tentative et pas seulement son résultat, sinon aucune règle de retry ne pourra être évaluée après coup ;
• Limiter la cascade à une reprise. Au-delà, la latence ajoutée et les frais d'autorisation dépassent le montant récupéré ;
• Distinguer la relance technique de la relance commerciale : un abonnement en échec se traite par un calendrier de représentation, pas par un rebond immédiat.

Normaliser les codes de refus

La normalisation des codes de refus désigne la projection des motifs d'échec émis par chaque rail sur un référentiel commun à la couche d'orchestration. Elle répond à l'hétérogénéité des vocabulaires en usage. La carte répond par deux caractères dans le champ DE39 d'un message ISO 8583, tandis que le prélèvement européen rejette avec un code ISO 20022 de quatre caractères, du type AM04 ou AC06. UPI renvoie les codes de réponse de NPCI, Pix des motifs portés par des messages ISO 20022 sous supervision du Banco Central do Brasil, un portefeuille asiatique ses libellés propriétaires. Aucun de ces vocabulaires ne se traduit exactement dans un autre.

La normalisation projette tous ces codes sur un ensemble d'états petit et stable. L'ensemble reste petit parce qu'une taxonomie de quarante états ne sera jamais appliquée correctement par les équipes produit. La liste reste stable parce que les règles de retry, les tableaux de bord et les engagements de service s'y adossent pour des années. Le code d'origine est toujours conservé.

RETRY_NOW        La route a echoue, pas la transaction.
                 carte 91 / 96 | rejet technique ISO 20022 | echec de switch UPI
                 -> failover immediat vers une autre route, sous idempotence

RETRY_LATER      Refus economique reversible avec le temps.
                 carte 51 | SEPA AM04 | solde insuffisant en mobile money
                 -> calendrier de representation, jamais de rebond immediat

NEED_AUTH        Authentification exigee, transaction rejouable telle quelle.
                 carte 65 (Mastercard) / 1A (Visa) | PIN ou biometrie A2A refaite
                 -> rejeu avec 3-D Secure, sur la meme route

NEED_CREDENTIAL  L'instrument doit changer avant toute nouvelle tentative.
                 carte 54 | SEPA AC04 | compte de portefeuille desactive
                 -> Account Updater, ou demande d'un nouveau moyen au client

TERMINAL         Ne jamais rejouer, quelle que soit la route.
                 carte 41 / 43 / 59 | Merchant Advice Code 03 et 21 | SEPA AC06, AG01
                 -> marquer le credential, arreter le cycle de relance

UNKNOWN          Non mappe. Une dette technique, pas une categorie de travail.
                 -> mesurer sa part par connecteur ; au-dela de quelques pour cent,
                    la couche uniformise au lieu de normaliser

Champs conserves a cote de l'etat canonique, sans exception :
  raw_code, raw_network, raw_message, raw_advice_code, route_id, attempt_id

Les réseaux carte transmettent, à côté du code de refus, deux informations qui portent une instruction et non un verdict. Le Merchant Advice Code de Mastercard indique s'il faut reprendre la transaction immédiatement, la reprendre plus tard, ou renoncer définitivement à toute nouvelle tentative. Les services de mise à jour de credentials (Visa Account Updater, Mastercard Automatic Billing Updater) renseignent une autre question, celle de savoir si le porteur détient désormais une carte différente. Une couche d'orchestration qui n'exploite pas ces deux canaux fonde ses règles de relance sur le seul code de refus. Les réseaux ont pourtant déjà produit cette information.

Les orchestrateurs du marché

Le marché de l'orchestration s'est constitué en quatre vagues, dont la première précède l'apparition du terme lui-même. Les années 2000 voient naître des passerelles de passerelles, alors que la catégorie n'a pas encore de nom. La fin des années 2010 est marquée par l'absorption des premiers indépendants par des PSP. Une troisième génération est fondée entre 2020 et 2022 par d'anciens dirigeants de PayPal, de Braintree, de Rappi et de Delivery Hero. La quatrième vague, en cours, vient des PSP eux-mêmes, qui intègrent l'optimisation dans leur propre pile.

Dans le flux ou hors du flux : la question qui décide du statut

Le régime juridique d'une couche d'orchestration dépend d'un seul critère, celui de savoir si elle entre en possession des fonds. Une couche hors du flux achemine des messages sans jamais détenir d'argent. Les fonds vont du payeur à l'acquéreur, puis de l'acquéreur au marchand, et la couche conserve le statut de prestataire technique. Une couche dans le flux encaisse au nom du marchand, détient temporairement les fonds et les reverse ensuite. Elle relève dès lors du régime des établissements réglementés, pays par pays.

Le basculement d'un régime à l'autre se produit souvent sans décision explicite. Un marchand réclame un versement consolidé, une place de marché demande une répartition entre vendeurs, une juridiction impose l'encaissement par une entité locale. La couche qui accepte l'une de ces demandes reçoit les fonds, et change par là de métier : elle quitte le statut de prestataire technique pour celui d'établissement réglementé. Le contrôle des changes impose ce passage dans plusieurs marchés. L'encaissement s'y fait en monnaie locale auprès d'une entité du pays, tandis que le rapatriement en devise forte relève d'un contrat entièrement distinct.

• Propriété des credentials : sous quel identifiant de demandeur de jeton (Token Requestor ID) les jetons réseau sont-ils provisionnés, celui du marchand, ou celui du prestataire ? La réponse détermine la réversibilité réelle ;
• Export : format, délai et coût d'une extraction complète du coffre, éprouvés une fois avant d'en avoir besoin ;
• Route de contournement : capacité contractuelle et technique d'appeler un prestataire en direct, sans passer par la couche ;
• Journal : accès aux codes bruts, aux routes écartées et à leurs scores, exportables sans dépendre de l'interface du fournisseur ;
• Sous-traitance : liste des hébergeurs et des sous-traitants ultérieurs, avec droit d'opposition et préavis ;
• Sortie : durée de réversibilité, assistance à la migration, sort des données après résiliation, y compris des jetons.

Le coût caché d'une couche de plus

Le coût d'une couche d'orchestration se répartit sur trois postes distincts. Le premier est monétaire et porte sur chaque transaction présentée, quelle qu'en soit l'issue. Le deuxième est la latence ajoutée sur le chemin critique du paiement, chaque appel supplémentaire allongeant le temps d'autorisation. Le troisième est une dépendance nouvelle, la couche devenant le point de passage unique des prestataires que le marchand avait multipliés pour réduire son exposition.

Le premier coût figure au contrat et se négocie. Les deux autres se constatent à l'usage et ne se corrigent qu'en refaisant l'intégration. Un programme d'orchestration dont la mesure se limite aux montants facturés pilote la variable la moins déterminante des trois, et laisse hors de vue la latence et la dépendance.

• Rapporter le coût de la couche au chiffre d'affaires autorisé, et non au volume d'appels : une transaction refusée consomme aussi des frais ;
• Mesurer la latence ajoutée au 95e centile, par région d'hébergement, avant puis après la mise en service ;
• Suivre la part des credentials détenus sous un identifiant de demandeur de jeton du marchand, car c'est la mesure directe de la réversibilité ;
• Nommer un propriétaire des règles de routage, dater chaque revue, supprimer les règles dont plus personne ne connaît la raison ;
• Exécuter le contournement en production au moins deux fois par an, journaliser le résultat, corriger ce qui a échoué.