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.

You can determine which features to provision for a customer by retrieving their active entitlements or listening to the Active Entitlement Summary event. You don’t have to retrieve their subscriptions, products, and features.

Exemple d’intégration

Cette section décrit notre exemple d’intégration sur GitHub, qui illustre la façon de créer une intégration pour les abonnements. Si vous êtes prêt à concevoir votre propre intégration, consultez notre QuickStart consacré à Billing ou notre 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 des tarifs affiche vos options d’abonnement compte tenu des produits et tarifs que vous avez créés lors de la configuration initiale de votre intégration, ce qui signifie que vous n’avez pas à les définir à chaque inscription d’un client. Cette page affiche les tarifs que vous avez créés, et vos clients choisissent l’option qui leur convient. 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.

Pour implémenter ceci :

• Sans code : si vous ne souhaitez pas rédiger de code, découvrez comment créer un lien de paiement et le partager avec vos clients.
• Low-code : si vous utilisez Checkout, découvrez comment ajouter un bouton à votre site Web qui crée une session Checkout.
• Code personnalisé : si vous utilisez Elements, découvrez comment collecter les données de paiement de votre client et activer l’abonnement avec le Payment Element ou le Card Element.

Mise en service

Utilisez les droits d’accès pour déterminer quand vous pouvez accorder à vos clients l’accès aux fonctionnalités de vos produits et quand vous pouvez le révoquer.

Par ailleurs, une fois qu’un paiement aboutit, vous pouvez mettre le produit à la disposition du client en toute sécurité. En général, vous devez :

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
• Traiter 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",
    ...
    "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",
    ...
    "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

Pour certains moyens de paiement, une authentification du client avec 3D Secure (3DS) est requise pour mener à bien le processus de paiement. Si vous utilisez l’API Payment Intents, latest_invoice.payment_intent.status est défini sur requires_action lorsqu’un client doit authentifier un paiement. 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",
    ...
    "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 de destinations d’événements. Celle-ci 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 en accord avec les paramètres du Dashboard. Si un échec renvoie un code de refus sans relance possible, 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.

Développer votre propre gestion des échecs pour les paiements 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.

Dans un tel scénario, configurez une destination d’événement et écoutez l’événement customer.subscription.updated pour recevoir une notification lorsque l’état d’un abonnement passe à 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.

Utilisation de 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 Côté client

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 Côté client

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 destinations d’événements que vous avez configurées.
5. Vous fournissez l’accès à votre produit. Vous pouvez confirmer si la facture a été payée en :
   • Mise en place d’une 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 impayés, la dernière facture reste ouverte, mais aucune tentative de paiement n’est effectuée. L’abonnement continue de générer des factures à chaque cycle de facturation et reste à l’état draft. Pour réactiver l’abonnement, vous devez :

• Collecter de nouvelles informations de paiement.
• Réactiver l’encaissement automatique en définissant auto advance sur true pour les brouillons de facture.
• Finaliser les factures ouvertes et déclencher leur paiement. La facture la plus récente doit être réglée avant sa date d’échéance pour basculer l’état de l’abonnement sur active.

Le comportement par défaut définit les abonnements past_due sur unpaid car ce réglage est celui qui vous offre le plus d’options pour les réactiver.

Annuler les 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 l’abonnement est à l’état incomplete et que vous annulez la première facture générée, il bascule sur incomplete_expired. Si vous annulez la facture la plus récente d’un abonnement actif et que celle-ci n’est pas la première, la logique suivante est appliquée à chaque facture (de la plus récente à la plus ancienne), jusqu’à ce qu’une des 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 collection_method est défini sur send_invoice et que la facture atteint sa date d’échéance, 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 de destinations d’événements.

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 (les modifications ne sont plus autorisées).
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 de manière à ce qu’il relance les paiements qui ont échoué. La fonction Smart Retries utilise le machine learning de Stripe afin de déterminer le moment le plus opportun 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 :

• Un rappel de renouvellement à venir que nous envoyons en même temps que l’événement invoice.upcoming.
• 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 votre URL pour mettre à jour une carte, ainsi que le logo et les couleurs utilisés dans vos e-mails, comme décrit dans la documentation relative aux reçus.

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.

Modification des 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. Pour en savoir plus sur la modification des abonnements existants, consultez la page Modification des abonnements.