Fonctionnement des abonnements

Avec un abonnement, le client s’acquitte de paiements récurrents en contrepartie de l’accès à un produit. Un abonnement vous amène à conserver davantage d’informations sur votre client que dans le cas d’achats ponctuels, de manière à pouvoir le débiter lors des échéances ultérieures.

Postes d’abonnement

Utilisez les principales ressources d’API suivantes pour créer et gérer des abonnements :

Voici un exemple de la manière dont les produits, les fonctionnalités et les droits d’accès fonctionnent ensemble. Imaginons que vous créez un service d’abonnement proposant deux niveaux : un produit standard avec des fonctionnalités de base et un produit avancé qui ajoute des fonctionnalités étendues.

1. Vous créez deux fonctionnalités : basic_features et extended_features.
2. Vous créez deux produits : standard_product et advanced_product.
3. Pour le produit standard, vous créez un objet ProductFeature qui associe basic_features à standard_product.
4. Pour le produit avancé, vous créez deux objets ProductFeature : un qui associe basic_features à advanced_product et un qui associe extended_features à advanced_product.

Un client, first_customer, s’abonne au produit standard. Lorsque vous créez l’abonnement, Stripe crée automatiquement un objet Entitlement qui associe first_customer à basic_features.

Un autre client, second_customer, s’abonne au produit avancé. Lorsque vous créez l’objet Subscription correspondant, Stripe crée automatiquement deux objets Entitlement : un qui associe second_customer à basic_features, et un qui associe second_customer à extended_features.

Pour savoir quelles fonctionnalités vous devez fournir à un client, récupérez ses droits d’accès actifs ou écoutez l’événement Active Entitlement Summary. Il n’est pas nécessaire de récupérer ses abonnements, produits et fonctionnalités.

Exemple d’intégration

Cette section décrit notre exemple d’intégration sur GitHub, qui illustre comment créer une intégration d’abonnements. Si vous êtes prêt à créer votre propre intégration, consultez le guide de démarrage rapide de Billing ou le guide d’intégration.

Page d’accueil

Sur votre front-end, la page d’accueil collecte prioritairement l’adresse e-mail du client. Dans votre application, il peut être judicieux de capturer d’autres informations client, telles que son nom d’utilisateur et son adresse postale. Lorsque le client clique sur le bouton d’inscription, les informations collectées sur la page d’accueil sont envoyées sur votre back-end. Un client est alors créé et la page des tarifs s’affiche sur votre front-end.

Page des tarifs

La page de tarification affiche vos options d’abonnement en fonction des produits et des tarifs que vous avez créés lors de la configuration initiale de votre intégration, ce qui signifie que vous n’avez pas besoin d’en créer de nouvelles à chaque inscription. Votre page de tarification affiche les tarifs que vous avez créés, et vos clients choisissent l’option qu’ils souhaitent. L’exemple sur GitHub affiche un formulaire de paiement lorsqu’un client sélectionne une option. En savoir plus sur les produits et les tarifs.

Paiement

Le formulaire de paiement permet de recueillir le nom du client ainsi que ses informations de carte bancaire. Stripe héberge ce formulaire si vous utilisez Checkout. Il s’agit de l’un des éléments essentiels pour l’encaissement des paiements et pour assurer votre conformité PCI. Cliquer sur le bouton S’abonner entraîne les actions suivantes :

1. Un nouvel abonnement est créé avec les ID du client et du tarif.
2. Une facture est générée pour votre cycle d’abonnement initial.
3. Les informations de paiement sont collectées et la facture est payée.
4. Définissez le moyen de paiement comme moyen de paiement par défaut pour l’abonnement. Cette action est nécessaire pour les paiements ultérieurs.

Assurez-vous de confirmer le paiement avant de fournir l’accès à votre client.

Pour implémenter ceci :

• Accepter des paiements sans rédiger de code : si vous ne souhaitez pas écrire de code, découvrez comment créer un lien de paiement et le partager avec vos clients.
• **Créer une page de paiement ** : utilisez l’API Checkout Sessions pour accepter des paiements par le biais d’une page hébergée, d’un formulaire intégré à votre site ou d’une page de paiement personnalisée comportant des composants intégrés.
• Intégration avancée : utilisez Stripe Elements pour collecter les informations de paiement et activer l’abonnement avec le composant Payment Element.

