Test

Testez votre intégration dans un environnement de test en simulant des transactions avec des valeurs de test. Ces transactions ne génèrent aucun transfert de fonds.

Vous pouvez accéder à vos environnements de test à l’aide du sélecteur de compte dans le Dashboard.

Les cartes de test agissent comme de « fausses » cartes de crédit et vous permettent de simuler les scénarios suivants :

• Paiements réussis par marque de carte ou pays
• Erreurs de carte bancaire liées à des refus de paiement, à la fraude ou à des données non valides
• Litiges et remboursements
• Authentification avec 3D Secure et les PIN

Vous pouvez également tester des paiements autres que par carte dans un environnement de test. Les paiements autres que par carte sont des moyens de paiement qui ne sont pas des cartes de crédit ou de débit. Stripe prend en charge diverses options de paiement autres que par carte, telles que les wallets et les virements bancaires. Chaque moyen de paiement a ses propres valeurs spéciales.

N’utilisez pas les environnements de test pour les tests de charge de votre intégration, car vous risquez d’atteindre les limites de débit. Pour les tests de charge de votre intégration, consultez la page Tests de charge.

Comment utiliser les cartes de test

Lorsque vous travaillez avec une carte de test, utilisez des clés API de test dans tous les appels API. C’est vrai que vous utilisiez un formulaire de paiement pour tester de manière interactive ou que vous écriviez du code de test.

Test interactif

Lorsque vous effectuez des tests de manière interactive, utilisez un numéro de carte, tel que 4242 4242 4242 4242. Saisissez le numéro de carte dans le Dashboard ou dans n’importe quel formulaire de paiement.

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

Code de test

Lorsque vous écrivez du code de test, utilisez un PaymentMethod tel que pm_card_visa au lieu d’un numéro de carte. Nous ne recommandons pas d’utiliser les numéros de carte directement dans les appels API ou le code côté serveur, même dans les environnements de test. Si vous le faites, votre code risque de ne pas être conforme à la norme PCI lorsque vous passerez en production. Par défaut, un PaymentMethod n’est pas rattaché à un Customer.

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

Lorsque vous êtes prêt à passer votre intégration en production, remplacez vos clés d’API (publiable et secrète) de test par des clés de mode production.

Vous ne pourrez pas traiter les paiements en mode production si votre intégration utilise encore vos clés API de test. Sauvegardez les clés API de mode production dans un coffre-fort de secrets ou des variables d’environnement. Ne sauvegardez pas les clés dans le code source ni dans les fichiers de configuration versionnés. Pour savoir comment utiliser les clés en mode production en toute sécurité, consultez les bonnes pratiques de gestion des clés API secrètes.

Simuler un paiement par marque de carte bancaire

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

Les frais transfrontaliers sont évalués en fonction du pays de l’émetteur de la carte. Les cartes dont le pays d’émission n’est pas les États-Unis (comme JCB et UnionPay) peuvent être soumises à des frais transfrontaliers, même dans les environnements de test.

La plupart des cartes Cartes Bancaires et eftpos sont comarquées avec Visa ou Mastercard. Les cartes de test du tableau suivant simulent des paiements réussis avec des cartes comarquées.

Simuler un paiement par pays

Pour simuler des paiements réussis depuis des pays spécifiques, utilisez les cartes de test des sections suivantes.

Simuler l’emplacement d’un client avec une adresse e-mail

Lors du test de Checkout Sessions, de Payment Links ou des grilles tarifaires, vous pouvez simuler la localisation géographique d’un client en utilisant une adresse e-mail formatée en fonction de son emplacement. Ajoutez le suffixe +location_XX à la partie locale de n’importe quelle adresse e-mail, où XX est un code pays valide à deux lettres ISO 3166-1 alpha-2.

Par exemple, pour simuler un client situé aux États-Unis, transmettez test+location_US@example.com comme paramètre customer_email lors de la création d’une Checkout Session et comme paramètre prefilled_email dans l’URL lors de la création d’un Payment Link.

Lorsque vous accédez à l’URL de la Checkout Session obtenue, vous voyez la même devise et les mêmes moyens de paiement qu’un client dans le pays spécifié. En savoir plus sur les tests avec des e-mails formatés en fonction de l’emplacement.

