Guide de migration vers la SCA pour la facturation

Authentification forte du client

La réglementation sur l’authentification forte du client (SCA), entrée en vigueur en Europe le 14 septembre 2019 dans le cadre des dispositions DSP2, modifie la manière dont vos clients européens authentifient leurs paiements en ligne. Cette réglementation s’applique aux paiements en ligne dès lors que la banque du client et l’entreprise sont toutes deux situées dans l’Espace économique européen(EEE).

La réglementation SCA exige des entreprises qu’elles s’appuient sur deux éléments d’authentification distincts pour la vérification des paiements. Concrètement, cette disposition implique d’ajouter une étape supplémentaire au processus de règlement, invitant le client à confirmer son paiement au moyen d’informations d’authentification telles qu’un mot de passe, un token matériel ou des données biométriques. 3D Secure 2 est la principale méthode d’authentification utilisée pour répondre aux exigences de la réglementation SCA pour les paiements par carte bancaire.

Les transactions qui ne répondent pas à ces exigences d’authentification et qui ne remplissent pas les conditions requises pour bénéficier d’une exemption peuvent être refusées.

Modifications apportées à Stripe Billing

En raison des contraintes accrues que la SCA fait peser sur paiements, une augmentation de vos délais d’encaissement et une baisse de vos taux de conversion sont à prévoir. Les modifications apportées à Stripe Billing vous permettent de maximiser vos revenus dans ce contexte nouveau. Ces modifications incluent :

• De nouveaux états d’abonnement pour faciliter le paiement initial
• Des PaymentIntents qui sont désormais exposés sur les factures en tant que mécanisme pour les paiements multi-états
• Des SetupIntents qui peuvent être utilisés pour collecter les données d’authentification lorsque le client est en session
• Un nouveau webhook qui indique lorsqu’une authentification SCA est requise pour un paiement
• Une page de facture hébergée actualisée qui permet au client de mener à bien l’authentification requise par la réglementation SCA
• Une nouvelle série d’e-mails de relance destinés à faciliter l’encaissement du paiement lorsqu’une authentification SCA est nécessaire

Incidences de la SCA pour Billing ?

La SCA a un impact sur les paiements par carte réalisés au profit d’entreprises de l’EEE par leurs clients situés dans l’EEE. Elle modifie la façon dont se déroulent les paiements en session et hors session.

Utilisation d’anciens mandats

Vous pouvez utiliser d’anciens mandats pour les paiements hors session dès lors qu’ils remplissent les critères suivants :

• Cartes de clients européens enregistrées avant le 31 décembre 2020
• Cartes de clients du Royaume-Uni enregistrées avant le 14 septembre 2021

Dans les scénarios ci-après, ceci signifie que vous n’avez pas à réenregistrer les cartes et à réauthentifier ces clients. Si vous utilisez Stripe pour les paiements non récurrents, veuillez vous reporter au guide des paiements hors périmètre.

Mise à jour de votre intégration Billing pour la prise en charge de la SCA

Les modifications que vous devez apporter à votre intégration dépendent de la façon dont vous utilisez Stripe Billing. Quatre scénarios différents sont à prendre en compte, qu’il vous faut potentiellement pouvoir gérer pour prendre en charge la SCA. Évaluez votre intégration au regard de ces scénarios pour déterminer ceux qui vous concernent.

• Scénario 1 : débiter les clients en session pour leur paiement initial
• Scénario 2 : débiter les clients hors session pour leur paiement initial
• Scénario 3 : gérer les paiements récurrents après que les clients ont effectué leur premier paiement
• Scénario 4 : factures ponctuelles

Vous êtes concerné par le premier scénario si vous débitez immédiatement vos clients lorsqu’ils s’abonnent, ce qui signifie que leur premier paiement a lieu en session. Le deuxième scénario s’applique à vous si vous ne débitez pas immédiatement vos clients lorsqu’ils s’abonnent et que leur paiement initial a lieu hors session.

Le troisième scénario s’applique à la majorité des utilisateurs Billing, car il s’agit de la gestion des paiements récurrents. Il s’agit des paiements qui ont lieu après le premier paiement. Vous n’êtes concerné par le quatrième scénario que si vous utilisez des factures ponctuelles.

Quel que soit le scénario qui s’applique à votre intégration, lorsque vous créez des abonnements, vous pouvez développer l’attribut latest_invoice.payments afin de déterminer le résultat d’un paiement. Vous pouvez également développer pending_setup_intent pour la gestion d’abonnements sans paiement initial, comme indiqué dans le scénario 2.

