Tester les cas d'usage

Découvrez comment tester votre intégration.

Les environnements de test, le mode test et les sandboxes vous permettent de tester votre intégration sans effectuer de paiements réels. Ils simulent la création d’objets réels sans affecter les transactions du mode production ni générer de vrais mouvements de fonds. Pour vous aider dans le processus de test, nous vous recommandons d’utiliser nos cas d’usage de test d’assurance qualité (QA) et d’importer notre collection Postman.

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 tarifs de test. Ces environnements vous permettent de simuler des transactions pour vous assurer que votre intégration fonctionne correctement. Cette fonctionnalité vous permet d’identifier d’éventuels bugs et erreurs dans votre implémentation Stripe avant de procéder à des paiements réels. Découvrez comment choisir entre le mode test et les environnements de test.

Une fois votre compte Stripe créé, vous trouverez un jeu de clés d’API de test dans le Dashboard Stripe. Vous pouvez vous en servir pour créer et récupérer des données fictives en effectuant des requêtes à l’API Stripe. Pour commencer à accepter des paiements réels, vous devez activer votre compte, désactiver le mode test et utiliser les clés API de production dans votre intégration. Stripe fournit de nombreuses ressources permettant de tester votre intégration.

Impact de l'utilisation du mode test sur le mode production

Dans le Dashboard, la modification des paramètres en mode test est également répercutée en mode production. De nombreuses pages du Dashboard présentent un cadre blanc de notification 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 ce cadre blanc n’est pas affiché, partez du principe que les modifications apportées en mode test seront répercutées en mode production (à moins que vous ne voyiez une bannière de données de test orange).

Comparer les environnements de test

Le mode test et les environnements de test permettent de simuler la création d’objets réels sans risque d’affecter des transactions réelles ou d’effectuer de transfert de fonds réel. Savoir quand il convient d’utiliser l’un ou l’autre peut vous aider à élaborer votre stratégie de test.

Nous vous recommandons d’utiliser des environnements de test, car ils offrent des fonctionnalités supplémentaires et une plus grande flexibilité par rapport au mode test. En passant aux environnements de test, 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 créer une stratégie de test plus robuste et plus complète.

Différences de fonctionnalité entre le mode test et les environnements de test

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	Utilise un seul environnement	Utilise jusqu’à cinq environnements
Contrôle des accès	Accorde les mêmes rôles et accès à tous les utilisateurs disposant d’un rôle.	Exerce un contrôle granulaire sur l’accès. Seuls les administrateurs ont automatiquement accès au mode production. Invite des utilisateurs dans des environnements de test uniquement, sans accès au mode production.
Paramètres	Partage les paramètres entre le mode production et le mode test. Vous ne pouvez pas tester plusieurs paramètres indépendamment.	Isole complètement les paramètres pour chaque environnement de test. Copie les paramètres du mode production au moment de la création et les teste indépendamment de votre intégration en mode production.
Limites du produit	Vous ne pouvez pas tester la tarification IC+ en mode test.	Vous ne pouvez pas tester la tarification IC+ dans un environnement de test.
Prise en charge des versions	Prend en charge V1 uniquement	Prend en charge les versions V1 et V2 (y compris des produits tels que la facturation à l’usage et les destinations d’événements).
Limites de débit	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.

Transition du mode test vers les environnements de test

Pour passer du mode test aux environnements de test dans le Dashboard :

Créez un environnement de test, puis invitez les utilisateurs qui ont besoin d’y accéder.
- Lorsque vous attribuez à un membre de votre équipe le rôle d’utilisateur d’environnements de test, vous lui donnez la possibilité de créer des environnements de test associés au compte de production de votre entreprise et de supprimer les environnements de test qu’il a créés. Contrairement au mode test, auquel tous les utilisateurs peuvent automatiquement accéder, seuls ceux disposant des rôles d’utilisateur d’environnements de test, d’administrateur, de développeur ou d’administrateur d’environnements de test peuvent accéder aux environnements de test.
Obtenez de nouvelles clés API de test et votre ID de compte pour votre environnement de test.
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 test, qui vous aideront à tester votre intégration Billing pour vous assurer qu’elle se comporte comme prévu. Lorsque vous utilisez des horloges de test, vous simulez l’avancement du temps dans l’environnement de test, ce qui entraîne un changement d’état des ressources Billing, telles que les abonnements, et déclenche des événements de webhook. Vous pouvez ainsi observer comment votre intégration gère certains scénarios, comme un échec de paiement dans le cadre d’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 d’API Stripe sont effectuées dans des environnements de test ou en mode production. Les objets d’API d’un mode ne sont pas accessibles dans l’autre. Par exemple, un objet produit de test ne peut pas être utilisé dans le cadre d’un paiement en mode production.

