Test Stripe Billing

Comment tester votre intégration de Billing.

Vous devez tester votre intégration de manière approfondie avant de la mettre à la disposition de vos clients ou de l’utiliser pour toute activité en mode production. Outre les directives de votre organisation (runbooks, murs qualité, listes de contrôle du développement, etc.), utilisez les ressources de cette page pour vous aider à déterminer si votre intégration est prête à passer en mode production.

Principes du passage en mode production

Avant de passer votre intégration en mode production, passez en revue ces listes de contrôle Stripe :

Voici un exemple de flux d’intégration classique.

Pour les intégrations d’abonnements et de revenus récurrents, assurez-vous au minimum que les composants suivants fonctionnent correctement.

Le tableau répertorie les notifications d’événement de chaque composant. Vous pouvez configurer votre intégration de sorte à écouter ces événements à l’aide de webhooks. Consultez ce guide pour en savoir plus sur les notifications d’événement et les tests.

Composant	Description	Événements
Inscription des clients	Assurez-vous que votre intégration peut recueillir les informations nécessaires à la création d’un enregistrement client dans Stripe. Vos clients peuvent saisir ces informations via Payment Links, Checkout, Elements ou un formulaire de paiement entièrement personnalisé créé avec l’API Stripe. Quel que soit le formulaire que vous utilisez, assurez-vous que l’objet Customer est stocké sur Stripe. Vous pouvez utiliser le Dashboard ou l’API pour afficher et gérer les clients.	`customer.created` `customer.subscription.created`
Facturation	Les abonnements génèrent des objets Invoice à la fin de chaque cycle de facturation. En fonction de votre méthode d’encaissement, vous pouvez envoyer une facture pour collecter le paiement à terme échu ou pour confirmer un paiement automatique. Assurez-vous que votre intégration crée et envoie des factures comme prévu. Consultez le guide pour en savoir plus sur la création et la gestion des factures d’abonnement. Vous pouvez utiliser des horloges de simulation pour simuler des cycles de facturation, génération et envoi des factures compris. Reportez-vous au guide consacré aux horloges de simulation pour en savoir plus sur les cas d’usage que vous pouvez tester.	`invoice.created` `invoice.finalized` `invoice.finalization_failed` `invoice.paid` `invoice.payment_action_required` `invoice.payment_failed` `invoice.upcoming` `invoice.updated`
Gestion des abonnements	Configurez le portail client pour permettre à vos clients de gérer leurs abonnements et leurs informations de facturation. Pour le tester, créez un abonnement dans un environnement de test. Ensuite, connectez-vous au portail en tant qu’utilisateur test et modifiez l’abonnement. Consultez le Dashboard ou l’API pour voir si l’abonnement reflète la modification effectuée par le client. Lisez le guide d’intégration pour savoir comment configurer le portail client.	`customer.subscription.deleted` `customer.subscription.paused` `customer.subscription.resumed` `customer.subscription.updated`
Périodes d’essai	Offrez la possibilité à vos clients d’essayer votre service. Pour vérifier que votre période d’essai est correctement configurée, vous pouvez créer une horloge de simulation. L’abonnement doit générer une facture nulle pour la période d’essai. Découvrez comment tester les périodes d’essai avec des horloges de simulation. Pour en savoir davantage sur le fonctionnement des périodes d’essai, consultez le guide consacré aux périodes d’essai des abonnements.	`customer.subscription.trial_will_end` `customer.subscription.updated`
Échecs de paiement	Les paiements de vos clients peuvent échouer pour plusieurs raisons. Assurez-vous que votre intégration est en mesure de gérer les échecs de paiement, et notamment les relances. Comment tester les échecs de paiement.	`invoice.finalization_failed` `invoice.payment_failed` `invoice.payment_action_required`

Horloges de simulation

Les horloges de simulation vous permettent de simuler des objets Billing, tels que les abonnements, au fil du temps dans un environnement de test. Ainsi, nul besoin d’attendre un an pour voir comment votre intégration gère un échec de paiement pour un renouvellement annuel. Vous n’avez pas besoin d’écrire de code avec des horloges de simulation : vous pouvez créer des simulations dans le Dashboard. Vous pouvez également y accéder via l’API. En savoir plus sur les horloges de simulation et les cas d’utilisation courants qui s’y rapportent.

Tester les périodes d’essai des abonnements

Tout d’abord, suivez les étapes ci-après pour commencer à utiliser des horloges de simulation :

