SCA et 3D Secure sur les renouvellements d’abonnement : gérer authentication_required

La plupart des renouvellements échoués sont une question d’argent ou de carte : fonds insuffisants, carte expirée, blocage à la banque. Un cas est différent. La carte est valide et l’argent est là, mais la banque veut que le client confirme le paiement. Sur Stripe, cela apparaît sous le code de refus authentication_required, ou comme une facture en attente d’une action du client.

Aucune nouvelle tentative n’y change rien. Le client doit revenir et approuver le paiement. Ce guide explique pourquoi cela arrive, ce que Stripe fait pour vous, et comment faire passer le client rapidement. Il s’appuie sur la documentation de Stripe et sur les règles européennes qui la sous-tendent (sources consultées en novembre 2026).

Ceci n’est pas un conseil juridique. La réglementation des paiements est complexe ; vérifiez votre configuration avec Stripe et, si besoin, un spécialiste.

Pourquoi les renouvellements ont besoin d’authentification

L’authentification forte en bref

L’authentification forte du client (Strong Customer Authentication, SCA) vient de la deuxième directive européenne sur les services de paiement (DSP2). Elle impose aux payeurs d’authentifier les paiements électroniques avec deux facteurs sur trois : quelque chose qu’ils savent, quelque chose qu’ils possèdent, quelque chose qu’ils sont. Pour les cartes, le moyen habituel en ligne est 3D Secure, où la banque affiche une étape de confirmation (un code, une validation dans l’appli, une empreinte).

D’après le guide SCA et le centre d’aide de Stripe, la SCA s’applique quand le prestataire de paiement de l’entreprise et la banque du titulaire sont tous deux dans l’Espace économique européen. La page des exemptions de Stripe couvre aussi le Royaume-Uni et la Suisse. Les paiements dont une partie est hors de la zone (« one leg out ») ne sont pas concernés, même si les banques peuvent quand même demander une authentification.

Paiements récurrents et transactions initiées par le marchand

Un renouvellement d’abonnement a lieu en l’absence du client. Les règles en tiennent compte :

• Les normes techniques européennes, le règlement délégué (UE) 2018/389 de la Commission, imposent la SCA quand un payeur crée, modifie ou initie pour la première fois une série d’opérations récurrentes de même montant et pour le même bénéficiaire. Les paiements suivants de la série peuvent être exemptés (article 14).
• Les paiements par carte que le marchand initie dans le cadre d’un accord avec le client sont traités comme des transactions initiées par le marchand (MIT). La page des exemptions de Stripe explique que la carte doit être authentifiée au moment de son enregistrement, et qu’il vous faut l’accord du client (un mandat) pour la débiter plus tard. Marquer un paiement comme MIT fonctionne à peu près comme demander une exemption.

En principe, une seule authentification à l’inscription couvre donc les renouvellements futurs.

Pourquoi cela échoue quand même

En pratique, la banque émettrice a le dernier mot. Elle peut refuser une exemption ou une MIT et demander quand même une authentification. Les cas courants : un changement de montant (une montée en gamme, une hausse de prix, des frais d’usage), une carte enregistrée sans authentification, ou simplement l’évaluation du risque propre à la banque. Quand cela arrive sur un renouvellement off-session, personne n’est là pour faire 3D Secure, et le paiement échoue.

L’article du support Stripe sur les refus authentication_required ajoute un cas limite : les banques émettrices renvoient parfois authentication_required même sur des paiements déjà passés par 3D Secure. Dans ce cas, le client doit contacter sa banque.

Ce que Stripe fait pour les abonnements

Si vous utilisez Stripe Billing, Stripe gère l’essentiel de la mécanique :

• Les renouvellements sont marqués off-session automatiquement. L’article de Stripe sur on-session et off-session indique que ce marqueur est posé pour vous sur les renouvellements Billing.
• Les cartes enregistrées deviennent des MIT. D’après la page de préparation à la SCA de Stripe, quand une carte est enregistrée via les API Payment Intents ou Setup Intents, les paiements off-session suivants sont marqués comme initiés par le marchand.
• La facture vous dit quand une action est nécessaire. Stripe envoie l’événement invoice.payment_action_required quand le paiement d’une facture demande une action supplémentaire du client. Le guide des webhooks d’abonnement de Stripe indique que votre application doit alors prévenir le client.
• La page de facture hébergée gère 3D Secure. La page de facture hébergée peut lancer le parcours d’authentification sans travail supplémentaire de votre côté.
• Stripe peut envoyer l’email. Dans les réglages des emails clients, vous pouvez demander à Stripe d’envoyer un lien pour que les clients confirment leurs paiements quand leur banque l’exige.

Côté nouvelles tentatives, notez que la page Smart Retries de Stripe range authentication_required parmi les codes de refus définitifs : Stripe ne le retentera pas automatiquement sans action du client.

Les deux formes que cela prend

Signal	Ce que cela veut dire	Que faire
invoice.payment_action_required, PaymentIntent en requires_action	La banque veut 3D Secure pour ce paiement	Envoyer au client le lien de la facture hébergée (ou votre propre page) pour confirmer
Code de refus authentication_required sur invoice.payment_failed	La banque émettrice a refusé et demandé une authentification	Pareil : faire revenir le client on-session pour confirmer ou ressaisir la carte

