Test

Pour tester votre intégration, simulez des transactions sans mouvement d’argent 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 :

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

Le test des paiements autres que par carte fonctionne de la même manière. 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

Chaque fois que 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.

Tester un formulaire de manière interactive avec le numéro de carte de test 4242 4242 4242 4242

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_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=500 \
  -d currency=gbp \
  -d payment_method=pm_card_visa \
  -d "payment_method_types[]"=card

La plupart des intégrations n’utilisent plus de tokens, mais nous mettons à votre disposition des tokens de test tels que tok_visa si vous en avez besoin.

Lorsque vous êtes prêt à mettre votre intégration en production, remplacez vos clés API publique et secrète de test par celles de production. Vous ne pouvez pas traiter les paiements en production si votre intégration utilise toujours vos 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 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.

Cartes par pays

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

Cartes de test HSA et 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.

Paiements refusés

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. L’utilisation de l’une de ces cartes entraîne une erreur de carte avec le code d’erreur et le code de refus donnés.

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.

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
  .

Litiges

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.

Remboursements

En mode production, les remboursements sont asynchrones : un remboursement peut sembler réussir puis échouer, ou peut apparaître comme en attente au début, puis réussir. Pour simuler des remboursements avec ces comportements, utilisez les cartes de test de cette section. (Avec toutes les autres cartes de test, les remboursements réussissent immédiatement et ne changent plus d’état par la suite.)

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.

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.

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.

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.

Défi 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.

Paiements avec 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.

Destinations des é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 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.

Paiements autres que par carte

Chaque fois que vous utilisez un moyen de paiement de test autre qu’une carte, utilisez des clés API de test dans tous les appels API. C’est vrai 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 :

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