Un generatore di numeri di carta di credito produce numeri di carta che soddisfano le regole strutturali che un modulo di pagamento controlla, così che un flusso di checkout possa essere esercitato senza che venga mai coinvolta una carta reale. Il numero non è una credenziale, non è collegato a un account e non autorizzerà nulla — ma supererà i controlli di formato, le regole sul prefisso dell’emittente e la cifra di controllo che un modulo applica prima di inoltrare qualsiasi cosa.
Questa guida spiega cosa significano le parti di un numero di carta, perché esiste la cifra di controllo e cosa non fa, perché il codice di sicurezza e la data di scadenza devono concordare con il numero in un record di test, e dove si colloca il confine tra un ambiente di test e un ambiente di dati dei titolari di carta. Alla fine saprete cosa verificare in un test del modulo di pagamento e cosa tenere completamente fuori dal vostro repository.
Cosa significano le parti di un numero di carta?
Un numero di carta è una stringa di cifre a lunghezza fissa con tre parti. Le cifre iniziali identificano l’emittente e il circuito, le cifre centrali identificano il singolo account all’interno di quell’emittente, e la cifra finale è un valore di controllo calcolato da tutte le altre. La lunghezza totale varia per circuito e per prodotto della carta, e un modulo che presuppone una sola lunghezza rifiuterà input validi.
Il numero di identificazione dell’emittente è il prefisso, ed è ciò che consente a un modulo di mostrare il logo giusto e applicare le regole giuste prima che venga inviata una richiesta. I prefissi dei principali circuiti occupano intervalli numerici distinti, e quegli intervalli sono pubblicati affinché un sistema possa instradare un numero senza contattare nessuno. Quando un numero generato porta un prefisso dell’intervallo sbagliato, il modulo o lo rifiuta del tutto oppure etichetta male il circuito nell’interfaccia.
La sezione centrale è la parte che un generatore inventa. In un record sintetico non porta alcun account dietro di sé, ed è proprio questo il punto. In una carta reale punta a un account specifico presso un emittente specifico, ed è precisamente per questo che non deve mai comparire in una fixture di test.
C’è una conseguenza pratica per chiunque costruisca un generatore. I numeri sintetici più sicuri restano dentro gli intervalli numerici che i circuiti riservano ai test, perché quegli intervalli sono definiti in modo che nessun account reale possa esistere lì. Un generatore che vaga per l’intero spazio dei prefissi può alla fine produrre una combinazione che appartiene a qualcuno, e un numero che appartiene a qualcuno non è più un dato di test, per quanto innocentemente sia stato prodotto.
Perché esiste la cifra di controllo e cosa dimostra
La cifra finale è calcolata tramite un checksum ponderato sulle cifre precedenti, una regola solitamente descritta come algoritmo di Luhn. Il suo scopo è intercettare gli errori di trascrizione: una singola cifra digitata male, o due cifre adiacenti invertite, produrranno quasi sempre un numero che fallisce il controllo. L’articolo sull’algoritmo di Luhn illustra l’aritmetica passo dopo passo.
Ciò che la cifra di controllo dimostra è limitato, e fraintenderlo causa difetti reali. Dimostra che le cifre sono internamente coerenti. Non dimostra nulla sul fatto che l’account esista, che la carta sia attiva, che i fondi siano disponibili o che il numero appartenga a qualcuno. Un modulo che tratta una cifra di controllo superata come verifica di qualcosa al di là dell’aritmetica è un modulo che accetterà ogni numero ben formato digitato male che un utente possa produrre.
È questo il motivo per cui un numero generato è così utile nei test. Porta esattamente la proprietà che un modulo controlla — la coerenza interna — e nessuna delle proprietà che un modulo non può controllare. Lo scarto tra questi due insiemi è dove vivono la maggior parte dei bug dei moduli di pagamento.
È anche il motivo per cui i valori segnaposto falliscono. Un campo riempito con una cifra ripetuta, o con una breve sequenza crescente, fallirà la cifra di controllo e quindi non raggiungerà mai i percorsi di codice che volete davvero testare. Un numero di test utile è un numero valido.
Perché il codice di sicurezza e la scadenza devono corrispondere al numero
Un record di carta è un piccolo insieme di campi che si vincolano a vicenda, e un modulo di pagamento accetterà combinazioni che nessun emittente emetterebbe mai. La lunghezza del codice di sicurezza dipende dal circuito, quindi un codice di tre cifre abbinato a un circuito che ne usa quattro è una mancata corrispondenza. La data di scadenza deve essere nel futuro perché la maggior parte dei flussi la accetti, e il mese deve ricadere nei dodici del calendario.
Anche la natura debito o credito del prodotto incide sul comportamento in alcuni flussi. Alcuni checkout li trattano allo stesso modo e altri applicano regole diverse, e una suite di test che esercita sempre e solo un tipo di prodotto non scoprirà la differenza. Un generatore in grado di produrre entrambi, con circuiti che corrispondono ai prefissi, vi offre la varietà per trovare quei percorsi.
Il prefisso dell’emittente e il branding del circuito nell’interfaccia hanno lo stesso rapporto. Se il modulo mostra il nome di un circuito mentre il prefisso appartiene a un altro, la mancata corrispondenza è di per sé un caso di test, ed è un difetto su cui un tester manuale raramente inciampa perché digita i numeri che conosce.
Le carte di test ufficiali sono migliori di quelle generate?
I fornitori di pagamento pubblicano numeri di carta di test per i loro ambienti sandbox, e quei numeri sono la scelta giusta per uno scopo specifico: esercitare il comportamento del fornitore stesso. Un numero di test pubblicato è legato a esiti documentati — un addebito riuscito, un addebito rifiutato, un codice di errore specifico — e riprodurre quegli esiti dipende dall’uso di quel numero esatto.
I numeri generati servono a uno scopo diverso. Sono per le parti dello stack che possedete: la validazione lato client, il rilevamento del prefisso, la formattazione, la messaggistica di errore, la memorizzazione e la gestione di lunghezze insolite. Una sandbox non avrà un esito documentato per un numero che non ha mai visto, quindi i numeri generati servono per tutto ciò che accade prima che la richiesta lasci la vostra applicazione.
I due approcci si combinano bene. Usate i numeri generati per l’ampia matrice di casi di validazione, e un piccolo insieme di numeri pubblicati dal fornitore per la manciata di test di integrazione che verificano le risposte del fornitore. L’articolo carte di test Stripe copre la seconda categoria, e la checklist di test del modulo di pagamento copre la prima.
Qualunque usiate, tenete i numeri nel codice di test e fuori dalle fixture che raggiungono un endpoint reale. Un numero sandbox inviato per errore a un gateway di produzione verrà rifiutato, ma affidarsi al rifiuto come rete di sicurezza non è un controllo.
Vale la pena progettare per un’ulteriore proprietà: una data di scadenza che non diventa mai obsoleta. Una fixture con una scadenza codificata descriverà un giorno una carta scaduta il mese scorso, e il test inizierà a fallire per una ragione che non ha nulla a che fare con la modifica in esame. Un generatore che calcola la scadenza rispetto alla data corrente mantiene la fixture valida a tempo indefinito e rimuove un’intera classe di errori confusi dalla suite.
Cosa significa PCI DSS per un’azienda senza carte reali
Lo standard di sicurezza dei dati del settore delle carte di pagamento regola come i dati dei titolari di carta vengono memorizzati, elaborati e trasmessi. La sua regola centrale è semplice da enunciare e facile da sottovalutare: un ambiente di test non deve contenere numeri di carta reali. Né in una fixture, né in uno script di seed, né in un commento, né in un log.
Il motivo è che un numero di carta insieme a un nome e a una scadenza è un dato protetto indipendentemente dall’ambiente in cui si trova. Copiare una riga di produzione nello staging crea una nuova ubicazione che detiene dati dei titolari di carta, di solito con controlli di accesso più deboli e una cronologia di backup più lunga. L’articolo dati di test PCI DSS esamina le conseguenze in maggiore dettaglio.
Per un team che non possiede carte reali, la conformità è relativamente semplice. Se ogni numero nell’ambiente è sintetico e nessuna carta reale può arrivare, la questione dell’ambito si risolve in gran parte da sola. La disciplina richiesta è mantenerla tale: non incollate mai un numero reale in una segnalazione di bug, non fate mai uno screenshot di un checkout live e non importate mai un estratto di produzione per far sembrare realistici i dati di test.
La modalità di fallimento organizzativa è di solito l’intenzione più che la negligenza. Qualcuno ha bisogno di riprodurre un difetto di produzione, importa una fetta di produzione per farlo e lascia la fetta al suo posto. Una regola secondo cui i dati di test devono essere generati anziché copiati è facile da mantenere quando non è mai stata allentata.
Quali casi di moduli di pagamento vale la pena scrivere
I casi che intercettano difetti reali sono quelli che si trovano ai confini. Testate un numero di una cifra più corto e di una cifra più lungo rispetto alla lunghezza attesa per ogni circuito supportato, e verificate che il modulo rifiuti entrambi con un messaggio su cui un utente possa agire. Testate un prefisso che appartiene a un circuito che il vostro checkout non accetta e confermate che il rifiuto sia chiaro anziché generico.
Testate la cifra di controllo in modo esplicito prendendo un numero valido e alterando una cifra al centro, poi verificando che il modulo lo rifiuti. Questo caso è prezioso perché distingue i moduli che eseguono davvero il checksum da quelli che contano solo le cifre, e il secondo tipo è più comune di quanto dovrebbe essere.
Testate la formattazione e l’incollaggio. Gli utenti incollano numeri con spazi, con trattini e con uno spazio iniziale o finale, e un campo che memorizza quei caratteri invariati fallirà a valle. Testate il campo del codice di sicurezza rispetto alla lunghezza attesa dal circuito, e testate una data di scadenza per il mese precedente e per il mese corrente, perché il confine tra i due è dove vivono gli errori di off-by-one. L’articolo sul formato del numero di carta elenca le regole strutturali che sono alla base di tutto questo.
Poi testate cosa accade dopo un errore. Un utente che digita male una cifra dovrebbe poterla correggere senza reinserire l’intero modulo, e l’errore non dovrebbe cancellare gli altri campi. Questo comportamento è raramente verificato e spesso rotto. Il generatore di numeri di carta su questo sito è costruito per produrre numeri attraverso i circuiti supportati con la lunghezza giusta e una cifra di controllo valida, così che una matrice di questi casi possa essere assemblata senza scrivere a mano una fixture per ciascuno.
Cos’è e cosa non è un numero di carta generato
Un numero di carta generato è un dato di test sintetico. Ha un prefisso ben formato, una lunghezza corretta per il suo circuito e una cifra di controllo valida, ed è progettato per esercitare il software. Non è una credenziale di pagamento, non è emesso da alcuna banca o circuito, non è collegato ad alcun account e non può essere usato per effettuare un acquisto, per autorizzare una transazione o per superare qualsiasi verifica reale.
Non deve essere usato per ottenere beni o servizi, per testare un sistema di pagamento live con l’intenzione di concludere una transazione, per impersonare un titolare di carta o per superare qualsiasi controllo che esiste per proteggere account reali. Esiste affinché i vostri moduli, parser e logiche di validazione possano essere testati, e per nient’altro.
Dove un numero di carta viene combinato con un nome, un indirizzo e una data di nascita in un record, l’intero record è sintetico. Struttura corretta e coerenza interna sono le proprietà che lo rendono utile; non sono affermazioni su nulla di reale, e nessuna parte di un simile record dovrebbe mai essere presentata come i dettagli finanziari di qualcuno.