Date d'expiration de carte bancaire : format, règles et cas limites

Une date d’expiration de carte bancaire occupe quatre caractères sur le plastique et provoque un nombre disproportionné de bugs dans le logiciel qui la lit. La valeur imprimée est courte, mais elle porte deux règles distinctes à la fois : à quel mois la carte cesse de fonctionner, et à quel moment du dernier jour de ce mois elle cesse réellement de fonctionner. Se tromper sur la limite est l’une des façons classiques dont un paiement rejette une carte encore parfaitement utilisable.

Les sections qui suivent expliquent ce que signifie la date imprimée, comment fonctionne la règle de fin de mois, pourquoi les formulaires et les bases de données stockent rarement la même chose que ce que montre la carte, et comment tester les cas délicats.

Ce que signifie la date imprimée

La date sur une carte est un mois et une année, chacun écrit sur deux chiffres, le mois en premier : mois neuf et année vingt-six, par exemple, ou mois un et année trente. Il n’y a pas de jour sur la carte, ce qui est la première source de confusion — les gens en cherchent un parce que toutes les autres dates qu’ils manipulent en comportent un.

Le mois et l’année décrivent le moment où la carte cesse d’être valable, et non celui où elle a été émise. Une carte imprimée avec une date de plusieurs années dans le futur est normale, car les émetteurs remplacent généralement une carte bien avant son expiration.

La valeur n’est dérivée de rien d’autre sur la carte. Ce n’est pas une somme de contrôle et elle n’interagit pas avec le numéro. Cela compte pour les tests : une date d’expiration ne peut pas être inventée par arithmétique, donc elle doit être fournie, et c’est pourquoi les cartes générées arrivent avec une date attachée.

Une carte est-elle valable tout le mois ?

Oui. C’est la règle qui prend les gens en défaut. Une carte imprimée avec un mois et une année donnés est acceptée jusqu’au dernier jour de ce mois, jusqu’au dernier instant de ce jour, dans le fuseau horaire utilisé par le système d’autorisation de l’émetteur.

Une carte imprimée avec le mois neuf et l’année vingt-six est donc utilisable le trente septembre de cette année, et elle cesse d’être utilisable au premier instant d’octobre. Tout système qui coupe la carte au début de septembre, ou à minuit le dernier jour, rejette des paiements valides pendant une période mesurée en heures ou en jours.

Le tableau montre aussi pourquoi le nombre de jours compte. Février est le mois délicat, car son dernier jour dépend de l’année, et un formulaire ou une tâche planifiée qui suppose vingt-huit jours se trompera de limite lors d’une année bissextile.

Pourquoi les formulaires demandent-ils deux chiffres au lieu de quatre ?

Les cartes n’impriment que deux chiffres pour l’année afin d’économiser de la place, et les formulaires demandent généralement les deux mêmes parce que c’est ce que l’utilisateur lit. Cette convention transfère une décision au logiciel : à quel siècle la valeur appartient-elle ?

En écrivant le siècle en toutes lettres plutôt qu’en code, l’approche courante consiste à considérer une année à deux chiffres comme appartenant au siècle actuel ou au suivant selon sa proximité avec aujourd’hui. Une valeur d’année qui semble loin dans le passé est presque toujours une faute de frappe, pas une carte d’une époque révolue, et une valeur décodée vers le mauvais siècle sera soit rejetée comme expirée, soit acceptée pour toujours.

L’approche la plus sûre pour un formulaire est d’accepter ce que l’utilisateur a, de le convertir une fois vers une représentation non ambiguë — un mois et une année complète à quatre chiffres, ou un premier jour et un dernier jour — et d’utiliser cette représentation partout ensuite. Ne comparez jamais directement des années à deux chiffres, car la comparaison redéfinit silencieusement le sens du siècle à chaque bascule.

Le format d’affichage et le format stocké sont deux choses différentes

La chaîne qu’un client voit et la valeur qu’un système conserve sont rarement identiques, et les confondre est une source fiable de défauts.

