Comment fonctionne le paiement par carte : modèle à quatre coins, autorisation et PCI DSS

Payer d'un geste avec sa carte est l'une des rares expériences grand public qui cachent toute une industrie derrière une seconde de latence. Pendant cette seconde, une requête part du terminal vers une banque acquéreuse, traverse le réseau d'un système de cartes, atteint la plateforme d'autorisation d'une banque émettrice, puis revient avec un code d'approbation. Ensuite, dans les jours qui suivent, un ensemble de fichiers entièrement distinct déplace l'argent, applique les commissions et, à l'occasion, annule tout.

Les développeurs n'en voient généralement qu'une tranche — un formulaire de paiement ou le SDK d'un terminal — et héritent d'un vocabulaire qui paraît arbitraire tant que la vue d'ensemble manque. Ce guide la fournit. Il suppose connus les concepts de grand livre et de règlement présentés dans les fondamentaux des systèmes de paiement ; la carte n'est qu'un instrument qui repose sur eux.

Le modèle à quatre coins

La transaction carte classique fait intervenir quatre institutions et repose sur une asymétrie très utile.

• Le porteur détient une carte émise à son nom.
• L'émetteur est la banque du porteur. Il tient le compte, décide d'approuver ou non une transaction et supporte l'essentiel des pertes pour fraude sur les transactions authentifiées.
• Le commerçant vend quelque chose et veut être payé.
• L'acquéreur est la banque du commerçant. Il l'enrôle, reçoit ses transactions et le paie, commissions déduites.
• Le réseau de cartes — le scheme — se place entre émetteur et acquéreur : il fournit le réseau de commutation, les règles communes, l'arbitrage des litiges et le calcul du règlement. Il n'est pas partie à la vente.

L'asymétrie tient à ceci : le porteur et le commerçant n'ont aucune relation avec la banque de l'autre, et pourtant la transaction fonctionne parce que les deux banques appliquent les mêmes règles. Ce sont ces règles, et non un quelconque contrat bilatéral, qui rendent une carte utilisable dans un pays où vous n'avez jamais mis les pieds.

Un modèle à trois coins fusionne émetteur, acquéreur et réseau en une seule entreprise, en relation directe avec le porteur comme avec le commerçant. Elle y gagne un contrôle plus serré sur la tarification et l'acceptation, au prix d'un parc de commerçants qui s'étend bien plus lentement. Dans la pratique, les grands réseaux combinent aujourd'hui les deux.

Entre le commerçant et l'acquéreur, la plupart des entreprises modernes intercalent un prestataire de services de paiement (PSP) ou une passerelle, qui fournit les API, la page de paiement hébergée, les tokens et souvent le moteur de risque. Certains prestataires détiennent d'ailleurs eux-mêmes la licence d'acquéreur.

La carte, le numéro et la puce

Le numéro de compte principal (PAN) compte normalement 16 chiffres, même si la norme en autorise jusqu'à 19. Les premiers chiffres forment l'issuer identification number (historiquement le BIN), qui identifie l'établissement émetteur, le réseau et le type de produit ; c'est sur lui que reposent les décisions de routage et d'acceptation, avant tout appel réseau. Le dernier chiffre est une clé de contrôle calculée avec l'algorithme de Luhn.

Validate 4111 1111 1111 1111

Starting from the rightmost digit, double every second digit
(the check digit itself is never doubled). If a doubled value
exceeds 9, subtract 9.

  digits   4  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
  double   x     x     x     x     x     x     x     x
  becomes  8  1  2  1  2  1  2  1  2  1  2  1  2  1  2  1

  sum = 8 + (7 x 2) + (8 x 1) = 8 + 14 + 8 = 30
  30 mod 10 == 0  ->  the number is internally consistent

Pour générer une clé de contrôle plutôt que la vérifier, appliquez la même pondération au numéro avec un zéro en dernière position, puis calculez (10 - sum mod 10) mod 10.

