Test

Per testare l’integrazione, simula le transazioni senza spostare denaro utilizzando valori di test speciali in una sandbox. Puoi accedere alle tue sandbox utilizzando il selettore account in alto a destra nella pagina, o nella dashboard.

Le carte di test fungono da carte di credito fasulle e consentono di simulare i seguenti scenari:

• Pagamenti riusciti per circuito di carta o Paese
• Errori delle carte dovuti a rifiuti, frodi o dati non validi
• Contestazioni e rimborsi
• Autenticazione con 3D Secure e PIN

I pagamenti senza carta funzionano in modo simile. I pagamenti senza carta sono metodi di pagamento che non sono carte di credito o di debito. Stripe supporta diverse opzioni di pagamento senza carta, come wallet e trasferimenti bancari. Ogni metodo di pagamento ha valori speciali propri.

Non utilizzare ambienti di test per eseguire il test di carico dell’integrazione perché potresti raggiungere i limiti di velocità. Per eseguire il test di carico dell’integrazione, consulta il test di carico.

Come usare le carte di test

Ogni volta che lavori con una carta di test, utilizza chiavi API di test in tutte le chiamate API. Questo vale sia per inviare un modulo di pagamento per un test interattivo, sia per scrivere il codice del test.

Test interattivi

Durante il test interattivo, utilizza un numero di carta, ad esempio 4242 4242 4242 4242. Inserisci il numero della carta nella dashboard o in qualsiasi modulo di pagamento.

• Usa una data futura valida, come 12/34.
• Usa un CVC qualsiasi a tre cifre (quattro cifre per le carte American Express).
• Usa un valore qualsiasi per gli altri campi del modulo.

Test interattivo di un modulo con il numero di carta di test 4242 4242 4242 4242

Codice di test

Quando scrivi il codice in modalità di test, usa un PaymentMethod come pm_card_visa anziché un numero di carta. Sconsigliamo di usare direttamente i numeri di carta nelle chiamate API o nel codice lato server, anche in modalità di test. Se li usi, il codice potrebbe non essere conforme alle norme PCI una volta che andrai in modalità live. Per impostazione predefinita, un PaymentMethod non è associato a un oggetto Customer.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=500 \
  -d currency=gbp \
  -d payment_method=pm_card_visa \
  -d "payment_method_types[]"=card

I token non sono più utilizzati in gran parte delle integrazioni, ma qualora dovessero servire mettiamo comunque a disposizione token di test come tok_visa.

Quando è tutto pronto per mettere in produzione l’integrazione, sostituisci le chiavi API pubblicabili e segrete di test con quelle per la modalità live. Se l’integrazione utilizza ancora le chiavi API di test, non potrai elaborare i pagamenti in modalità live.

Carte suddivise per marchio

Per simulare un pagamento riuscito per un circuito di carta particolare, usare le carte di test dal seguente elenco.

Molte carte Cartes Bancaires e eftpos sono in co-branding con Visa o Mastercard. Le carte di test della tabella che segue simulano pagamenti andati a buon fine con carte in co-branding.

Carte suddivise per Paese

Per simulare i pagamenti a buon fine provenienti da Paesi specifici, usare le carte di test riportate nelle sezioni che seguono.

Carte di test HSA e FSA

Di seguito sono riportati i numeri delle carte di test per simulare le transazioni utilizzando gli Health Savings Accounts (HSA) e i Flexible Spending Accounts (FSA). Questi conti sono comunemente utilizzati per le spese mediche e i test con essi garantiscono la corretta gestione delle transazioni relative all’assistenza sanitaria all’interno dell’applicazione.

Pagamenti rifiutati

Per testare la logica di gestione degli errori dell’integrazione simulando pagamenti che la società emittente rifiuta per svariati motivi, usa le carte di test riportate in questa sezione. L’uso di una di queste carte produce un errore della carta con il relativo codice di errore e codice di pagamento rifiutato.

Prevenzione delle frodi

