En bref : une description de paiement, également appelée libellé de relevé ou libellé de transaction, est la courte chaîne de caractères qui accompagne une transaction par carte et s'affiche à côté du montant sur un relevé bancaire ou dans une application. Pour les paiements par carte, elle est définie par le commerçant ou son prestataire de services de paiement et limitée à environ 22 caractères, ce qui explique pourquoi elle ressemble si souvent à une suite de lettres aléatoires plutôt qu'à un nom reconnaissable. Lorsqu'une opération affiche un préfixe de passerelle tel que PAYPAL ou SQ, le véritable commerçant est généralement encodé dans la chaîne après l'astérisque, mais l'identifier de manière fiable à grande échelle est un problème d'enrichissement de données.
C'est le champ unique qui détermine le plus si un client reconnaît ce qu'il a acheté, à qui il a payé et si la transaction est légitime. Les banques le contrôlent rarement et, sous sa forme brute, il est rarement assez clair pour être affiché.
Qu'est-ce qu'une description de paiement ?
Comme indiqué, une description de paiement est le texte destiné au client qui apparaît à côté d'une transaction sur un relevé bancaire ou dans une application bancaire. Pour un paiement par carte, elle provient d'un champ appelé libellé de paiement (également connu sous le nom de libellé de relevé ou libellé de transaction) : une courte chaîne que le commerçant soumet au réseau de cartes en même temps que la transaction. Pour un virement bancaire ou un flux d'open banking, elle provient d'un champ totalement différent : le message au destinataire ou la référence de paiement définie par le payeur ou le système d'origine. Quoi qu'il en soit, c'est la ligne de texte que le client lit pour identifier l'opération.
Pour les transactions par carte, le format est très limité. Chez la plupart des processeurs traditionnels, le champ du nom commercial (DBA) est limité à 22 caractères, avec un supplément de 11 caractères pour un champ ville ou contact. Un libellé de relevé complet doit contenir entre 5 et 22 caractères, être composé uniquement de caractères latins, contenir au moins une lettre et exclure les caractères spéciaux tels que <, >, , ', ", et *. Certains réseaux autorisent jusqu'à 25 caractères, mais 22 est la limite pratique sur laquelle la plupart des commerçants se basent. Compressez un nom comme « Marks & Spencer - Simply Food, Prague » en 22 caractères et vous comprendrez pourquoi le résultat est si souvent illisible.
Le libellé est défini par le commerçant ou son prestataire de services de paiement. La banque le reçoit. En dehors du rejet ou de la mise en forme de la chaîne, la banque n'a aucun contrôle éditorial sur ce qui lui parvient.
Pour un examen plus approfondi de l'ensemble des champs qui accompagnent une transaction par carte, tels que les identifiants de terminal, les identifiants de commerçant, les codes MCC, les libellés ou la norme ISO 18245, consultez ce que contiennent réellement les données de transaction et d'où elles proviennent.
Des sources différentes signifient des descriptions différentes
La description de paiement n'a pas de source unique. Elle dépend du réseau de paiement utilisé pour la transaction, et chaque réseau produit un type de chaîne différent avec un niveau de structure variable.
Transactions par carte (Visa, Mastercard) : La description provient du libellé de relevé du commerçant, un champ limité et abrégé défini par le commerçant ou le processeur. C'est la source que la plupart des gens associent aux textes de transaction illisibles.
Virements bancaires (SEPA, BACS, Faster Payments, CERTIS) : La description provient d'un champ de référence en texte libre défini par le payeur. Il est généralement plus long qu'un libellé de carte (140 caractères pour le SEPA), mais le contenu est ce que l'expéditeur a saisi.
Données d'open banking (PSD2 AISP) : Lorsqu'une banque ou une fintech lit les transactions via des API d'open banking, le champ de description peut à nouveau contenir une valeur différente. Il s'agit parfois de la chaîne du commerçant, parfois de la référence de paiement, ou encore du nom d'une contrepartie extrait des propres registres de la banque.
Un flux d'application bancaire mélange tout cela. L'utilisateur ne sait pas par quel réseau une transaction donnée est arrivée, et il ne devrait pas avoir à le savoir. Pour présenter un flux cohérent, la banque doit normaliser les descriptions provenant de sources multiples en une identité de commerçant unique et reconnaissable.
Libellé fixe (hard) vs libellé temporaire (soft) vs libellé dynamique
Pour les paiements par carte en particulier, trois termes sont utilisés de manière approximative dans le secteur, alors qu'ils décrivent deux choses différentes.
Les termes « fixe » (hard) et « temporaire » (soft) concernent le timing. Un libellé temporaire (soft) apparaît pendant la demande d'autorisation, c'est-à-dire le débit en attente que le titulaire de la carte voit en ligne avant le règlement définitif. Un libellé fixe (hard) est la chaîne finale inscrite sur le relevé une fois la transaction réglée. Les deux sont souvent, mais pas toujours, identiques.
Les termes « statique » et « dynamique » concernent la variation de la chaîne selon la transaction. Un libellé statique est défini au niveau du compte commerçant et ne varie jamais : chaque débit provenant de ce MID apparaît avec le même texte. Un libellé dynamique est généré par programme pour chaque transaction, combinant généralement un préfixe fixe (le nom commercial) avec un suffixe contenant des détails tels qu'une référence de commande, une gamme de produits ou le nom d'un vendeur sur une place de marché.
Un exemple concret pour chacun :
- Statique / fixe (hard) : JOHN LEWIS LONDON GB - la même chaîne apparaît sur chaque transaction J. Lewis.
- Dynamique / temporaire (soft) : MKTPLC*VENDOR-44871 - une plateforme de place de marché transmet un identifiant par vendeur lors de l'autorisation.
- Dynamique / fixe (hard) : RUNCLUB* OCT MARATHON - format de type Stripe où les 7 premiers caractères constituent le préfixe du nom commercial et le reste décrit l'achat spécifique.
Un commerçant peut utiliser un descripteur fixe (ce que font la plupart des petites entreprises) ou un descripteur dynamique (places de marché, plateformes d'abonnement, détaillants multi-produits). Ces termes se complètent et ne s'excluent pas mutuellement.
Comment identifier le commerçant derrière un débit PayPal ou Stripe
Les passerelles de paiement sont la raison la plus fréquente pour laquelle une description désigne la mauvaise entité. Lorsqu'un paiement est traité via PayPal, Stripe, Square, Adyen ou un processeur similaire, la chaîne de caractères qui parvient à la banque commence souvent par le nom de la passerelle, et non celui du vendeur. Le véritable commerçant, s'il apparaît, est relégué en suffixe. Pour une banque ou une fintech qui développe un flux de transactions, comprendre ces modèles fait toute la différence entre une chaîne identifiable et un espace réservé de type « commerçant inconnu ».
PayPal : Un débit traité par PayPal apparaît généralement sous la forme «PAYPAL » suivi d'un identifiant de vendeur compressé - PAYPAL*EBAYNCSHIP,PAYPAL*STEAMGAMES,PAYPAL*JOHNSMITH. Le nom du vendeur après l'astérisque est tronqué et souvent dépourvu d'espaces, ainsi EBAYNCSHIP correspond à eBay, et non à un commerçant nommé « Ebayncship ». Pour un paiement entre particuliers ou auprès d'un petit vendeur, le suffixe peut être le nom d'une personne ou un identifiant commercial qui ne correspond à aucune marque publique.
Stripe : Les descripteurs Stripe sont structurés différemment. Stripe divise le descripteur en un préfixe (la plateforme ou l'entreprise que le client doit reconnaître) et un suffixe qui précise le produit ou la commande - par exemple RUNCLUB*OCT MARATHON, où RUNCLUB est l'entreprise et le reste correspond à l'achat. Comme Stripe propulse des milliers d'entreprises indépendantes, le même modèle visuel (NOM* détail) couvre tout, d'une salle de sport à un abonnement SaaS. Le préfixe est votre signal marchand, le suffixe est le contexte.
Square, Adyen et autres : Square utilise généralement le préfixe SQ* (SQ*COFFEE BAR), où le suffixe correspond au nom configuré par le commerçant lui-même. Adyen et d'autres processeurs de plateforme peuvent transmettre le nom de la plateforme, celui du sous-commerçant, ou un mélange des deux, selon la configuration du compte par la plateforme.
L'essentiel à retenir est que le préfixe de la passerelle est un signal à interpréter. Afficher PAYPAL*EBAYNCSHIP et faire apparaître « PayPal » dans le flux est une erreur : le client a payé eBay. Pour une résolution fiable, il faut faire correspondre le modèle de descripteur à un commerçant connu. Tapix gère cela grâce à un module d'enrichissement des passerelles de paiement qui reconnaît les modèles de passerelles des principaux processeurs et associe le suffixe encodé au vendeur vérifié, afin que le flux affiche le commerçant avec lequel le client a réellement effectué sa transaction.
Pourquoi les descriptions de paiement sont souvent méconnaissables
Le champ de description a été conçu à l'ère des relevés papier, où les clients avaient le temps de décoder « TETSPC #4781 » en Tesco Hypermarket. Dans le flux d'une application bancaire en temps réel, cette même chaîne de caractères sème la confusion.
Quatre problèmes structurels expliquent pourquoi la description brute est rarement suffisante pour être affichée.
Les limites de caractères imposent des abréviations agressives. Une limite de 22 caractères pour les descripteurs de carte signifie que tout ce qui dépasse un mot court est coupé, abrégé ou supprimé.
Les noms des sociétés mères apparaissent à la place des noms commerciaux. Un achat dans une chaîne de cafés peut apparaître sous le nom de la société holding qui exploite la franchise, et non sous la marque inscrite sur le gobelet.
Les noms des processeurs de paiement apparaissent. Les paiements en ligne effectués via Stripe, PayPal, Adyen ou Square affichent souvent la passerelle dans la description au lieu du véritable vendeur. Tapix résout ce problème directement grâce à un module d'enrichissement des passerelles de paiement, qui identifie les modèles de transaction des principaux prestataires.
Formatage incohérent selon les acquéreurs et les réseaux. Un même commerçant passant par deux acquéreurs différents peut générer deux libellés de transaction distincts. Un même destinataire de virement bancaire peut apparaître sous des références différentes selon l'initiateur du paiement.
Le résultat, observé sur des données de production réelles : des chaînes de caractères chaotiques comme "F.LLI MARINO SNC" ou "B2B PRIME" qui s'affichent dans les applications sans contexte, sans logo et sans catégorie.
L'impact sur l'activité
Les descriptions illisibles ne sont pas qu'un problème esthétique. Elles ont des conséquences mesurables à trois niveaux.
Rétrofacturations et fraude amicale : Lorsqu'un client ne reconnaît pas une opération sur son relevé, la solution la plus simple pour lui est de la contester. Chaque litige entraîne un coût direct (frais de rétrofacturation, perte de biens ou de services) et un coût indirect lié au temps d'enquête, tant pour le commerçant que pour la banque.
Charge de travail du service client : Chaque appel du type "Je ne reconnais pas cette transaction" qui s'avère légitime est un appel qui n'aurait jamais dû avoir lieu. Aux volumes traités par la plupart des banques, même un faible pourcentage de demandes concernant des transactions non identifiées représente un poste de dépense permanent dans le budget du support.
Érosion de la confiance envers l'application : Un historique de transactions que le client ne peut pas comprendre au premier coup d'œil est un historique auquel il cesse de se fier. Il consulte moins, interagit moins et utilise moins l'application pour les fonctionnalités que les banques souhaitent mettre en avant : suivi des dépenses, gestion des abonnements, budgétisation et résolution des litiges.
Ce que l'enrichissement apporte par rapport à une simple description
L'enrichissement remplace la description brute par une information que le client reconnaît. Plus précisément, il génère trois résultats que le descripteur seul ne peut fournir.
Un nom de commerçant vérifié et officiel : Pas « MKTPLC*VENDOR-44871 » mais « Marks & Spencer ». Ce nom propre est résolu à partir d'une base de données de commerçants, validé par de multiples signaux et cohérent pour toutes les variantes de descripteurs d'un même commerçant.
Un logo de commerçant : La reconnaissance visuelle est plus rapide que la lecture. Le logo de Tesco à côté d'une transaction est identifié en quelques millisecondes, alors que la chaîne « TESCO STORES 2401 » oblige le client à lire, réfléchir et faire le lien.
Une catégorie et une étiquette : Au-delà de l'identification du commerçant, l'enrichissement classe la transaction dans une catégorie telle que Alimentation, Transport, Abonnements ou Restauration. Lorsque la catégorisation des commerçants basée uniquement sur le code MCC est comparée à une catégorisation complète prenant en compte davantage de facteurs, seuls 63 % des transactions sont correctement identifiées sur la base du code MCC. Le MCC seul ne suffit pas ; le descripteur, combiné au MCC et à des signaux contextuels, permet d'obtenir une catégorie sur laquelle le client peut compter.
Comment Tapix résout l'ambiguïté des descriptions
Tapix traite le descripteur comme une donnée parmi d'autres. La logique de correspondance combine le texte du descripteur avec l'identifiant du commerçant (MID), le code de catégorie de commerçant (MCC), les données de localisation du terminal et un graphe de commerçants mis à jour en continu qui associe les modèles de descripteurs connus aux marques vérifiées.
Le modèle de données sous-jacent est hiérarchique. Un terminal de paiement est lié à un magasin (avec GPS, adresse et catégorie). Un magasin est lié à un commerçant (avec son nom officiel et son logo). Lorsqu'une nouvelle variante de descripteur apparaît, le système peut la résoudre par rapport au graphe existant plutôt que de la traiter comme une chaîne inconnue.
Le résultat est ce que le client aurait dû voir dès le départ : un nom reconnaissable nom du commerçant, une logo, une catégorie, et une correspondance résolue entre la passerelle et le commerçant qui élimine le bruit de traitement pour révéler le véritable vendeur. Sur 4 milliards+ de transactions enrichies mensuelles et 1,4 million+ de marchands reconnus dans la base de données, cela fonctionne avec 99,99 % de précision des données avec un temps de réponse moyen de 6 ms par transaction.
L'idée n'est pas que le champ de description doive être corrigé. Ce n'est pas le cas. Les libellés de carte continueront d'arriver sous leur forme brute et abrégée, car c'est le champ défini par les réseaux de paiement et renseigné par les marchands. L'idée est qu'aucune application bancaire ne devrait jamais afficher la description brute à un client. L'enrichissement est la couche intermédiaire entre ce qui arrive via les réseaux de paiement et ce que le client lit ; c'est cette couche qui détermine si le reste de l'application inspire confiance.
Pour une analyse plus approfondie de la manière dont l'infrastructure d'enrichissement doit être conçue en production, le guide des bonnes pratiques de l'API d'enrichissement des transactions couvre les modèles d'intégration, la gestion des erreurs et la différence entre couverture et précision.