Scénario 1 : débiter les clients en session pour leur paiement initial

Lorsque vous débitez vos clients immédiatement pour un abonnement, leur premier paiement nécessite une authentification SCA. Vous devez par conséquent intégrer la gestion de cette authentification dans le flux de paiement ou d’inscription de votre application. Lors de la souscription initiale d’un abonnement, vos clients sont en session. Cela signifie qu’ils sont en mesure de réagir à vos demandes sur leur navigateur ou leur application.

Lors de la mise en place d’un abonnement avec règlement immédiat, Stripe tente de débiter la carte enregistrée pour votre client dans le cadre de l’appel de création de l’abonnement ou de création du client qui génère l’abonnement.

Étape 1 : création des abonnements

Les abonnements possèdent de nouveaux états incomplete que vous devez utiliser pour prendre en charge la SCA. Deux solutions sont possibles pour l’accès à ces états. Dans le premier cas de figure, vous demeurez sur votre ancienne version de l’API, mais vous devez dès lors transmettre un indicateur à certains de vos appels à l’API. La seconde option consiste quant à elle à mettre à jour votre version de l’API. Ces deux solutions sont expliquées dans les sections qui suivent, les diagrammes ci-dessous vous donnant pour leur part un aperçu du comportement de l’abonnement avec ces états.

Lorsqu’un paiement réussit, l’état de l’abonnement est défini sur active et aucune autre action n’est requise. Lorsqu’un paiement échoue, l’état de l’abonnement est défini sur incomplete et l’attribut status est défini sur requires_payment_method. Vous pouvez obtenir le Payment Intent 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 paiements de facture. Dans ce cas, vous devez débiter le client avec un autre moyen de paiement à l’aide de l’endpoint Pay Invoice.

Lorsque le paiement nécessite une authentification forte (SCA), l’état de l’abonnement est défini sur incomplete et l’attribut status sur requires_action. Vous pouvez obtenir le Payment Intent 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 paiements de facture. Vous devez alors demander à votre client de terminer le flux d’authentification 3D Secure à l’aide du PaymentIntent. L’étape suivante vous explique comment procéder.

Vous pouvez utiliser des cartes de test réglementaires pour étudier ce comportement dans votre environnement de test. Pour obtenir des instructions détaillées sur la manière de développer une intégration d’abonnements complète, consultez le guide d’intégration.

Option 1 : utilisation de l’indicateur de comportement du paiement

Si vous choisissez de ne pas mettre à niveau votre version de l’API, mais que vous transmettez le nouvel indicateur payment_behavior=allow_incomplete sur les appels de création et de modification d’abonnement, vos abonnements utiliseront la nouvelle fonctionnalité état incomplet. Cela vous permet de gérer les scénarios nécessitant une authentification forte, comme expliqué à l’étape suivante. Consultez la FAQ à la fin de ce document pour obtenir la liste complète des endpoints auxquels vous devez transmettre cet indicateur.

Si vous ne mettez pas à niveau votre version de l’API et que vous ne transmettez pas l’indicateur payment_behavior, les tentatives de création d’abonnement nécessitant une authentification forte du client échoueront et renverront une erreur card_error (dans la même logique que le comportement antérieur qui bloque la création d’un abonnement si le paiement échoue).

Option 2 : mise à niveau de votre API

Si vous mettez à niveau votre API avec la version 2019-03-14 ou une version ultérieure, vos abonnements utiliseront automatiquement la nouvelle fonctionnalité des états incomplete. Une fois votre API mise à niveau, passez simplement à l’étape suivante.

Étape 2 : gestion de la SCA

Afin de réaliser un paiement qui nécessite une authentification forte (SCA), vous pouvez utiliser Stripe.js ou un flux de redirection dans le navigateur. Stripe.js est l’option recommandée, car la plupart des utilisateurs de Stripe l’emploient déjà et elle facilite la gestion des authentifications 3DS. L’utilisation de Stripe.js oblige à transmettre l’attribut latest_invoice.confirmation_secret.client_secret dans la méthode confirmCardPayment, ce qui affiche une fenêtre dans laquelle le client peut authentifier son paiement.

Cependant, si vous ne souhaitez pas utiliser Stripe.js, vous pouvez transmettre une return_url au endpoint de confirmation PaymentIntent et initier un flux de virement avec redirection bancaire :

curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  --data-urlencode return_url="https://www.example.com/return_url"

Pour plus d’informations sur l’utilisation de l’API Payment Intents pour effectuer l’authentification 3D Secure pour Billing, consultez le guide de présentation.

Une fois que le flux de virement avec redirection bancaire ou le flux modal a abouti, l’état de l’abonnement est défini sur active et l’état de la facture sur paid. Notez qu’il est possible que le client quitte son navigateur après l’authentification, mais avant d’avoir été redirigé. Pour un traitement plus robuste, Stripe vous recommande d’écouter les webhooks des factures indiqués à l’étape suivante.

Étape 3 : mise en service et exécution

Il peut arriver que le client quitte son navigateur avant que le rappel confirmCardPayment ne s’exécute, ou avant que la redirection return_url n’ait lieu. Dans un tel cas, la validation du paiement n’est pas forcément perçue par votre application et le produit associé risque de ne pas être accessible par votre client. Pour éviter ces situations, vous pouvez écouter la notification d’événement invoice.paid pour vérifier que la facture est à l’état paid et que billing_reason=subscription_create. Dès lors, vous pouvez fournir à votre client l’accès à son abonnement.

Scénario 2 : débiter les clients hors session pour leur paiement initial

Les abonnements qui prévoient une période d’essai, une facturation à la consommation ou l’application aux factures de bons de réduction ou du solde créditeur du client donnent souvent lieu à des factures sans paiement. Cela signifie que le client n’est pas immédiatement débité au moment de la création de l’abonnement. Vous devez dans ce cas, pour pouvoir le débiter ultérieurement, enregistrer les informations de paiement du client et authentifier sa carte lorsqu’il est en session.

Pour gérer les situations de ce type, Stripe a créé l’API Setup Intents, qui permet :

• De collecter les informations de paiement du client
• D’authentifier la carte bancaire du client
• D’autoriser la carte bancaire du client sans la débiter

La collecte des informations de paiement en amont et l’authentification des paiements permettent à Stripe de solliciter des exemptions en votre nom. Ces exemptions réduisent généralement la probabilité que 3DS soit nécessaire au moment de débiter vos clients hors session.

Si la création d’un abonnement ne nécessite pas de paiement initial et si l’authentification est recommandée lorsque le client a une session ouverte, Stripe Billing crée automatiquement un SetupIntent. Celui-ci est exposé sur l’objet Subscription via l’attribut pending_setup_intent. Consultez la section Utilisation des SetupIntents pour en savoir plus sur les SetupIntents et leur utilisation avec Billing. Pour créer des abonnements et facturer le paiement initial des clients hors session, vous devez :

1. Utiliser CreatePaymentMethod pour collecter les informations de paiement
2. Créer un client en utilisant l’identifiant du PaymentMethod que vous avez créé
3. Créer l’abonnement
4. Configurer le traitement des erreurs grâce à confirmCardSetup pour les échecs d’authentification et confirmCardPayment pour les échecs d’autorisation

Vous pouvez également utiliser des SetupIntents pour modifier le moyen de paiement défini pour un client ou un abonnement. La section Enregistrer des cartes sans qu’il y ait paiement vous explique comment procéder au niveau du client. Au niveau de l’abonnement, Stripe met automatiquement à jour le champ pending_setup_intent de l’objet Subscription si une authentification est recommandée pour le moyen de paiement par défaut mis à jour.

Scénario 3 : gérer les paiements récurrents après le premier paiement du client

Les paiements récurrents ont généralement lieu alors que le client est hors session. Si aucune exemption ne s’applique au paiement et qu’une authentification SCA est nécessaire, vous devez faire revenir l’utilisateur en session afin qu’il puisse finaliser son paiement. Pour ce faire, vous pouvez utiliser les outils préconfigurés de Stripe ou bien créer votre propre solution. Ces deux options sont illustrées ci-dessous.

Lorsque que l’échéance du cycle de facturation ou le seuil d’un abonnement sont atteints, une tentative de paiement de l’abonnement correspondant est générée. Si le paiement requiert une authentification SCA, l’état de l’abonnement bascule sur past_due. Avec les outils Stripe, vous pouvez faire en sorte qu’une série d’e-mails spécifique à 3D Secure soit envoyée à vos clients lorsqu’un telle authentification est nécessaire. Si vous souhaitez envoyer vos propres e-mails, mais sans créer votre propre votre flux d’authentification, vous pouvez également utiliser notre Page de facture hébergée.