Ensuite, vous pouvez commencer à tester les périodes d’essai avec les horloges de simulation. Imaginons que vous voulez que vos clients testent vos produits gratuitement pendant une période d’essai de sept jours avant de commencer à payer et vous souhaitez collecter les informations de paiement en amont. Suivez les étapes ci-après pour simuler cette situation en utilisant des horloges de simulation :

Créez une nouvelle horloge de simulation et réglez son frozen_time sur le 1er janvier.
Ajoutez un client et spécifiez son moyen de paiement. Dans ce cas, utilisez une carte de test.
Créez un abonnement et ajoutez une période d’essai gratuit de sept jours :

Pour ajouter une période d’essai à un abonnement existant via le Dashboard :

Recherchez l’abonnement que vous souhaitez modifier.

Cliquez sur Actions.
Cliquez sur Mettre à jour l’abonnement.
Cliquez sur Ajouter une période d’essai et saisissez sept dans le champ Nombre de jours de l’essai gratuit.
Cliquez sur Mettre à jour l’abonnement.

Suite à la création d’un abonnement avec une période d’essai gratuit de sept jours, un abonnement est créé dans un état trialing. L’essai gratuit donne lieu à la génération d’une facture de 0 $.
Avancez la date au 5 janvier pour recevoir la notification d’événement customer.subscription.trial_will_end. Stripe envoie la notification trois jours avant la fin de la période d’essai. Vous pouvez utiliser cet événement webhook pour informer vos clients que la période d’essai arrive bientôt à son terme.
Avancez la date au 8 janvier pour vérifier que l’abonnement est désormais à l’état paid et qu’une facture de 50 USD a été créée.
Avancez la date d’un cycle (par exemple, au 8 février pour un abonnement mensuel) pour constater le renouvellement.

Tester des périodes d'essai sans horloge de simulation

Tester les notifications webhook des abonnements

Les intégrations d’abonnement s’appuient fortement sur les webhooks. Vous pouvez configurer un endpoint de webhook sur votre serveur et indiquer les notifications d’événement à écouter. Stripe émet des notifications pour des événements tels que la mise à niveau ou l’annulation d’un abonnement.

Vous pouvez tester des webhooks en créant des abonnements de test ou en déclenchant des notifications d’événement avec la CLI Stripe ou via le Dashboard.

Après avoir configuré la CLI Stripe et le lien vers votre compte Stripe, vous pouvez déclencher des événements à partir du cycle de vie de l’abonnement pour tester votre intégration de webhook. Si vous utilisez la CLI Stripe pour déclencher des événements, vous pouvez voir les notifications d’événement sur votre serveur à mesure qu’elles arrivent. Ainsi, vous pouvez vérifier votre intégration de webhook directement, sans tunnel réseau ou pare-feu.

Lorsque vous utilisez la CLI Stripe ou le Dashboard pour déclencher des événements, votre webhook reçoit un événement contenant des données factices qui ne correspondent pas aux informations de l’abonnement. La façon la plus fiable de tester les notifications de webhook consiste à créer des abonnements de test réels et de gérer les événements correspondants.

Le tableau suivant décrit les événements les plus courants liés aux abonnements et, le cas échéant, suggère les actions à entreprendre pour les gérer.