function luhnValid(pan) {
  let sum = 0;
  for (let i = 0; i < pan.length; i++) {
    let d = pan.charCodeAt(pan.length - 1 - i) - 48;
    if (d < 0 || d > 9) return false;
    if (i % 2 === 1) { d *= 2; if (d > 9) d -= 9; }
    sum += d;
  }
  return pan.length >= 12 && sum % 10 === 0;
}

Physiquement, la carte a beaucoup évolué depuis la piste magnétique, qui stockait une copie statique des données et pouvait donc être clonée par quiconque la lisait une seule fois. Les cartes à puce EMV la remplacent par un petit ordinateur qui signe un cryptogramme portant sur les détails de la transaction, avec une clé qui ne quitte jamais la puce : un échange intercepté ne peut donc pas être rejoué. Le sans contact, c'est la même cryptographie sur une interface radio, avec des plafonds hors ligne et des demandes de code PIN périodiques pour borner le risque en cas de carte perdue.

Dans un wallet sur téléphone ou montre, la carte est tokenisée par le réseau : le wallet détient non pas le vrai numéro mais un token PAN propre à l'appareil, émis par le service de tokenisation du réseau, avec son propre cryptogramme à chaque transaction. Si le token fuite, il est inutilisable sur un autre appareil, et il n'est pas nécessaire de réémettre la carte sous-jacente. La tokenisation des cartes enregistrées (card-on-file) applique la même idée aux abonnements, avec un effet de bord appréciable : les mises à jour de date d'expiration se propagent sans que le client ait quoi que ce soit à faire.

Les trois ou quatre chiffres imprimés sur la carte (le cryptogramme visuel) n'existent que pour prouver la possession de la carte lors des transactions à distance. Les conserver après l'autorisation est purement et simplement interdit : aucune configuration conforme ne vous permet de les garder.

Autorisation, capture, compensation, règlement

Quatre mots que les débutants emploient indifféremment et qui désignent quatre choses distinctes.

L'autorisation demande à l'émetteur, en temps réel, de vérifier le compte et de réserver le montant. La réponse est un code d'approbation ou un motif de refus. Aucun argent ne bouge ; la réservation diminue le solde disponible du porteur et expire au bout d'un délai fixé par le réseau si elle n'est pas utilisée.

La capture (ou finalisation) indique à l'acquéreur que la marchandise est partie et que le commerçant réclame désormais le montant. Beaucoup d'entreprises autorisent au moment du paiement et capturent à l'expédition ; les hôtels et les stations-service autorisent une estimation puis capturent un montant final différent, dans certaines limites.

La compensation (clearing) est l'échange, via le réseau, des enregistrements de transactions capturées entre acquéreur et émetteur, généralement par lots quotidiens, en appliquant au passage l'interchange et les frais de réseau.

Le règlement (settlement) est le mouvement effectif des fonds entre les banques, en net après compensation par le réseau, suivi du paiement du commerçant par l'acquéreur selon son propre calendrier.

Day 0  10:32  Authorization request  (terminal -> acquirer -> scheme -> issuer)
       10:32  Approval, funds reserved on the cardholder account
Day 1  09:00  Capture / presentment batch sent by the acquirer
Day 1  22:00  Clearing: scheme computes net positions, applies fees
Day 2  08:00  Interbank settlement
Day 3        Merchant credited, net of the merchant service charge
Day 40       Cardholder disputes -> chargeback -> possible representment

Les commissions circulent en sens inverse de l'argent. Le commerçant paie à son acquéreur une commission de service, sur laquelle l'acquéreur verse l'interchange à l'émetteur et des frais au réseau. L'interchange explique que les émetteurs puissent proposer des cartes gratuites et des programmes de fidélité, et c'est aussi pour cela que les régulateurs de plusieurs régions l'ont plafonné pour les cartes des particuliers. Considérez ces mécanismes comme conceptuels : les taux évoluent et dépendent de la juridiction.

