Tests

Pour tester votre intégration, simulez des transactions sans déplacer de fonds, en utilisant des valeurs de test spéciales dans un environnement de test. Vous pouvez accéder à vos environnements de test à l’aide du sélecteur de compte en haut à droite de la page ou dans le Dashboard.

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

• Les paiements réussis par marque de carte ou par pays
• Erreurs de carte bancaire dues à des refus de paiement, des fraudes, ou des données non valides
• Les litiges et les remboursements
• L’authentification avec 3D Secure et les codes PIN

Les tests de paiements hors cartes fonctionnent de la même manière. Les paiements hors cartes sont des moyens de paiement qui ne relèvent pas de cartes de crédit ni de débit. Stripe prend en charge diverses options de paiement hors cartes, comme les wallets et les transferts bancaires. Chaque moyen de paiement a ses propres valeurs spécifiques.

N’utilisez pas d’environnements de test pour effectuer des tests de charge de votre intégration, car vous risquez de dépasser les limites de débit. Pour tester la charge de votre intégration, consultez la rubrique Test de charge.

Comment utiliser des cartes bancaires 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 bancaire de type 4242 4242 4242 4242. Saisissez ce numéro de carte dans le Dashboard ou dans un formulaire de paiement.

• Utilisez une date d’expiration 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 interactif d’un formulaire avec le numéro de carte bancaire de test 4242 4242 4242 4242

Code de test

Lorsque vous écrivez du code de test, utilisez un PaymentMethod comme pm_card_visa plutôt qu’un numéro de carte. Nous vous déconseillons d’utiliser les numéros de carte directement dans les appels à l’API ou le code côté serveur, même dans les environnements de test. Votre code risquerait de ne pas être conforme à la norme PCI lors de votre passage en mode production. Par défaut, un PaymentMethod n’est pas associé à un objet Customer.

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 tokens, mais il existe des tokens 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é des cartes bancaires et des cartes eftpos sont co-marquées Visa ou Mastercard. Les cartes de test présentes dans la section suivante simulent des paiements aboutis avec des cartes co-marquées.

Cartes par pays

Pour simuler des paiements réussis provenant de pays spécifiques, utilisez les cartes de test 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 eux permettent de garantir un traitement correct 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 la fraude de Stripe. Il permet de bloquer les paiements à haut risque ou pour lesquels la vérification a échoué. Vous pouvez utiliser les numéros de carte présents dans cette section pour tester vos paramètres Radar ou déterminer 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, vous n’avez pas besoin d’une carte de test spéciale : il vous suffit de saisir une ou plusieurs données invalides. 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 bancaire 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.

Preuves

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 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 pouvez uniquement annuler le remboursement d’un paiement par carte via le Dashboard. En mode production, vous pouvez annuler le remboursement d’un paiement par carte dans un délai court, mais non spécifique. Les environnements de test simulent ce délai en vous permettant d’annuler un remboursement de paiement par carte sous 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 de test envoient les fonds d’un paiement test réussi vers votre solde en attente.

Authentification 3D Secure

Le protocole 3D Secure requiert un niveau d’authentification supplémentaire pour les paiements par carte bancaire. Les cartes de test fournies dans cette section vous permettent de simuler le déclenchement d’une authentification dans différents tunnels de paiement.

Seules les cartes de cette section vous permettent de tester efficacement votre intégration 3D Secure en simulant un comportement 3DS défini, par exemple un flux d’authentification ou une carte non prise en charge. Les autres cartes de test de Stripe peuvent déclencher une authentification 3DS, mais nous renvoyons attempt_acknowledged pour contourner les étapes supplémentaires étant donné que les tests 3DS ne sont 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 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 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.

Flux d’authentification 3D Secure pour mobile

Dans le cadre d’un paiement par mobile, plusieurs flux d’authentification (où le client doit suivre des instructions au sein de 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. Étant donné qu’elles ne sont pas utiles dans les appels à l’API, nous ne fournissons pas de valeurs PaymentMethod ou Token avec lesquelles les tester.

Test Captcha

Pour prévenir la fraude, Stripe peut présenter un test captcha à l’utilisateur sur la page de paiement. Utilisez la carte bancaire de test ci-dessous pour simuler ce flux.

Paiements avec codes PIN

Utilisez les cartes de test présentes dans cette section pour simuler l’aboutissement de paiements par TPE avec un code PIN. Il existe de nombreuses autres options pour tester les paiements par TPE, 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énements

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 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 strict dans les environnements de test qu’en mode production.

Nous vous déconseillons de tester le chargement 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 production. Consultez la page test du chargement pour une autre approche.

Paiements par d’autres moyens que la carte bancaire

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 bancaire, que vous souhaitiez tester un formulaire de paiement de manière interactive ou rédiger du code de test.

Chaque moyen de paiement doit être testé selon un procédure qui lui est propre :

Link

À l’heure actuelle, Link fonctionne uniquement pour les cartes de crédit, les cartes de débit et les achats admissibles effectués via un compte bancaire américain. Link nécessite un enregistrement de domaine.

Vous pouvez créer des comptes dans un 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 en mode 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.

Redirections

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 pris en charge.

Pour créer un PaymentIntent 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. Envoyez le paiement à Stripe.
4. Autorisez ou faites échouer le paiement test.

Assurez-vous que la page (correspondant au paramètre return_url) sur votre site Web indique l’état du paiement.