Tests

Pour vérifier que votre intégration fonctionne correctement, simulez des paiements sans transférer de fonds à l’aide de valeurs spéciales en mode test ou dans les bacs à sable.

Les cartes de test fonctionnent comme de fausses cartes de crédit et vous permettent de simuler plusieurs scénarios :

• Les paiements réussis par marque de carte ou pays
• Erreurs de cartes dues à des refus, des fraudes, ou des données non valides
• Les litiges et les remboursements
• Authentification avec 3D Secure et des NIP

Les tests de paiements effectués avec un autre mode de paiement qu’une carte fonctionnent de façon similaire. Chaque mode de paiement possède ses propres valeurs. Compte tenu des limites de débit, nous vous déconseillons d’utiliser les environnements de test pour tester la charge de votre intégration. Consultez plutôt la documentation sur les tests de charge.

Comment utiliser des cartes de test

Utilisez des clés API de test pour les appels à l’API chaque fois que vous utilisez une carte de test, que vous souhaitiez tester un formulaire de paiement de manière interactive ou rédiger du code de test.

Tests interactifs

Lorsque vous effectuez des tests interactifs, utilisez un numéro de carte de type 4242 4242 4242 4242. Saisissez ce numéro de carte dans le Dashboard ou dans un formulaire de paiement.

• Utilisez une date future valide telle que 12/34.
• Utilisez n’importe quel code CVC à trois chiffres (quatre chiffres pour les cartes American Express).
• Utilisez la valeur de votre choix pour les autres champs du formulaire

Test d’un formulaire interactif avec la carte de test 4242 4242 4242 4242

Code de test

Lorsque vous rédigez du code de test, utilisez un PaymentMethod de type pm_card_visa plutôt qu’un numéro de carte. Nous vous déconseillons d’utiliser des numéros de carte directement dans des appels à l’API ou dans du code côté serveur, même dans les environnements de test, car votre code risquerait de ne pas être conforme à la norme PCI lors de votre passage en mode production. Par défaut, les clients. ne sont pas associés à un a PaymentMethod.

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

La majorité des intégrations n’utilisent plus de jetons, mais il existe des jetons de test comme tok_visa en cas de besoin.

Au moment de passer votre intégration en mode production, remplacez vos clés API de test par celles de production. Vous ne pouvez pas traiter de paiements en mode production si votre intégration utilise toujours des clés API de test.

Cartes par marque

Pour simuler un paiement réussi pour une marque de carte spécifique, utilisez les cartes de test de la liste suivante.

La majorités des cartes Cartes Bancaires et eftpos sont comarquées avec Visa ou Mastercard. Les cartes de test présentes dans la section suivante simulent des paiements aboutis avec ce genre de cartes.

Cartes par pays

Pour simuler des paiements effectués de pays spécifiques, utilisez les cartes de test présentes dans les sections suivantes.

Cartes de test HSA et FSA

Vous trouverez ci-dessous des numéros de carte de test permettant de simuler des transactions à l’aide de comptes d’épargne santé (HSA) et de comptes de dépenses flexibles (FSA). Ces comptes sont couramment utilisés pour les frais médicaux, et les tests effectués avec ces comptes permettent d’assurer un traitement adéquat des transactions liées aux soins de santé dans votre application.

Paiements refusés

Pour tester la logique de gestion des erreurs de votre intégration en simulant des paiements refusés pour différents motifs, utilisez les cartes de test présentées dans cette section. L’utilisation de l’une de ces cartes génère une erreur de carte avec un code d’erreur et un code de refus de paiement correspondant.

Prévention de la fraude

Radar est le système de prévention de fraude de Stripe. Il peut bloquer des paiements s’ils présentent un risque élevé ou si les vérifications échouent. Vous pouvez utiliser les numéros de cartes présents dans la section suivante pour tester vos paramètres de Radar ou pour observer comment votre intégration réagit face à des paiements bloqués.

Chaque carte simule différents facteurs de risque. Vos paramètres Radar déterminent quels sont ceux qui bloquent un paiement. Les paiements bloqués génèrent des erreurs de cartes dont le code d’erreur correspond à une fraude.

Données non valides

Pour tester des erreurs résultant de données invalides, fournissez des informations invalides. Vous n’avez pas besoin d’une carte de test spéciale; toute valeur invalide fonctionne. Par exemple :

• invalid_expiry_month : utilisez un mois non valide (par exemple, 13).
• invalid_expiry_year : indiquez une année remontant à moins de 50 ans (par exemple, 95).
• invalid_cvc : utilisez un nombre à deux chiffres (par exemple, 99).
• incorrect_number : utilisez un numéro de carte qui échoue à la vérification par algorithme de Luhn par exemple, 4242424242424241
  .

Litiges

Pour simuler une transaction contestée, utilisez les cartes de test présentées dans cette section. Ensuite, pour simuler le gain ou la perte du litige, vous devrez fournir des preuves correspondantes.

Preuve

Pour simuler le fait de remporter ou de perdre le litige, répondez avec l’une des valeurs de preuve du tableau ci-dessous.

• Si vous répondez via l’API, transmettez l’une des valeurs du tableau en tant que paramètre uncategorized_text.
• Si vous répondez via le Dashboard, saisissez l’une des valeurs du tableau dans le champ Informations supplémentaires, puis cliquez sur Soumettre des preuves.

Remboursements

