Test

Per verificare che l’integrazione funzioni correttamente, puoi simulare delle transazioni senza trasferire denaro usando valori speciali in modalità di test o sandbox.

Le carte di test funzionano come carte di credito false e ti consentono di simulare diversi scenari:

• Pagamenti andati buon fine in base al circuito della carta o al paese
• Errori carta dovuti a rifiuti, frode o dati non validi
• Contestazioni e rimborsi
• Autenticazione con 3D Secure e PIN

I test dei pagamenti effettuati senza carta funzionano in modo simile. Ogni metodo di pagamento ha i propri valori speciali. A causa dei limiti di velocità, consigliamo di non utilizzare ambienti di test per eseguire il test di carico dell’integrazione. Consulta invece i test di carico.

Come usare le carte di test

Ogni volta che lavori con una carta di test, 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 di codice di 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 a tre cifre qualsiasi (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 codice di test, usa un PaymentMethod come pm_card_visa anziché un numero di carta. Sconsigliamo di usare i numeri di carta direttamente nelle chiamate API o nel codice lato server, anche in ambienti 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 Cliente.

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

In gran parte delle integrazioni non sono più utilizzati i token, ma qualora dovessero servirti mettiamo comunque a disposizione token di test come tok_visa.

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

Carte suddivise per circuito

Per simulare un pagamento con successo per un circuito di carta specifico, usa le carte di test dal seguente elenco.

Molte carte Cartes Bancaires ed 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 pagamenti con esito positivo provenienti da paesi specifici, usa le carte di test riportate nelle seguenti sezioni.

Carte di test HSA e FSA

Di seguito sono riportati i numeri delle carte di test per simulare le transazioni con Health Savings Accounts (HSA) e Flexible Spending Accounts (FSA). In genere questi conti vengono utilizzati per spese mediche e testarli garantisce una corretta gestione delle transazioni relative all’assistenza sanitaria nella tua applicazione

Pagamenti rifiutati

Per testare la logica di gestione del reindirizzamento per la tua integrazione simulando pagamenti che la società emittente rifiuta per vari motivi, usa le carte di test riportate in questa sezione. L’uso di una di queste carte porta a un errore della carta con il relativo codice di errore e codice di rifiuto.

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 tue impostazioni Radar. Puoi anche usarle per testare la risposta della tua integrazione ai pagamenti bloccati.

Ogni carta ha un profilo di rischio personalizzato. Le tue impostazioni Radar definiscono quali segnali di pericolo bloccano un pagamento. Se un pagamento viene interrotto, potresti ricevere un codice di errore di frode.

Dati non validi

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

• invalid_expiry_month: usa un mese non valido, ad esempio 13.
• invalid_expiry_year: usa un anno fino a 50 anni nel passato, ad esempio 95.
• invalid_cvc: usa un numero a due cifre, ad esempio 99.
• incorrect_number: usa un numero di carta che non supera la verifica della formula di 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 perdita di una contestazione, fornisci prove che indichino la vittoria o la perdita.

Prove

Per simulare la vittoria o la perdita di una contestazione, rispondi fornendo una delle prove riportate nella tabella qui sotto.

• Se rispondi usando l’API, specifica il valore della tabella come uncategorized_text.
• Se rispondi nella Dashboard, inserisci il valore della tabella nel campo Ulteriori informazioni e fai clic su Fornisci prove.

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 successivamente andare a buon fine. Per simulare 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 successive).

Puoi annullare un rimborso della carta solo utilizzando la Dashboard. In modalità live, puoi annullare un rimborso della carta entro un periodo di tempo breve ma non specifico. Gli ambienti di test simulano quel periodo permettendoti di annullare un rimborso della 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 ti consentono di simulare l’attivazione dell’autenticazione in diversi flussi di pagamento.

Solo le carte in questa sezione consentono di testare in modo efficace la tua 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 tali 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 (o sono già state) configurate per pagamenti futuri.

Supporto e disponibilità

Stripe richiede l’autenticazione se è imposta da eventuali normative oppure se viene attivata da regole Radar o da un codice personalizzato. Anche se viene richiesta, non sempre l’autenticazione 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 varie combinazioni di questi fattori.

Flussi di autenticazione standard su dispositivo mobile 3D Secure

In un pagamento tramite dispositivo mobile, sono disponibili diversi flussi di autenticazione standard, in cui il cliente deve interagire con gli avvisi che compaiono sull’interfaccia utente. Usa le carte di test riportate in questa sezione per attivare un flusso di autenticazione specifico a fini di 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 di PaymentMethod o Token per effettuare i test.

Test Captcha

Per prevenire le frodi, Stripe potrebbe mostrare un test Captcha all’utente sulla 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 delle carte di test fisiche. Per ulteriori informazioni, consulta la sezione Test di Stripe Terminal.

Destinazioni degli eventi

To test your webhook endpoint or event destination, choose one of these two options:

1. Perform actions in a sandbox that send legitimate events to your event destination. For example, to trigger the charge.succeeded event, you can use a test card that produces a successful charge.
2. Trigger events using the Stripe CLI or using Stripe for Visual Studio Code.

Limiti di frequenza

Se le richieste nei tuoi ambienti di test iniziano a ricevere errori HTTP 429, riducine la frequenza. Questi errori dipendono dal nostro limitatore di frequenza, che è più rigido in ambienti di test rispetto alla modalità live.

Sconsigliamo di eseguire il test di carico dell’integrazione usando l’API Stripe in ambienti di test. Dato che il limitatore del carico è più rigido in ambienti di test, potresti vedere degli errori che non vedresti in produzione. Per scoprire approcci alternativi, consulta i test di carico.

Pagamenti senza carta

Ogni volta che ti servi di una modalità di pagamento senza carta di test, 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 di codice di test.

Le varie modalità di pagamento hanno procedure di test diverse:

Link

Currently, Link only works with credit cards, debit cards, and qualified US bank account purchases. Link requires domain registration.

You can create sandbox accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that Stripe accepts for authenticating sandbox accounts:

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 del reindirizzamento per la tua integrazione simulando un pagamento che utilizza un flusso di reindirizzamento (ad esempio, iDEAL), utilizza un metodo di pagamento supportata che richiede reindirizzamenti.

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

1. Accedi alle impostazioni dei metodi di pagamento nella Dashboard e abilita un metodo di pagamento supportato facendo clic su Attiva nel tuo ambiente di test.
2. Raccogli i 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.