Data di scadenza della carta di credito: formato, regole e casi limite

Una data di scadenza della carta di credito occupa quattro caratteri sulla plastica e causa un numero sproporzionato di bug nel software che la legge. Il valore stampato è breve, ma porta con sé due regole distinte allo stesso tempo: in quale mese la carta smette di funzionare e in quale preciso momento dell’ultimo giorno di quel mese smette davvero. Sbagliare il confine è uno dei modi classici in cui un pagamento rifiuta una carta ancora perfettamente utilizzabile.

Le sezioni seguenti spiegano cosa significa la data stampata, come funziona la regola di fine mese, perché moduli e database raramente memorizzano la stessa cosa che mostra la carta e come testare i casi scomodi.

Cosa significa la data stampata

La data su una carta è un mese e un anno, ciascuno scritto con due cifre, con il mese per primo: mese nove e anno ventisei, per esempio, oppure mese uno e anno trenta. Sulla carta non c’è il giorno, ed è la prima fonte di confusione: le persone lo cercano perché ogni altra data che gestiscono ne ha uno.

Il mese e l’anno descrivono quando la carta cessa di essere valida, non quando è stata emessa. Una carta stampata con una data di diversi anni avanti è normale, perché gli emittenti in genere sostituiscono una carta ben prima che scada.

Il valore non è derivato da nulla d’altro sulla carta. Non è una somma di controllo e non interagisce con il numero. Questo conta per i test: una data di scadenza non può essere inventata con l’aritmetica, quindi deve essere fornita, ed è per questo che le carte generate arrivano con una data allegata.

Una carta è valida per tutto il mese?

Sì. Questa è la regola che coglie le persone di sorpresa. Una carta stampata con un dato mese e anno è accettata fino all’ultimo giorno di quel mese, fino all’ultimo istante di quel giorno, nel fuso orario usato dal sistema di autorizzazione dell’emittente.

Una carta stampata con mese nove e anno ventisei è quindi utilizzabile il trenta settembre di quell’anno, e smette di essere utilizzabile al primo istante di ottobre. Qualsiasi sistema che tagli la carta all’inizio di settembre, o a mezzanotte dell’ultimo giorno, sta rifiutando pagamenti validi per un periodo misurato in ore o giorni.

La tabella mostra anche perché il conteggio dei giorni conta. Febbraio è quello scomodo, perché l’ultimo giorno dipende dall’anno, e un modulo o un processo pianificato che presuppone ventotto giorni sbaglierà il confine in un anno bisestile.

Perché i moduli chiedono due cifre invece di quattro?

Le carte stampano solo due cifre per l’anno per risparmiare spazio, e i moduli di solito chiedono le stesse due perché è ciò che l’utente sta leggendo. Quella convenzione sposta una decisione sul software: a quale secolo appartiene il valore?

Scrivendo il secolo a parole anziché nel codice, l’approccio comune è trattare un anno a due cifre come appartenente al secolo corrente o a quello successivo in base a quanto è vicino a oggi. Un valore d’anno che sembra molto nel passato è quasi sempre un errore di battitura, non una carta di un’epoca precedente, e un valore decodificato nel secolo sbagliato sarà o rifiutato come scaduto o accettato per sempre.

L’approccio più sicuro per un modulo è accettare ciò che l’utente ha, convertirlo una volta in una rappresentazione inequivocabile — un mese e un anno completo a quattro cifre, oppure un primo giorno e un ultimo giorno — e usare quella rappresentazione ovunque in seguito. Non confrontare mai direttamente anni a due cifre, perché il confronto ridefinisce silenziosamente il significato del secolo a ogni cambio di secolo.

Formato di visualizzazione e formato memorizzato sono cose diverse

La stringa che un cliente vede e il valore che un sistema conserva raramente coincidono, e confonderli è una fonte affidabile di difetti.