L’article du support Stripe sur les échecs SCA off-session indique qu’un PaymentIntent off-session échoué peut finir en requires_payment_method plutôt qu’en requires_action. Si vous construisez votre propre page de confirmation, gérez les deux états : soit confirmer le moyen de paiement existant avec 3D Secure, soit recueillir de nouveau un moyen de paiement.

Faire confirmer le client

Le client n’a rien fait de mal, et il ne sait souvent pas ce que veut dire « authentification ». Le message doit être court, calme et précis.

Ce que l’email doit dire

• Objet : « Merci de confirmer votre paiement [Produit] »
• Pourquoi : « Votre banque vous demande de confirmer ce paiement. C’est un contrôle de sécurité standard, pas un problème avec votre carte. »
• Quoi : le montant, l’offre, la date.
• Comment : un seul bouton, « Confirmer le paiement », qui mène directement à la page de confirmation.
• Quand : « Votre abonnement reste actif pendant que vous confirmez. Si nous ne pouvons pas confirmer avant le [date], il sera mis en pause. »

Évitez « votre paiement a échoué » dans l’objet. Ce n’est pas tout à fait vrai, et les clients croient alors qu’il leur faut une nouvelle carte.

Le bon moment

Envoyez le premier message dès que l’événement arrive. Contrairement aux refus temporaires, attendre n’aide pas : la banque ne changera pas d’avis d’elle-même. Un court rappel après deux ou trois jours, puis un dernier avis avant la fin de votre délai de grâce, suffisent. Nos modèles d’emails de relance incluent une variante pour l’authentification.

La page de confirmation

• Fonctionne sur mobile sans connexion (un lien signé).
• Affiche le montant et le produit avant l’étape bancaire.
• Ouvre directement l’étape 3D Secure de la banque.
• Propose « utiliser une autre carte » en solution de repli, pour les clients dont la banque continue de refuser.
• Confirme clairement la réussite, et arrête tous les emails suivants sur invoice.paid.

Réduire les échecs d’authentification

Vous ne pouvez pas les supprimer entièrement, car c’est la banque qui décide. Vous pouvez les rendre plus rares.

1. Authentifier au moment d’enregistrer la carte

Recueillez la carte avec un SetupIntent (ou le premier PaymentIntent) et setup_future_usage réglé pour l’usage off-session, pour que la carte soit authentifiée avec le mandat en place. La doc SetupIntents de Stripe couvre ce point. Stripe Checkout et le Payment Element le font pour vous à l’inscription à un abonnement.

2. Faire reconfirmer quand vous changez l’accord

Montées en gamme, changements de prix et nouveaux add-ons changent le montant. Si possible, faites confirmer le changement au client pendant qu’il est dans votre application, pour que toute authentification se fasse on-session plutôt qu’à 3 h du matin le jour du renouvellement.

3. Attention aux essais gratuits

Si un essai démarre sans prélèvement, assurez-vous que la carte est quand même enregistrée via un SetupIntent avec authentification. Sinon, le premier vrai prélèvement, après l’essai, est la première fois que la banque voit le mandat. Nous traitons les essais dans la conversion de l’essai au payant.

4. Traiter l’Inde à part

L’Inde a ses propres règles de paiements récurrents. La page de Stripe sur les paiements récurrents en Inde explique que les cartes ont besoin d’un e-mandat enregistré avec authentification par facteur supplémentaire, que les clients reçoivent une notification avant débit au moins 24 heures avant chaque prélèvement, et que les prélèvements récurrents au-dessus de 15 000 INR demandent une authentification à chaque fois. Si vous avez des clients indiens, lisez cette page ; cela fonctionne différemment de la SCA.

Mesurer

Suivez l’authentification à part des autres échecs. Elle se comporte différemment et a sa propre solution.

• Demandes d’authentification par mois, par pays de la carte.
• Taux de confirmation : factures avec une demande d’authentification payées dans votre délai de grâce.
• Délai de confirmation : de l’événement à invoice.paid.
• Taux de repli : clients qui ont confirmé en passant plutôt à une nouvelle carte.

Si le taux de confirmation est faible, regardez d’abord l’email (objet, clarté, bouton unique), puis la page sur mobile.

Check-list

• Les cartes sont enregistrées avec une authentification off-session à l’inscription.
• invoice.payment_action_required et authentication_required déclenchent tous deux un email de confirmation.
• Les emails « confirmer le paiement » de Stripe sont activés, ou vos propres emails les remplacent (pas les deux).
• La page de confirmation fonctionne sur mobile sans mot de passe.
• Les changements de prix et les montées en gamme sont confirmés on-session quand c’est possible.
• Les emails s’arrêtent dès que la facture est payée.
• L’authentification est suivie comme une catégorie à part.
• Les clients indiens sont gérés selon les règles de l’e-mandat.

Comment NoChurn aide

NoChurn traite les demandes d’authentification comme un cas à part. Quand un renouvellement demande une confirmation, il évite les nouvelles tentatives inutiles et envoie un email de récupération rédigé par l’IA, relu avant l’envoi et dans la langue du client, qui explique que la banque demande une confirmation rapide, avec un lien pour confirmer le paiement et une page hébergée de mise à jour de carte en solution de repli. Les données de carte restent chez Stripe.

Il se connecte à Stripe en un clic, ou fonctionne par API avec votre propre facturation. Le prix ne dépend que du MRR, jamais du revenu récupéré. Voir paiements échoués et tarifs.