I fornitori di pagamenti mantengono un proprio piccolo catalogo di carte di test Stripe, e il motivo è pratico più che generoso: una sandbox che non riesce a produrre un rifiuto non può testare il percorso di codice che lo gestisce. Le credenziali di pagamento reali non possono mai essere usate per questo, sia perché è pericoloso sia perché gli esiti sarebbero imprevedibili, quindi i fornitori pubblicano numeri il cui comportamento è definito in anticipo dai loro stessi sistemi.
Questo articolo spiega cosa sono quei numeri, perché un fornitore dovrebbe pubblicarli affatto, come vengono simulati rifiuti e autenticazione e dove iniziano i limiti di un elenco fornito dal fornitore.
Cos’è una carta di test di un fornitore
Una carta di test è un numero che la sandbox di un fornitore di pagamenti riconosce. Quando compare in una richiesta di pagamento, la sandbox non contatta alcuna banca. Cerca il numero in una tabella, decide quale debba essere l’esito della richiesta e restituisce quell’esito: un successo, uno specifico motivo di rifiuto o una richiesta di autenticazione aggiuntiva.
Quella ricerca è l’intero meccanismo. Il numero non deve appartenere a nessuno, la data di scadenza non deve essere reale purché sia nel futuro, e il codice di sicurezza viene controllato solo rispetto alle forme che la sandbox si aspetta. Poiché il comportamento è programmato anziché risolto, due sviluppatori che usano la stessa carta di test nei propri account sandbox ottengono lo stesso risultato, ed è questo che rende riproducibili le segnalazioni di bug sui flussi di pagamento.
Perché i fornitori di pagamenti pubblicano i propri numeri di test?
Ogni gateway implementa la propria interpretazione delle risposte delle reti di carte. I codici di rifiuto, i passaggi di autenticazione e il comportamento di retry differiscono tra i fornitori, e quelle differenze sono esattamente ciò che un test di integrazione deve esercitare. Un numero sintetico generico può dimostrare che un modulo accetta sedici cifre; solo un numero riconosciuto dal fornitore può dimostrare che la tua applicazione gestisce il modo particolare in cui quel fornitore dice che la carta è stata rifiutata.
C’è anche un argomento di sicurezza. Gli editori vogliono che gli sviluppatori usino numeri che sono certamente non riconducibili a un conto reale, in qualsiasi ambiente e con qualsiasi configurazione. Un elenco curato è il modo in cui il fornitore garantisce che un test in sandbox non possa trasformarsi accidentalmente in una transazione reale.
Il catalogo cambia man mano che i fornitori aggiungono funzionalità, quindi l’elenco autorevole è sempre la documentazione del fornitore stesso. Leggilo lì anziché fidarti di una versione copiata in un post di blog o in un repository, incluso questo.
L’unica carta di test che quasi ogni sviluppatore usa
Tra i numeri documentati da Stripe, uno è diventato il default di fatto: un valore di sedici cifre che inizia con quattro ed è formato ripetendo lo stesso breve schema, vale a dire la coppia quarantadue ripetuta fino a completare la lunghezza. Presentato con qualsiasi data di scadenza futura e qualsiasi codice di sicurezza a tre cifre, produce un addebito riuscito nella sandbox.
La sua popolarità è facile da capire. È memorabile, soddisfa le regole di formato che avrebbe una carta reale e permette a uno sviluppatore di completare un intero flusso di pagamento entro pochi minuti dall’inizio. È anche il motivo per cui così tante integrazioni di pagamento sono appena testate, perché un singolo caso di successo non ti dice nulla su cosa accade quando un pagamento viene rifiutato.
Due avvertenze meritano di essere dette chiaramente. Primo, questo numero ha significato solo all’interno di una sandbox di un fornitore; puntarlo verso un gateway attivo produce un’autorizzazione fallita e una voce nei log antifrode di qualcuno. Secondo, un addebito riuscito in sandbox è un esito simulato, non la prova che la carta sia reale o che il conto dietro di essa esista: la sandbox non l’ha mai chiesto.
Come si simula un rifiuto?
I rifiuti sono di solito guidati da numeri che il fornitore riserva a esiti particolari, e l’elenco copre in genere i casi sui quali il codice di integrazione deve davvero diramarsi:
- Un rifiuto generico, usato per verificare che il modulo mostri un errore recuperabile anziché un crash.
- Un rifiuto che indica che l’emittente vuole che il cliente lo contatti, che è un vicolo cieco per il flusso di pagamento.
- Fondi insufficienti, l’unico rifiuto che un utente può plausibilmente risolvere usando un’altra carta.
- Una risposta di carta scaduta, che verifica se la validazione della data del tuo modulo e il gateway sono d’accordo.
- Un errore di elaborazione, che di solito va ritentato anziché mostrato al cliente come risposta definitiva.
- Un blocco di tipo frode, che dovrebbe fermare il flusso anziché spingere l’utente verso un nuovo tentativo.
Ognuno di questi merita un percorso deliberato nella tua applicazione: un messaggio diverso, una politica di retry diversa e un record diverso nel tuo database. Usare un unico numero di rifiuto per tutti nasconde le differenze finché un cliente non ne incontra uno.
Testare l’autenticazione e i flussi 3-D Secure
I pagamenti moderni con carta includono spesso un passaggio in cui il cliente viene reindirizzato, o gli viene mostrata una sfida incorporata, per confermare il pagamento con la propria banca. Le sandbox simulano questo con numeri dedicati: alcuni attivano una sfida che viene sempre superata, altri una sfida che viene sempre fallita, altri ancora un flusso che si completa senza alcuna sfida.
I casi che vale la pena coprire riguardano raramente il percorso felice. Cosa accade quando il cliente abbandona la sfida a metà e torna sul tuo sito? Il tuo ordine resta per sempre in stato di attesa, o si risolve in un esito definito? Un tentativo ripetuto crea un secondo ordine? L’autenticazione introduce un passaggio in cui il tuo sistema perde il controllo dell’utente per qualche secondo, e ogni integrazione ha almeno un bug in quella finestra.
Per gli sviluppatori: gli elenchi di scenari battono un singolo numero magico
L’abitudine che vale la pena costruire è pianificare la copertura dei test come un elenco di esiti anziché un elenco di numeri. Scrivi gli stati in cui può terminare il tuo flusso di pagamento — autorizzato, rifiutato come ritentabile, rifiutato in via definitiva, autenticazione richiesta, autenticazione fallita, abbandonato, scaduto — e poi trova un input sandbox per ciascuno.
Conserva quella mappatura nel repository accanto ai test, con una nota sulla versione della documentazione del fornitore da cui proviene, e rivedila quando il fornitore aggiorna il suo catalogo. Quando in seguito si indaga su un incidente di pagamento, la mappatura è ciò che ti permette di dire quali stati sono stati esercitati e quali non sono mai stati coperti.
Alcuni punti più piccoli fanno risparmiare tempo reale. Conserva le credenziali sandbox solo nell’ambiente di test e controlla la configurazione prima di eseguire qualsiasi cosa, perché una carta di test contro una chiave attiva è esattamente l’incidente che tutta questa pratica esiste per prevenire. Verifica l’esito che il tuo sistema ha registrato, non solo la risposta del gateway, dato che i bug interessanti vivono tra i due. E decidi presto come distinguerai una transazione sandbox da una reale nelle tue tabelle, così un futuro audit non deve tirare a indovinare.
Generare carte senza un account di fornitore
I cataloghi dei fornitori sono lo strumento giusto quando ti serve un esito programmato, e quello sbagliato quando ti serve volume. Un modulo che deve accettare cento carte diverse, una demo che dovrebbe mostrare una varietà di reti, o un insieme di fixture che copre lunghezze e prefissi è servito meglio da dati generati.
Il generatore di numeri di carta di questo sito produce numeri per una rete scelta o un mix casuale, con date di scadenza e codici di sicurezza segnaposto, e nessuno di essi è legato a un conto. Ogni valore è strutturalmente valido e non è mai stato emesso, quindi sarà accettato da un controllo di formato e rifiutato da qualsiasi gateway reale.
Usa i due tipi di dati per lavori diversi: i numeri di test dei fornitori per gli esiti programmati del gateway, i numeri generati per tutto ciò che il gateway non vede mai. Il confronto tra reti è utile quando ti serve una carta per marca, e la checklist del modulo di pagamento elenca i flussi in cui quelle carte dovrebbero comparire.
Passi successivi
Scrivi l’elenco degli esiti per il tuo flusso di pagamento, mappa ogni voce su un input sandbox dalla documentazione corrente del tuo fornitore e aggiungi quelle che non riesci ancora a produrre a una backlog visibile. Poi genera un lotto separato di carte sintetiche per i test a livello di modulo, così i due tipi di dati di test non vengono mai confusi.