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 testTest payment methods (1)

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.

Errore comune

Non utilizzare i dati reali della carta. Il Contratto di servizio Stripe vieta il test in modalità live con i dati reali della modalità di pagamento. Utilizza le tue chiavi API di test e i numeri di carta riportati di seguito.

Test interattiviTest payment methods (2)

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.

Test payment methods (3)

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

Codice di testTest payment methods (4)

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.

Command Line

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 circuitoTest payment methods (5)

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.

Attenzione

Le commissioni per transazioni transfrontaliere sono valutate in base al paese della società emittente della carta. Anche se ciascuna delle carte in questa sezione utilizzi gli Stati Uniti come paese di addebito, le carte per cui il paese della società emittente non è gli Stati Uniti (come JCB e UnionPay) potrebbero essere soggette a una commissione per transazioni transfrontaliere, anche in modalità di test.

CircuitoNumeroCVCData
Visa3 cifre qualsiasiQualsiasi data futura
Visa (carta di debito)3 cifre qualsiasiQualsiasi data futura
Mastercard3 cifre qualsiasiQualsiasi data futura
Mastercard (serie 2)3 cifre qualsiasiQualsiasi data futura
Mastercard (carta di debito)3 cifre qualsiasiQualsiasi data futura
Mastercard (carta prepagata)3 cifre qualsiasiQualsiasi data futura
American Express4 cifre qualsiasiQualsiasi data futura
American Express4 cifre qualsiasiQualsiasi data futura
Discover3 cifre qualsiasiQualsiasi data futura
Discover3 cifre qualsiasiQualsiasi data futura
Discover (debito)3 cifre qualsiasiQualsiasi data futura
Diners Club3 cifre qualsiasiQualsiasi data futura
Diners Club (carta con 14 cifre)3 cifre qualsiasiQualsiasi data futura
BCcard e DinaCard3 cifre qualsiasiQualsiasi data futura
JCB3 cifre qualsiasiQualsiasi data futura
UnionPay3 cifre qualsiasiQualsiasi data futura
UnionPay (carta di debito)3 cifre qualsiasiQualsiasi data futura
UnionPay (carta con 19 cifre)3 cifre qualsiasiQualsiasi data futura

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.

Circuito/Co-brandingNumeroCVCData
Cartes Bancaires/Visa3 cifre qualsiasiQualsiasi data futura
Cartes Bancaires/Mastercard3 cifre qualsiasiQualsiasi data futura
eftpos Australia/Visa3 cifre qualsiasiQualsiasi data futura
eftpos Australia/Mastercard3 cifre qualsiasiQualsiasi data futura

Carte suddivise per paeseTest payment methods (6)

Per simulare pagamenti con esito positivo provenienti da paesi specifici, usa le carte di test riportate nelle seguenti sezioni.

PaeseNumeroCircuito
AMERICHE
Stati Uniti (USA)Visa
Argentina (AR)Visa
Brasile (BR)Visa
Canada (CA)Visa
Cile (CL)Visa
Colombia (CO)Visa
Costa Rica (CR)Visa
Ecuador (EC)Visa
Messico (MX)Visa
Messico (MX)Carnet
Panama (PA)Visa
Paraguay (PY)Visa
Perù (PE)Visa
Uruguay (UY)Visa
EUROPA e MEDIO ORIENTE

Suggerimento sulla sicurezza

Le normative sulla Strong Customer Authentication richiedono l’autenticazione 3D Secure per i pagamenti online effettuati all’interno dello Spazio economico europeo (SEE). Le carte di test di questa sezione simulano un pagamento che va a buon fine senza autenticazione. Consigliamo di testare anche scenari che prevedono l’autenticazione, usando carte di test 3D Secure.