Sur la carte, et dans un champ de saisie, la valeur apparaît sous forme de deux chiffres pour le mois et de deux pour l’année. Dans une base de données, elle est souvent stockée comme une date au premier du mois, ou comme des colonnes entières séparées pour le mois et l’année, ou comme un horodatage du dernier instant de validité. Chaque choix a des conséquences. Un horodatage au premier du mois est facile à trier et à comparer, mais ne vous dit pas quand la carte expire sauf si vous connaissez aussi la règle de fin de mois. Un horodatage au dernier instant encode la bonne limite mais paraît alarmant dans un écran d’administration où personne ne s’attend à voir une heure à côté d’une expiration.

Quelle que soit la représentation choisie, gardez la conversion en un seul endroit. Le bug qui apparaît en production est généralement une seconde conversion écrite par quelqu’un qui ignorait l’existence de la première, et les deux diffèrent d’un mois.

Erreurs courantes lors de la saisie d’une date d’expiration

Les erreurs que les gens commettent sur ce champ suivent une courte liste, et chacune appelle une réponse sensée :

• Saisir l’année sur quatre chiffres dans un champ à deux chiffres. Acceptez-le si vous pouvez le mapper sans ambiguïté, et ne supprimez pas silencieusement les caractères initiaux.
• Intervertir le mois et l’année. Mois treize et année vingt-huit sont tous deux invalides, donc validez chaque partie selon son propre intervalle plutôt que seulement leur combinaison.
• Saisir un mois avec un zéro initial dans un champ qui attend un seul chiffre. Traitez un et zéro-un comme le même mois.
• Coller une valeur avec un séparateur que le champ n’attend pas, comme un tiret là où une barre oblique devrait figurer.
• Saisir une date déjà passée, qui est un rejet que le formulaire devrait expliquer plutôt que simplement signaler.

Pour les développeurs : contrôles de saisie et tests de limites

Deux petits contrôles évitent l’essentiel de ces maux. Premièrement, séparez le mois et l’année en champs distincts, ou utilisez un champ unique qui guide visiblement la forme attendue, afin qu’une valeur intervertie soit improbable plutôt que simplement détectable. Deuxièmement, validez chaque composant selon son propre intervalle avant de valider la combinaison, pour que l’utilisateur sache quelle partie est fausse.

Pour la logique de limite, testez les extrémités de l’intervalle plutôt que le milieu. Les quatre cas qui méritent d’être écrits sont le premier jour du mois imprimé, le dernier jour du mois imprimé, le lendemain du dernier jour, et le même cas du dernier jour lors d’une année bissextile. Un test écrit contre le milieu d’un mois ne prouve presque rien de la règle que vous cherchez à protéger.

Vérifiez ensuite comment votre système se comporte lorsque l’horloge avance. Si une expiration stockée est convertie une fois au moment de la soumission et jamais revue, un formulaire laissé ouvert au passage d’un mois soumettra une date qui vient de devenir invalide. Décidez délibérément s’il s’agit d’une erreur qui mérite d’être signalée ou d’un cas limite acceptable, et assurez-vous que la demande de paiement et vos propres enregistrements sont d’accord sur ce point.

Obtenir une expiration correspondante depuis l’outil de carte

Chaque carte produite par le générateur de numéros de carte est livrée avec une date d’expiration qui suit la même convention : un mois et une année dans le futur, cohérents sur tout un lot. Cette cohérence est ce qui rend un jeu de fixtures utilisable — un test qui associe un numéro à une date attend que la paire reste valable aussi longtemps que la suite est utilisée, ce qui est une raison de garder les données générées structurellement correctes et jamais émises plutôt que d’inventer des valeurs à la main.

Si vous avez besoin de plusieurs cartes partageant toutes une même expiration, générez un lot et sélectionnez-y plutôt que de retaper la date, car une seule année mal saisie est difficile à repérer dans un fichier de fixtures. La liste de contrôle du formulaire de paiement couvre l’ensemble plus large des flux autour de ce champ, et le guide du code de sécurité explique les quatre autres caractères qu’un client lit sur la carte.

Étapes suivantes

Décidez, par écrit, ce que votre système entend par une date d’expiration — un mois, un premier jour ou un dernier instant — et placez la conversion derrière une fonction unique. Ajoutez ensuite les quatre tests de limites décrits ci-dessus, y compris le cas de l’année bissextile, et confirmez qu’une carte imprimée avec le mois courant est encore acceptée le jour de sa fin de validité.