Si vous choisissez de développer votre propre solution, vous pouvez écouter le nouveau webhook invoice.payment_action_required ou bien le webhook customer.subscription.updated afin d’être informé de tout basculement en past_due d’un abonnement du fait des exigences SCA. Lorsque ceci se produit, vous devez faire revenir votre client en session et le soumettre à un flux d’authentification similaire à celui décrit dans le premier scénario.

Une fois le paiement authentifié et mené à bien, l’état de l’abonnement bascule sur active, et l’état de la facture sur paid.

Scénario 4 : factures ponctuelles

Les factures ponctuelles peuvent également être soumises à la SCA. Les modifications que vous devez apporter pour gérer les factures ponctuelles dépendent de la façon dont vous utilisez Billing aujourd’hui. Si vous utilisez déjà notre Page de facture hébergée, vous bénéficiez d’emblée de la prise en charge de la SCA, sans modifications à effectuer. Si vous utilisez collection_method=charge_automatically, il se peut que vous ayez à faire revenir vos clients en session pour qu’ils mènent à bien leur authentification SCA. Vous pouvez pour cela recourir à notre Page de facture hébergée ou au traitement personnalisé décrit dans le troisième scénario.

Si votre application utilise l’endpoint Régler la facture, il vous faut utiliser notre Page de facture hébergée ou bien créer un traitement personnalisé pour éviter les renvois par cet endpoint d’une erreur HTTP 402 lorsqu’une authentification SCA sera requise. Si vous choisissez de créer un traitement personnalisé, vous devez utiliser le PaymentIntent de la facture pour que le paiement puisse aboutir. Pour vos tentatives de règlement à l’aide de l’endpoint, vous devez également définir le paramètre off_session.

Outils pour l’encaissement des paiements hors session

Stripe Billing propose différents outils préconfigurés qui se chargent en toute autonomie de gérer les paiements qui requièrent une authentification 3D Secure.

Vous pouvez demander à Stripe :

• D’envoyer un e-mail à vos clients lorsqu’un paiement hors session nécessite une authentification 3D Secure
• D’envoyer des e-mails de suivi à vos clients afin de leur rappeler qu’ils doivent s’authentifier
• De fournir un lien vers une page de facture hébergée sur laquelle vos clients pourront s’authentifier

Vous pouvez personnaliser vos e-mails ainsi que la page de facture hébergée dans vos paramètres de marque.

Le tableau suivant répertorie les différentes actions que vous ou Stripe pouvez engager pour déclencher la SCA et indique si Stripe considère ou non que l’action a lieu en session ou hors session par défaut. Pour les actions hors session, Stripe envoie un lien d’authentification si l’envoi d’e-mails SCA est activé.

Les actions API pour la création des abonnements, leur mise à jour et le paiement des factures fournissent par ailleurs un attribut off_session que vous pouvez configurer manuellement. Définissez cet attribut sur true pour indiquer un paiement hors session, et sur false pour un paiement en session.

E-mails et relances

Vous pouvez envoyer un e-mail de relance aux clients qui ont des paiements en retard afin d’augmenter les chances de recouvrement. Notre suite d’e-mails client inclut désormais des notifications adressables à vos clients pour les avertir lorsque qu’une authentification 3D Secure est nécessaire pour les paiements hors session. Ces notifications viennent compléter la prise en charge des envois de factures, de reçus et de notifications d’échec de paiement.

Paramètres de paiement 3D Secure

Vous pouvez programmer l’envoi d’e-mails 3D Secure et déterminer l’effet que doit avoir un non-paiement sur l’abonnement. Utilisez les paramètres Billing du Dashboard Stripe pour configurer ces paramètres.

E-mails 3D Secure de demande d’authentification des paiements

Un modèle d’e-mail configurable vous est proposé pour automatiser l’envoi à vos clients d’un message les invitant à s’authentifier pour finaliser le paiement de leur facture ou de leur abonnement.

Page de facture hébergée

Stripe Billing propose une page de facture hébergée qui prend en charge toutes les factures. Pour répondre aux exigences d’authentification SCA, cette page gère à présent l’authentification 3D Secure.

Lorsqu’un paiement hors session nécessite de soumettre le client à une authentification 3D Secure, vous pouvez lui envoyer un lien vers une page de facture hébergée. Sur cette page de facture hébergée, le client est invité à confirmer son paiement ou à ajouter au besoin un nouveau moyen de paiement. Après confirmation de son paiement, le client peut s’authentifier auprès de sa banque à l’aide du modal 3D Secure 2 qui s’affiche.