Type	Quand l’utiliser	Objets	Comment l’utiliser	Considérations
sandboxes	Use a sandbox, and its associated test API keys, as you build your integration. In a sandbox, card networks and payment providers don’t process payments.	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’affecte pas votre code d’intégration. Vos clés API de test et de production affectent le comportement de votre code. Vos clés API de test et de production affectent le comportement de votre code.

Numéros de cartes bancaires de test

Stripe fournit plusieurs numéros de carte de test afin de vous permettre de simuler différents scénarios de paiement. Vous pouvez les utiliser pour créer des paiements fictifs dans des environnements de test, sans traiter aucun paiement réel.

Vous pouvez simuler un paiement abouti en utilisant un numéro de carte de test, combiné à n’importe quelle date d’expiration postérieure à la date du jour et n’importe quel code CVC à trois chiffres. Pour simuler un échec de paiement, vous devez utiliser des numéros de carte et codes CVC de test 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 les paiements réels.

Supprimer les données de test

Pour supprimer toutes les données de test de votre compte Stripe, effectuez les actions suivantes :

Connectez-vous au Dashboard à l’aide de votre compte Stripe existant.
Dans vos environnements de test, cliquez sur Développeurs > sur Aperçu.
Sous Données de test, cliquez sur Examiner les données de test. La boîte de dialogue affiche une liste de tous les objets de données de test existants.
Cliquez sur Supprimer les données de test pour lancer le processus de suppression. Vous ne pouvez pas annuler la suppression de vos données de test.

Les environnements de test sont temporairement inutilisables pendant le processus de suppression.

Remarque

Vous devez supprimer manuellement les dispositifs de mesure, car cet objet n’est pas pris en charge par le processus de suppression automatique 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 environnement de test ne génère pas l’envoi d’un e-mail de reçu au client. Les factures finalisées via l’API dans des environnements de test ne génèrent pas non plus l’envoi d’un e-mail de reçu au client.

Si vous souhaitez que Stripe envoie des e-mails à vos 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.

Si vous souhaitez vérifier les adresses e-mail des factures et des reçus, vous pouvez définir l’adresse e-mail de votre équipe sur l’objet Customer ou l’attribut receipt_email de l’objet PaymentIntent.

Tester les cas d’usage

Le tableau suivant présente les cas d’usage des tests d’assurance qualité (AQ) :