Mise en service

Utilisez les droits d’accès pour déterminer quand vous pouvez accorder ou révoquer l’accès aux fonctionnalités d’un produit à vos clients. Une fois le paiement réussi, vous pouvez également mettre le produit à disposition du client en toute sécurité. Cela signifie généralement :

1. Vérifier que l’état de l’abonnement est active.
2. Accorder au client l’accès aux produits et fonctionnalités inclus dans son abonnement.

Découvrez comment utiliser les destinations d’événements pour :

• Suivre les abonnements actifs
• Gérer les échecs de paiement
• Vérifier les objets d’événements

Fonctionnement des paiements avec les abonnements

Pour simplifier la gestion des échecs de paiement et pour créer des abonnements avant toute tentative de paiement :

1. Transmettez payment_behavior=default_incomplete lors de la création d’un abonnement. Si un paiement est requis, l’abonnement est créé avec l’état incomplete. Sinon, votre abonnement est immédiatement active.

2. Activez un abonnement incomplet en payant la première facture.

3. Transmettez l’identifiant du PaymentIntent correspondant à la facture à votre interface utilisateur pour collecter les informations de paiement et confirmer le PaymentIntent. Vous pouvez utiliser Elements, le SDK Android ou le SDK iOS.

État du paiement

Le processus de paiement diffère selon le moyen de paiement utilisé et la zone géographique. Les paiements peuvent par ailleurs initialement échouer (par exemple, si le client a saisi un numéro de carte erroné ou si ses fonds sont insuffisants). Différents résultats sont donc possibles pour un même paiement.

Un PaymentIntent suit le cycle de vie de chaque paiement. Dès qu’un paiement arrive à échéance pour un abonnement, Stripe génère une facture et un PaymentIntent. L’ID du PaymentIntent est associé à la facture et vous pouvez y accéder depuis les objets Invoice et Subscription. L’état du PaymentIntent affecte l’état de la facture et de l’abonnement. Voici les correspondances entre les différents résultats et états d’un paiement :

Les sections suivantes expliquent ces différents états et précisent les actions à mettre en œuvre pour chacun d’entre eux.

Paiement réussi

Lorsque votre paiement aboutit, le PaymentIntent est à l’état succeeded, et l’abonnement devient active. Pour les moyens de paiement avec des périodes de traitement plus longues, les abonnements sont immédiatement activés. Dans ces cas-là, le PaymentIntent peut être à l’état processing pour un abonnement active jusqu’à ce que le paiement aboutisse.

Maintenant que votre abonnement est activé, fournissez l’accès à votre produit. Consultez le guide pour en savoir plus sur le cycle de vie d’un abonnement et les bonnes pratiques concernant la mise en service.

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "active",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "paid",
    "payments": {
      "data": [
        {
          "payment": {
            "type": "payment_intent",
            "payment_intent": {
              "status": "succeeded",
              ...
            }
          }
          ...
        }
      ],
    ...
  }
}

Moyen de paiement requis

Si le paiement échoue en raison d’une erreur de carte, un refus de paiement par exemple, l’état du PaymentIntent bascule sur requires_payment_method et celui de l’abonnement sur incomplete.

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "incomplete",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "open",
    "payments": {
      "data": [
        {
          "payment": {
            "type": "payment_intent",
            "payment_intent": {
              "status": "requires_payment_method",
              ...
            }
          }
          ...
        }
      ],
      ...
    }
  }
}

Dans un tel scénario :

• Prévenez votre client.
• Recueillez de nouvelles données de paiement et confirmez le PaymentIntent.
• Mettez à jour le moyen de paiement par défaut de l’abonnement.

Découvrez comment gérer les échecs de paiement dans le cadre d’un abonnement.

Action requise

Certains moyens de paiement requièrent l’authentification du client avec 3D Secure (3DS) pour finaliser le processus de paiement. Si vous utilisez l’API Payment Intents, la valeur status du PaymentIntent est définie sur requires_action lorsqu’un client doit authentifier un paiement. Vous pouvez obtenir le PaymentIntent sur la ressource Invoice Payment en développant latest_invoice.payments.data.payment.payment_intent ou en spécifiant le paramètre de facture avec la liste des PaymentIntent. 3DS finalise le processus d’authentification. L’authentification d’un moyen de paiement dépend de vos règles Radar et de la banque émettrice de la carte.

