Mise à l’essai

Pour tester votre intégration, simulez des transactions sans déplacer d’argent en utilisant des valeurs de test spéciales dans un bac à sable. Vous pouvez accéder à vos bacs à sable en utilisant le 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 avec le logo de votre marque de carte ou votre pays
• Erreurs de carte dues à un refus de paiement, une fraude, ou des données non valides
• Litiges et remboursements
• Authentification avec 3D Secure et NIP

Les tests pour les paiements sans carte fonctionnent de façon similaire. Les paiements sans carte sont des modes de paiement qui n’impliquent pas de cartes de crédit ou de débit. Stripe prend en charge diverses options de paiement sans carte, telles que les portefeuilles numériques et les virements bancaires. Chaque mode de paiement a ses propres valeurs spéciales.

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

Comment utiliser des cartes de test

Any time you work with a test card, use test API keys in all API calls. This is true whether you’re serving a payment form to test interactively or writing test code.

Tests interactifs

Lors d’un test interactif, utilisez un numéro de carte, tel que 4242 4242 4242 4242 4242. Saisissez le numéro de carte dans le Dashboard ou dans tout 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

Sans codage

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

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 jetons, mais nous mettons à votre disposition des jetons de test tels que tok_visa si vous en avez 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 cartes test pour simuler des transactions utilisant des comptes d’épargne santé (HSA) et des comptes de dépenses flexibles (FSA). Ces comptes sont couramment utilisés pour les dépenses médicales et les tests effectués avec ces comptes permettent de s’assurer que les transactions liées aux soins de santé sont traitées correctement dans votre formulaire d’inscription.

Paiements refusés

Pour tester la logique de traitement 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 .

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 qu’ils échouent les contrôles de vérification. Vous pouvez utiliser les cartes de cette section pour tester vos paramètres Radar. Vous pouvez également les utiliser pour tester la façon dont votre intégration répond aux paiements bloqués.

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

Des 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, tel que 13.
• invalid_expiry_year : Utilisez une année jusqu’à 50 ans dans le passé, comme 95.
• invalid_cvc : Utilisez un nombre à deux chiffres, comme 99.
• incorrect_number : Utilisez un numéro de carte qui ne satisfait pas au contrôle Luhn, tel que 4242424242424241
  .

Litiges

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

Preuve

Pour justifier le fait de remporter ou de perdre le litige, répondez par l’une des preuves figurant dans le tableau ci-dessous.

• Si vous répondez en utilisant l’API, transmettez la valeur de la table en tant que uncategorized_text.
• Si vous répondez dans le Dashboard ou dans les composants intégrés Connect, saisissez les valeurs du tableau dans le champ Informations supplémentaires. Ensuite, cliquez sur Envoyer les preuves.

Remboursements

En mode production, les remboursements sont asynchrones : un remboursement peut sembler réussir puis échouer, ou apparaître comme en attente dans un premier temps, puis réussir par la suite. 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 pas 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é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 paiements qui incluent l’identification, utilisez les cartes de test présentées dans cette section. Certaines de ces cartes peuvent également être configurées pour des paiements par carte 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.

Flux de contestations mobiles 3D Secure

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 de cette section pour simuler des paiements en personne réussis avec un code 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 plus d’informations, consultez le site Test 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 vos requêtes dans vos environnements de test commencent à recevoir des erreurs HTTP 429, faites-les moins fréquemment. Ces erreurs proviennent de notre limite de débit , qui est plus stricte dans les environnements de test qu’en mode production.

Nous ne recommandons pas de charger le test de votre intégration en utilisant l’API de Stripe dans des environnements de test. Étant donné que le limiteur de charge est plus strict dans les environnements de test, vous risquez de voir des erreurs que vous ne verriez pas en production. Consultez load testing pour une approche alternative.

Paiements par des moyens autres qu’une carte

Chaque fois que vous utilisez un mode de paiement autre que par carte, utilisez les clés API de test dans tous les appels API. Cela s’applique que vous traitiez un formulaire de paiement que vous pouvez tester de manière interactive ou que vous écriviez un code de test.

Chaque mode 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 qui utilise un flux de redirection (par exemple, iDEAL), utilisez un mode de paiement pris en charge qui nécessite des redirections.

Pour créer un PaymentIntent de test susceptible de réussir ou d’échouer :

1. Accédez aux paramètres des modes de paiement de dans le Dashboard et activez un mode de paiement supporté 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.