Étapes et statuts des transactions
Chaque paiement suit un parcours. Ce qui semble instantané pour un consommateur — ce rapide message « approuvé » à l’écran — est en réalité une chaîne d’étapes étroitement orchestrées qui se déroulent entre plusieurs systèmes en seulement quelques secondes. Parcourons d’abord le flux heureux typique, celui où tout se passe bien.
Le flux heureux
Tout commence lorsqu’un consommateur initie un paiement : en ligne ou sur un terminal. Le système du marchand ou la passerelle de paiement envoie une demande d’autorisation sécurisée via l’acquéreur et le réseau de cartes vers l’émetteur, en posant une question simple mais cruciale : cette carte est-elle valide, y a-t-il suffisamment de fonds et cette carte peut-elle être autorisée ?
Si l’émetteur approuve, la transaction est autorisée. À ce stade, les fonds ne sont pas encore transférés. Ils sont simplement réservés sur le compte du client, en attente que le marchand les finalise plus tard. Cet état de réservation empêche que le même argent soit dépensé deux fois.
Une fois que le marchand confirme la commande ou expédie les marchandises, il envoie une instruction de Capture. Dans certains cas, cette étape se fait automatiquement, sans approbation du marchand. Cela indique à l’acquéreur : « Oui, versez l’argent maintenant ». L’acquéreur regroupe ensuite plusieurs Captures et les soumet aux réseaux de cartes pendant le clearing.
Enfin, lors de la phase de Settlement, le transfert effectif des fonds a lieu. L’émetteur envoie l’argent (moins les frais) à l’acquéreur, qui paie ensuite le marchand. Cela se produit généralement sous un à trois jours ouvrables, selon l’accord de Settlement du marchand.
Dans un monde parfait, chaque paiement s’arrêterait là : le client est satisfait, le marchand est payé, et tout le monde passe à autre chose. Mais les paiements ne sont pas toujours parfaits — parfois ils sont annulés, remboursés ou contestés.
Quand les choses ne se passent pas comme prévu
Tous les paiements n’ont pas une fin heureuse. Parfois, les clients annulent, les transactions échouent ou des litiges surviennent des semaines plus tard. Dans les paiements, ces « mauvais flux » sont tout aussi importants à comprendre que les bons. Ils montrent comment le risque, les annulations et la protection du client fonctionnent en pratique. Examinons les trois flux d’exception les plus courants : les voids, les refunds et les chargebacks.
Voids / Annulations
Un void se produit lorsqu’une transaction est annulée avant d’être capturée ou réglée. On peut le voir comme l’annulation d’une autorisation qui n’a pas encore été transformée en véritable transfert d’argent.
Par exemple, un client peut annuler une commande juste après l’avoir passée, ou un marchand peut remarquer une transaction en double. Dans de tels cas, au lieu de traiter un refund (qui renvoie l’argent et prend quelques jours), le marchand peut void l’autorisation.
Comme les fonds n’étaient que réservés et n’ont jamais réellement été déplacés, un void libère simplement la retenue sur le compte du client. Le solde disponible du titulaire de la carte revient à la normale, généralement sous un jour ou deux (ou instantanément, cela dépend de la banque du consommateur !), et aucun frais n’est impliqué au-delà du coût initial de l’autorisation. En bref, un void est une annulation propre : rapide, efficace et invisible pour la plupart des clients.
Refunds
Un refund intervient après qu’une transaction a été capturée et réglée. Cela signifie que le marchand a déjà reçu les fonds, mais doit maintenant en restituer une partie ou la totalité. Les refunds sont courants dans le commerce quotidien : produit retourné, réservation annulée ou erreur de facturation. Ils peuvent être complets (la totalité du montant) ou partiels (seulement une partie du paiement). Selon le type de transaction, un seul ou plusieurs refunds peuvent être possibles.
Lorsqu’un refund est déclenché, le système du marchand envoie un message via l’acquéreur et le réseau de cartes vers l’émetteur, lui demandant de créditer le compte du client. Selon le réseau et les banques concernés, ce processus peut prendre de un à cinq jours ouvrables. Et il peut même falloir plus de temps au consommateur pour recevoir ses fonds (pensez à la banque émettrice ou au marchand qui met plus de temps à traiter une demande).
Selon la passerelle, un refund peut être créé comme une transaction distincte ou comme partie de l’organisation parente dans l’outil de gestion du marchand. Dans certains cas, les refunds peuvent ne pas être liés à une autorisation parente. On peut les appeler unreferenced refunds.
Bien que simple du point de vue du client, les refunds entraînent un coût opérationnel pour le marchand. La plupart des acquéreurs facturent de petits frais par refund, et dans de nombreux cas, les frais de transaction initiaux ne sont pas remboursés. Des refunds fréquents peuvent également nuire à la réputation d’un marchand auprès des acquéreurs ou des prestataires de paiement.
Chargebacks
Le chargeback est le pire scénario dans la vie d’une transaction. Il se produit lorsque l’émetteur annule de force un paiement après un litige client. Voici comment cela se déroule généralement : un titulaire de carte remarque un débit inconnu ou problématique et contacte sa banque pour le contester. L’émetteur enquête et, si la réclamation semble fondée, retire les fonds de l’acquéreur du marchand : qui débite à son tour le compte du marchand.
Les raisons des chargebacks varient :
- Fraude ou utilisation non autorisée d’une carte
- Marchandises non reçues ou services non fournis
- Articles non conformes à la description
- Double facturation ou erreurs techniques
- Refunds promis mais jamais reçus
Pour les marchands, un chargeback est à la fois une perte de fonds et un signal potentiel de mauvaise expérience client ou d’exposition à la fraude. Chaque chargeback s’accompagne également de frais administratifs. Si le marchand estime que le litige est injuste, il peut le contester. Cela implique de soumettre des preuves (comme des confirmations de livraison, des reçus ou des correspondances) pour démontrer que la transaction était légitime. Cependant, même en cas de succès, la representment demande du temps et des efforts. Des chargebacks répétés peuvent entraîner des pénalités ou une inclusion dans des programmes de surveillance des card schemes. Chargeback = pas bon. Le mieux est de régler d’abord le litige avec le consommateur.
Et puis il y a les erreurs
Même les systèmes de paiement les mieux conçus trébuchent parfois. Toutes les transactions n’atteignent pas la ligne d’arrivée. Les declines et les erreurs font partie de la vie quotidienne des paiements — la friction invisible derrière « quelque chose s’est mal passé ». Elles peuvent survenir pour des centaines de raisons, d’une simple faute de frappe à quelque chose d’aussi grave qu’une fraude suspectée.
Pour les marchands, ces moments sont frustrants ; pour les clients, ils sont simplement déroutants. Les principaux responsables :
- Fonds insuffisants (≈ 30–40 % des declines) — la raison la plus simple et la plus humaine
- Règles de risque ou de fraude de l’émetteur (≈ 25 %) — les banques bloquent ce qui semble suspect, surtout les transactions transfrontalières ou inhabituellement élevées
- Cartes expirées ou inactives (≈ 10 %) — encore étonnamment courant
- Erreurs techniques (≈ 10 %) — pannes réseau, timeouts ou incompatibilités de protocole
- Identifiants incorrects (≈ 5–10 %) — mauvais CVV, code postal ou échec de 3-D Secure
Les bons prestataires atténuent cela grâce à des retries intelligents, à la tokenization réseau et à un routage intelligent. Même une amélioration de deux points du taux d’approbation peut représenter des millions de revenus supplémentaires pour les grands marchands. Les declines ne disparaîtront jamais, mais comprendre pourquoi elles se produisent aide les marchands à corriger ce qui dépend d’eux — et à arrêter de blâmer ce qui n’en dépend pas. Voyons pourquoi elles se produisent et comment elles sont généralement classées.
Hard Declines
Un hard decline signifie que l’émetteur — la banque du client — a refusé catégoriquement la transaction, et qu’aucune retry n’aidera. Les raisons courantes incluent :
- Fonds insuffisants ou limite de crédit dépassée
- Carte expirée.
- Numéro de carte invalide (PAN saisi incorrectement ou obsolète)
- Carte perdue ou volée
- Carte restreinte (non activée pour certaines régions, devises ou catégories de marchands)
Lorsque cela se produit, l’autorisation échoue immédiatement. Le marchand peut afficher un message d’erreur convivial, mais réessayer ne résoudra rien — le client doit utiliser un autre moyen de paiement. De nombreux hard declines peuvent être évités en amont en détectant les erreurs de saisie évidentes : longueur incorrecte du numéro de carte, CVV invalide ou cartes expirées.
Soft Declines
Un soft decline est différent. L’émetteur refuse temporairement la transaction, mais une retry peut réussir. Ceux-ci sont souvent liés à l’authentification ou à des problèmes réseau temporaires, tels que :
- Échec ou timeout de l’authentification 3D Secure
- Système de l’émetteur indisponible
- Erreur temporaire de routage ou de l’acquéreur
- Limite quotidienne dépassée ou schéma de dépenses inhabituel
Dans de tels cas, la passerelle peut réessayer automatiquement ou inviter le client à réessayer. Les soft declines sont courants dans l’e-commerce, où plusieurs systèmes et réseaux doivent rester synchronisés.
Fraud-Related Declines
Il y a aussi les declines déclenchés par des systèmes de prévention de la fraude — côté émetteur, côté acquéreur ou côté marchand. Exemples :
- Localisation inhabituelle ou empreinte d’appareil
- Plusieurs échecs de CVV ou de 3D Secure
- Limites de velocity (trop de transactions en peu de temps)
- Test de cartes par des bots ou des données volées
Les filtres anti-fraude s’ajustent en permanence. Parfois, ils bloquent un acheteur légitime — un faux positif. Trouver l’équilibre entre la détection de la fraude et l’acceptation des vrais clients est l’un des plus grands défis des paiements. Certains prestataires permettent désormais aux marchands d’ajuster leurs propres règles de risque afin d’affiner cet équilibre.
Communication and Technical Errors
Parfois, le problème ne vient ni de la carte ni du client. Les erreurs techniques se produisent lorsqu’un message de transaction ne parvient pas à circuler correctement — timeouts, données mal formées, pannes de l’acquéreur ou incompatibilités de protocole.
Les passerelles gèrent généralement cela en réessayant ou en mettant les transactions en file d’attente pour une soumission ultérieure. La plupart sont résolues rapidement, mais si l’erreur survient pendant l’autorisation, le paiement échoue simplement. Pour les marchands et les PSP, c’est le pire scénario — perte de revenus sans coupable évident. Dans les cas graves, de telles pannes peuvent même déclencher des pénalités ou des demandes de service-credit contre la partie responsable.
Statuts des transactions
Chaque paiement que vous effectuez ou traitez passe par une série de statuts. Des instantanés de l’endroit où cette transaction se trouve actuellement dans son parcours.
Ces statuts aident les marchands, les passerelles et les acquéreurs à suivre l’avancement, détecter les problèmes et rapprocher les fonds. Bien que la vie complète d’une transaction implique des autorisations, des Captures, des refunds et des chargebacks, ces statuts représentent les points de contrôle en cours de route. Ces statuts peuvent différer selon la passerelle ou le prestataire de services. Pour simplifier, j’ai essayé de résumer les statuts existants dans le tableau ci-dessous et leur flux.