Emirati Arabi Uniti (EAU)Visa
Emirati Arabi Uniti (EAU)Mastercard
Austria (AT)Visa
Belgio (BE)Visa
Bulgaria (BG)Visa
Bielorussia (BY)Visa
Croazia (HR)Visa
Cipro (CY)Visa
Repubblica Ceca (CZ)Visa
Danimarca (DK)Visa
Estonia (EE)Visa
Finlandia (FI)Visa
Francia (FR)Visa
Germania (DE)Visa
Gibilterra (GI)Visa
Grecia (GR)Visa
Ungheria (HU)Visa
Irlanda (IE)Visa
Italia (IT)Visa
Lettonia (LV)Visa
Liechtenstein (LI)Visa
Lituania (LT)Visa
Lussemburgo (LU)Visa
Malta (MT)Visa
Paesi Bassi (NL)Visa
Norvegia (NO)Visa
Polonia (PL)Visa
Portogallo (PT)Visa
Romania (RO)Visa
Arabia Saudita (SA)Visa
Slovenia (SI)Visa
Slovacchia (SK)Visa
Spagna (ES)Visa
Svezia (SE)Visa
Svizzera (CH)Visa
Regno Unito (GB)Visa
Regno Unito (GB)Visa (carta di debito)
Regno Unito (GB)Mastercard
ASIA-PACIFICO

Considerazioni locali

Per eseguire il test degli abbonamenti che richiedono mandati e notifiche di preaddebito, consulta Pagamenti ricorrenti in India.

Australia (AU)Visa
Cina (CN)Visa
Hong Kong (HK)Visa
India (IN)Visa
Giappone (JP)Visa
Giappone (JP)JCB
Malaysia (MY)Visa
Nuova Zelanda (NZ)Visa
Singapore (SG)Visa
Taiwan (TW)Visa
Thailandia (TH)Visa (credito)
Thailandia (TH)Visa (carta di debito)

Pagamenti rifiutatiTest payment methods (7)

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.

Errore comune

Per simulare un CVC errato, devi indicare uno, ovvero qualsiasi numero composto da tre cifre. Se non indichi un CVC, Stripe non esegue il controllo del CVC, il quale non potrà così risultare errato.

DescrizioneNumeroCodice di erroreCodice di rifiuto
Rifiuto genericocard_declinedgeneric_decline
Pagamento rifiutato per fondi insufficienticard_declinedinsufficient_funds
Pagamento rifiutato per carta smarritacard_declinedlost_card
Pagamento rifiutato per carta rubatacard_declinedstolen_card
Pagamento rifiutato per carta scadutaexpired_cardn/a
Pagamento rifiutato per CVC erratoincorrect_cvcn/a
Pagamento rifiutato per errore di elaborazioneprocessing_errorn/a
Pagamento rifiutato per numero erratoincorrect_numbern/a
Rifiuto limite di velocità in eccessocard_declinedcard_velocity_exceeded

Le carte riportate nella tabella precedente non possono essere associate a un oggetto Customer. Per simulare un pagamento rifiutato con una carta associata, usa quella indicata di seguito.

DescrizioneNumeroDettagli
Rifiuto dopo associazioneL’associazione di un oggetto Customer alla carta riesce, ma il tentativo di addebitare il costo al cliente non va a buon fine.

Prevenzione delle frodiTest payment methods (8)

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.

Errore comune

Per simulare un controllo del CVC non riuscito, devi indicare un CVC, ovvero un qualsiasi numero composto da tre cifre. Per simulare un controllo del codice postale non riuscito, devi indicare un qualsiasi codice postale valido. Se non indichi questi valori, Radar non esegue i controlli corrispondenti, che non possono perciò non andare a buon fine.

DescrizioneNumeroDettagli

Sempre bloccato

L’addebito ha un livello di rischio “massimo”.

Radar lo blocca sempre.

Rischio massimo

L’addebito ha un livello di rischio “massimo”.

Radar potrebbe bloccarlo a seconda delle impostazioni che hai scelto.

Rischio elevato

L’addebito ha un livello di rischio “elevato”.

Se usi Radar for Fraud Teams, Radar potrebbe inserirlo nella coda di revisione.

Controllo CVC non riuscito

Se indichi un numero CVC, il relativo controllo non va a buon fine.

Radar potrebbe bloccarlo a seconda delle impostazioni che hai scelto.

Controllo del codice postale non riuscito

Se indichi un codice postale, il relativo controllo non va a buon fine.

