Tests

Pour tester votre intégration, simulez des transactions sans transférer de fonds avec des valeurs de test spéciales dans un bac à sable. Vous pouvez accéder à vos bacs à sable à l’aide du sélecteur de compte en haut à droite de la page ou dans le Dashboard.

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. Les paiements autres que par carte sont des modes 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, comme les portefeuilles numériques et les virements bancaires. Chaque mode de paiement possède ses propres valeurs.

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 page 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

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

1. Effectuez des actions dans un bac à sable pour envoyer des événements légitimes vers votre destination d’événements. Par exemple, pour déclencher l’événement charge.succeeded, vous pouvez utiliser une carte de test qui aboutit à un paiement.
2. Déclencher des événements à l’aide de l’interface de ligne de commande Stripe ou de 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 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

À l’heure actuelle, Link fonctionne uniquement avec les cartes de crédit, les cartes de débit et les achats admissibles effectués à partir d’un compte bancaire des États-Unis. Link exige l’enregistrement de domaine.

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

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.