# Tester mon intégration Billing Découvrez comment tester votre intégration Billing pour vous assurer qu’elle est prête pour la production. - Utilisez des [cartes bancaires](https://docs.stripe.com/testing.md#cards) et des [numéros de compte](https://docs.stripe.com/testing.md#test-account-numbers) de test pour déclencher différents scénarios, comme des échecs de paiement ou une authentification obligatoire. - Utilisez des [horloges de simulation](https://docs.stripe.com/billing/testing/test-clocks.md) pour simuler des objets Billing sur une certaine durée et tester des événements à différentes étapes clés telles que la fin d’un essai gratuit ou d’un plan annuel. - Consultez la [documentation consacrée aux tests généraux](https://docs.stripe.com/testing.md) pour en savoir plus sur les tests fondamentaux communs à tous les produits Stripe. 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 : - [Liste de contrôle pour les comptes](https://docs.stripe.com/get-started/account/checklist.md) - [Liste de contrôle pour le développement](https://docs.stripe.com/get-started/checklist/go-live.md) - [Liste de contrôle pour les sites Web](https://docs.stripe.com/get-started/checklist/website.md) Voici un exemple de flux d’intégration classique. Une intégration Billing classique (See full diagram at https://docs.stripe.com/billing/testing) > #### 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](https://docs.stripe.com/api-v2-overview.md#sdk-and-api-versioning) dans votre code. > > Pour demander l’accès à l’aperçu Accounts v2, > > 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](https://docs.stripe.com/accounts-v2/use-accounts-as-customers.md), plutôt que d’utiliser des objets [Customer](https://docs.stripe.com/api/customers.md). 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* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests). Consultez ce guide pour en savoir plus sur les [notifications d’événement](https://docs.stripe.com/billing/testing.md#webhooks) et les tests. | Composant | Description | Événements | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Inscription des clients** | Veillez à 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* (A set of UI components for building a web checkout flow. They adapt to your customer's locale, validate input, and use tokenization, keeping sensitive customer data from touching your server) ou un formulaire de paiement personnalisé créé avec l’[API Stripe](https://docs.stripe.com/api.md). 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](https://docs.stripe.com/billing/customer.md#manage-customers). | - `v2.core.account.created` - `v2.core.account[configuration.customer].updated` - `customer.created` - `customer.subscription.created` | | **Facturation** | Les abonnements génèrent des *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) à la fin de chaque période de facturation. Selon votre méthode d’encaissement, vous pouvez envoyer une facture pour percevoir un paiement à terme échu ou pour confirmer un débit automatique. Assurez-vous que votre intégration crée et envoie les factures comme prévu. Lisez le guide pour en savoir plus sur la création et la gestion des [factures pour les abonnements](https://docs.stripe.com/billing/invoices/subscription.md). Vous pouvez utiliser les horloges de simulation pour simuler les périodes de facturation, ce qui inclut la génération et l’envoi de factures. Lisez le guide des horloges de simulation pour découvrir des [cas d’usage](https://docs.stripe.com/billing/testing/test-clocks/api-advanced-usage.md#use-cases) 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 abonnements** | Configurez le *portail client* (The customer portal is a secure, Stripe-hosted page that lets your customers manage their subscriptions and billing details) pour permettre à vos clients de gérer leurs *abonnements* (A Subscription represents the product details associated with the plan that your customer subscribes to. Allows you to charge the customer on a recurring basis) et leurs informations de facturation. Pour le tester, créez un abonnement dans un *environnement de test* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes). 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](https://docs.stripe.com/customer-management.md) 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](https://docs.stripe.com/billing/testing.md#trials). Pour en savoir davantage sur le fonctionnement des périodes d’essai, consultez le [guide consacré aux périodes d’essai des abonnements](https://docs.stripe.com/billing/subscriptions/trials.md). | - `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](https://docs.stripe.com/billing/testing.md#payment-failures). | - `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* (A Subscription represents the product details associated with the plan that your customer subscribes to. Allows you to charge the customer on a recurring basis), au fil du temps dans un *environnement de test* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes). 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](https://docs.stripe.com/billing/testing/test-clocks.md) et les [cas d’utilisation](https://docs.stripe.com/billing/testing/test-clocks.md) courants qui s’y rapportent. ## Tester les périodes d’essai des abonnements Imaginons que vous souhaitiez permettre à vos clients de tester votre produit gratuitement pendant sept 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 4242424242424242[carte de test](https://docs.stripe.com/testing.md#cards). - Créez un abonnement et ajoutez une période d’essai gratuit de sept jours : #### Dashboard Pour ajouter une période d’essai à un abonnement existant via le Dashboard : Recherchez l’abonnement que vous souhaitez modifier. 1. Cliquez sur **Actions**. 1. Cliquez sur **Mettre à jour l’abonnement**. 1. Cliquez sur **Ajouter une période d’essai** et saisissez sept dans le champ **Nombre de jours de l’essai gratuit**. 1. Cliquez sur **Mettre à jour l’abonnement**. #### API Vous pouvez démarrer l’abonnement d’un client avec une période d’essai gratuite en spécifiant l’argument `trial_period_days=7` lors de la création de l’abonnement : #### 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 ``` - Après la création d’un abonnement avec une période d’essai gratuite de sept jours, l’abonnement est créé avec l’état `trialing`. Une facture de 0,00 USD est générée en raison de la période d’essai gratuite. - Avancez la date au 5 janvier pour recevoir 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). 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 Pour tester la façon dont votre intégration gère les périodes d’essai sans avoir à attendre une période d’essai complète, créez un nouvel *abonnement* (A Subscription represents the product details associated with the plan that your customer subscribes to. Allows you to charge the customer on a recurring basis) dont la valeur `trial_end` se situe quelques minutes dans le futur. Si vous utilisez Checkout, définissez la valeur [trial_end](https://docs.stripe.com/api/subscriptions/create.md#create_subscription-trial_end) sur au moins 2 jours. En utilisant cette approche, vous ne recevrez pas de notification d’événement `customer.subscription.trial_will_end` (qui survient trois jours avant le terme de la période d’essai). Pour le reste, le comportement reste identique à celui d’un abonnement avec une période d’essai plus longue. ## Tester les notifications webhook des abonnements Les intégrations d’abonnement s’appuient fortement sur les *webhooks* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests). 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](https://docs.stripe.com/stripe-cli.md) ou via le [Dashboard](https://dashboard.stripe.com/test/account/webhooks). 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](https://docs.stripe.com/billing/subscriptions/overview.md#subscription-lifecycle) 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. > 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](https://docs.stripe.com/accounts-v2/use-accounts-as-customers.md) ou [Customer](https://docs.stripe.com/api/customers.md) 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. | Événement | Description | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `v2.core.account.created` | Envoyé lorsqu’un [Compte v2](https://docs.stripe.com/api/v2/core/accounts/object.md) est créé avec succès. | | `customer.created` | Envoyé lorsqu’un objet [Customer](https://docs.stripe.com/api/customers/object.md) 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 finaliser le paiement ou si le paramètre `payment_behavior` est défini sur [default_incomplete](https://docs.stripe.com/api/subscriptions/create.md#create_subscription-payment_behavior). | | `customer.subscription.deleted` | Envoyé lorsque l’abonnement d’un client prend fin. | | `customer.subscription.paused` | Envoyé lorsque l’`état` d’un abonnement passe à `paused`. Par exemple, nous l’envoyons lorsque vous [configurez](https://docs.stripe.com/api/subscriptions/create.md#create_subscription-trial_settings-end_behavior-missing_payment_method) un abonnement pour qu’il soit suspendu lorsqu’une [période d’essai gratuite se termine sans moyen de paiement](https://docs.stripe.com/billing/subscriptions/trials/free-trials.md#create-free-trials-without-payment). Invoicing remporté(e) n’aura lieu qu’une fois l’abonnement [repris(/API/abonnement/reprise). Nous n’envoyons pas cet événement si vous [suspendez le recouvrement](https://docs.stripe.com/billing/subscriptions/pause-payment.md) car les factures continuent d’être créées pendant cette période. | | `customer.subscription.resumed` | Envoyé lorsque vous reprenez un abonnement précédemment à l’état `paused`. Cela ne s’applique pas lorsque vous [interrompez le recouvrement des paiements](https://docs.stripe.com/billing/subscriptions/pause-payment.md#unpausing). | | `customer.subscription.trial_will_end` | Envoyé trois jours avant la [fin de la période d’essai](https://docs.stripe.com/billing/subscriptions/trials.md). 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é](https://docs.stripe.com/billing/subscriptions/change.md). 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](https://docs.stripe.com/billing/entitlements.md). | | `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](https://docs.stripe.com/invoicing/integration/automatic-advancement-collection.md) est retardée de 72 heures au maximum. Renseignez-vous sur la [finalisation des factures](https://docs.stripe.com/invoicing/integration/workflow-transitions.md#finalized). - Répondez à la notification en envoyant une requête à l’API [de finalisation des factures](https://docs.stripe.com/api/invoices/finalize.md). | | `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](https://docs.stripe.com/invoicing/integration/workflow-transitions.md#finalized) 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](https://docs.stripe.com/invoicing/integration/workflow-transitions.md#emails) pour en savoir plus. | | `invoice.finalization_failed` | La facture n’a pas pu être finalisée. Découvrez [comment gérer les échecs de finalisation](https://docs.stripe.com/tax/customer-locations.md#finalizing-invoices-with-finalization-failures) et [la finalisation](https://docs.stripe.com/invoicing/integration/workflow-transitions.md#finalized) des factures. - Inspectez la [last_finalization_error](https://docs.stripe.com/api/invoices/object.md#invoice_object-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](https://docs.stripe.com/api/invoices/object.md#invoice_object-last_finalization_error) 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](https://docs.stripe.com/tax/customer-locations.md) demandé. - 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](https://docs.stripe.com/billing/subscriptions/overview.md#requires-action) 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 : - Prévenez votre client. - Configurez vos [paramètres d’abonnement](https://dashboard.stripe.com/settings/billing/automatic) dans le Dashboard pour activer [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md) et d’autres fonctionnalités de recouvrement de revenus. - Si vous utilisez des PaymentIntents, recueillez de nouvelles données de paiement et [confirmez le PaymentIntent](https://docs.stripe.com/api/payment_intents/confirm.md). - Mettez à jour le [moyen de paiement par défaut](https://docs.stripe.com/api/subscriptions/object.md#subscription_object-default_payment_method) 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](https://dashboard.stripe.com/settings/billing/automatic). 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](https://docs.stripe.com/billing/invoices/subscription.md#adding-upcoming-invoice-items) 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](https://docs.stripe.com/api/payment_intents.md) 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](https://docs.stripe.com/billing/subscriptions/subscription-schedules.md#subscription-schedule-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](https://docs.stripe.com/api/subscription_schedules/release.md), 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](https://docs.stripe.com/testing.md#cards) spécifiques pour déclencher des échecs de paiement pour les abonnements et 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). 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**](https://docs.stripe.com/testing.md#cards) 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](https://docs.stripe.com/invoicing/overview.md#draft) 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 des [horloges de simulation](https://docs.stripe.com/billing/testing/test-clocks.md) pour simuler l’avancement du temps en *environnement de test* (A sandbox is an isolated test environment that allows you to test Stripe functionality in your account without affecting your live integration. Use sandboxes to safely experiment with new features and changes), et faire en sorte que les ressources Billing, telles que Subscriptions, changent d’état et déclenchent des événements *webhook* (A webhook is a real-time push notification sent to your application as a JSON payload through HTTPS requests). 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**](https://docs.stripe.com/testing.md#three-ds-cards) 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]`. 1. Recherchez la facture dans le Dashboard et cliquez sur **Envoyer**. 1. 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](https://docs.stripe.com/payments/customer-balance/funding-instructions.md#create-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](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. 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](https://docs.stripe.com/api/payment_methods/attach.md) avec `pm_card_visa` et le client correspondant à l’abonnement ou à la facture. 1. 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](https://docs.stripe.com/testing.md?testing-method=payment-methods#cards) 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é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](https://docs.stripe.com/automated-testing.md) pour votre intégration. Pour optimiser les tests : - 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 les [coupons](https://docs.stripe.com/api/coupons.md) et les [codes de promotion](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)