Radar potrebbe bloccarlo a seconda delle impostazioni che hai scelto.

Controllo riga1 non riuscito

Il controllo della riga 1 dell’indirizzo non va a buon fine.

Il pagamento va a buon fine a meno che tu non lo blocchi con una regola Radar personalizzata.

Controlli indirizzo non riusciti

Il controllo del codice postale e della riga 1 dell’indirizzo non vanno a buon fine.

Radar potrebbe bloccarlo a seconda delle impostazioni che hai scelto.

Indirizzo non disponibile

Il controllo del codice postale e della riga 1 dell’indirizzo non sono disponibili.

Il pagamento va a buon fine a meno che tu non lo blocchi con una regola Radar personalizzata.

Dati non validiTest payment methods (9)

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 .

ContestazioniTest payment methods (10)

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.

DescrizioneNumeroDettagli
FrodeCon le impostazioni predefinite dell’account, l’addebito va a buon fine ma viene contestato per frode. Dopo l’autenticazione 3D Secure, questo tipo di contestazione è protetto.
Mancata ricezioneCon le impostazioni predefinite dell’account, l’addebito va a buon fine ma viene contestato come prodotto non ricevuto. Dopo l’autenticazione 3D Secure, questo tipo di contestazione non è protetto.
IndagineCon le impostazioni predefinite dell’account, l’addebito va a buon fine ma viene contestato per la necessità di un’indagine.
AvvisoCon le impostazioni predefinite dell’account, l’addebito va a buon fine ma genera un preavviso di frode.
Più contestazioniCon le impostazioni predefinite dell’account, l’addebito va a buon fine, ma viene contestato più volte.

ProveTest payment methods (11)

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.
ProveDescrizione
winning_evidenceLa contestazione è stata chiusa e contrassegnata come vinta. L’importo dell’addebito e delle relative commissioni è stato accreditato sull’account.
losing_evidenceLa contestazione viene chiusa e contrassegnata come persa. L’importo non viene accreditato sull’account.

RimborsiTest payment methods (12)

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

DescrizioneNumeroDettagli
Esito positivo asincronoL’addebito va a buon fine. Se avvii un processo di rimborso, il suo stato iniziale è pending. Successivamente, lo stato passa a succeeded e invia un evento webhook charge.refund.updated.
Esito negativo asincronoL’addebito va a buon fine. Se avvii un processo di rimborso, il suo stato iniziale è succeeded. Successivamente, lo stato passa a failed e invia un evento webhook charge.refund.updated.

Saldo disponibileTest payment methods (13)

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.

DescrizioneNumeroDettagli
Salta saldo in sospesoL’addebito statunitense va a buon fine. I fondi vengono aggiunti direttamente al saldo disponibile, senza passare per il saldo in sospeso.
Salta saldo in sospesoL’addebito internazionale va a buon fine. I fondi vengono aggiunti direttamente al saldo disponibile, senza passare per il saldo in sospeso.

Autenticazione 3D SecureTest payment methods (14)

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.

Dashboard non supportata

I reindirizzamenti a 3D Secure non si verificano per i pagamenti creati direttamente nella Dashboard Stripe. Usa invece il front-end della tua integrazione o una chiamata API.

Autenticazione e configurazioneTest payment methods (15)

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.

DescrizioneNumeroDettagli
Autenticazione in mancanza di configurazioneQuesta carta richiede l’autenticazione per i pagamenti all’esterno della sessione a meno che tu non l’abbia configurata per pagamenti futuri. Dopo la configurazione, i pagamenti all’esterno della sessione non richiederanno più l’autenticazione.
Autentica sempreQuesta carta richiede l’autenticazione per tutte le transazioni, indipendentemente dalla sua configurazione.
Configura sempreQuesta carta è già stata configurata per l’uso all’esterno della sessione. Richiede l’autenticazione per i pagamenti una tantum e altri pagamenti all’interno della sessione. Tuttavia, tutti i pagamenti all’esterno della sessione andranno a buon fine come se la carta fosse stata precedentemente configurata.
Fondi insufficientiQuesta carta richiede l’autenticazione per i pagamenti una tantum. Tutti i pagamenti vengono rifiutati con un codice di errore insufficient_funds anche dopo essere stati correttamente autenticati o precedentemente configurati.