Sulla carta, e in un campo di input, il valore appare come due cifre per il mese e due per l’anno. In un database è spesso memorizzato come una data al primo del mese, oppure come colonne intere separate per mese e anno, oppure come timestamp dell’ultimo momento di validità. Ogni scelta ha conseguenze. Un timestamp al primo del mese è facile da ordinare e da confrontare, ma non ti dice quando la carta scade se non conosci anche la regola di fine mese. Un timestamp all’ultimo momento codifica il confine corretto ma sembra allarmante in una schermata amministrativa dove nessuno si aspetta di vedere un’ora del giorno accanto a una scadenza.

Qualunque rappresentazione tu scelga, tieni la conversione in un unico posto. Il bug che compare in produzione è di solito una seconda conversione scritta da qualcuno che non sapeva che esistesse la prima, e le due discordano di un mese.

Errori comuni quando si digita una data di scadenza

Gli errori che le persone commettono su questo campo seguono una breve lista, e ognuno ha una risposta sensata:

• Digitare l’anno a quattro cifre in un campo a due cifre. Accettalo se riesci a mapparlo in modo inequivocabile, e non eliminare silenziosamente i caratteri iniziali.
• Scambiare il mese e l’anno. Mese tredici e anno ventotto sono entrambi non validi, quindi valida ogni parte rispetto al proprio intervallo e non solo la loro combinazione.
• Inserire un mese con zero iniziale in un campo che si aspetta una sola cifra. Tratta uno e zero-uno come lo stesso mese.
• Incollare un valore con un separatore che il campo non si aspetta, come un trattino dove andrebbe una barra.
• Inserire una data già passata, che è un rifiuto che il modulo dovrebbe spiegare e non solo segnalare.

Per gli sviluppatori: controlli di input e test di confine

Due piccoli accorgimenti prevengono gran parte di questo dolore. Primo, separa mese e anno in input distinti, oppure usa un unico campo che guidi visibilmente la forma prevista, così che un valore scambiato sia improbabile e non solo rilevabile. Secondo, valida ogni componente rispetto al proprio intervallo prima di validare la combinazione, così l’utente impara quale parte è sbagliata.

Per la logica di confine, testa gli estremi dell’intervallo e non il centro. I quattro casi che vale la pena scrivere sono il primo giorno del mese stampato, l’ultimo giorno del mese stampato, il giorno dopo l’ultimo e lo stesso caso dell’ultimo giorno in un anno bisestile. Un test scritto contro la metà di un mese non dimostra quasi nulla sulla regola che stai cercando di proteggere.

Poi controlla come si comporta il tuo sistema quando l’orologio si muove. Se una scadenza memorizzata viene convertita una volta al momento dell’invio e mai più rivista, un modulo lasciato aperto a cavallo di un confine mensile invierà una data appena diventata non valida. Decidi deliberatamente se sia un errore da segnalare o un limite accettabile, e assicurati che la richiesta di pagamento e i tuoi stessi registri siano d’accordo al riguardo.

Ottenere una scadenza corrispondente dallo strumento carte

Ogni carta prodotta dal generatore di numeri di carta arriva con una data di scadenza che rispetta la stessa convenzione: un mese e un anno nel futuro, coerenti su tutto un lotto. Quella coerenza è ciò che rende utilizzabile un insieme di fixture: un test che abbina un numero a una data si aspetta che la coppia resti valida finché la suite è in uso, ed è uno dei motivi per conservare i dati generati strutturalmente corretti e mai emessi anziché inventare valori a mano.

Se ti servono diverse carte che condividono una sola scadenza, genera un lotto e seleziona da esso anziché ridigitare la data, perché un singolo anno digitato male è difficile da notare in un file di fixture. La checklist del modulo di pagamento copre l’insieme più ampio di flussi attorno a questo campo, e la guida al codice di sicurezza spiega gli altri quattro caratteri che un cliente legge dalla carta.

Passi successivi

Decidi, per iscritto, cosa significa la tua data di scadenza — un mese, un primo giorno o un ultimo momento — e metti la conversione dietro un’unica funzione. Poi aggiungi i quattro test di confine descritti sopra, incluso il caso dell’anno bisestile, e conferma che una carta stampata con il mese corrente sia ancora accettata il suo ultimo giorno.