Cas d’usage pour les tests
Apprenez à tester votre intégration.
Les environnements de test de Stripe, le mode test et les Sandboxes, vous permettent de tester votre intégration sans effectuer de véritables débits ou paiements. Ces environnements simulent la création d’objets réels sans affecter les transactions réelles ni déplacer de l’argent réel. Nous vous recommandons d’utiliser nos cas d’usage de test d’assurance qualité (QA) et d’importer notre collection Postman pour vous aider dans le processus de test.
Environnements de test
Dans un environnement de test, vous pouvez débiter des cartes de crédit de test et créer des produits et des prix de test. Ces environnements vous permettent de simuler des transactions pour vous assurer que votre intégration fonctionne correctement. Cette fonctionnalité permet d’identifier les bogues ou les erreurs dans votre mise en œuvre de Stripe avant de passer en production avec des paiements réels. Découvrez comment choisir entre l’utilisation du mode test et des Sandboxes.
Après avoir créé un compte Stripe, vous pouvez trouver un jeu de clés API de test dans le Stripe Dashboard. Vous pouvez utiliser ces clés API pour créer et récupérer des données simulées en effectuant des requêtes à l’API Stripe. Pour commencer à accepter des paiements réels, vous devez activer votre compte, quitter votre environnement de test à l’aide du sélecteur de compte, et utiliser les clés API de production dans votre intégration. Stripe fournit un certain nombre de ressources pour tester votre intégration.
Impact sur le mode production lors de l’utilisation du mode test
Si vous modifiez des paramètres dans le Dashboard en mode test, vous risquez de les modifier également en mode production. De nombreuses pages du Dashboard affichent un encadré blanc et désactivent les paramètres du mode production en mode test. Dans ce cas, tous les paramètres encore activés peuvent être utilisés en toute sécurité. Si vous ne voyez pas d’encadré blanc, partez du principe que toute modification apportée en mode test affecte les paramètres du mode production (sauf si vous voyez une bannière de données de test orange ou bleue).
Comparer les environnements de test
Le mode test et les Sandboxes sont des environnements de test qui simulent la création d’objets réels sans risquer d’affecter des transactions réelles ou de déplacer de l’argent réel. Comprendre quand utiliser chacun d’eux peut vous aider à construire votre stratégie de test.
Nous vous recommandons d’utiliser les Sandboxes pour vos besoins de test, car ils offrent des fonctionnalités supplémentaires et une plus grande flexibilité que le mode test. En passant aux Sandboxes, vous pouvez améliorer vos capacités de test avec plusieurs environnements, un contrôle d’accès granulaire et des paramètres isolés, ce qui vous permet de construire une stratégie de test plus robuste et complète.
Différences de fonctionnalités entre le mode test et les Sandboxes
Consultez le tableau ci-dessous pour comprendre les différences et choisir l’environnement le plus adapté à vos besoins.
Mode test | Environnements de test | |
---|---|---|
Nombre d’environnements | Utiliser un seul environnement | Utiliser jusqu’à cinq environnements |
Contrôle d’accès | Accordez à tous les utilisateurs dotés de rôles les mêmes rôles et accès. | Exercez un contrôle granulaire sur l’accès. Seuls les administrateurs ont automatiquement accès. Invitez les utilisateurs aux sandboxes uniquement, sans accès au mode production. |
Paramètres | Les paramètres sont partagés entre le mode production et le mode test. Vous ne pouvez pas tester de nombreux paramètres de manière indépendante. | Isolez complètement les paramètres pour chaque sandbox. Copiez les paramètres du mode production au moment de la création et effectuez des tests indépendamment de votre intégration en production. |
Limites des produits | Vous ne pouvez pas tester la tarification IC+ en mode test. | Vous ne pouvez pas tester la tarification IC+ dans un sandbox. |
Prise en charge des versions | Prend en charge V1 uniquement | Prend en charge V1 et V2 (y compris des produits tels que Usage-based billing et Event Destinations). |
Limites d’appels | Maintenez des limites d’appels cohérentes. | Maintenez des limites d’appels cohérentes. |
Numéros de carte de test | Utilisez les mêmes numéros de carte de test. | Utilisez les mêmes numéros de carte de test. |
Passer du mode test aux Sandboxes
Pour passer du mode test aux Sandboxes dans le Dashboard :
- Créez un sandbox, puis invitez les utilisateurs qui ont besoin d’y accéder.
- Lorsque vous accordez à un membre de l’équipe le Sandbox User role, vous lui donnez l’accès pour créer des sandboxes associés à votre compte de production et supprimer les sandboxes qu’il a créés. Contrairement au mode test, où tous les utilisateurs avaient un accès automatique, seuls ceux qui ont le rôle d’utilisateur de sandbox, les rôles d’administrateur, le rôle de développeur ou le rôle d’administrateur de sandbox peuvent accéder aux sandboxes.
- Obtenir de nouvelles clés API de test et l’ID de votre compte pour votre sandbox.
- Configurez des données de test pertinentes telles que des produits, des clients, des abonnements et des moyens de paiement de test.
- (Facultatif) Configurez des horloges de simulation, qui vous aident à tester votre intégration Billing pour vous assurer qu’elle se comporte comme prévu. Lorsque vous utilisez des horloges de simulation, vous simulez l’avancement du temps dans le sandbox, ce qui amène les ressources Billing telles que les Subscriptions à changer d’état et à déclencher des événements de webhook. Cela vous permet de voir comment votre intégration gère les scénarios, tels qu’un échec de paiement pour un renouvellement trimestriel ou annuel, sans attendre de longues périodes.
- Mettez à jour toute partie de vos processus de test qui dépend d’ID d’objets de test spécifiques. Cela change lorsque vous créez de nouveaux objets dans un environnement de test.
Environnements de test et mode production
Toutes les requêtes API Stripe s’effectuent soit dans des environnements de test, soit en mode production. Les objets API d’un mode ne sont pas accessibles dans l’autre. Par exemple, un objet Product de test ne peut pas faire partie d’un paiement en mode production.
Type | Quand l’utiliser | Objets | Comment l’utiliser | Considérations |
---|---|---|---|---|
environnements de test | Utilisez un environnement de test et les clés API test associées au fur et à mesure que vous développez votre intégration. Dans un bac à sable, les réseaux de cartes et les prestataires de services de paiement ne traitent pas les paiements. | Les appels à l’API renvoient des objets fictifs. Vous pouvez par exemple récupérer et utiliser des objets account , payment , customer , charge , refund , transfer , balance et subscription de test. | Utilisez des cartes et des comptes de test. Vous ne pouvez pas accepter de moyens de paiement réels ni utiliser de vrais comptes. | Identity n’effectue aucun contrôle de vérification. Les objets Account de Connect ne renvoient pas de champs sensibles. |
mode production | Utilisez le mode production et les clés API de production correspondantes au moment de lancer votre intégration et de commencer à accepter des fonds. En mode production, les paiements sont réellement traités par les réseaux de cartes et fournisseurs de services de paiement. | Les appels à l’API renvoient des objets réels. Vous pouvez par exemple récupérer et utiliser des objets account , payment , customer , charge , refund , transfer , balance et subscription réels. | Acceptez des cartes bancaires réelles et utilisez de vrais comptes client. Vous pouvez accepter des paiements, autorisations de paiement et captures réels à partir de cartes bancaires et de comptes. | Les litiges ont un flux plus nuancé et un processus de test plus simple. En outre, certains moyens de paiement ont un flux plus nuancé et nécessitent plus d’étapes. |
Le fait d’être dans un environnement de test dans le Dashboard n’a aucune incidence sur votre code d’intégration. Vos clés API de mode test et de mode production ont une incidence sur le comportement de votre code.
Numéros de carte de test
Stripe fournit un ensemble de numéros de carte de test que vous pouvez utiliser pour simuler différents scénarios de paiement. Vous pouvez utiliser ces numéros de carte de test pour créer des paiements simulés dans des environnements de test sans traiter de paiements ou de débits réels.
Lorsque vous utilisez des numéros de carte de test, vous pouvez saisir n’importe quelle date d’expiration future et n’importe quel code CVC à trois chiffres pour simuler un paiement réussi. Si vous souhaitez simuler un paiement qui a échoué, vous pouvez utiliser les numéros de carte de test et les codes CVC spécifiques fournis par Stripe.
Les numéros de carte de test ne sont valides que dans les environnements de test. Ne les utilisez pas pour des paiements réels.
Supprimer les données de test
Pour supprimer toutes vos données de test de votre compte Stripe, procédez comme suit :
- Connectez-vous au Dashboard en utilisant votre compte Stripe existant.
- Dans vos environnements de test, cliquez sur Développeurs > Vue d’ensemble.
- Sous Données de test, cliquez sur Examiner les données de test. La boîte de dialogue vous présente une liste de tous vos objets de données de test existants.
- Cliquez sur Supprimer les données de test pour lancer le processus de suppression. La suppression de vos données de test est irréversible.
Les environnements de test sont temporairement inutilisables pendant le processus de suppression.
Remarque
Vous devez supprimer manuellement les Meters, car l’objet n’est pas pris en charge par le processus automatisé de suppression des données de test.
E-mail de test
Par défaut, Stripe n’envoie pas d’e-mails aux clients dans les environnements de test. Par exemple, le paiement d’une facture dans un sandbox n’entraîne pas l’envoi d’un e-mail de reçu au client. Les factures finalisées par le biais de l’API dans les environnements de test n’entraînent pas non plus l’envoi d’un e-mail de reçu au client.
Si vous souhaitez que Stripe envoie des e-mails aux clients dans un environnement de test, vous pouvez effectuer les opérations suivantes dans le Dashboard :
- Créer et envoyer manuellement une facture à un client spécifique.
- Envoyer manuellement un reçu pour une facture payée.
Pour vérifier les e-mails pour les factures et les reçus, définissez l’adresse e-mail de votre équipe sur l’objet Customer
ou l’attribut receipt_
sur le PaymentIntent.
Cas d’usage pour les tests
Le tableau suivant contient des cas d’usage de test d’assurance qualité (AQ) :
Cas d’usage | Action |
---|---|
Réussite du paiement (capture immédiate) |
|
Réussite de l’autorisation d’un PaymentIntent (capture de fonds pour plus tard) |
|
Réussite de la capture d’un PaymentIntent (capture immédiate ou capture de fonds pour plus tard) |
|
Échec du paiement | Le paiement apparaît avec l’état Échec dans le Dashboard, sous Payments.
|
Blocage par Radar | Quelle que soit la version de Radar que vous utilisez, il se peut qu’un paiement soit bloqué en raison d’un risque élevé ou d’une règle. La réponse est la même que celle que vous obtenez lorsqu’un paiement échoue. |
Paiement contesté |
|
Demande d’information sur un paiement ouverte | Les demandes d’information sont similaires aux litiges, mais présentent trois différences majeures : aucun fonds n’est retiré, à moins que nous ne transformions une demande d’information en litige ; elles restent remboursables jusqu’à ce qu’elles fassent l’objet d’un litige ; et elles possèdent un ensemble d’états différent. Dans ce cas, Stripe déclenche un événement
|
Litige gagné |
|
Litige perdu | Lorsqu’un client perd un litige, Stripe met à jour l’objet
|
Demande d’information gagnée | Lorsque vous remportez une demande d’information, votre solde reste le même, car aucun fonds n’a été retiré lors de l’ouverture initiale de la demande d’information. Stripe met à jour l’objet
|
Demande d’information perdue |
|
Paiement remboursé | Le paiement apparaît avec l’état Remboursé dans le Dashboard, sous Payments.
|
Paiement partiellement remboursé |
|
Le solde du compte devient négatif | Assurez-vous de tester un solde négatif sur Stripe et de vérifier que vos comptes bancaires peuvent accepter nos débits. |
Virement réussi | Si vous activez les webhooks pour un virement réussi (recommandé), testez votre gestion de l’événement. |
Échec de virement | Si vous activez les webhooks pour un virement qui a échoué (recommandé), testez votre gestion de l’événement. |
La collection Postman de Stripe
Postman est un outil de développement d’API très répandu. Pour faciliter l’intégration de Stripe, nous fournissons une collection Postman spécifique aux paiements qui contient les outils dont vous avez besoin pour tester le composant côté serveur de votre intégration.
Importer la collection
Pour commencer, vous devez accéder à l’application Postman. Vous pouvez utiliser la version pour navigateur ou pour ordinateur de bureau. Après avoir lancé l’application, importez la collection.
Pour lancer ce processus sur le web, appuyez sur le bouton Importer en haut à gauche, puis sur l’option Lien. Insérez le lien de la collection Payments. Si vous utilisez l’application de bureau Postman, cliquez sur Fichier > Importer. Une fois l’importation terminée, la collection apparaît sous Collections.

La boîte de dialogue d’importation
Utiliser la collection
Pour utiliser la collection, allez à la collection que vous venez d’importer et cliquez sur Variables. Copiez votre clé secrète Stripe de mode test depuis le Stripe Dashboard, et collez-la dans le champ Valeur initiale. Une fois cette étape terminée, vous êtes prêt à commencer à effectuer des requêtes.
D’autres variables sont remplies par des scripts pendant l’exécution de la collection. Par exemple, lors de la création d’un Customer, d’un Price, d’un Charge ou d’un PaymentIntent, le système enregistre cet ID par le biais d’un script dans la collection, qui est ensuite accessible pour les requêtes ultérieures, comme l’émission d’un remboursement.

Ajouter une clé secrète à une collection Postman