Qui veut la peau des paiements récurrents ?
Rédigé par Thomas Bahon
DSP2, 3D Secure et les dessous d’un modèle sous pression
Les paiements récurrents par carte ont longtemps été la partie invisible de l’iceberg des abonnements. Discrets, efficaces, quasi-automatiques. La DSP2 a changé ça. Mais pas seulement en corrigeant des dérives : en remettant en cause, plus profondément, la mécanique sur laquelle repose tout un modèle économique.
La fin du « bon vieux temps »
Pendant longtemps, les paiements récurrents ont constitué un levier de croissance aussi discret qu’efficace pour de nombreux acteurs du numérique. Abonnements médias, services SaaS, plateformes de contenus ou encore services du quotidien : tous ont largement bénéficié de la simplicité d’activation et de la fluidité des prélèvements par carte.
Mais derrière cette apparente simplicité se cachaient des pratiques parfois contestables, voire abusives, et des contournements techniques progressivement devenus la norme. C’est dans ce contexte que la DSP2 est venue s’imposer, avec une ambition claire : redonner le contrôle au porteur et sécuriser les paiements.
La promesse était simple : plus de transparence, plus de sécurité, moins d’abus. La réalité, elle, s’est révélée plus nuancée. Car en cherchant à encadrer des pratiques hétérogènes et parfois mal maîtrisées, le régulateur a aussi profondément complexifié la gestion des paiements récurrents. Marchands, prestataires et banques ont dû adapter en urgence leurs systèmes à des exigences nouvelles, souvent interprétées de manière variable, et parfois difficilement compatibles avec la réalité opérationnelle du commerce.
Dès lors, une question s’impose : la DSP2 a-t-elle simplement assaini le marché… ou est-elle en train de fragiliser, plus profondément, le modèle même des paiements récurrents ?
DSP2 : surtout la fin des dérives… et des raccourcis
La transposition de la DSP2 (Directive sur les Services de Paiement) dans les législations européennes est venue mettre un coup d’arrêt à un certain nombre de pratiques devenues, avec le temps, aussi répandues que problématiques autour des paiements initiés par le marchand (MIT).
Les dérives étaient d’abord commerciales. Certains prélèvements étaient effectués sans réel consentement du porteur, ou dans des conditions de transparence limitées, rendant la facturation difficile à comprendre, parfois à la frontière de l’escroquerie. Mais les abus étaient aussi techniques, notamment dans l’univers du paiement par carte. Même avec l’accord du client, les paiements récurrents servaient souvent de substitut au paiement « en un clic », évitant la ressaisie du CVV/CVC. D’autres contournements consistaient à qualifier des transactions Internet comme des paiements « MOTO » pour échapper à des contrôles plus stricts. Dans les cas les plus extrêmes, certaines transactions pouvaient même être envoyées directement en compensation sans véritable demande d’autorisation, en exploitant des systèmes encore imparfaitement synchronisés.
La DSP2 a mis fin à ces pratiques. Mais, comme souvent lorsqu’un cadre réglementaire interrompt des usages bien installés, les conséquences ont été loin d’être neutres.
De nombreux acteurs, dont le modèle repose sur l’abonnement ou sur des flux de type MOTO, ont vu leur activité fortement impactée. La mise en conformité, malgré les périodes de tolérance, s’est révélée complexe, en raison d’une double sous-estimation : celle de la diversité des cas d’usage et celle de la difficulté à les traduire en règles opérationnelles et en solutions techniques adaptées.
Autrement dit, la DSP2 n’a pas seulement supprimé des abus : elle a aussi supprimé des raccourcis techniques largement utilisés.
Une régulation face à la réalité du commerce
Les exemples sont nombreux, mais ils illustrent tous une même difficulté : celle d’adapter un cadre réglementaire structuré à la réalité, beaucoup plus mouvante, des modèles commerciaux.
Face à la diversité des situations rencontrées, régulateurs et réseaux de paiement ont progressivement multiplié les cas d’usage : « abonnement à durée et montant fixes », « paiement fractionné », puis des variantes par réseau comme « abonnement à durée OU montant fixe » de MasterCard ou le « paiement à l’expédition » de CB en France. Une segmentation minutieuse. Résultat : les marchands ont massivement opté pour la case fourre-tout, l’UCOF, ou paiement sans montant ni durée définis.
Ce choix n’est pas anodin. Il est même révélateur. Il traduit une réalité simple : pour les commerçants, le paiement n’est pas une finalité, mais la dernière étape d’un processus souvent complexe. Sourcing, logistique, offres packagées, services additionnels, promotions, périodes gratuites, tarification dynamique : autant de variables qui rendent difficile l’application de cadres rigides. C’est précisément là que la tension apparaît. Là où le régulateur cherche à structurer, catégoriser et sécuriser, le marchand cherche à simplifier, fluidifier et adapter en permanence. Le paiement, censé être un point de passage discret, risque alors de se transformer en une véritable « gare de triage », où chaque flux doit être orienté vers le bon « rail » réglementaire, au risque de complexifier inutilement l’expérience et, à terme, de fragiliser l’ensemble du parcours.
Le casse-tête opérationnel côté marchands
Côté marchands et prestataires, l’un des principaux points de friction introduits par la DSP2 a concerné la gestion du 3D Secure, et plus précisément la manière dont l’authentification forte devait être appliquée aux transactions initiées par le client (CIT).
En apparence, le message était simple : le 3DS devenait la norme, avec la possibilité de recourir à des exemptions, et, en cas de doute, l’émetteur conservait le dernier mot sur l’application ou non d’un challenge. Dans ce nouveau paradigme, le marchand pouvait influencer la décision, sans en être systématiquement à l’origine.
Mais cette logique générale s’est retrouvée en contradiction avec une exigence beaucoup plus spécifique : celle applicable aux paiements récurrents. Dans ce cadre, toute transaction CIT servant à initier une série de paiements récurrents doit obligatoirement faire l’objet d’un challenge explicitement demandé par le marchand. Cette authentification initiale n’est pas une option : elle conditionne la légitimité de l’ensemble des transactions MIT qui en découleront.
C’est précisément ici qu’un télescopage s’est opéré. D’un côté, les marchands ont intégré, parfois à juste titre, qu’une CIT pouvait faire l’objet d’une exemption, voire qu’il suffisait de ne rien demander et de laisser l’émetteur décider. De l’autre, le cas particulier des paiements récurrents imposait une logique inverse, où la responsabilité du déclenchement du challenge reposait explicitement sur le marchand.
Deux lectures, deux pratiques, mais un même objet : la CIT.
Cette superposition de règles, appliquées à des cas d’usage différents mais techniquement proches, a généré des incompréhensions fréquentes et des implémentations parfois non conformes. Elle illustre plus largement la difficulté à concilier une approche générique de l’authentification avec des exigences spécifiques liées à certains modèles économiques, au premier rang desquels les paiements récurrents.
Le chaînage des transactions : une complexité sous-estimée
Le chaînage des transactions constitue un autre point de complexité majeur dans la mise en œuvre des paiements récurrents sous DSP2. Sur le principe, la règle est simple : toute transaction initiée par le marchand (MIT) doit être reliée à une transaction initiale réalisée par le client (CIT), afin de justifier la légitimité des prélèvements successifs.
Dans la pratique, cette règle recouvre une réalité plus complexe.
Chaque paiement repose en effet sur deux références distinctes : celle de la transaction CIT initiale, nécessaire pour attester du consentement du porteur, et celle de la transaction MIT elle-même, qui constitue la référence opérationnelle du paiement en cours.
Cette dualité introduit une subtilité souvent sous-estimée. Si le lien avec la CIT est bien pris en compte au moment de l’autorisation, c’est lors de la capture que les deux logiques doivent être réunies : la conformité, en se rattachant à la transaction initiale, et l’opérationnel, en s’appuyant sur l’identifiant propre à la MIT.
Or, dans de nombreux cas, l’attention s’est principalement portée sur la conformité à l’étape d’autorisation, sans toujours intégrer correctement cette exigence au moment de la capture.
Dit autrement, la conformité se joue dès l’autorisation, mais la cohérence du système se joue jusqu’à la capture.
Ce double référentiel, réglementaire et technique, applicable quel que soit le cas d’usage, a été largement sous-estimé dans les premières phases de mise en conformité, alors même qu’il constitue un point structurant dans la fiabilité des implémentations.
Quand les banques compliquent encore le jeu
À ces complexités côté marchands se sont ajoutées, dans certains cas, des difficultés liées aux implémentations des banques émettrices elles-mêmes.
Certaines décisions, parfois liées à des interprétations spécifiques ou à des implémentations incomplètes, ont pu avoir des effets particulièrement contre-productifs sur les paiements récurrents.
Un cas résume bien l’absurdité possible du système. Durant la période de mise en conformité, une banque émettrice irlandaise ignorait les demandes de challenge formulées par les marchands, avant de rejeter les autorisations au motif que ce challenge n’avait pas été effectué.
Autrement dit, une transaction pouvait être refusée pour une condition que l’émetteur lui-même avait contribué à ne pas respecter.
Ce type de situation illustre les limites d’une chaîne de paiement où les responsabilités sont partagées, mais où les interprétations et les implémentations peuvent diverger. Il rappelle également que, au-delà du cadre réglementaire, la cohérence de son application reste un enjeu tout aussi critique.
Abonnements vs UCOF : la fausse simplicité
En pratique, les évolutions introduites par la DSP2 n’ont pas fondamentalement transformé la nature des paiements récurrents, mais elles en ont considérablement accru les contraintes. La mise en œuvre de modèles d’abonnement « encadrés » impose désormais de fournir un certain nombre d’informations structurantes : date de fin, fréquence, montant, voire nombre total d’occurrences ou position dans la série. Des exigences qui fonctionnent bien pour les cas simples, et qui coincent précisément là où les modèles commerciaux sont les plus dynamiques.
Lexique des termes et acronymes
DSP2 (Directive sur les Services de Paiement 2) Directive européenne (UE) 2015/2366, entrée en application en septembre 2019. Elle encadre les services de paiement au sein de l’Union européenne, renforce la sécurité des transactions via l’authentification forte (SCA) et ouvre l’accès aux comptes aux prestataires tiers (open banking).
DSP3 (Directive sur les Services de Paiement 3) Révision en cours de la DSP2, proposée par la Commission européenne en juin 2023. Elle vise à harmoniser l’application des règles entre États membres, à corriger les ambiguïtés laissées par la DSP2 et à mieux encadrer les nouveaux acteurs du paiement.
CIT (Customer Initiated Transaction)
Transaction initiée par le client, généralement lors d’un paiement en ligne classique. Dans le cadre des paiements récurrents, la CIT initiale sert à établir le consentement du porteur.
MIT (Merchant Initiated Transaction)
Transaction initiée par le marchand, sans action directe du client au moment du paiement. Utilisée notamment pour les prélèvements récurrents ou différés.
3D Secure (3DS)
Protocole d’authentification forte permettant de vérifier l’identité du porteur (via code, application bancaire, biométrie…). Il peut donner lieu à un challenge ou être contourné via des exemptions.
SCA (Strong Customer Authentication)
Exigence réglementaire introduite par la DSP2 imposant une authentification forte du porteur, reposant sur au moins deux facteurs (connaissance, possession, inhérence).
Challenge (3DS Challenge)
Étape d’authentification active dans le processus 3DS, où le client doit valider son identité. Dans certains cas, notamment pour les paiements récurrents, ce challenge doit être explicitement demandé par le marchand lors de la transaction initiale.
Exemption (3DS Exemption)
Possibilité de ne pas déclencher d’authentification forte dans certains cas (faible montant, faible risque, transactions récurrentes, etc.), sous réserve d’acceptation par la banque émettrice.
UCOF – Unscheduled Card on File
Paiement effectué à partir d’une carte enregistrée, sans montant ni fréquence prédéfinis. Utilisé pour des facturations irrégulières ou flexibles.
MOTO (Mail Order / Telephone Order)
Transactions initiées à distance (courrier ou téléphone), historiquement exclues du 3DS. Par extension, certaines transactions en ligne ont été identifiées à tort de MOTO pour contourner les contrôles.
COF (Card-on-file)
Stockage des données de carte par un marchand ou un prestataire, permettant des paiements ultérieurs sans ressaisie des informations par le client.
Scheme (réseau de paiement)
Réseau de cartes (Visa, Mastercard, etc.) définissant les règles de fonctionnement des transactions, en complément du cadre réglementaire.
Acquéreur (Acquirer)
Banque ou prestataire qui traite les paiements pour le compte du marchand.
Émetteur (Issuer)
Banque du porteur de la carte, responsable notamment de l’autorisation des transactions et de l’application des règles d’authentification.
R2P (Request-to-Pay)
Mécanisme permettant à un marchand d’envoyer une demande de paiement au client, que celui-ci accepte ou refuse. Repose sur une logique de paiement initié par le client.
R0 / R1 / R3 (codes de rejet)
Codes utilisés pour signaler le rejet de paiements récurrents. R0 désigne l’arrêt d’une série spécifique. R1 et R3 désignent un arrêt plus global des prélèvements liés à un porteur.
Unclaimed subscription
Abonnement actif mais peu ou pas utilisé par le client, générant des revenus récurrents sans usage réel.
Les périodes d’essai gratuites, les suspensions d’abonnement, les ajustements en cours de contrat ou encore les modèles hybrides combinant abonnement et consommation viennent rapidement mettre en défaut ces cadres trop rigides. Dans certains cas, cela conduit même à dissocier artificiellement une offre en plusieurs flux de facturation distincts.
Dans ce contexte, le recours à l’UCOF (Unscheduled Card on File) s’est imposé comme une alternative séduisante. Plus souple, il permet de gérer plus facilement des situations évolutives : prolongation d’un abonnement, facturation irrégulière ou ajustements ponctuels.
Cette simplicité est toutefois relative, voire trompeuse.
D’une part, certains réseaux ont tenté d’introduire des modèles intermédiaires, comme MasterCard, qui autorise une variation encadrée du montant ou de la fréquence, sans que ces initiatives soient réellement harmonisées à l’échelle des schemes. En pratique, il est difficilement envisageable pour un marchand d’adapter ses offres en fonction de la marque de la carte utilisée. D’autre part, l’UCOF s’accompagne lui aussi de contraintes spécifiques, notamment en matière d’information du porteur. Par exemple, certaines règles imposent d’avertir le client avant un nouveau prélèvement après une longue période d’inactivité. Des obligations qui, parce qu’elles interviennent en dehors de l’acte de paiement lui-même, sont plus difficiles à contrôler et à automatiser.
Ainsi, ce qui apparaissait initialement comme une solution de simplification s’avère en réalité porteur de nouvelles complexités. Et pour les acteurs gérant plusieurs abonnements pour un même client, comme les agrégateurs de contenus, ces choix structurants ne sont pas sans conséquences à moyen terme.
Rejets et effets de bord : un risque systémique sous-estimé
L’introduction de nouveaux codes de rejet et l’évolution des règles de gestion associées ont également apporté leur lot de complexité dans l’univers des paiements récurrents.
Parmi ces évolutions, certains codes permettent désormais de distinguer des situations pourtant très différentes : le rejet de l’ensemble des prélèvements liés à un porteur (R1, voire R3 dans les cas les plus radicaux), et le rejet d’une série de paiements spécifique (R0). La granularité de ces codes est réelle. Elle permet, en théorie, d’aligner plus finement l’instruction donnée par le porteur avec son intention réelle : mettre fin à un abonnement précis sans impacter les autres engagements en cours.
Dans la pratique, la réalité est plus incertaine.
Faute de visibilité complète sur l’usage effectif de ces codes, on peut légitimement s’interroger sur leur bonne application. La gestion est-elle réellement différenciée, ou tend-elle à privilégier des approches plus globales, voire brutales, à travers des codes comme le R3 ?
Pour les acteurs gérant plusieurs abonnements pour un même porteur, l’enjeu est loin d’être anecdotique. L’arrêt d’un abonnement, en dehors de tout processus commercial maîtrisé par le marchand, peut entraîner la suspension de l’ensemble des prélèvements, avec des conséquences parfois mal comprises, y compris par le porteur lui-même.
Dans ce contexte, le rôle de la banque émettrice devient déterminant. C’est elle qui reçoit et interprète l’instruction du porteur, et qui décide, in fine, du niveau de granularité appliqué. Encore faut-il que cette instruction soit correctement comprise… et correctement traduite en code opérationnel. Le sujet n’est pas encore clairement soulevé, sans doute parce que les implications sont inconfortables pour tout le monde et qu’il révèle un risque plus large : celui d’effets de bord systémiques, où des mécanismes conçus pour mieux protéger le porteur peuvent, en pratique, produire des résultats contre-intuitifs.
Des alternatives encore marginales
Face à ces complexités, certaines solutions alternatives émergent, à l’image du SEPA Request-to-Pay.
Ce dispositif propose une approche différente, fondée sur des paiements initiés par le client (CIT), déclenchés à partir d’une demande envoyée par le marchand. Il introduit ainsi un scénario plus explicite et potentiellement plus conforme à l’esprit de la DSP2, en redonnant au porteur un rôle actif dans l’exécution du paiement.
Pour autant, ce modèle reste aujourd’hui cantonné à des cas d’usage bien spécifiques. Il semble davantage adapté à des contextes où la relation de paiement est déjà structurée et régulière, comme les services publics, la facturation de commodités (eau, électricité, gaz), les assurances, la téléphonie ou l’accès à Internet, qu’à des abonnements de consommation plus spontanés ou à faible engagement.
En pratique, il ne constitue donc pas, à ce stade, une alternative généralisable aux modèles d’abonnement actuels, mais plutôt une réponse complémentaire, pertinente dans des environnements bien identifiés.
Ce qui confirme que, pour l’instant, le modèle « paiement par carte » reste dominant malgré ses contraintes.
Le vrai sujet : la remise en cause du modèle économique
Au-delà des aspects techniques et opérationnels, la transformation des paiements récurrents pose une question plus fondamentale : celle du modèle économique des abonnements.
En cherchant à mieux protéger le consommateur, le régulateur s’attaque indirectement à une source de revenus particulièrement rentable pour de nombreux acteurs : les abonnements peu ou pas utilisés, parfois qualifiés d’unclaimed subscriptions.
Ces abonnements « oubliés », qu’il s’agisse de services numériques, de contenus ou d’offres de télécommunication, génèrent des revenus récurrents significatifs, souvent décorrélés de l’usage réel. Leur remise en cause n’est donc pas neutre.
Selon l’étude Subscription Services Study de 2022 menée par C+R Research, la proportion d’abonnements oubliés varie de 6 % dans le jeu vidéo à près de 30 % dans les services de téléphonie ou d’accès à Internet.
Dans ce contexte, le durcissement des règles encadrant les paiements récurrents peut être interprété comme une tentative de rééquilibrage en faveur du consommateur. Mais il soulève également une question plus délicate : jusqu’où peut-on réguler sans fragiliser un modèle économique devenu central dans de nombreux secteurs ?
La question est d’autant plus sensible qu’elle s’inscrit dans un environnement où les principaux acteurs des solutions de paiements récurrents sont, pour une large part, extra-européens, qu’il s’agisse de Stripe, Paypal ou le spécialiste du genre Recurly. Même Adyen, souvent perçu comme une exception européenne, présente une structure de capital partiellement internationalisée.
Dès lors, difficile d’écarter totalement l’hypothèse selon laquelle certaines orientations réglementaires puissent également s’inscrire dans une logique plus large, mêlant protection du consommateur, souveraineté économique et rééquilibrage des rapports de force.
Réguler, simplifier… ou transformer ?
En quelques années, les paiements récurrents sont passés d’un modèle discret et permissif à un environnement fragmenté, exigeant, et désormais sous surveillance permanente.
La DSP2 a corrigé des dérives réelles, commerciales et techniques. Mais en cherchant à encadrer les pires pratiques, elle a imposé à l’ensemble de l’écosystème une complexité qui dépasse largement le périmètre des abus qu’elle visait. Les acteurs les plus sérieux ne sont pas épargnés. Et ceux qui tiraient profit de l’inertie de leurs abonnés n’ont pas tous disparu : ils se sont adaptés.
Ce que la DSP2 a surtout changé, c’est le coût de faire tourner un modèle par abonnement. Authentification initiale, chaînage des transactions, gestion des rejets, arbitrages entre cas d’usage : chaque étape est devenue un point de friction supplémentaire, une source d’erreur potentielle, un risque opérationnel à gérer. Pour les grands acteurs, c’est absorbable. Pour les autres, c’est une charge structurelle.
Les travaux autour de la DSP3 témoignent d’une volonté d’harmoniser ce que la DSP2 a fragmenté. Nécessaire, mais pas suffisant si le cadre continue de produire des règles génériques face à des modèles qui ne le sont pas.
Dans un environnement où chaque transaction doit être justifiée, tracée et comprise, les paiements récurrents ne peuvent plus se contenter d’être invisibles. Ce qui est en jeu, ce n’est pas seulement la conformité : c’est la viabilité d’un modèle économique pour ceux qui n’ont pas les moyens d’en absorber indéfiniment le coût.