Radar, il sistema di prevenzione delle frodi di Stripe, è in grado di bloccare i pagamenti che presentano un alto livello di rischio o che non superano i controlli di verifica. Puoi usare le carte riportate in questa sezione per testare le impostazioni di Radar. Puoi anche usarle per testare la risposta della tua integrazione in caso di pagamenti bloccati.

Ogni carta simula fattori di rischio specifici. Le impostazioni Radar definiscono quali fattori di rischio bloccano un pagamento. Se un pagamento viene interrotto, potresti ricevere errori sulla carta con codice errore di frode.

Dati non validi

Per testare errori derivanti da dati non validi, fornisci dettagli non validi. Per questo non occorre una carta di test speciale, funzionano tutti i dati non validi. Ad esempio:

• invalid_expiry_month: utilizzare un mese non valido, ad esempio 13.
• invalid_expiry_year: usa un anno fino a 50 anni nel passato, ad esempio 95.
• invalid_cvc: utilizza un numero di due cifre, ad esempio 99.
• incorrect_number: utilizza un numero di carta che non supera il controllo Luhn, ad esempio 4242424242424241
  .

Contestazioni

Per simulare una transazione contestata, usa le carte di test riportate in questa sezione. Poi, per simulare la vittoria o la sconfitta in una contestazione, fornisci prove che indichino la vittoria o la sconfitta.

Prova

Per simulare la vittoria o la sconfitta in una contestazione, rispondi fornendo una delle prove riportate nella tabella che segue.

• Se rispondi utilizzando l’API, specifica il valore della tabella come uncategorized_text.
• Se rispondi nella dashboard o nei componenti integrati in Connect, inserisci il valore della tabella nel campo Ulteriori informazioni e fai clic su Fornisci prova.

Rimborsi

In modalità live, i rimborsi sono asincroni: può sembrare che un rimborso vada a buon fine per poi non riuscire, oppure può inizialmente risultare in stato pending e riuscire in seguito. Per simulare i rimborsi con questi comportamenti, usa le carte di test riportate in questa sezione (con tutte le altre carte di test, i rimborsi vanno immediatamente a buon fine e il loro stato non subisce modifiche in seguito).

Puoi annullare un rimborso con carta solo attraverso la dashboard. In modalità live, è possibile annullare il rimborso di una carta entro un periodo di tempo breve ma non specificato. Gli ambienti di test simulano tale periodo, consentendo di annullare il rimborso di una carta entro 30 minuti.

Saldo disponibile

Per inviare fondi da una transazione di test direttamente al tuo saldo disponibile, usa le carte di test riportate in questa sezione. Altre carte di test inviano fondi da un pagamento andato a buon fine al tuo saldo in sospeso.

Autenticazione 3D Secure

3D Secure richiede un livello aggiuntivo di autenticazione per le transazioni con carta di credito. Le carte di test riportate in questa sezione consentono di simulare l’attivazione dell’autenticazione in diversi flussi di pagamento.

Solo le carte in questa sezione consentono di testare in modo efficace l’integrazione 3D Secure simulando il comportamento 3DS definito, ad esempio un flusso con richiesta di autenticazione o una carta non supportata. Altre carte di test di Stripe potrebbero attivare 3DS, ma viene restituito attempt_acknowledged per saltare i passaggi aggiuntivi, poiché il test 3DS non è l’obiettivo di quelle carte.

Autenticazione e configurazione

Per simulare i flussi di pagamento che prevedono l’autenticazione, usa le carte di test riportate in questa sezione. Alcune di queste carte possono anche essere configurate per pagamenti futuri, o lo sono già state.

Supporto e disponibilità

Stripe richiede l’autenticazione se è imposta da eventuali normative oppure viene attivata dalle regole Radar o da un codice personalizzato. Anche se l’autenticazione viene richiesta, non sempre può essere eseguita. Ad esempio, la carta del cliente potrebbe non essere registrata oppure si potrebbe verificare un errore. Utilizza le carte di test riportate in questa sezione per simulare combinazioni diverse di questi fattori.