Les réglementations en vigueur en Europe imposent souvent le recours à 3D Secure. Consultez la rubrique consacrée à l’authentification forte du client pour déterminer si la gestion de cet état est importante dans votre cas. Si vous disposez d’une intégration de facturation existante et souhaitez ajouter la prise en charge de ce flux, reportez-vous également au guide de migration SCA pour Billing.

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "incomplete",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "open",
    ...
    "payments": {
      "data": [
        {
          "payment": {
            "type": "payment_intent",
            "payment_intent": {
              "status": "requires_action",
              "client_secret": "pi_91_secret_W9",
              "next_action": {
                "type": "use_stripe_sdk",
                ...
              },
              ...
            }
          }
          ...
        }
      ],
    }
  }
}

Dans un tel scénario :

• Surveillez la notification d’événement invoice.payment_action_required à l’aide des endpoints de webhook. Cela indique qu’une authentification est requise.
• Avertissez votre client qu’une authentification est requise.
• Récupérez la clé secrète du client pour le PaymentIntent et transmettez-la dans un appel à stripe.ConfirmCardPayment. Cette action entraîne la présentation d’une fenêtre modale d’authentification à vos clients, une tentative de paiement, puis la fermeture de la fenêtre modale et le renvoi du contexte à votre application.
• Surveillez l’événement invoice.paid sur votre destination d’événement pour vérifier que le paiement a abouti. Les utilisateurs peuvent quitter votre application avant que la fonction confirmCardPayment() ne se termine. Le fait de vérifier que le paiement a abouti vous permet de fournir l’accès à votre produit de manière adéquate.

Paiements récurrents

Stripe gère automatiquement les paiements récurrents :

• Stripe facture automatiquement les clients et tente de finaliser les paiements lorsqu’un nouveau cycle de facturation commence.
• Lorsqu’un paiement échoue, Stripe le relance à l’aide de la fonctionnalité Smart Retries ou de votre calendrier de relance personnalisé. Ainsi, lorsqu’une carte est refusée, une nouvelle tentative de paiement est effectuée selon les paramètres du Dashboard. Si un échec renvoie un code de refus définitif, les tentatives programmées se poursuivent, mais le paiement n’est effectué que si vous utilisez un nouveau moyen de paiement.

Vous pouvez envoyer un e-mail de relance aux clients qui ont des paiements en souffrance afin d’augmenter les chances de recouvrement. Pour les paiements qui nécessitent 3D Secure, vous pouvez configurer vos paramètres de facturation de manière à envoyer un lien hébergé aux clients pour leur permettre de terminer le tunnel de paiement.

Gérer les échecs de paiement récurrents

Si vous ne voulez pas utiliser l’outil de gestion des échecs de Stripe, vous pouvez développer le vôtre. Si un paiement échoue ou qu’il nécessite une authentification du client, le status de l’abonnement est défini sur past_due et l’état du PaymentIntent bascule sur requires_payment_method ou requires_action.

Pour gérer ces scénarios, configurez un endpoint de webhook et écoutez l’événement customer.subscription.updated afin de recevoir une notification lorsque les abonnements passent à l’état past_due :

{
  "id": "sub_E8uXk63MAbZbto",
  "object": "subscription",
  ...
  "status": "past_due",
  "latest_invoice": "in_1EMLu1ClCIKljWvsfTjRFAxa"
}

Pour ces abonnements, vos clients doivent revenir sur votre application pour renseigner un autre moyen de paiement et effectuer le paiement. Pour cela, vous pouvez leur envoyer un e-mail ou une notification Push sur leur téléphone portable. Stripe propose des e-mails de rappel intégrés à cet effet, que vous pouvez configurer dans vos paramètres de facturation.

Quand votre client revient sur votre application, réutilisez le flux des échecs de paiement ou le flux des actions du client, selon l’état du PaymentIntent associé. Une fois le paiement réalisé, l’état de l’abonnement est active et celui de la facture est paid.

Gérer les factures sans paiement

