Accéder directement au contenu
Créez un compte ou connecter-vous
Logo de la documentation Stripe
/
Créez un compteConnectez-vous

Tester mon intégration Billing

Découvrez comment tester votre intégration Billing pour vous assurer qu’elle est prête pour la production.

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.

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

Flux de test et d’intégration

Voici à quoi ressemble un flux d’intégration classique :

Utiliser l’API Accounts v2 pour représenter les clients

L’API Accounts v2 est généralement disponible pour les utilisateurs de Connect et en aperçu public pour les autres utilisateurs de Stripe. Si vous avez accès à l’aperçu Accounts v2, vous devez spécifier une version d’aperçu dans votre code.

Pour accéder à l’aperçu Accounts v2, rendez-vous sur aperçus et fonctionnalités de Account dans votre Dashboard et activez Moyens de paiement réutilisables pour les virements internationaux.

Dans la plupart des cas d’usage, nous vous recommandons de modéliser vos clients en tant qu’objets Account configurés par le client, plutôt que d’utiliser des objets Customer.

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.

ComposantDescriptionÉvénements
Inscription des clientsVeillez à ce que votre intégration collecte les informations nécessaires à la création d’un dossier client dans Stripe. Vos clients peuvent saisir ces informations via Payment Links, Checkout, Elements, ou un formulaire de paiement personnalisé créé avec l’API Stripe. Quel que soit le type de formulaire utilisé, assurez-vous que l’objet Account côté client ou l’objet Customer est stocké sur Stripe. Vous pouvez utiliser le Dashboard ou l’API pour consulter et gérer des clients.
  • v2.core.account.created
  • v2.core.account[configuration.customer].updated
  • customer.created
  • customer.subscription.created
FacturationSubscriptions génère des factures à la fin de chaque période de facturation. Selon votre méthode d’encaissement, vous pouvez envoyer une facture pour encaisser un paiement à terme échu ou pour confirmer un paiement automatique. Assurez-vous que votre intégration crée et envoie les factures comme prévu. En savoir plus sur la création et la gestion de factures pour les abonnements. Vous pouvez utiliser des horloges de simulation pour simuler des périodes de facturation, ce qui inclut la génération et l’envoi de factures. Lisez le guide sur les horloges de simulation pour découvrir des cas d’usage spécifiques à tester.
  • invoice.created
  • invoice.finalized
  • invoice.finalization_failed
  • invoice.paid
  • invoice.payment_action_required
  • invoice.payment_failed
  • invoice.upcoming
  • invoice.updated
Gestion des abonnementsConfigurez 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’essaiProposez aux clients un essai de votre service. Pour vérifier que votre essai est correctement configuré, vous pouvez créer une horloge de simulation. L’abonnement génère une facture d’un montant nul pour la période d’essai. Découvrez comment tester les périodes d’essai à l’aide des horloges de simulation. Pour plus d’informations sur leur fonctionnement, consultez le guide des périodes d’essai d’abonnement.
  • customer.subscription.trial_will_end
  • customer.subscription.updated
Échecs de paiementLes paiements de vos clients peuvent échouer pour diverses raisons. Assurez-vous que votre intégration peut gérer les échecs, y compris les nouvelles tentatives de paiement. Découvrez 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, comme des abonnements, dans le temps au sein d’un environnement de test. Ainsi, vous n’avez pas à attendre un an pour voir comment votre intégration gère un échec de paiement lors d’un renouvellement annuel. Vous n’avez pas besoin d’écrire de code avec les 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 leurs cas d’usage courants.

Tester les périodes d’essai des abonnements

Imaginons que vous souhaitiez permettre à vos clients de tester votre produit gratuitement pendant 7 jours avant le début de la facturation et que vous vouliez collecter les informations de paiement à l’avance. Pour simuler cette situation avec les horloges de simulation, suivez les étapes suivantes :

  • Créez une nouvelle simulation et définissez le paramètre 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 7 jours :

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

Recherchez l’abonnement que vous souhaitez modifier.

  1. Cliquez sur Actions.
  2. Cliquez sur Mettre à jour l’abonnement.
  3. Cliquez sur Ajouter une période d’essai et saisissez sept dans le champ Nombre de jours de l’essai gratuit.
  4. Cliquez sur Mettre à jour l’abonnement.
  • La création d’un abonnement avec une période d’essai gratuite de 7 jours crée un abonnement à l’état trialing. Une facture de 0,00 USD est générée pour cet essai gratuit.
  • Avancez la date au 5 janvier pour recevoir la notification d’événement customer.subscription.trial_will_end. Stripe envoie la notification 3 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 EUR 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 Subscriptions s’appuient sur des webhooks. Vous configurez un endpoint de webhook sur votre serveur et spécifiez les notifications d’événements à écouter. Stripe envoie des notifications pour des événements tels que le passage à une offre supérieure 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.