Simuler un paiement par carte bancaire HSA ou FSA

Vous trouverez ci-dessous des numéros de carte de test pour 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 eux garantissent une gestion correcte des transactions liées aux soins de santé dans votre application.

Simuler un paiement refusé

Pour tester la logique de gestion des erreurs de votre intégration en simulant des paiements que l’émetteur refuse pour diverses raisons, utilisez les cartes de test de cette section. Ces cartes renvoient une erreur de carte avec le code d’erreur et le code de refus listés.

Fournissez un CVC lorsque vous testez le comportement CVC. Stripe ignore la vérification CVC si vous l’omettez, de sorte que la vérification ne peut pas échouer. Pour simuler un CVC incorrect, utilisez la carte bancaire de test « Refus de paiement pour CVC incorrect » répertoriée dans le tableau suivant et fournissez n’importe quel CVC à trois chiffres.

Prévention de la fraude

Le système de prévention de la fraude de Stripe, Radar, peut bloquer les paiements lorsqu’ils présentent un niveau de risque élevé ou échouent aux vérifications. Vous pouvez utiliser les cartes de cette section pour tester vos paramètres Radar. Vous pouvez également les utiliser pour tester la manière dont votre intégration répond aux paiements bloqués.

Chaque carte simule des facteurs de risque spécifiques. Vos paramètres Radar déterminent les facteurs de risque qui entraînent le blocage d’un paiement. Les paiements bloqués entraînent des erreurs de carte avec un code d’erreur de fraude.

Pour déclencher un échec de la vérification CVC, incluez un CVC (n’importe quel numéro à trois chiffres). Pour déclencher un échec de la vérification du code postal, incluez n’importe quel code postal valide. Si vous omettez ces champs, Radar ignore ces vérifications, et les vérifications ne peuvent donc pas échouer.

Déclencher une erreur avec des données non valides

Pour tester les erreurs résultant de données non valides, fournissez des informations non valides. Vous n’avez pas besoin d’une carte de test spéciale pour cela. N’importe quelle valeur non valide fonctionne. Par exemple :

• invalid_expiry_month : utilisez un mois non valide, tel que 13.
• invalid_expiry_year : utilisez une année passée (jusqu’à 50 ans en arrière), telle que 95.
• invalid_cvc : utilisez un numéro à deux chiffres, tel que 99.
• incorrect_number : utilisez un numéro de carte qui échoue à la vérification de Luhn, tel que 4242424242424241.

Simuler un litige

Pour simuler une transaction contestée, utilisez les cartes de test de cette section. Ensuite, pour simuler la victoire ou la perte du litige, fournissez des preuves de victoire ou de perte.

Preuve

Pour simuler la victoire ou la perte du litige, répondez avec l’une des valeurs de preuve du tableau ci-dessous.

• Si vous répondez à l’aide de l’API, transmettez la valeur du tableau en tant que uncategorized_text.
• Si vous répondez via le Dashboard ou les composants intégrés Connect, saisissez l ’ une des valeurs du tableau dans le champ Informations supplémentaires, puis cliquez sur Soumettre des preuves.

Prévention des litiges

La prévention des litiges permet de résoudre ou de bloquer les litiges avant qu’ils ne deviennent des rétrofacturations. Pour simuler des litiges évités en mode test, utilisez les cartes bancaires de test de cette section. Si votre compte a la fonctionnalité de résolution des litiges ou déviation des litiges activé, le litige lié à la transaction est soit bloqué, soit résolu. Sinon, la transaction fait l’objet d’un litige avec succès.

Simuler un remboursement asynchrone

En mode production, les remboursements se produisent de manière asynchrone : un remboursement peut sembler aboutir et finalement échouer, 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 (avec les autres cartes de test, les remboursements aboutissent immédiatement et ne changent plus d’état).

Vous ne pouvez annuler un remboursement de carte qu’en utilisant le Dashboard. En mode production, vous pouvez annuler un remboursement de carte dans un délai court mais non spécifié. Les environnements de test simulent cette période en vous permettant d’annuler un remboursement de carte dans les 30 minutes.

Envoyer des fonds vers votre solde disponible

Pour envoyer les fonds d’une transaction de test directement à votre solde disponible, utilisez les cartes de test de cette section. Les autres cartes de test envoient les fonds d’un paiement réussi à votre solde en attente.