Les abonnements qui prévoient une période d’essai, une facturation à l’usage ou l’application aux factures de bons de réduction ou du solde créditeur du client donnent souvent lieu à des factures sans paiement. Ceci signifie que vous ne débitez pas immédiatement le client lorsque vous créez l’abonnement.

Même si vous ne débitez pas vos clients pour la première facture, l’authentification et l’autorisation de leur carte bancaire restent souvent des étapes pertinentes, en ceci que vos chances de voir ensuite le premier paiement non-nul aboutir s’en trouvent accrues. Les paiements effectués de cette façon sont appelés paiements hors session. Pour gérer ces scénarios, Stripe a créé les SetupIntents.

Utiliser SetupIntents

Vous pouvez utiliser les SetupIntents pour :

• Collecter les informations de paiement.
• Authentifier la carte bancaire de votre client afin de solliciter des exemptions ultérieurement.
• Autoriser la carte bancaire de votre client sans la débiter.

L’authentification des paiements permet à votre client d’autoriser le débit de sa carte. Cette opération est nécessaire pour une authentification forte du client et est souvent menée à bien avec 3DS. La collecte des informations du moyen de paiement et son autorisation sont nécessaires pour que vous puissiez débiter le moyen de paiement.

Dans les scénarios hors session, les SetupIntents vous permettent de débiter le premier paiement non-nul d’un client sans nécessité de le faire revenir sur votre site Web ou votre application pour une authentification. Ils fluidifient ainsi le processus pour le client.

Le champ pending_setup_intent d’un abonnement n’est pas automatiquement annulé à la fin de l’abonnement. Écoutez les événements customer.subscription.deleted et annulez manuellement le SetupIntent d’abonnement si nécessaire.

Stripe crée automatiquement des SetupIntents pour les abonnements qui ne nécessitent pas de paiement initial. Les processus d’authentification et d’autorisation sont également exécutés à ce stade, s’ils sont nécessaires. Si ces deux étapes aboutissent ou si elles ne sont pas nécessaires, aucune action n’est requise et le champ subscription.pending_setup_intent prend la valeur null. Dès lors que l’une de ces étapes échoue, Stripe vous recommande d’utiliser le SetupIntent sur votre front-end afin de résoudre le problème pendant que votre client est en session. Les deux sections suivantes expliquent en détail comment gérer les cas où l’authentification ou l’autorisation échoue.

Gérer les échecs d’authentification Client-side

Les échecs d’authentification se produisent lorsque Stripe ne parvient pas à authentifier votre client auprès de l’émetteur de sa carte bancaire. Dans ce cas, le status du SetupIntent est défini sur requires_action.

Dans un tel scénario, appelez confirmCardSetup sur votre front-end pour que votre client suive le flux d’authentification manuellement. L’exemple de code ci-dessous développe le pending_setup_intent pour l’exécution du flux.

const {pending_setup_intent} = subscription;

if (pending_setup_intent) {
  const {client_secret, status} = subscription.pending_setup_intent;

  if (status === "requires_action") {
    const {setupIntent, error} = await stripe.confirmCardSetup(client_secret);

    if (error) {
      // Display error.message in your UI.
    } else {
      // The setup has succeeded. Display a success message.
    }
  }
}

Une fois ce flux terminé, l’autorisation s’exécute si nécessaire. Si l’autorisation aboutit ou si elle n’est pas requise, pending_setup_intent bascule alors sur null.

Gérer les échecs d’autorisation Client-side

Un échec d’autorisation de paiement se produit lorsque Stripe ne peut pas vérifier qu’une carte bancaire peut être débitée. Dans ce cas, le status du SetupIntent est défini sur requires_payment_method. En général, cela signifie que les paiements suivants effectués avec cette carte échoueront également.

Dans un tel scénario, collectez un nouveau moyen de paiement, puis mettez à jour le moyen de paiement par défaut de votre client ou de l’abonnement. L’exemple de code ci-dessous développe le paramètre pending_setup_intent pour l’exécution du flux.

const {pending_setup_intent, latest_invoice} = subscription;