Supporto e disponibilitàTest payment methods (16)

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.

Nota

Tutti i riferimenti a 3DS indicano 3D Secure 2.

Uso di 3D SecureRisultatoNumeroDettagli
3DS richiestoOKPerché il pagamento vada a buon fine è necessario completare l’autenticazione 3D Secure. Per impostazione predefinita, le regole Radar impongono l’autenticazione 3D Secure per questa carta.
3DS richiestoOperazione rifiutataÈ necessario completare l’autenticazione 3D Secure, ma al termine della procedura i pagamenti saranno rifiutati con un codice di errore card_declined. Per impostazione predefinita, le regole Radar impongono l’autenticazione 3D Secure per questa carta.
3DS richiestoErroreL’autenticazione 3D Secure è obbligatoria, ma le richieste di ricerca 3D Secure non vanno a buon fine e restituiscono un errore di elaborazione. I pagamenti vengono rifiutati con un codice di errore card_declined. Per impostazione predefinita, le regole Radar impongono l’autenticazione 3D Secure per questa carta.
3DS supportatoOKÈ possibile, ma non obbligatorio, eseguire l’autenticazione 3D Secure. Per impostazione predefinita, le regole Radar non impongono l’autenticazione 3D Secure per questa carta.
3DS supportatoErroreÈ possibile, ma non obbligatorio, eseguire l’autenticazione 3D Secure. Tuttavia, i tentativi di eseguire questo tipo di autenticazione genereranno un errore di elaborazione. Per impostazione predefinita, le regole Radar non impongono l’autenticazione 3D Secure per questa carta.
3DS supportatoRegistrazione non eseguitaL’autenticazione 3D Secure è supportata per questa carta, ma la carta non è registrata in 3D Secure. Anche se le regole Radar impongono l’autenticqazione 3D Secure, al cliente non verrà richiesto di eseguire autenticazione. Per impostazione predefinita, le regole Radar non impongono l’autenticazione 3D Secure per questa carta.
3DS non supportatoL’autenticazione 3D Secure non è supportata per questa carta e non può essere richiamata. Il PaymentIntent o il SetupIntent verrà eseguito senza l’autenticazione.

Flussi di autenticazione standard su dispositivo mobile 3D SecureTest payment methods (17)

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.

Flusso di autenticazione standardNumeroDettagli
Fuori da StripeÈ necessario completare l’autenticazione 3D Secure 2 per tutte le transazioni. Attiva il flusso di autenticazione standard con interfaccia utente esterna.
Passcode una tantumÈ necessario completare l’autenticazione 3D Secure 2 per tutte le transazioni. Attiva il flusso di autenticazione standard con interfaccia utente del passcode una tantum.
Selezione singolaÈ necessario completare l’autenticazione 3D Secure 2 per tutte le transazioni. Attiva il flusso di autenticazione standard con interfaccia utente a selezione singola.
Selezione multiplaÈ necessario completare l’autenticazione 3D Secure 2 per tutte le transazioni. Attiva il flusso di autenticazione standard con interfaccia utente a selezione multipla.

Pagamenti tramite PINTest payment methods (18)

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.

DescrizioneNumeroDettagli
PIN offlineQuesta carta simula un pagamento in cui il titolare della carta è tenuto a inserire un PIN offline. L’addebito che ne risulta ha la voce cardholder_verification_method impostata su offline_pin.
Ripetizione tentativi PIN offlineSimula un flusso di ripetizione di tentativi attivato dall’autenticazione SCA, in cui l’addebito senza contatto iniziale del titolare della carta non riesce, per cui il lettore richiede l’inserimento della carta e la digitazione del PIN offline. L’addebito che ne risulta ha la voce cardholder_verification_method impostata su offline_pin.
PIN onlineQuesta carta simula un pagamento in cui il titolare della carta inserisce un PIN online. L’addebito che ne risulta ha la voce cardholder_verification_method impostata su online_pin.
Ripetizione tentativi PIN onlineSimula un flusso di ripetizione di tentativi attivato dall’autenticazione SCA, in cui l’addebito senza contatto iniziale del titolare della carta non riesce, per cui il lettore richiede l’inserimento della carta e la digitazione del PIN online. L’addebito che ne risulta ha la voce cardholder_verification_method impostata su online_pin.