Cas d’usage	Action
Paiement réussi (si capture immédiate)	Pas d’erreur. Le paiement apparaît comme réussi dans le Dashboard sous Paiements. Stripe capture le paiement.
Autorisation du PaymentIntent réussie (capture de fonds ultérieurement)	`{ ... "capture_method": "manual", ... "status": "requires_capture", ... }`
Capture du PaymentIntent réussie (si capture immédiate ou capture de fonds ultérieurement)	`{ ... "status": "succeeded", ... }`
Échec de paiement	Le paiement apparaît comme En échec dans le Dashboard sous Paiements. `{ "error": { "charge": "ch_quiu1bDyIREPZRRf", "code": "card_declined", "decline_code": "<<REASON HERE>>", "doc_url": "https://docs.stripe.com/error-codes#card-declined", "message": "Your card was declined.", "type": "card_error" } }`
Blocage Radar	Quelle que soit la version de Radar utilisée, un paiement peut être bloqué en raison d’un risque élevé ou d’une règle. La réponse est la même que celle renvoyée en cas d’échec de paiement.
Paiement contesté	Le paiement apparaît comme contesté dans le Dashboard sous Paiements. Stripe débite le montant du paiement plus les frais de litige du solde, crée un objet `Dispute`, ainsi que l’événement `charge.dispute.created` qui lui est associé. `{ "object": { "id": "du_vywDO7rf5TQZCK0q", "object": "dispute", "charge_id": "ch_zWk3reWklP4TpTGA", ... "status": "needs_response" } }`
Demande d’information sur le paiement en cours	Les demandes d’informations sont semblables aux litiges, mais il convient de noter trois principales différences : les fonds ne sont pas prélevés (sauf si la demande d’informations est considérée comme un litige), les fonds relatifs aux demandes d’informations sont remboursables jusqu’à ce que le paiement soit contesté, et les états des demandes sont différents. Dans ce cas, Stripe envoie un événement `charge.dispute.created`. `{ "object": { "id": "du_gZim1RUmZ8NnvJEF", "object": "dispute", "charge_id": "ch_vHMSNj8GhnfhH46i", ... "is_charge_refundable": true, ... "status": "warning_needs_response" } }`
Litige remporté	Lorsqu’un client remporte un litige, les fonds du paiement d’origine sont reversés sur le compte, déduction faite des frais de litige. Stripe met à jour l’objet `Dispute` existant et déclenche l’événement `charge.dispute.closed`. `{ "object": { "id": "du_vSvd9dkHqnShs2E2", "object": "dispute", "charge_id": "ch_hga7cLgDDAcnWWVu", ... "status": "won" } }`
Litige perdu	Lorsqu’un client perd un litige, Stripe met à jour l’objet `Dispute` existant et déclenche l’événement `charge.dispute.closed`. `{ "object": { "id": "du_wjgSen5SIGYRRCMd", "object": "dispute", "charge_id": "ch_Skuu7EVFtL2eKphc", ... "status": "lost" } }`
Demande d’informations remportée	Lorsque vous remportez une demande d’information, votre solde reste le même, car les fonds ne sont pas retirés lors de l’ouverture initiale de la demande d’information. Stripe met à jour l’objet `Dispute` existant et déclenche un événement `charge.dispute.closed`. `{ "object": { "id": "du_sfRe6TvjCGFuuaOq", "object": "dispute", "charge_id": "ch_GKvpgOcIDk7wzjab", ... "status": "warning_closed" } }`
Demande d’information perdue	Lorsque vous perdez une demande d’information, celle-ci se transforme en litige. Lorsqu’elle se transforme en litige, son état est modifié par l’événement `charge.dispute.updated`, et les fonds sont retirés par l’événement `charge.dispute.funds_withdrawn` : `{ "object": { "id": "du_3W3s8TcMHdjiO3tF", "object": "dispute", "charge_id": "ch_WsqwWrgCgoAMe5YW", ... "status": "needs_response" } }`
Paiement remboursé	Le paiement apparaît comme Remboursé dans le Dashboard sous Paiements. `{ "id": "re_mDcw0R0Qp84O9Hr0", "object": "refund", "amount": "<<FULL AMOUNT>>", "charge": "ch_st5FGUT9FmSm18k8", ... "payment_intent": "pi_LWJVMobDtWCBKIlH", // if you're using PaymentIntents ... "status": "succeeded" }`
Paiement partiellement remboursé	Le paiement apparaît comme Remboursé dans le Dashboard sous Paiements. Le montant du remboursement diffère du montant du paiement, et vous pouvez toujours contester les paiements partiellement remboursés. `{ "id": "re_OS6Kzi7ZB4A9B6FP", "object": "refund", "amount": "<<PARTIAL AMOUNT>>", "charge": "ch_0jjoMEliryhHCiZQ", ... "payment_intent": "pi_RCQTBnJRVZyyS1UA", // if you are using PaymentIntents ... "status": "succeeded" }`
Le solde du compte devient négatif	Veillez à tester les soldes négatifs sur Stripe et à vérifier que vos comptes bancaires peuvent accepter des prélèvements de notre part.
Virement réussi	Si vous activez les webhooks en cas de réussite du virement (recommandé), testez votre gestion de l’événement.
Échec du virement	Si vous activez les webhooks en cas d’échec de virement (recommandé), testez votre gestion de l’événement.

Collection Postman de Stripe

Postman est un outil de développement d’API largement utilisé. Pour simplifier l’intégration de Stripe, nous offrons une collection Postman spécifique aux paiements avec les outils dont vous aurez 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 navigateur ou bureau. Après avoir lancé l’application, importez la collection.

Pour lancer ce processus sur le Web, cliquez sur le bouton Importer dans le coin supérieur 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 réussie, la collection apparaît sous Collections.

La boîte de dialogue d’importation

Utiliser la collection

Pour utiliser la collection, accédez à la collection que vous venez d’importer et cliquez sur Variables. Copiez votre clé secrète Stripe en mode test depuis le Dashboard Stripe et collez-la dans le champ Valeur initiale. Une fois cette étape terminée, vous pouvez commencer à effectuer des requêtes.

D’autres variables sont renseignées par des scripts pendant la phase d’exécution de la collection. Par exemple, lors de la création d’un client, d’un tarif, d’un paiement ou d’un PaymentIntent, un script dans la collection enregistre cet ID à utiliser dans les requêtes postérieures telles qu’un remboursement.

Ajouter une clé secrète à une collection Postman