if (pending_setup_intent) {
  const {client_secret, status} = subscription.pending_setup_intent;

  if (status === "requires_action") {
    const {setupIntent, error} = await stripe.confirmCardSetup(client_secret);

    if (error) {
      // Display error.message in your UI.
    } else {
      // The setup has succeeded. Display a success message.
    }
  } else if (status === "requires_payment_method") {
    // Collect new payment method
  }
}

Le cycle de vie de l’abonnement

Voici à quoi ressemble le flux d’abonnement recommandé :.

1. Vous créez l’abonnement. Le status de l’abonnement est défini sur incomplete (si vous suivez le flux recommandé, c’est-à-dire si vous créez un abonnement sans spécifier le payment_behavior et que le status par défaut est active).

2. Une facture est créée pour l’abonnement. Le status de la facture est open.

3. Le client paie la première facture.

4. Lorsque le paiement aboutit :

   • Le status de l’abonnement bascule sur active
   • Le status de la facture est défini sur paid
   • Stripe envoie un événement invoice.paid aux endpoints de webhook que vous avez configurés.

5. Vous fournissez l’accès à votre produit. Vous pouvez confirmer si la facture a été payée en :

   • Configuration d’un endpoint de webhook ou d’un autre type de destination d’événement et écoute de l’événement invoice.paid.
   • Vérifiant manuellement l’objet Subscription et en recherchant l’état subscription.status=active. Le status devient active suite au paiement de la facture via un prélèvement automatique ou un paiement manuel par le client.

Le status peut aussi passer à trialing si vous proposez des périodes d’essai qui ne nécessitent pas de paiement. L’état de l’abonnement devient active lorsque la période d’essai est achevée et le client abonné commence à être débité.

Comportement de paiement des abonnements

Pour simplifier la gestion des échecs de paiement, créez des abonnements en définissant payment_behavior sur default_incomplete. Vous obtenez ainsi des abonnements à l’état incomplete, et pouvez alors collecter et confirmer les données de paiement sur une seule et même interface utilisateur. Avec allow_incomplete ou error_if_incomplete, Stripe tente immédiatement de régler la facture. Si le paiement échoue, l’état de l’abonnement bascule sur incomplete ou la création échoue.

Paiements réussis

Quand le paiement de la facture par votre client aboutit, l’abonnement bascule sur active et la facture sur paid. À ce stade, vous pouvez fournir l’accès à votre produit.

Délai de paiement

Vos clients disposent d’environ 23 heures pour s’acquitter de leur paiement. Pendant ce temps, l’abonnement reste à l’état incomplete et la facture est open. Si votre client paie la facture, l’état de l’abonnement bascule sur active et celui de la facture sur paid. Si le paiement n’est pas réalisé par le client dans le délai fixé, l’état de l’abonnement bascule sur incomplete_expired et celui de la facture sur void.

Ce délai a pour objet de permettre à votre client de réaliser le premier paiement de son abonnement en session. Si le client revient sur votre application après l’expiration du délai de 23 heures, créez-lui un nouvel abonnement.

Échecs de paiement

L’état de l’abonnement reste active tant que les paiements automatiques aboutissent. Si un paiement automatique échoue, l’état de l’abonnement bascule sur past_due et Stripe tente de recouvrer le paiement conformément à vos règles de relance. Si le recouvrement échoue, vous pouvez définir l’état de l’abonnement sur canceled, unpaid ou le laisser sur past_due.

Abonnements impayés

Pour les abonnements avec des factures impayées, ces dernières restent en cours, mais les tentatives de paiement ultérieures sont suspendues. L’abonnement continue de générer des factures à chaque cycle de facturation, qui restent à l’état draft. Pour réactiver l’abonnement :

1. Collectez de nouvelles informations de paiement si nécessaire.

2. Activez le recouvrement automatique en paramétrant l’avancement automatique sur true pour les factures à l’état de brouillon.

3. Finalisez et payez les factures en cours. Le paiement de la dernière facture non annulée avant sa date d’échéance met à jour l’état de l’abonnement sur active.

Les factures marquées comme non recouvrables sont traitées comme paid lors de la détermination de l’état de l’abonnement, même si leur propriété paid reste false. Stripe ignore les factures annulées lors de la détermination de l’état de l’abonnement ; la facture non annulée la plus récente est utilisée à la place.