Tester l’authentification 3D Secure

3D Secure exige une couche 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 3DS défini, tel qu’un parcours de challenge ou une carte non prise en charge. D’autres cartes de test Stripe peuvent toujours déclencher 3DS, mais nous renvoyons attempt_acknowledged pour contourner les étapes supplémentaires, car le test 3DS n’est pas l’objectif pour ces cartes.

Authentification et configuration

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

Assistance et disponibilité

Stripe demande 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 si l’authentification est demandée, elle ne peut pas toujours être effectuée : par exemple, la carte du client peut ne pas être enrôlée, ou une erreur peut se produire. Utilisez les cartes de test de cette section pour simuler différentes combinaisons de ces facteurs.

Toutes les références 3DS indiquent 3D Secure 2.

Flux de challenge mobile 3D Secure

Dans un paiement mobile, plusieurs parcours de challenge pour l’authentification (où le client doit interagir avec des invites dans l’interface utilisateur) sont disponibles. Utilisez les cartes de test de cette section pour déclencher un parcours de challenge spécifique à des fins de test. Ces cartes ne sont pas utiles dans les formulaires de paiement basés sur un navigateur ou dans les appels API. Dans ces environnements, elles fonctionnent mais ne déclenchent aucun comportement spécial. Comme elles ne sont pas utiles dans les appels API, nous ne fournissons aucune valeur PaymentMethod ou Token pour les tests.

Simuler un test captcha

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

Simuler un paiement en personne avec un code PIN

Utilisez les cartes de test de cette section pour simuler des paiements en personne réussis impliquant un PIN. Il existe de nombreuses autres options pour tester les paiements en personne, notamment un lecteur simulé et des cartes de test physiques. Consultez la page Tester Stripe Terminal pour plus d’informations.

Tester une destination webhook ou d’événement

Pour tester votre endpoint de webhook ou votre destination d’événement, choisissez l’une des deux options suivantes :

1. Utilisez un environnement de test pour effectuer des actions qui envoient des événements légitimes à votre destination d’événements. Par exemple, vous pouvez utiliser une carte de test amenant un paiement à aboutir pour déclencher l’événement charge.succeeded.
2. Déclenchez des événements à l’aide de l’interface de ligne de commande Stripe ou via Stripe pour Visual Studio Code.

Limites d’appels

Si les requêtes dans vos environnements de test commencent à recevoir des erreurs HTTP 429, diminuez leur fréquence. Ces erreurs proviennent de notre limiteur de débit, qui est plus strict dans les environnements de test qu’en mode production.

Nous ne recommandons pas les tests de 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, il se peut que vous rencontriez des erreurs que vous ne verriez pas en production. Consultez la page Tests de charge pour une autre approche.

Tester un moyen de paiement autre que par carte

Lorsque vous utilisez un moyen de paiement de test autre qu’une carte, utilisez des clés API de test dans tous les appels API, que vous utilisiez un formulaire de paiement que vous pouvez tester de manière interactive ou que vous écriviez du code de test.

Les différents moyens de paiement ont des procédures de test différentes :

Tester Link

À l’heure actuelle, Link fonctionne uniquement pour les cartes de crédit, les cartes de débit et les achats effectués à partir d’un compte bancaire américain éligible. Link requiert un enregistrement de domaine.

Vous pouvez créer des comptes environnement de test pour Link à l’aide d’une adresse e-mail valide. Le tableau suivant répertorie les codes à usage unique acceptés par Stripe pour l’authentification des comptes environnement de test :

Sources de financement multiples

Dans la mesure où Stripe prend en charge des sources de financement supplémentaires, vous n’avez pas besoin de mettre à jour votre intégration. Stripe les prend en charge automatiquement avec les mêmes délais de virement de fonds et les mêmes garanties que pour les paiements par carte ou par compte bancaire.

Tester un flux de redirection

Pour tester la logique de gestion des redirections de votre intégration en simulant un paiement qui utilise un flux de redirection (par exemple, iDEAL), utilisez un moyen de paiement pris en charge qui nécessite des redirections.

Pour créer un PaymentIntent de test qui réussit ou échoue :

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

Assurez-vous que la page (correspondant à return_url) sur votre site web fournit l’état du paiement.