`customer.created`	Envoyé lorsqu’un objet Customer a bien été créé.
`customer.subscription.created`	Envoyé lors de la création de l’abonnement. Le `status` de l’abonnement peut être `incomplete` si l’authentification du client est demandée pour mener à bien le paiement ou si vous définissez `payment_behavior` sur `default_incomplete`. Familiarisez-vous avec le comportement de paiement des abonnements pour en savoir plus.
`customer.subscription.deleted`	Envoyé lorsque l’abonnement d’un client prend fin.
`customer.subscription.paused`	Envoyé lorsque le `status` d’un abonnement passe à `paused`. Par exemple, l’événement est envoyé lorsqu’un abonnement est configuré pour être suspendu lorsqu’un essai gratuit prend fin sans moyen de paiement. La facturation n’aura pas lieu tant que l’abonnement n’aura pas repris. Nous n’envoyons pas cet événement si l’encaissement des paiements est suspendu, car des factures continuent d’être créées pendant cette période.
`customer.subscription.resumed`	Envoyé lors de la reprise d’un abonnement qui était à l’état `paused`. Cela ne s’applique pas lorsque l’encaissement des paiements est réactivé.
`customer.subscription.trial_will_end`	Envoyé trois jours avant la fin de la période d’essai. Si la période d’essai est inférieure à trois jours, l’événement est déclenché.
`customer.subscription.updated`	Envoyé lorsqu’un abonnement démarre ou est modifié. Par exemple, le renouvellement d’un abonnement, l’ajout d’un bon de réduction, l’application d’une réduction, l’ajout d’un poste de facture et le changement de plan déclenchent sont des situations qui déclenchent cet événement.
`entitlements.active_entitlement_summary.updated`	Envoyé lorsque les droits actifs d’un client sont mis à jour. Lorsque vous recevez cet événement, vous pouvez donner ou retirer l’accès aux fonctionnalités de votre produit. En savoir plus sur l’intégration des droits.
`invoice.created`	Envoyé lorsqu’une facture est créée pour un nouvel abonnement ou un renouvellement. Si Stripe ne reçoit pas une réponse positive à `invoice.created`, la finalisation de toutes les factures avec l’encaissement automatique est retardée de 72 heures au maximum. Renseignez-vous sur la finalisation des factures. Répondez à la notification en envoyant une requête à l’API de finalisation des factures.
`invoice.finalized`	Envoyé lorsqu’une facture est finalisée et prête à être payée. Vous pouvez envoyer la facture au client. Familiarisez-vous avec la finalisation des factures pour en savoir plus. Selon vos paramètres, nous débitons automatiquement le moyen de paiement par défaut ou tentons un encaissement. Renseignez-vous sur les e-mails après la finalisation pour en savoir plus.
`invoice.finalization_failed`	La facture n’a pas pu être finalisée. Reportez-vous à la page consacrée à la gestion des échecs de finalisation des factures. Davantage d’informations à propos de la finalisation des factures sont disponibles dans le guide de présentation générale des factures. Inspectez e champ `last_finalization_error` de l’objet Invoice pour déterminer la cause de l’erreur. Si vous utilisez Stripe Tax, vérifiez le champ automatic_tax de l’objet Invoice. Si `automatic_tax[status]=requires_location_inputs`, la facture ne peut pas être finalisée et les paiements ne sont pas perçus. Prévenez votre client et collectez la localisation du client demandée. Si `automatic_tax[status]=failed`, relancez la requête plus tard.
`invoice.paid`	Envoyé lorsque la facture est réglée. Vous pouvez fournir l’accès à votre produit dès la réception de cet événement et le basculement du `status` de l’abonnement sur `active`.
`invoice.payment_action_required`	Envoyé lorsque la facture nécessite une authentification du client. Découvrez comment gérer un abonnement quand une action est requise pour la facture.
`invoice.payment_failed`	Le paiement d’une facture a échoué. L’état du PaymentIntent bascule sur `requires_action`. L’état de l’abonnement reste `incomplete` seulement pour la première facture de l’abonnement. Lorsqu’un paiement échoue, plusieurs actions sont possibles : Prévenez votre client. Apprenez à configurer les paramètres d’abonnement pour activer les relances intelligentes Smart Retries et d’autres fonctionnalités d’encaissement. Si vous utilisez des PaymentIntents, recueillez de nouvelles données de paiement et confirmez le PaymentIntent. Mettez à jour le moyen de paiement par défaut de l’abonnement.
`invoice.upcoming`	Envoyé quelques jours avant le renouvellement de l’abonnement. Le nombre de jours dépend de la valeur Événements de renouvellement à venir configurée dans le Dashboard. Pour les abonnements existants, la modification du nombre de jours prend effet à la période de facturation suivante. Vous pouvez toujours ajouter des postes de facture supplémentaires si nécessaire.
`invoice.updated`	Envoyé lorsqu’un paiement aboutit ou échoue. Si le paiement aboutit, l’attribut `paid` est défini sur `true` et le `status` sur `paid`. Si le paiement échoue, `paid` est défini sur `false` et le `status` reste `open`. Les échecs de paiement déclenchent par ailleurs un événement `invoice.payment_failed`.
`payment_intent.created`	Envoyé lorsqu’un PaymentIntent est créé.
`payment_intent.succeeded`	Envoyé lorsqu’un PaymentIntent a effectué un paiement avec succès.
`subscription_schedule.aborted`	Envoyé lorsqu’une planification d’abonnement est annulée car un défaut de paiement a entraîné la résiliation de l’abonnement correspondant.
`subscription_schedule.canceled`	Envoyé lorsqu’une planification d’abonnement est annulée, ce qui annule également tout abonnement actif associé.
`subscription_schedule.completed`	Envoyé lorsque toutes les phases d’une planification d’abonnement sont terminées.
`subscription_schedule.created`	Envoyé lorsqu’une nouvelle planification d’abonnement est créée.
`subscription_schedule.expiring`	Envoyé 7 jours avant la date d’expiration d’un abonnement.
`subscription_schedule.released`	Envoyé lorsqu’une planification d’abonnement est publiée, ou interrompue et dissociée de l’abonnement, lequel est conservé.
`subscription_schedule.updated`	Envoyé lorsqu’une planification d’abonnement est mise à jour.