Exemptions à la SCA

The SCA regulation contains a set of exemptions. These exemptions mean that your customers might not need to provide additional authentication to confirm some payments. Stripe’s goal is to optimize your payment flow and attempt to automatically apply as many exemptions as possible to reduce the likelihood of your customers needing to authenticate.

Récapitulatif des modifications de l’API

L’API contient un certain nombre de mises à jour destinées à faciliter la gestion des exigences SCA et du flux d’authentification.

États des abonnements

Deux états ont été ajoutés à la ressource Subscription : incomplete et incomplete_expired. Les abonnements ne passent à l’état incomplete qu’à la première tentative de paiement se soldant par un échec ou lorsque le paiement nécessite une authentification forte (SCA). Tout abonnement qui demeure à l’état incomplete et dont le paiement n’a pu aboutir expire au bout de 23 heures. L’état passe alors automatiquement à incomplete_expired. Une fois qu’un abonnement est passé à l’état active, il ne peut plus repasser à l’état incomplete. Les paiements futurs pour lesquels l’authentification forte (SCA) est requise entraînent le passage de l’abonnement à l’état past_due.

Les abonnements référencent leur dernière facture

Le champ latest_invoice de l’abonnement référence la facture qui affecte l’état de l’abonnement. Cette modification s’ajoute à toutes les versions de l’API.

Toutes les factures utilisent des PaymentIntents pour le paiement

L’API Payment Intents gère le cycle de vie d’un paiement. Elle fournit un nouvel état de paiement requires_action et un nouvel attribut next_action, qui définissent la manière dont est finalisé le paiement (généralement via une redirection vers la banque du titulaire de la carte pour authentification ou bien via une URL intégrée à la réponse). L’objet Invoice possède un champ payments contenant les objets Invoice Payment, qui permettent de fournir les liens entre la facture et le paiement et que vous pouvez utiliser pour gérer le cycle de vie du paiement.

Prise en charge de Stripe.js pour l’API Payment Intents

Puisque les factures Stripe Billing sont totalement compatibles avec l’API Payment Intents, vous bénéficiez des fonctions de l’assistant Stripe.js, qui simplifie la gestion de votre tunnel de paiement. La fonction JavaScript confirmCardPayment vous permet d’afficher un modal 3D Secure pour collecter les informations d’authentification nécessaires à la finalisation du paiement. Cette modification ne vous sera utile que si vous utilisez des PaymentIntents.

Un webhook invoice.payment_action_required est envoyé dès lors qu’une authentification SCA est nécessaire

Lorsqu’une facture nécessite une action de la part du client, Stripe envoie un nouveau webhook invoice.payment_action_required qui contient la facture associée. Ce webhook vient compléter les webhooks invoice.paid et invoice.payment_failed existants. Cette modification s’ajoute à toutes les versions de l’API. Les utilisateurs Stripe Billing qui ne sont pas concernés par la SCA peuvent ignorer ce webhook.

Les abonnements référencent des SetupIntents pour la collecte des authentifications

Les abonnements disposent à présent d’un attribut pending_setup_intent qui référence un SetupIntent. Le SetupIntent peut être utilisé pour recueillir les authentifications lorsque les clients sont en session, optimisant ainsi les paiements hors session. Cette modification s’ajoute à toutes les versions de l’API.

Foire aux questions (FAQ)

• La SCA s’applique-t-elle à mon entreprise ?

  La réglementation relative à l’authentification forte du client (SCA) s’applique aux paiements en ligne lorsque la banque du titulaire de la carte et le prestataire de services de paiement se trouvent tous les deux dans l’Espace économique européen (EEE). Pour en savoir plus, reportez-vous à la page de présentation de l’authentification forte du client.

• Quels sont les moyens de paiement qui nécessitent une authentification SCA ?

  L’authentification SCA s’applique aux paiements en ligne « à l’initiative du client » en Europe. Par conséquent, la plupart des paiements par carte et tous les virements bancaires nécessiteront une authentification SCA. Les principales modifications requises sur le plan de l’intégration concernent les cartes, comme documenté dans ce guide. Les virements bancaires ne nécessiteront pas de modifications d’intégration dans la mesure où c’est à la banque du client qu’il appartient d’authentifier les virements via son interface bancaire en ligne existante.