Le status d’un abonnement impayé dépend des paramètres relatifs aux échecs de paiement que vous avez définis dans le Dashboard.

Annuler des abonnements

L’annulation d’un abonnement entraîne la désactivation de la création de nouvelles factures et l’arrêt de l’encaissement automatique de toutes les factures liées à l’abonnement, car la valeur d’auto_advance est définie sur false. L’abonnement est également supprimé, et vous ne pouvez plus le mettre à jour ou mettre à jour ses métadonnées. Si votre client souhaite se réabonner, vous devez collecter de nouvelles informations de paiement auprès de lui et créer un nouvel abonnement.

Annuler une facture générée par un abonnement

Si vous annulez la première facture d’un abonnement, la logique suivante est appliquée en fonction de l’état de l’abonnement :

• Si l’abonnement est incomplete, l’état de l’abonnement est défini sur incomplete_expired.
• Si l’abonnement est past_due, l’état de l’abonnement est défini sur active.
• Si l’abonnement est active, l’état de l’abonnement reste inchangé.

Si vous annulez la facture la plus récente d’un abonnement actif qui n’est pas la première, Stripe applique la logique suivante à chaque facture, de la plus récente à la plus ancienne, jusqu’à ce qu’une de ces conditions soit remplie :

• Si la facture est à l’état paid ou uncollectible, l’état de l’abonnement est défini sur active.
• Si l’attribut collection_method présente la valeur charge_automatically permettant de débiter automatiquement sur facture et que les relances du paiement ont cessé après avoir atteint le nombre maximum de tentatives autorisées, l’abonnement passe à l’état canceled, unpaid ou past_due, selon vos paramètres d’encaissement automatique.
• Si l’attribut collection_method est défini sur send_invoice et que la facture est en souffrance, l’état de l’abonnement bascule sur past_due.
• Si la facture ne se trouve dans aucun de ces états, les mêmes étapes sont exécutées sur la facture la plus récente suivante.

Si aucune facture ne remplit l’un ou l’autre des critères ci-dessus, l’état de l’abonnement est défini sur active.

Sessions Checkout

Pour les intégrations Stripe Checkout, vous ne pouvez pas mettre à jour l’abonnement ou sa facture si l’abonnement de la session est incomplete. Vous pouvez écouter l’événement checkout.session.completed pour effectuer la mise à jour une fois la session terminée.

Vous pouvez également faire expirer la session si vous souhaitez annuler l’abonnement de la session, invalider la facture d’abonnement ou marquer la facture comme irrécouvrable.

Obtenir des informations de parrainage

Vous pouvez utiliser Stripe Apps pour les affiliations et les parrainages pour mettre en place et gérer des programmes de parrainage et d’affiliation avec Stripe, obtenir des informations sur les clients et automatiser les ajustements de commissions à partir du Dashboard Stripe.

États des abonnements

Événements d’abonnement

Des événements sont déclenchés chaque fois qu’un abonnement est créé ou modifié. Nous envoyons certains événements dès la création de l’abonnement, tandis que d’autres se répètent régulièrement à l’occasion de chaque facturation. Nous vous recommandons d’écouter les événements à l’aide des endpoints de webhook.

Veillez à ce que votre intégration gère les événements de manière adéquate. Par exemple, vous pouvez envoyer un e-mail à votre client en cas d’échec de paiement ou révoquer son accès s’il annule son abonnement.

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.

Cycle de vie d’une facture

La page de présentation générale des factures fournit une explication plus détaillée du fonctionnement des factures, mais en ce qui concerne les factures générées par les abonnements, leur cycle de vie se déroule comme suit :

1. L’abonnement génère une nouvelle facture à l’état draft.

2. Environ une heure après sa création, la facture est finalisée. Vous ne pouvez plus apporter de modifications une fois la facture finalisée.

3. L’état est défini sur open et Stripe tente automatiquement d’effectuer le paiement avec le moyen par défaut.

4. Si le paiement aboutit, l’état bascule sur paid.

5. Si le paiement échoue, la facture reste open et l’abonnement bascule sur past_due.

Dans ce flux, Stripe n’informe pas votre client de l’émission de la facture et le paiement est automatiquement tenté peu après sa génération. Cependant, si les e-mails client sont activés, nous envoyons un reçu par e-mail.

