Fiche · Décision de la transaction

TVR, le carnet de notes du terminal

95Terminal Verification Results

Cinq octets où le terminal note tout ce qui s’est mal passé pendant la transaction. Personne ne les lit à l’œil nu, et pourtant c’est ce champ – croisé avec deux autres – qui décide seul, sans réseau, si un paiement est refusé.

Qui l’écrit, qui le lit

Écrit par	Le terminal, et lui seul. La carte n’y touche jamais. Il est remis à zéro au début de chaque transaction et se remplit au fil des étapes.
Lu par	Le terminal lui-même pour décider en local ; la carte, qui le reçoit dans le CDOL au moment du GENERATE AC ; l’émetteur, qui le reçoit dans le message d’autorisation (champ 55).
Le piège	Un bit à 1 n’est pas un refus. C’est un constat. Ce qui transforme un constat en refus, c’est le croisement avec les action codes – voir plus bas.

40 bits, 26 utilisés

Les 14 bits gris ne sont pas « libres » : ils sont réservés par la spécification et doivent rester à zéro. Un TVR dont un bit réservé est à 1 sort d’une implémentation qui bricole, ou d’une capture mal alignée.

Les six bits que vous verrez vraiment

Sur les 26, une poignée revient en permanence dans les traces réelles. Les autres sont des cas de bord ou des reliquats d’une époque où l’authentification statique existait encore.

Octet 1 · bit 8 · 80 00 00 00 00 Authentification offline des données non réalisée
Le terminal n’a pas vérifié la signature de la carte. Ce n’est pas forcément une anomalie : en transaction en ligne systématique, beaucoup de configurations sautent l’étape. C’est le bit le plus fréquemment allumé du TVR, et celui qui affole le plus de monde à tort.
Octet 1 · bit 3 Échec CDA
Là en revanche, la carte n’a pas su prouver son authenticité de façon dynamique. Sur une carte moderne, ce bit ne devrait jamais être à 1. S’il l’est en série sur un parc, c’est le certificat de l’émetteur ou la clé publique du réseau qu’il faut aller regarder dans le terminal, pas les cartes.
Octet 2 · bit 7 Application expirée
Le terminal compare la date d’expiration de la carte à sa propre date. Un terminal dont l’horloge a dérivé refuse donc des cartes parfaitement valides – et le TVR est le seul endroit où ça se voit.
Octet 3 · bit 8 Vérification du porteur en échec
Le CVM choisi n’a pas abouti. À croiser systématiquement avec le tag 9F34 (CVM Results), qui dit lequel a échoué. Le TVR dit qu’il y a eu un problème, le 9F34 dit lequel.
Octet 4 · bit 8 · 00 00 00 80 00 Dépassement du plafond (floor limit)
Le montant dépasse le plancher au-delà duquel le terminal doit demander une autorisation. C’est le bit qui envoie la transaction en ligne dans l’écrasante majorité des cas – et le plus simple à provoquer volontairement pour tester une chaîne.
Octet 4 · bit 5 Transaction sélectionnée aléatoirement pour passer en ligne
Le terminal tire au sort. C’est voulu : ça empêche un fraudeur de rester indéfiniment sous le plafond en sachant qu’il ne montera jamais. Ce bit explique les « pourquoi celle-là est passée en ligne et pas l’autre » qui n’ont aucune autre explication.

La mécanique que personne n’explique

Le TVR seul ne décide de rien. Il est croisé, bit à bit, avec deux jeux de masques : les Terminal Action Codes, posés par l’acquéreur dans la configuration du terminal, et les Issuer Action Codes, portés par la carte elle-même (tags 9F0E, 9F0F, 9F0D). Le terminal combine les deux, puis fait un ET logique avec le TVR. Un seul bit qui ressort à 1 suffit.

Et quand le terminal veut monter en ligne mais n’y arrive pas – ligne coupée, serveur muet – il rejoue le même calcul avec un troisième masque, le TAC-Default, pour trancher tout seul. C’est là que se jouent les refus « inexplicables » d’un magasin dont la liaison est instable.

Décoder une vraie valeur

TVR = `00 00 00 80 00`

Cinq octets, on les lit dans l’ordre. Les octets 1, 2, 3 et 5 sont à zéro : rien à signaler côté authentification, application, porteur, dialogue émetteur.
Octet 4 = 0x80 = 1000 0000 en binaire, donc le bit 8 est à 1.
Octet 4, bit 8 : dépassement du plafond. Le montant est au-dessus du floor limit configuré.
Le terminal croise avec son TAC-Denial : ce bit n’y est pas → pas de refus local.
Il croise avec son TAC-Online, où ce bit est à 1 dans toute configuration saine → la transaction part en ligne.

Lecture inverse utile en dépannage : une transaction qui monte en ligne alors que le montant est faible, avec un TVR à 00 00 00 08 00, c’est le tirage au sort – pas un incident.

Trois erreurs qu’on entend souvent

« Le TVR est à 80 00 00 00 00, la carte est suspecte. »

Non. Ce bit dit seulement que l’authentification hors ligne n’a pas été faite, ce qui est le comportement normal de beaucoup de configurations en ligne systématique. Le bit qui accuse la carte, c’est l’échec CDA de l’octet 1.

« C’est le terminal qui a refusé, donc c’est le TVR. »

Le TVR constate, il ne décide pas. Sans les action codes en face, il ne se passe rien. Deux terminaux avec le même TVR et des TAC différents prennent deux décisions opposées – et c’est l’acquéreur qui a écrit ces TAC.

« Les bits inutilisés, on peut s’en servir. »

Ils sont réservés par la spécification, et les tests de certification les vérifient. Un octet 5 avec le bit 4 à 1 ne passera pas.

[VOIX ?] – à valider, remplacer ou supprimer par Charles

Trois emplacements attendent du vécu, pas de la doctrine : (1) un cas où l’horloge d’un terminal a fait refuser des cartes valides, avec l’ordre de grandeur du parc touché ; (2) ce qu’on regarde en premier quand un TVR revient avec un échec CDA en série ; (3) une phrase sèche sur les TAC copiés-collés d’un acquéreur à l’autre sans être relus. Sans ça, cette fiche reste excellente et impersonnelle – exactement ce que fait déjà la documentation existante.

Décoder votre propre TVR L’entrée courte dans le lexique Voir aussi : 9F34, CVM Results