Version bêta publique

L’API Accounts v2 est en disponibilité générale (GA) pour les utilisateurs de Connect, et en version bêta publique pour les autres utilisateurs Stripe.

Que vous utilisiez des objets Accounts v2 ou Customer pour représenter les comptes connectés ou les clients de votre plateforme, utilisez les événements customer.subscription pour suivre les événements d’abonnement.

v2.core.account.createdEnvoyé lorsqu’un Compte v2 est créé avec succès.
customer.createdEnvoyé lorsqu’un objet Customer a bien été créé.
customer.subscription.createdEnvoyé 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 finaliser le paiement ou si le paramètre payment_behavior est défini sur default_incomplete.
customer.subscription.deletedEnvoyé lorsque l’abonnement d’un client prend fin.
customer.subscription.pausedEnvoyé lorsque l’état d’un abonnement passe à paused. Par exemple, nous envoyons cet événement lorsque vous configurez un abonnement pour qu’il soit suspendu lorsqu’une période d’essai gratuite prend fin sans moyen de paiement. La facturation n’a pas lieu tant que l’abonnement ne reprend pas. Nous n’envoyons pas cet événement si vous suspendez l’encaissement des paiements, car des factures continuent d’être créées pendant cette période.
customer.subscription.resumedEnvoyé lorsque vous reprenez un abonnement précédemment à l’état paused. Cela ne s’applique pas lorsque vous interrompez le recouvrement des paiements.
customer.subscription.trial_will_endEnvoyé 3 jours avant la fin de la période d’essai. Cet événement est déclenché si la durée de l’essai est inférieure à 3 jours.
customer.subscription.updatedEnvoyé 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.updatedEnvoyé 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.createdEnvoyé 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.
invoice.finalizedEnvoyé 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_failedLa facture n’a pas pu être finalisée. Découvrez comment gérer les échecs de finalisation et la finalisation des factures.
  • Inspectez la last_finalization_error de la facture 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 peuvent pas être encaissés. Prévenez votre client et collectez l’emplacement client demandé.
  • Si automatic_tax[status]=failed, relancez la requête plus tard.
invoice.paidEnvoyé 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_requiredEnvoyé 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 incomplet seulement pour la première facture de l’abonnement. Lorsqu’un paiement échoue, plusieurs actions sont possibles :

invoice.upcomingEnvoyé 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.updatedEnvoyé 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.createdEnvoyé lorsqu’un PaymentIntent est créé.
payment_intent.succeededEnvoyé lorsqu’un PaymentIntent a effectué un paiement avec succès.
subscription_schedule.abortedEnvoyé 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.canceledEnvoyé lorsqu’une planification d’abonnement est annulée, ce qui annule également tout abonnement actif associé.
subscription_schedule.completedEnvoyé lorsque toutes les phases d’une planification d’abonnement sont terminées.
subscription_schedule.createdEnvoyé lorsqu’une nouvelle planification d’abonnement est créée.
subscription_schedule.expiringEnvoyé 7 jours avant la date d’expiration d’un abonnement.
subscription_schedule.releasedEnvoyé lorsqu’une planification d’abonnement est publiée, ou interrompue et dissociée de l’abonnement, lequel est conservé.
subscription_schedule.updatedEnvoyé 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, associez la carte bancaire 4000 0000 0000 0341 comme moyen de paiement par défaut du client, mais utilisez une période d’essai pour différer la tentative (une période de quelques secondes ou de quelques 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 1 heure pour que l’état de la facture passe à ouvert, puis une tentative d’encaissement du paiement est effectuée, sans succès.

Utilisez des horloges de simulation pour simuler l’avancement du temps en environnement de test, et faire en sorte que les ressources Billing, telles que Subscriptions, changent d’état et déclenchent des événements webhook. Vous pourrez ainsi observer la façon dont votre intégration gère un échec de paiement pour un renouvellement trimestriel ou annuel sans attendre l’échéance de l’abonnement.

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 :

  1. 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].
  2. Recherchez la facture dans le Dashboard et cliquez sur Envoyer.
  3. 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 :

  1. Appelez l’endpoint d’association de PaymentMethod avec pm_card_visa et le client correspondant à l’abonnement ou à la facture.
  2. 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

Utilisez les numéros fiscaux suivants pour déclencher certaines conditions de vérification dans les environnements de test. Le type de numéro fiscal doit correspondre au numéro d’identification australien (ABN), au numéro de TVA européen ou au numéro de TVA britannique (TVA GB).

NuméroType
000000000Vérification réussie
111111111Échec de la vérification
222222222Vé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 :

Voir aussi

Sur cette page