En mode production, les remboursements sont asynchrones : un remboursement peut sembler aboutir et échouer finalement, ou peut d’abord apparaître comme pending avant d’aboutir. Pour simuler ce genre de remboursements, utilisez les cartes de test présentes dans cette section (les remboursements aboutissent immédiatement et ne changent plus d’état avec les autres cartes de test).

L’annulation d’un remboursement de carte s’effectue uniquement à l’aide du Dashboard. En mode production, vous pouvez annuler un remboursement de carte dans un délai court, mais non spécifique. Les environnements de test simulent cette période en vous permettant d’annuler un remboursement de carte dans les 30 minutes.

Solde disponible

Pour virer les fonds d’un paiement test directement vers votre solde disponible, utilisez les cartes de test présentes dans cette section. Les autres cartes test envoie les fonds d’un paiement test réussi vers votre solde courant.

Authentification 3D Secure

3D Secure nécessite un niveau d’authentification supplémentaire pour les transactions par carte de crédit. Les cartes de test de cette section vous permettent de simuler le déclenchement de l’authentification dans différents flux de paiement.

Seules les cartes de cette section testent efficacement votre intégration 3D Secure en simulant un comportement d’authentification 3DS défini, tel qu’une demande d’authentification ou une carte non prise en charge. D’autres cartes de test Stripe peuvent toujours déclencher l’authentification 3DS, mais nous renvoyons attempt_acknowledged pour contourner les étapes supplémentaires, car le test d’authentification 3DS n’est pas l’objectif de ces cartes.

Authentification et configuration

Pour simuler des flux de paiement incluant une authentification, utilisez les cartes de test présentées dans cette section. Certaines de ces cartes peuvent également être configurées pour les paiements futurs, ou l’ont déjà été.

Prise en charge et disponibilité

Stripe requiert une authentification lorsque la réglementation l’exige, ou lorsqu’elle est déclenchée par vos règles Radar ou votre code personnalisé. Même dans les cas où l’authentification est demandée, elle ne peut pas toujours être effectuée; par exemple, la carte du client peut ne pas être enregistrée ou une erreur peut se produire. Utilisez les cartes bancaires de test de cette section pour simuler diverses combinaisons de ces facteurs.

Demandes d’authentification 3D Secure mobile

Dans le cadre d’un paiement par mobile, plusieurs flux d’authentification (où le client doit interagir avec des instructions dans l’interface utilisateur) sont disponibles. Utilisez les cartes de test présentées dans cette section pour déclencher un flux d’authentification spécifique à des fins de test. Ces cartes ne sont pas utiles dans les formulaires de paiement basés sur les navigateurs ou les appels à l’API. Dans ces environnements, elles fonctionnent mais elles ne déclenchent aucun comportement particulier. Parce qu’elles ne sont pas utiles dans les appels à l’API, nous ne fournissons pas de valeurs de PaymentMethod ou de Token avec lesquelles les tester.

Défi d’authentification Captcha

Pour prévenir la fraude, Stripe peut afficher à l’utilisateur un défi d’authentification Captcha sur la page de paiement. Utilisez les cartes de test ci-dessous pour simuler ce processus.

Paiements avec NIP

Utilisez les cartes de test présentes dans cette section pour simuler l’aboutissement de paiements en personne avec un NIP. Il existe de nombreuses autres options pour tester les paiements en personne, notamment un lecteur de simulation et des cartes de test physiques. Pour en savoir plus, consultez la page consacrée au test de Stripe Terminal.

Destinations d’événement

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.

Limites de débit

Si vous commencez à recevoir des erreurs HTTP 429 pour les requêtes que vous effectuez dans vos environnements de test, réduisez leur fréquence. Ces erreurs proviennent de notre limiteur de débit, qui est plus exigeant dans les environnements de test qu’en mode production.

Nous vous déconseillons de tester la charge de votre intégration à l’aide de l’API Stripe dans les environnements de test. Le limiteur de charge étant plus strict dans les environnements de test, vous risquez de voir apparaître des erreurs que vous ne verriez pas en mode production. Consultez la section Test de charge pour découvrir une méthode alternative.

Paiements par des moyens autres qu’une carte

Utilisez des clés API de test dans les appels à l’API chaque fois que vous utilisez un moyen de paiement de test autre que la carte, que vous souhaitiez tester un formulaire de paiement de manière interactive ou rédiger du code de test.

Chaque moyen de paiement a ses propres procédures de test :

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:

Sources de financement multiples

Au fur et à mesure que Stripe ajoute des sources de financement supplémentaires, vous n’avez pas besoin de mettre à jour votre intégration. Stripe les prend en charge automatiquement avec le même délai de règlement des transactions et les mêmes garanties que les paiements par carte et par compte bancaire.

Redirection

Pour tester la logique de gestion des redirections de votre intégration en simulant un paiement avec flux de redirection (par exemple, iDEAL), utilisez un moyen de paiement à redirection compatible.

Pour créer un PaymentIntent de test susceptible de réussir ou d’échouer :

1. Accédez aux paramètres des modes de paiement dans le Dashboard et activez un mode de paiement pris en charge en cliquant sur Activer dans votre environnement de test.
2. Collecter les informations de paiement.
3. Envoyer le paiement à Stripe.
4. Autoriser ou faire échouer le paiement test.

Assurez-vous que la page (correspondant à return_url) de votre site Web indique l’état du paiement.