Test payment methods (2024)

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

Le carte di test ti permettono di simulare scenari diversi:

• 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 modalità di pagamento ha i propri valori speciali. A causa dei limiti di frequenza, consigliamo di non usare la modalità di test per eseguire il test di carico dell’integrazione. Per soluzioni alternative, consulta la nostra documentazione sul test di carico.

Come usare le carte di test

Ogni volta che utilizzi 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

Per eseguire test in modalità interattiva, usa un numero di carta come 4242 4242 4242 4242. Inserisci tale numero nella Dashboard o in un 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.

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 i numeri di carta direttamente 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_9W1R4v0cz6AtC9PVwHFzywti
:" \ -d amount=500 \ -d currency=gbp \ -d payment_method=pm_card_visa

Gran parte delle integrazioni non usa più i Token, ma mettiamo comunque a disposizione dei token di test come tok_visa qualora dovessero servirti.

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 esito positivo, usa le carte di test riportate nel seguente elenco. Il paese di addebito è impostato su Stati Uniti per tutte le carte di test. Se devi creare pagamenti con carta di test utilizzando carte con altri paesi di addebito, utilizza le carte di test internazionali.

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.

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 simula fattori di rischio specifici. Le impostazioni di Radar determinano i fattori di rischio che fanno scattare il blocco di un pagamento. I pagamenti bloccati risultano in errori di carta con codice di errore per 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 .

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).

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.

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.

Webhook

Per testare i webhook, puoi scegliere tra due opzioni:

1. Esegui le operazioni in modalità di test per inviare eventi legittimi al tuo endpoint. 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 richieste in modalità di test iniziano a ricevere errori HTTP 429, riducine la frequenza. Tali errori dipendono dal nostro limitatore di frequenza, che è più rigido in modalità di test rispetto alla modalità live.

Sconsigliamo di eseguire il test di carico dell’integrazione usando l’API Stripe in modalità di test. Dato che il limitatore del carico è più rigido in modalità 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:

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 una modalità di pagamento supportata che richiede reindirizzamenti.

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

1. Accedi alle impostazioni delle modalità di pagamento nella Dashboard e abilita una modalità di pagamento supportata cliccando su **Attiva ** in modalità 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.