# Tester mon intégration Billing Découvrez comment tester votre intégration Billing pour vous assurer qu’elle est prête pour la production. Testez comment votre intégration Billing gère les renouvellements d’abonnements, les périodes d’essai, les échecs de paiement et les notifications de webhooks avant de traiter des paiements réels. Choisissez les tests qui s’appliquent à votre intégration et exécutez-les dans un [environnement de test](https://docs.stripe.com/sandboxes.md). Pour obtenir des conseils généraux sur les tests, consultez la section [Tests](https://docs.stripe.com/testing.md). ## Scénarios de test Passez en revue les scénarios suivants et exécutez les tests qui s’appliquent à votre intégration. > #### Disponibilité d’Accounts v2 > > Le test d’inscription des clients dans le tableau suivant fait référence à la fois aux objets `Customer` de l’API v1 et aux objets `Account` configurés pour le client de l’[API Accounts v2](https://docs.stripe.com/accounts-v2/use-accounts-as-customers.md). L’API Accounts v2 est en disponibilité générale pour les utilisateurs de Connect et en version bêta publique pour les autres utilisateurs de Stripe. | Scénario | Ce qu’il faut vérifier | Méthode de test | | --- | --- | --- | | **Inscription des clients** | Votre tunnel d’inscription recueille les informations client obligatoires et stocke un objet `Account` ou `Customer` configuré pour le client dans Stripe. | Effectuez le tunnel d’inscription de votre intégration dans un environnement de test. Dans le Dashboard, confirmez que vous consultez cet environnement de test, puis accédez à **Clients** et recherchez l’enregistrement client. | | **Facturation** | Les *factures* (Invoices are statements of amounts owed by a customer. They track the status of payments from draft through paid or otherwise finalized. Subscriptions automatically generate invoices, or you can manually create a one-off invoice) sont générées et le paiement est encaissé comme prévu, soit en débitant automatiquement un moyen de paiement, soit en envoyant une facture au client. | [Simuler les renouvellements et les cycles de facturation](https://docs.stripe.com/billing/testing.md#simulate-subscriptions). | | **Gestion des abonnements** | L’abonnement dans Stripe reflète toute modification effectuée via le *portail client* (The customer portal is a secure, Stripe-hosted page that lets your customers manage their subscriptions and billing details). | Une fois votre [portail client configuré](https://docs.stripe.com/customer-management/configure-portal.md), créez un abonnement en environnement de test, ouvrez le portail client en tant que client de test et mettez à jour l’abonnement. Dans le Dashboard, confirmez que vous consultez cet environnement de test, puis accédez à **Abonnements** et vérifiez la modification. | | **Périodes d’essai** | L’abonnement commence avec l’état `trialing`, génère une facture d’essai d’une valeur nulle et passe à l’état attendu à la fin de la période d’essai. | [Tester les périodes d’essai des abonnements](https://docs.stripe.com/billing/testing.md#trials). | | **Échecs de paiement** | Votre intégration détecte les échecs de paiement et gère les nouvelles tentatives ainsi que les notifications aux clients en fonction de votre configuration. | [Tester les échecs de paiement](https://docs.stripe.com/billing/testing.md#payment-failures). | Pour identifier les événements de webhook à surveiller pendant ces tests, consultez [Événements d’abonnement](https://docs.stripe.com/billing/subscriptions/webhooks.md#events). ## Tests de cycle de vie des abonnements ### Tester les renouvellements et les modifications au fil du temps Utilisez les horloges de simulation pour avancer le temps simulé dans un environnement de test et voir comment vos abonnements et factures évoluent. Par exemple, testez la manière dont votre intégration gère un échec de paiement lors d’un renouvellement annuel sans avoir à attendre un an. Vous pouvez exécuter des simulations dans le Dashboard sans écrire de code, ou utiliser l’API. Utilisez les simulations pour : - Testez les mises à niveau et les changements d’offres en cours de cycle. - Testez comment les [soldes clients](https://docs.stripe.com/billing/customer/balance.md) et les [postes de facture ponctuels](https://docs.stripe.com/billing/invoices/subscription.md#adding-upcoming-invoice-items) affectent les factures à venir. - Vérifiez que votre intégration traite correctement les webhooks liés au cycle de vie de Billing. - Vérifiez la gestion des périodes d’essai dans votre application. - Générer et tester des planifications d’abonnement à plusieurs phases. #### Simuler des abonnements Suivez ces étapes pour simuler un abonnement dans le Dashboard. Pour créer et gérer des horloges de simulation via l’API, consultez la section [Utilisation avancée des horloges de simulation](https://docs.stripe.com/billing/testing/test-clocks/api-advanced-usage.md). 1. Créez un environnement de test dans le [Dashboard](https://dashboard.stripe.com). 2. Sur la page [Subscriptions](https://dashboard.stripe.com/test/subscriptions), cliquez sur l’abonnement que vous souhaitez tester. 3. Cliquez sur **Lancer une simulation** dans la bannière. Le Dashboard peut désactiver le bouton **Exécuter la simulation** si le client de l’abonnement : - Possède plus de trois abonnements, y compris des [abonnements planifiés](https://docs.stripe.com/billing/subscriptions/subscription-schedules.md). - Possède un profil complexe avec plus de 25 devis, factures ou autres objets associés. 4. Dans la fenêtre modale, définissez la date et l’heure à simuler, puis cliquez sur **Avancer le temps**. Vous pouvez avancer l’horloge par incréments de votre choix, jusqu’à deux périodes d’abonnement à la fois à partir de l’instant initial de la simulation. Par exemple, pour un abonnement mensuel, vous pouvez avancer l’horloge de 2 mois maximum à la fois. Une fois la simulation terminée, la bannière affiche le temps de simulation actuel. #### Affichez et supprimez des simulations Consultez vos simulations dans **Subscriptions** > [Simulations](https://dashboard.stripe.com/test/billing/subscriptions/simulations) dans le Dashboard. Pour supprimer une simulation, cliquez sur **Terminer la simulation**. Tous les objets associés sont alors supprimés de l’environnement de test, y compris le client et l’abonnement. Cela n’a aucun effet sur le mode production. ### Tester les périodes d’essai des abonnements Pour tester une période d’essai gratuite de 7 jours qui collecte les informations de paiement à l’avance, utilisez des horloges de simulation : 1. Créez une nouvelle simulation et définissez le paramètre `frozen_time` sur le 1er janvier. 2. Ajoutez un client et spécifiez son moyen de paiement. Dans ce cas, utilisez une 4242424242424242[carte de test](https://docs.stripe.com/testing.md#cards). 3. Créez un abonnement et ajoutez une période d’essai gratuit de 7 jours : #### Dashboard Pour ajouter une période d’essai à un abonnement existant via le Dashboard : 1. Recherchez l’abonnement que vous souhaitez modifier. 2. Cliquez sur **Actions**. 3. Cliquez sur **Mettre à jour l’abonnement**. 4. Cliquez sur **Ajouter une période d’essai gratuite** et saisissez sept dans **Jours d’essai gratuits**. 5. Cliquez sur **Mettre à jour l’abonnement**. #### API Créez l’abonnement avec `trial_end` défini sur 7 jours après le `frozen_time` de la simulation, en remplaçant la valeur dans cet exemple : #### Accounts v2 ```curl curl https://api.stripe.com/v1/subscriptions \ -u "<>:" \ -d "customer_account={{CUSTOMERACCOUNT_ID}}" \ -d "items[0][price]={{PRICE_ID}}" \ -d trial_end=1610403705 ``` #### Customers v1 ```curl curl https://api.stripe.com/v1/subscriptions \ -u "<>:" \ -d "customer={{CUSTOMER_ID}}" \ -d "items[0][price]={{PRICE_ID}}" \ -d trial_end=1610403705 ``` **Résultat attendu :** l’abonnement a le statut `trialing` et génère une facture d’un montant nul pour la période d’essai gratuite. 4. Avancez la date au 5 janvier pour tester la notification d’événement [customer.subscription.trial_will_end](https://docs.stripe.com/api/events/types.md#event_types-customer.subscription.trial_will_end) avec le délai de notification par défaut de 3 jours. Si vous avez configuré un délai de notification différent, avancez plutôt jusqu’à cette date. Vous pouvez utiliser cet événement webhook pour informer vos clients que la période d’essai prend fin prochainement. 5. Avancez la date au 8 janvier pour mettre fin à la période d’essai. Avancez le temps simulé si nécessaire pour la finalisation de la facture et l’encaissement du paiement. **Résultat attendu :** une fois le paiement réussi, l’abonnement devient `active` et la facture est payée. Le prix configuré pour l’abonnement détermine le montant de la facture. 6. 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 Pour tester les périodes d’essai sans avoir à attendre la fin d’une période complète : 1. Créez un abonnement avec une valeur [trial_end](https://docs.stripe.com/api/subscriptions/create.md#create_subscription-trial_end) réglée sur quelques minutes dans le futur à l’aide de l’API Subscriptions. Si vous utilisez Checkout, définissez [subscription_data.trial_end](https://docs.stripe.com/api/checkout/sessions/create.md#create_checkout_session-subscription_data-trial_end) à au moins deux jours dans le futur. 2. Laissez la période d’essai se terminer, puis vérifiez les états de l’abonnement et de la facture attendus pour votre tunnel de paiement configuré. Utilisez les [horloges de simulation](https://docs.stripe.com/billing/testing.md#test-clocks) pour tester de manière contrôlée le timing de la notification `customer.subscription.trial_will_end`. Les périodes d’essai courtes peuvent se terminer avant que le traitement des notifications en arrière-plan ne les détecte. La fenêtre de notification par défaut est de 3 jours avant la fin de la période d’essai. ### Tester les notifications webhook des abonnements Les intégrations Subscriptions s’appuient sur des *webhooks* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests). 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. [Vérifiez les signatures de webhook](https://docs.stripe.com/webhooks.md#verify-events) pour confirmer que les événements proviennent bien de Stripe. Que vous représentiez les clients avec Accounts v2 ou des [objets Customer](https://docs.stripe.com/api/customers.md), écoutez les événements `customer.subscription.*` pour suivre l’activité des abonnements. Utilisez ces deux méthodes pour tester votre intégration : - **Testez le tunnel d’abonnement** : créez des abonnements réels en environnement de test, effectuez des actions liées au [cycle de vie des abonnements](https://docs.stripe.com/billing/subscriptions/overview.md#subscription-lifecycle) telles que des mises à niveau ou des annulations, et vérifiez les événements reçus ainsi que le comportement de votre application. - **Testez les gestionnaires individuels** : configurez la [CLI Stripe](https://docs.stripe.com/stripe-cli.md) et associez-la à votre compte Stripe pour déclencher des notifications d’événements synthétiques, ou déclenchez-les via le [Dashboard](https://dashboard.stripe.com/test/account/webhooks). Ces événements contiennent des données de test qui ne correspondent pas à des ressources d’abonnement réelles et ne valident donc pas l’intégralité du cycle de vie de l’abonnement. Utilisez la CLI Stripe pour recevoir des notifications d’événements sur votre serveur sans tunnels réseau ni pare-feux. Ne partez pas du principe que les événements seront reçus dans un ordre particulier. Pour en savoir plus sur les types d’événements d’abonnement et obtenir des conseils de gestion, consultez la section [Événements d’abonnement](https://docs.stripe.com/billing/subscriptions/webhooks.md#events). ## Tests de paiement ### Tester les échecs de paiement Utilisez des [cartes de test](https://docs.stripe.com/testing.md#cards) pour déclencher des échecs de paiement pour les abonnements et les factures. L’échec d’un paiement initial peut laisser un abonnement nouvellement créé à l’état `incomplete`. Pour tester un échec de paiement à l’issue d’une période d’essai : 1. Définissez la carte 4000000000000341 comme moyen de paiement par défaut du client. 2. Créez un abonnement avec une courte période d’essai pour différer la tentative de paiement jusqu’à la fin de la période d’essai. 3. Laissez la période d’essai se terminer et attendez que la facture soit finalisée et que l’encaissement du paiement soit tenté. Dans ce test, la tentative de paiement échoue et votre intégration reçoit `invoice.payment_failed`. Vérifiez les états de la facture et de l’abonnement, puis assurez-vous que votre intégration respecte le comportement configuré pour les nouvelles tentatives et les notifications au client. Pour tester un échec de paiement lors d’un renouvellement trimestriel ou annuel sans attendre la fin de la période de facturation, utilisez les horloges de simulation pour avancer le temps simulé dans un environnement de test. Consultez les [scénarios avancés pour les horloges de simulation](https://docs.stripe.com/billing/testing/test-clocks/api-advanced-usage.md#use-cases). ### Tester les paiements nécessitant 3D Secure Pour tester l’authentification des abonnements et des factures : 1. Utilisez la carte 4000002760003184 pour déclencher 3D Secure. 2. Authentifiez-vous ou faites échouer la tentative de paiement dans la boîte de dialogue 3D Secure qui s’ouvre. Vérifiez le résultat pour chaque issue : - **Authentification réussie** : la facture est payée. Si la facture appartient à un abonnement dont l’état est `incomplete`, l’abonnement devient `active`. - **Échec de l’authentification** : la facture reste `open`. Pour d’autres scénarios d’authentification, consultez les [cartes de test 3D Secure](https://docs.stripe.com/testing.md#three-ds-cards). ### 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**. Stripe attribue à votre client un numéro de compte bancaire virtuel unique, que vous pouvez récupérer via l’[API des instructions de financement](https://docs.stripe.com/payments/customer-balance/funding-instructions.md#create-funding-instructions). Les coordonnées bancaires virtuelles apparaissent également sur la page de facture hébergée et sur le PDF. ### Tester les moyens de paiement par défaut pour les factures et les abonnements Utilisez les [ID de carte bancaire de test](https://docs.stripe.com/testing.md?testing-method=payment-methods#cards) pour simuler l’utilisation d’un moyen de paiement par défaut sur un abonnement ou une facture. Associez le moyen de paiement au client avant de le définir comme `default_payment_method`. Par exemple, pour utiliser `pm_card_visa` comme moyen de paiement Visa de test : 1. [Associez le moyen de paiement de test](https://docs.stripe.com/api/payment_methods/attach.md) `pm_card_visa` au client associé à l’abonnement ou à la facture. 2. Créez l’abonnement ou la facture en utilisant l’ID du moyen de paiement associé comme `default_payment_method`. L’abonnement ou la facture utilise ce moyen de paiement pour l’encaissement des paiements. ## 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éro | Type | | --- | --- | | `000000000` | Vérification réussie | | `111111111` | Échec de la vérification | | `222222222` | Vérification en attente pour une durée indéfinie | ## Automatiser vos tests Vous pouvez configurer des [tests automatisés](https://docs.stripe.com/automated-testing.md) pour votre intégration. Utilisez des environnement de test distinctes pour le développement local et l’intégration continue (CI) afin que les tests automatisés n’affectent pas vos produits, prix, clients, endpoints de webhook, paramètres ou données de test. Pour lancer un test : - Prenez connaissance de la [politique de conservation des données](https://support.stripe.com/questions/test-mode-subscription-data-retention) pour les données liées aux abonnements dans un environnement de test. - Évitez de réutiliser des ressources telles que des [bons de réduction](https://docs.stripe.com/api/coupons.md) et des [codes promotionnels](https://docs.stripe.com/api/promotion_codes.md) d’un test à l’autre. - Utilisez le serveur HTTP [stripe-mock](https://github.com/stripe/stripe-mock), qui est basé sur l’API Stripe et reflète fidèlement le comportement de l’API. ## See also - [Environnements de test](https://docs.stripe.com/sandboxes.md) - [Comptes multiples](https://docs.stripe.com/get-started/account/multiple-accounts.md)