| Statut | Description | Signification dans le flux |
|---|---|---|
| Pending | La transaction vient d’être créée — soit par un utilisateur, un terminal POS, soit un appel API. C’est la toute première étape, qui ne dure souvent que quelques secondes avant de passer à la suivante. | Considérez cela comme « paiement demandé ». Rien n’a encore été confirmé. |
| Authorized | L’émetteur a approuvé le paiement, et les fonds sont réservés sur le compte du titulaire de la carte. Le marchand doit encore Capturer le montant pour recevoir réellement l’argent. | La transaction a réussi du point de vue du client, mais elle n’est pas encore finalisée. |
| Cancelled / Void | La transaction a été annulée avant Capture. Aucun fonds n’a été déplacé, et la retenue d’autorisation a été levée. | Souvent utilisé pour les commandes annulées ou les transactions en double détectées tôt. |
| Declined | L’acquéreur ou l’émetteur a rejeté la transaction. Aucune réservation ni transfert de fonds n’a eu lieu. | Le client peut devoir essayer une autre carte ou un autre moyen de paiement. |
| Failed | La transaction n’a pas abouti en raison d’un problème technique — peut-être un timeout, une panne réseau ou un format de message invalide. | Aucune réponse d’autorisation n’a été reçue ; il s’agit d’une erreur de traitement plutôt que d’un refus financier. |
| Captured | Le marchand a confirmé la transaction, et le montant spécifié est en cours de traitement pour le Settlement. | L’argent est effectivement engagé et sera transféré lors du prochain cycle de clearing. |
| Submitted | La transaction a été transmise à l’acquéreur pour le clearing. Elle est maintenant dans la file d’attente pour être traitée via les schemes. | Entre « Captured » et « Cleared ». Utile pour le suivi de rapprochement. |
| Cleared | L’acquéreur a envoyé la transaction aux schemes et attend le Settlement final. (Statut spécifique à Planet.) | La transaction a bien traversé le pipeline financier mais n’a pas encore été payée. |
| Funded | L’acquéreur a terminé le versement sur le compte bancaire du marchand. (Statut spécifique à Planet.) | Le marchand a reçu les fonds — l’étape financière finale. |
| Partially Refunded | Seule une partie du montant capturé a été retournée au client. | Courant lorsqu’un marchand ajuste pour des articles retournés ou des annulations partielles. |
| Refunded | La totalité du montant capturé a été retournée au client. | La transaction est clôturée des deux côtés ; le marchand ne détient plus les fonds. |
| Disputed | Le titulaire de la carte a contesté la transaction, et une enquête est en cours. | Le montant peut être temporairement retenu jusqu’à la résolution du litige. |
| Chargeback | Le litige a été résolu en faveur du titulaire de la carte, et les fonds ont été retournés sur son compte. | Un refund forcé a été traité |
Pfiou... si vous êtes arrivé jusqu’ici, félicitations. Comprendre les statuts est probablement l’un des plus grands défis lorsqu’on veut comprendre les paiements.