Paramètres et récupération des abonnements

Vos paramètres d’abonnement déterminent la manière dont Stripe traite les échecs de paiement et les expirations d’abonnement.

Smart Retries

Après la création d’un abonnement, l’échec du paiement est l’événement le plus important qui puisse survenir. Plusieurs raisons peuvent être à l’origine d’un échec de paiement :

• Aucun moyen de paiement n’est associé au client.
• Le moyen de paiement a expiré.
• Le paiement est refusé.

Vous pouvez configurer Stripe pour tenter à nouveau d’effectuer des paiements refusés. Smart Retries utilise le modèle d’IA de Stripe afin de choisir le moment idéal pour les relances sur une période configurable allant jusqu’à 2 mois après l’échec du paiement initial.

Vous pouvez également modifier le calendrier des relances avec des règles personnalisées. Vous pouvez configurer jusqu’à trois relances en précisant pour chacune quand elle doit intervenir, en nombre de jours après la tentative précédente.

Vous pouvez utiliser l’événement invoice.payment_failed pour surveiller les événements d’échec de paiement d’un abonnement et les mises à jour des tentatives de relance. Après une tentative de paiement sur une facture, sa valeur next_payment_attempt est définie à l’aide des paramètres d’abonnement actuels dans votre Dashboard.

Si le recouvrement échoue, l’abonnement est modifié selon vos paramètres. Vous pouvez choisir de :

Après la dernière tentative de paiement, nous n’effectuons plus aucune relance. La modification des paramètres de votre abonnement n’a d’incidence que sur les tentatives futures.

E-mails

Si vous le souhaitez, Stripe peut envoyer différents e-mails aux clients à l’aide des adresses e-mail associées à l’objet Customer :

• An upcoming renewal reminder at the same time that we send the invoice.upcoming event for subscriptions set up to collect payment automatically.
• Une notification d’échec de paiement invitant les clients à mettre à jour leurs informations de paiement. Découvrez comment activer les notifications d’échec de paiement.
• Une notification d’expiration lorsqu’une carte default_source d’un de vos clients arrive à expiration.

Vous pouvez personnaliser les logos et les couleurs que vos clients voient dans leurs e-mails, ainsi que sur notre page de paiement de facture hébergée, en modifiant les paramètres de marque dans le Dashboard.

Paiement manuel

Vous pouvez configurer la date d’échéance des factures qui utilisent la méthode d’encaissement send_invoice pour recevoir des paiements manuels. Vous pouvez également configurer jusqu’à trois rappels, de 10 jours avant la date d’échéance jusqu’à 60 jours après.

Vous pouvez également déclencher des actions supplémentaires sur l’abonnement 30, 60 ou 90 jours après la date d’échéance de la facture. Vous pouvez :

En savoir plus sur les états d’abonnement.

Paiements nécessitant 3D Secure

Pour les paiements qui nécessitent une vérification 3D Secure, Stripe peut envoyer un e-mail de confirmation à votre client en même temps que nous envoyons invoice.payment_action_required. Vous pouvez également configurer l’envoi de trois rappels maximum, jusqu’à 7 jours après l’initiation du paiement.

Si le paiement n’est toujours pas finalisé au terme du nombre de jours défini, vous pouvez :

Périodes d’essai

Les réseaux de cartes vous donnent l’obligation de fournir à vos clients certaines informations relatives à leurs périodes d’essai. Cette communication peut être gérée automatiquement par Stripe. Dans le Dashboard Stripe, vous pouvez configurer l’URL d’annulation à inclure dans les e-mails de rappel et sur le reçu de la première facture après la période d’essai. Vous pouvez aussi configurer le libellé de relevé bancaire pour le premier paiement après la période d’essai. Pour en savoir plus sur ces exigences et paramètres, consultez la page des périodes d’essai.

Modifier les abonnements

Stripe prend en charge la modification des abonnements existants sans avoir à les annuler et à les recréer. Quelques-unes des principales modifications que vous pouvez apporter sont l’augmentation ou la diminution des tarifs des abonnements, l’annulation ou la suspension de l’encaissement des paiements des abonnements actifs. En savoir plus sur la modification des abonnements existants.