Flussi di autenticazione standard su dispositivo mobile 3D Secure

In un pagamento da dispositivo mobile, sono disponibili diversi flussi di autenticazione standard, in cui l’interazione del cliente con gli avvisi che compaiono sull’interfaccia utente. Usa le carte di test riportate in questa sezione per attivare un flusso di autenticazione specifico per il test. Queste carte non sono utili per i moduli di pagamento basati su browser o per le chiamate API. In tali ambienti funzionano ma non innescano alcun comportamento specifico. Non essendo utili nelle chiamate API, non forniamo valori PaymentMethod o Token con cui effettuare i test.

Test captcha

Per prevenire le frodi, Stripe potrebbe mostrare un test captcha all’utente nella pagina di pagamento. Utilizza la carta di test riportata di seguito per simulare questo flusso.

Pagamenti tramite PIN

Usa le carte di test riportate in questa sezione per simulare pagamenti di persona con esito positivo e che prevedono l’uso di un PIN. I pagamenti di persona possono essere testati in molti altri modi, ad esempio con un lettore simulato e carte di test fisiche. Per ulteriori informazioni, consulta la sezione Test di Stripe Terminal.

Destinazioni degli eventi

Per eseguire il test dell’endpoint del webhook o della destinazione dell’evento, scegli una di queste due opzioni:

1. Esegui azioni in una sandbox per inviare eventi legittimi alla destinazione dell’evento. Ad esempio, per attivare l’evento charge.succeeded, puoi usare una carta di test che produca un addebito con esito positivo.
2. Attiva eventi utilizzando la CLI di Stripe oppure usando Stripe per Visual Studio Code.

Limiti di frequenza

Se le tue richieste negli ambienti di test iniziano a ricevere errori HTTP 429, riducine la frequenza. Questi errori provengono dal nostro limitatore di velocità, che negli ambienti di test è più rigoroso rispetto alla modalità live.

Sconsigliamo di eseguire il test di carico dell’integrazione usando l’API Stripe negli ambienti di test. Dato che il limitatore di carico è più rigido negli ambienti di test, potresti vedere degli errori che non apparirebbero in produzione. Per un approccio alternativo, consulta i test di carico.

Pagamenti senza carta

Ogni volta che ti servi di un metodo di pagamento di test senza carta, usa le chiavi API di test in tutte le chiamate API. Questa regola vale sia per la compilazione di un modulo di pagamento da testare in modo interattivo, sia per la scrittura del codice di test.

I vari metodi di pagamento hanno procedure di test diverse:

Link

Attualmente Link funziona solo con carte di credito, carte di debito e acquisti su conti bancari qualificati degli Stati Uniti. Link richiede la registrazione del dominio.

Puoi creare account sandbox per Link utilizzando qualsiasi indirizzo email valido. La tabella seguente mostra i valori di passcode monouso fissi che Stripe accetta per autenticare gli account sandbox:

Più fonti di finanziamento

Quando Stripe fornisce fonti di finanziamento aggiuntive, non è necessario aggiornare l’integrazione. Stripe le supporta automaticamente con le stesse tempistiche di regolamento delle transazioni e le stesse garanzie dei pagamenti con carta e conto corrente.

Reindirizzamenti

Per testare la logica di gestione dei reindirizzamenti dell’integrazione simulando un pagamento che utilizza un flusso di reindirizzamento (ad esempio, iDEAL), utilizza una modalità di pagamento supportata che richieda i reindirizzamenti.

Per creare un PaymentIntent di test con esito positivo o negativo:

1. Accedi alle impostazioni dei metodi di pagamento nella dashboard e abilita una modalità di pagamento supportata facendo clic su Attiva nell’ambiente di test.
2. Raccolta dei dati di pagamento.
3. Invia il pagamento a Stripe.
4. Autorizza o rifiuta il pagamento di test.

Assicurati che la pagina (corrispondente a return_url) del tuo sito web indichi lo stato del pagamento.