Tests

Pour vérifier que votre intégration fonctionne comme prévu, vous pouvez simuler des paiements sans transférer de fonds en utilisant certaines valeurs spéciales en mode test.

Les cartes bancaires de test vous permettent de simuler différents scénarios :

• 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

Le test des paiements par d’autres moyens que la carte bancaire fonctionne de la même façon. Chaque moyen de paiement possède ses propres valeurs spéciales. Compte tenu des limites de débit, nous vous déconseillons d’utiliser le mode test pour tester la charge de votre intégration. Consultez plutôt notre documentation sur les tests 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 rédigez du code de test, utilisez un PaymentMethod de type pm_card_visa plutôt d’un numéro de carte bancaire. Nous vous déconseillons d’utiliser des numéros de carte bancaire directement dans des appels à l’API ou côté serveur, même en mode test, car votre code risquerait de ne pas être conforme à la norme PCI lors de la mise en production. Par défaut, les clients ne sont pas associés à un PaymentMethod.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_4eC39HqLyjWDarjtT1zdp7dc
:" \
  -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.

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

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. Le mode test simule 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 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

To test event destinations, choose one of these two options:

1. Perform actions in test mode 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. 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 en mode test, réduisez leur fréquence. Ces erreurs sont dues à notre limiteur de débit, qui est plus exigeant en mode test qu’en mode production.

Nous vous déconseillons de tester la charge de votre intégration à l’aide de l’API Stripe en mode test. Le limiteur de charge étant plus strict en mode 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 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 en mode 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 en mode 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.