Les chargebacks sont le mécanisme de contestation. Un porteur se plaint auprès de son émetteur, qui reprend les fonds à l'acquéreur sous un code motif (fraude, non-livraison, montant erroné, double traitement), et le commerçant peut répondre avec des preuves dans une représentation. Les réseaux surveillent les taux de chargeback, et un taux durablement élevé coûte au commerçant son droit d'accepter les cartes. Concrètement, vos systèmes doivent pouvoir produire, des mois plus tard, la preuve de ce qui a été commandé, authentifié, expédié et livré — un argument de plus pour conserver des journaux de commandes et d'authentification immuables.

Authentification : 3-D Secure et SCA

Les transactions à distance n'ont pas de puce pour prouver la présence de la carte ; les réseaux ont donc conçu 3-D Secure : une étape d'authentification qui se joue entre le commerçant, le serveur d'annuaire (directory server) du réseau et le serveur de contrôle d'accès (ACS) de l'émetteur. La première génération, c'était la fameuse page pop-up de mot de passe. La génération actuelle est fondée sur le risque : le commerçant envoie un large ensemble de données sur l'appareil, la transaction et le comportement, et l'émetteur choisit entre une approbation frictionless et un challenge (en général une notification push dans l'application bancaire).

En Europe, l'authentification forte du client (SCA) exige, pour la plupart des paiements électroniques, deux facteurs indépendants parmi la connaissance, la possession et l'inhérence, avec des exemptions définies : transactions de faible montant, paiements récurrents d'un montant fixe après le premier, commerçants que le porteur a placés en liste blanche, et analyse de risque de la transaction sous un seuil de taux de fraude. Le contexte réglementaire est celui décrit dans DSP2 et open banking.

Deux conséquences techniques en découlent. D'abord, l'authentification est asynchrone et peut entraîner une redirection ou l'ouverture d'une application : votre tunnel de paiement doit donc pouvoir reprendre là où il s'est arrêté. Un client qui s'authentifie sur son téléphone et revient deux minutes plus tard ne doit pas perdre son panier. Ensuite, une authentification réussie transfère généralement la responsabilité de la fraude à l'émetteur ; l'intérêt d'un challenge n'est donc pas seulement réglementaire, il change qui paie lorsque la transaction se révèle frauduleuse.

{
  "amount": { "currency": "EUR", "value": 4990 },
  "paymentMethod": { "type": "scheme", "token": "tok_9f3c1a7b" },
  "authentication": {
    "threeDSRequestorChallengeIndicator": "no-preference",
    "exemption": "transaction-risk-analysis"
  },
  "merchantOrderReference": "ORD-2026-114522",
  "shopperInteraction": "Ecommerce"
}

PCI DSS : garder un périmètre réduit

Le Payment Card Industry Data Security Standard s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de carte. Ses exigences couvrent la segmentation réseau, le chiffrement en transit et au repos, le contrôle d'accès, la journalisation, la gestion des vulnérabilités et les tests réguliers ; l'effort de validation va d'un court questionnaire d'auto-évaluation à un audit sur site, selon le volume et le type d'intégration.

La décision d'architecture la plus rentable, et de loin, consiste à rester totalement en dehors de l'environnement des données de titulaires de carte. Du moins contraignant au plus lourd :

1. Redirection ou page de paiement hébergée. Le client saisit sa carte sur la page du prestataire. Vos serveurs ne voient jamais de PAN.
2. Champs hébergés / iframe. Les champs de carte sont rendus par le prestataire à l'intérieur de votre tunnel de paiement : l'apparence est la vôtre, les données sont les siennes. C'est en général le meilleur compromis.
3. Chiffrement côté client ou API directe vers le prestataire. Le navigateur chiffre les données de carte ou les envoie directement au prestataire ; votre backend ne reçoit qu'un token.
4. Collecte côté serveur. Votre application reçoit des PAN en clair. Périmètre d'audit complet, tests d'intrusion, segmentation, gestion des clés : cela ne vaut la peine qu'avec une très bonne raison.

Quel que soit votre choix, les défenses habituelles restent de mise : ne journalisez jamais un PAN ni un cryptogramme visuel (filtrez au niveau du framework de logging, pas à chaque point d'appel), masquez en ne gardant que les six premiers et les quatre derniers chiffres lorsque l'affichage est réellement nécessaire, stockez des tokens plutôt que des numéros en base, et traitez la page de paiement comme critique pour la sécurité, car un script injecté à cet endroit neutralise n'importe quelle iframe. Les guides OWASP Top 10 et architecture de sécurité applicative couvrent l'hygiène qui l'entoure.

S'intégrer avec un prestataire

Voici une check-list d'intégration réaliste, que bien des équipes ont apprise à leurs dépens :

• Idempotence sur chaque appel qui modifie un état. Une capture relancée ne doit pas capturer deux fois ; envoyez une clé stable dérivée de votre identifiant de commande.
• Ce sont les webhooks qui font foi, pas la réponse HTTP. Résultats d'autorisation, chargebacks et notifications de règlement arrivent de façon asynchrone, parfois dans le désordre et plus d'une fois. Vérifiez les signatures, dédoublonnez sur l'identifiant d'événement et rendez vos handlers idempotents.
• Stockez les références du prestataire — code d'autorisation, identifiant de transaction, token, référence réseau — à côté de votre commande. Chaque échange avec le support et chaque litige en auront besoin.
• Rapprochez chaque jour le rapport de règlement de vos propres enregistrements, en faisant la correspondance sur la référence du prestataire, et alertez sur les éléments non rapprochés dans les deux sens.
• Modélisez explicitement les captures partielles, les remboursements partiels et les expirations. Ce ne sont pas des cas limites, c'est le quotidien.
• Testez les refus, pas seulement les acceptations. Les prestataires publient des cartes de test pour les fonds insuffisants, les cartes expirées, le « do not honour », le challenge 3-D Secure et les timeouts. Un tunnel de paiement qui ne gère que le succès n'est écrit qu'à moitié.
• Ne construisez jamais votre propre boucle de relance sur un refus. Les tentatives répétées sur une carte refusée sont pénalisées par les réseaux, et c'est ainsi qu'un commerçant finit dans un programme de surveillance.

Concevez la frontière de l'API de façon à pouvoir remplacer le prestataire : une petite abstraction de paiement interne, avec votre propre vocabulaire de statuts, traduite à la périphérie, vous évite une réécriture quand les conditions commerciales changent. Les principes généraux de conception d'API REST s'appliquent directement.

Points clés à retenir

• Quatre institutions — émetteur, acquéreur, réseau et commerçant, le plus souvent accompagnés d'un PSP — coopèrent selon les règles d'un réseau que ni le porteur ni le commerçant ne signent.
• Le PAN encode l'émetteur dans ses premiers chiffres et se termine par une clé de Luhn qui détecte les fautes de frappe, et rien de plus.
• Les cryptogrammes EMV et les tokens réseau remplacent des données de carte statiques et clonables par une preuve propre à chaque transaction ; c'est pour cela que les wallets sont plus sûrs que les numéros qu'ils cachent.
• L'autorisation réserve, la capture réclame, la compensation échange les enregistrements et le règlement déplace l'argent — à plusieurs jours d'intervalle, avec des litiges qui peuvent remonter des mois en arrière.
• 3-D Secure et l'authentification forte ajoutent de la friction mais transfèrent la responsabilité de la fraude ; construisez un tunnel de paiement qui peut être interrompu puis repris.
• Choisissez une intégration qui tient les données de carte hors de vos serveurs : le périmètre PCI DSS se décide par l'architecture bien avant de se décider par la paperasse.