• Quelles incidences sont à prévoir si je ne mets pas à niveau mon intégration, ou que je ne transmets pas l’indicateur payment_behavior ?

  Les appels nécessaires pour créer ou mettre à jour les abonnements impliquant des paiements soumis à la SCA échoueront avec un code d’erreur HTTP 402. De la même façon, les appels de l’endpoint Régler la facture échoueront eux aussi. Vous risquez par conséquent de voir se multiplier les échecs de paiement.

• Comment puis-je bénéficier du nouveau comportement des abonnements sans mettre à jour ma version des API ?

  Si la mise à jour de la version de vos API n’est pas envisageable, vous pouvez utiliser l’indicateur payment_behavior=allow_incomplete. Puisque les paiements peuvent être initiés lors de la création ou de la mise à jour de l’abonnement, vous devez transmettre cet indicateur à tous les appels de création ou de mise à jour subscription et subscription_item. Voici la liste des endpoints auxquels s’applique cet indicateur :

  • Créer un client
  • Mettre à jour un client
  • Créer un abonnement
  • Mettre à jour un abonnement
  • Mettre à jour un poste d’abonnement

  Pour la création et la mise à jour des clients, l’indicateur payment_behavior n’est pris en charge que lorsque l’abonnement est effectué à l’aide d’une requête API. La création et la mise à jour des abonnements via l’objet Customer ne sont plus documentées, mais les API sont toujours prises en charge pour des raisons de compatibilité.

• Quand des authentifications SCA sont-elles nécessaires et quand pourrais-je compter sur des exemptions ?

  Pour les abonnements, Stripe s’efforce d’optimiser les exemptions sollicités en votre nom. La SCA est systématiquement appliquée pour le premier paiement d’un abonnement lorsque le marchand et le client sont tous les deux situés dans l’EEE. Les paiements suivants peuvent faire l’objet d’exemptions. Pour les factures et paiements ponctuels, Stripe sollicitera des exemptions en votre nom dans toute la mesure du possible.

  Un certain nombre de limites sont à prendre en compte en ce qui concerne les exemptions à la SCA :

  • Même si la situation est susceptible d’évoluer à l’avenir, certaines banques émettrices de cartes ne prennent en charge qu’une partie des catégories d’exemption, voire aucune.
  • La banque émettrice de la carte dispose du droit inconditionnel de contester une demande d’exemption légitime. Elle peut exercer ce doit lorsqu’elle considère qu’une transaction présente des risques élevés.

  Lorsque vous envisagez de mettre à jour votre intégration, prenez toujours en compte la SCA.

• Qu’est-ce que le hors session et quelle est son utilité ?

  Un paiement est dit « hors session » dès lors qu’il intervient sans implication directe du client, au moyen de ses informations de paiement précédemment collectées. Lorsque vous marquez explicitement des transactions comme étant hors session, Stripe est en mesure de solliciter des exemptions en votre nom. Par exemple, l’exemption pour transaction initiée par le marchand (TIM) s’applique uniquement aux paiements hors session. Le fait de solliciter cette exemption réduit la probabilité qu’une authentification SCA soit nécessaire, avec à la clé une moindre complexité pour le client lorsqu’elle est obtenue.

• De quelle façon Stripe distingue-t-il automatiquement les paiements en session et hors session ?

  • Les paiements initiés au moment de la création de l’abonnement sont supposés s’effectuer en session.
  • Les paiements initiés par les systèmes automatisés de Stripe, tels que les paiements pour un abonnement récurrent, sont considérés comme des paiements hors session.
  • Les paiements réalisés avec l’endpoint Régler la facture doivent être explicitement définis comme des paiements en ou hors session à l’aide de l’attribut off_session. Si aucune valeur n’est paramétrée, Stripe utilise la valeur true par défaut.

Historique des révisions du Guide de migration SCA

Les révisions majeures apportées à ce guide sont indiquées ci-après.

15-07-2019

• Ajout de contenu expliquant les SetupIntents et dans quelles situations les utiliser
• Ajout de contenu expliquant la façon dont Stripe distingue automatiquement les paiements en session et hors session
• Ajout de contenu expliquant quand et comment définir off_session sur l’endpoint Régler la facture
• Ajout d’un lien vers une nouvelle carte pour tester la SCA
• Indicateur enable_incomplete_payments renommé payment_behavior
  • payment_behavior peut être défini sur allow_incomplete ou sur error_if_incomplete

15-04-2019

• Publication du contenu initial