Tester les échecs de paiement

Utilisez des numéros de cartes de test spécifiques pour déclencher des échecs de paiement pour les abonnements et les factures.

Suite à certaines mises à jour d’abonnement, Stripe facture l’abonnement et tente de traiter le paiement immédiatement (cette tentative de paiement synchrone peut survenir sur la facture initiale, ou sur certaines mises à jour de facture). Si cette tentative échoue, l’abonnement est créé à l’état incomplete.

Pour tester les effets d’un échec de paiement sur un abonnement actif, définissez la carte 4000 0000 0000 0341 comme moyen de paiement par défaut du client, mais appliquez une période d’essai pour reporter la tentative (un essai de quelques secondes ou minutes suffit). L’abonnement devient actif immédiatement et un brouillon de facture est créé à la fin de la période d’essai. Il faut environ une heure pour que les modifications de l’état de la facture s’ouvrent, moment où la tentative d’encaissement du paiement échoue.

Utilisez les horloges de simulation pour simuler l’avancement du temps dans un 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 un échec de paiement pour un renouvellement trimestriel ou annuel sans attendre un an.

Tester les paiements nécessitant 3D Secure

Utilisez la carte 4000 0027 6000 3184 afin de simuler le déclenchement de 3D Secure pour les abonnements et les factures.

Lorsqu’un flux d’authentification 3D Secure est déclenché, vous pouvez tester l’authentification ou l’échec de la tentative de paiement dans la boîte de dialogue 3DS qui s’affiche. Si le paiement est correctement authentifié, la facture est payée. Si la facture appartient à un abonnement dont l’état est incomplete, l’abonnement devient actif. Lorsqu’une tentative de paiement échoue, la tentative d’authentification échoue et la facture demeure à l’état open.

Tester les paiements par virement bancaire pour les factures

Pour tester les paiements manuels sur des factures via des virements bancaires :

Dans un environnement de test, créez une facture, puis définissez la méthode d’encaissement sur send_invoice et le tableau payment_settings[payment_method_types]sur [customer_balance].
Recherchez la facture dans le Dashboard et cliquez sur Envoyer.
Votre client s’est vu attribuer un numéro de compte bancaire virtuel unique que vous pouvez récupérer via l’API Funding Instructions. Les coordonnées bancaires virtuelles sont également présentes sur la page de facture hébergée ainsi que dans le PDF.

Tester les moyens de paiement par défaut pour les factures et les abonnements

Utilisez les ID de carte bancaire de test pour simuler l’utilisation d’un moyen de paiement par défaut sur un abonnement ou une facture.

Le moyen de paiement fourni doit être associé au paramètre Client de l’abonnement ou de la facture, en le définissant comme default_payment method. Par exemple, si l’on utilise pm_card_visa pour créer un moyen de paiement Visa de test :

Appelez l’endpoint d’association de PaymentMethod avec pm_card_visa et le client correspondant à l’abonnement ou à la facture.
Créez ensuite l’abonnement ou la facture en ajoutant l’ID de moyen de paiement obtenu en tant que default_payment_method.

Désormais, l’abonnement ou la facture débitera ce moyen de paiement.

En savoir plus sur l’utilisation des moyens de paiement par défaut pour les abonnements et les factures.

Tester la vérification du numéro fiscal du client

Use these magic tax IDs to trigger certain verification conditions in testing environments. The tax ID type must be either the EU VAT Number or Australian Business Number (ABN).

Numéro	Type
`000000000`	Vérification réussie
`111111111`	Échec de la vérification
`222222222`	Vérification en attente pour une durée indéfinie

Tests automatiques

Vous pouvez configurer des tests automatiques pour votre intégration. Pour optimiser les tests :

Prenez connaissance de la politique de conservation des données pour les données liées aux abonnements dans un environnement de test.
Évitez de réutiliser des ressources telles que les coupons et les codes de promotion d’un test à l’autre.
Utilisez le serveur HTTP stripe-mock, qui est basé sur l’API Stripe et reflète fidèlement le comportement de l’API.