WebhookTest payment methods (19)

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 frequenzaTest payment methods (20)

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 cartaTest payment methods (21)

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:

Scopri come testare gli scenari con verifiche immediate utilizzando Financial Connections.

Invia email delle transazioni in modalità di testTest payment methods (22)

Dopo aver raccolto le coordinate bancarie e accettato un mandato, invia le email di conferma del mandato e di verifica del microdeposito in modalità di test. Per farlo, fornisci un’email nel campo payment_method_data.billing_details[email] sotto forma di {any-prefix}+test_email@{any_domain} quando raccogli i dettagli della modalità di pagamento.

Errore comune

Devi attivare il tuo account Stripe prima di poter attivare queste email in modalità di test.

Test account numbersTest payment methods (23)

Stripe fornisce diversi numeri di account di prova e token corrispondenti che è possibile utilizzare per assicurarsi che l’integrazione per i conti bancari inseriti manualmente sia pronta per la produzione.

Account numberTokenRouting numberBehavior
000123456789pm_usBankAccount_success110000000Il pagamento va a buon fine.
000111111113pm_usBankAccount_accountClosed110000000Il pagamento non va a buon fine perché l’account è chiuso.
000111111116pm_usBankAccount_noAccount110000000Il pagamento non va a buon fine perché non è stato trovato alcun account.
000222222227pm_usBankAccount_insufficientFunds110000000Il pagamento non va a buon fine a causa di fondi insufficienti.
000333333335pm_usBankAccount_debitNotAuthorized110000000Il pagamento non va a buon fine perché gli addebiti non sono autorizzati.
000444444440pm_usBankAccount_invalidCurrency110000000Il pagamento non va a buon fine a causa di una valuta non valida.
000666666661pm_usBankAccount_failMicrodeposits110000000Invio dei microdepositi non riuscito.
000555555559pm_usBankAccount_dispute110000000Il pagamento determina l’avvio di una contestazione.
000000000009pm_usBankAccount_processing110000000Il pagamento rimane in elaborazione a tempo indeterminato. Utile per verificare l’annullamento di un PaymentIntent.

Prima di completare le transazioni di test, è necessario verificare tutti gli account di prova che generano automaticamente l’esito positivo o negativo del pagamento. A tal fine, utilizza gli importi di microdeposito di test o i codici voce riportati di seguito.

Importi dei microdepositi di test e codici voceTest payment methods (24)

Per imitare scenari diversi, utilizza questi importi dei microdepositi o i valori di codice voce 0,01.

Valori di microdepositoValori del codice voce 0,01Scenario
32 and 45SM11AASimula la verifica dell’account.
10 e 11SM33CCSimula il superamento del numero di tentativi di verifica consentiti.
40 e 41SM44DDSimula un timeout di microdeposito.

ReindirizzamentiTest payment methods (25)

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.

Vedi ancheTest payment methods (26)

  • Test dell’integrazione Connect
  • Test dell’integrazione di Billing
  • Test dell’integrazione di Terminal
  • Test di carico
Test payment methods (2024)
Top Articles
Latest Posts
Article information

Author: Maia Crooks Jr

Last Updated:

Views: 5835

Rating: 4.2 / 5 (63 voted)

Reviews: 94% of readers found this page helpful

Author information

Name: Maia Crooks Jr

Birthday: 1997-09-21

Address: 93119 Joseph Street, Peggyfurt, NC 11582

Phone: +2983088926881

Job: Principal Design Liaison

Hobby: Web surfing, Skiing, role-playing games, Sketching, Polo, Sewing, Genealogy

Introduction: My name is Maia Crooks Jr, I am a homely, joyous, shiny, successful, hilarious, thoughtful, joyous person who loves writing and wants to share my knowledge and understanding with you.