PSD3 et PSR : ce que les marchands doivent vraiment changer

Sous PSD2, les règles de conduite au quotidien — délais de remboursement, responsabilité en cas de fraude, gestion des réclamations — étaient fixées par une directive. Les directives ne s'appliquent pas directement. Chacun des 27 États membres a dû transposer PSD2 dans son droit national, chacun avec son propre calendrier, ses propres lacunes et sa propre interprétation locale. Un marchand opérant dans cinq pays de l'UE se trouvait, en pratique, soumis à cinq réglementations légèrement différentes, même si toutes prétendaient mettre en œuvre « la même » directive.

Le nouveau paquet répartit le travail différemment. PSD3 reste une directive et couvre principalement l'agrément, la supervision et l'accès au marché des établissements de paiement — ce qui concerne le statut réglementaire de votre PSP, pas votre parcours de paiement. Les règles de conduite qui touchent réellement les marchands — responsabilité en cas de fraude, obligations de remboursement, exigences d'authentification, gestion des réclamations — basculent dans le PSR, un règlement. Les règlements s'appliquent directement et de façon identique dans chaque État membre, sans étape de transposition nationale ni marge pour des particularités de rédaction locales.

Selon les analyses juridiques des textes convenus, il s'agit d'une réponse délibérée au problème de fragmentation créé par PSD2 — le PSR est conçu pour donner aux marchands et aux PSP un référentiel de règles unique plutôt que 27 variantes locales (l'analyse des textes convenus par Freshfields). Pour les marchands, cela signifie que la revue de conformité que vous menez pour votre entité allemande devrait, une fois le PSR applicable, produire les mêmes réponses que la revue pour votre entité irlandaise ou portugaise. C'est une réelle simplification, mais cela signifie aussi qu'il n'y a plus d'argument du type « le régulateur local est souple sur ce point » sur lequel se rabattre.

Les règles de responsabilité de PSD2 s'appuyaient sur une notion assez étroite de transaction « non autorisée » — c'est-à-dire une transaction que le client n'avait pas approuvée. La fraude a évolué depuis. Les escroqueries par ingénierie sociale, où un fraudeur se fait passer pour un employé de banque ou convainc un client d'autoriser lui-même un virement, produisent techniquement une transaction « autorisée » selon l'ancien cadre, ce qui laissait historiquement le client (et, par extension, le marchand qui dépendait de ce paiement) avec moins de recours.

Le PSR étend la responsabilité dans plusieurs directions qui concernent les marchands :

• La fraude par usurpation d'identité — lorsqu'un fraudeur se fait passer pour le personnel ou la marque d'un PSP — transfère davantage de responsabilité vers les prestataires de services de paiement, plutôt que de laisser le client absorber la perte.
• Le défaut de proposer ou d'appliquer correctement l'authentification forte du client (SCA) fait peser la responsabilité sur la partie de la chaîne qui a échoué à l'appliquer correctement, ce qui inclut les acquéreurs et, dans certains parcours, les marchands qui contournent l'authentification.
• Un traitement lent des signalements de fraude par un PSP peut lui-même engendrer une responsabilité, ce qui vise à inciter les banques et les PSP à traiter les signalements de fraude plus rapidement plutôt que de traiter chaque réclamation comme une longue enquête.

Pour un marchand, l'effet concret est que les litiges liés à la fraude reposeront de plus en plus sur des preuves de ce qui s'est passé pendant l'authentification, et non plus seulement sur l'affirmation du client selon laquelle il n'a pas autorisé le paiement. Vos journaux d'authentification et vos données de résultat SCA deviennent ainsi des éléments de preuve dans vos litiges, et non plus un simple enregistrement de conformité conservé puis oublié.

L'un des changements les plus concrets pour les parcours de paiement concerne la vérification que le nom associé à un compte correspond bien à la personne à qui le payeur pense envoyer de l'argent. Cela s'appuie sur le mécanisme de vérification du bénéficiaire (VoP, Verification of Payee) déjà exigé pour les virements instantanés en vertu du règlement européen sur les paiements instantanés, et le nouveau paquet sur les paiements étend cette logique à d'autres services de paiement.

En pratique, la VoP signifie que la banque du payeur vérifie le nom du titulaire du compte par rapport à l'IBAN avant qu'un virement ne soit finalisé, et signale une discordance — « aucune correspondance » ou « correspondance partielle » — au payeur avant qu'il ne confirme le paiement. Cette mesure vise directement la fraude par virement autorisé mais détourné, où un client est incité à transférer de l'argent vers un compte qui n'appartient pas à qui il croit.

Pour les marchands, cela concerne tout parcours où un client initie un virement bancaire pour vous payer — moyens de paiement de compte à compte, paiements initiés via l'open banking, ou toute étape de paiement où vous affichez vos propres coordonnées bancaires pour qu'un client réalise un virement :

• Le nom légal enregistré sur votre compte bancaire marchand doit correspondre exactement au nom commercial que voient les clients sur votre page de paiement, sous peine de voir apparaître des avertissements de discordance qui ressemblent à des signaux de fraude alors que tout est normal.
• Si vous opérez sous un nom commercial différent du nom de votre entité légale, c'est le moment soit de les aligner, soit de vous assurer que votre parcours de paiement explique clairement cette différence avant qu'un client ne reçoive un avertissement VoP en plein paiement.
• Toute documentation interne répertoriant les coordonnées de votre compte de règlement à des fins de rapprochement comptable doit être vérifiée par rapport à ce qui est réellement enregistré auprès de votre banque, car un enregistrement obsolète apparaîtra comme une discordance pour chaque client utilisant un moyen de paiement basé sur le virement.

C'est un cas où une vérification administrative de cinq minutes — confirmer que le nom enregistré de votre compte bancaire correspond à l'image de marque de votre boutique — évite une vague de confusion côté client une fois les contrôles de type VoP largement en vigueur.

PSD2 offrait aux banques gestionnaires de comptes deux options pour exposer les données de compte à des tiers : une API dédiée, ou une interface de secours construite sur leurs écrans de banque en ligne existants destinés aux clients. En pratique, les interfaces de secours étaient souvent plus lentes, moins fiables et entretenues de façon inégale, ce qui rendait les parcours de paiement basés sur l'open banking — options de paiement par virement direct, informations de compte pour l'évaluation du risque, et fonctionnalités similaires — moins fiables que les paiements par carte.

Le nouveau cadre renforce cela. Les banques seront soumises à des obligations plus claires et plus contraignantes concernant la performance de leurs interfaces dédiées — se rapprochant de la fiabilité de leurs propres canaux destinés aux clients, avec des attentes définies en matière de disponibilité et de temps de réponse, plutôt que la norme de « moyens raisonnables » faiblement appliquée qui caractérisait certaines parties de la mise en œuvre de PSD2 (l'analyse de MoFo sur les développements PSD3/PSR).

Pour les marchands qui proposent ou envisagent des options de paiement par virement direct ou de compte à compte, cela compte de deux façons :

• Moins de tentatives d'autorisation échouées ou expirées devrait signifier moins de paniers abandonnés sur les moyens de paiement basés sur le virement, qui affichaient historiquement des taux de complétion inférieurs à ceux des cartes, en partie à cause de la fiabilité des interfaces.
• Si vous vous appuyez sur des services d'information sur les comptes pour vos décisions de risque — vérifier la propriété d'un compte ou consulter des soldes avant d'expédier des commandes de valeur élevée — ces flux de données devraient devenir plus cohérents, permettant de construire vos processus autour d'eux plutôt que de devoir développer une logique de nouvelle tentative et de gestion des échecs.

Rien de tout cela ne dispense de tester votre intégration face au comportement réel des banques une fois les règles en vigueur. Cela signifie simplement que le niveau de fiabilité de référence que vous testez devrait s'améliorer.

C'est la partie qui est généralement absente des résumés juridiques. Voici ce qui évolue de votre côté.

Vos contrats PSP et acquéreur. Passez en revue les clauses de répartition de responsabilité de vos contrats de services de paiement existants. Sous les contrats de l'ère PSD2, les clauses de responsabilité supposaient souvent l'ancienne définition, plus étroite, de « transaction non autorisée » et les anciennes règles d'exemption SCA. Une fois les dispositions de responsabilité du PSR applicables, les contrats non mis à jour risquent de faire référence à des normes qui ne correspondent plus à la loi, ce qui crée une ambiguïté précisément au moment où vous avez besoin de clarté — en plein litige. Demandez directement à votre PSP si ses conditions marchand standard seront mises à jour pour refléter la répartition de responsabilité du PSR, et obtenez la réponse par écrit plutôt que de supposer que c'est déjà réglé.

• Votre parcours de paiement. Trois changements concrets à vérifier :
• Confirmez que le nom légal associé à votre compte de règlement correspond à l'image de marque de votre boutique, afin d'éviter des avertissements de discordance VoP inutiles sur les moyens de paiement basés sur le virement.
• Assurez-vous que votre parcours de défi SCA (3DS ou équivalent) se dégrade correctement — un client qui abandonne un achat parce qu'une étape d'authentification a échoué techniquement, plutôt que parce qu'il l'a refusée, est exactement le scénario que les nouvelles règles de responsabilité visent à identifier, et vous ne voulez pas être du mauvais côté lorsqu'un litige est examiné.
• Si vous proposez le paiement par virement direct ou d'autres options de compte à compte, prévoyez de retester les taux de complétion une fois les nouvelles obligations de performance des API en vigueur — les hypothèses de fiabilité sur lesquelles vous avez construit votre logique de secours pourraient ne plus être la contrainte déterminante.

• Votre processus de litige. Les preuves qui déterminent l'issue d'un litige lié à la fraude ou à un chargeback évoluent. Alors que les litiges de l'ère PSD2 portaient souvent sur la simple question de savoir si la SCA avait été appliquée, les litiges de l'ère PSR porteront plus souvent sur la façon dont elle a été appliquée, sur le fait qu'un contrôle VoP a bien eu lieu et sur le résultat qu'il a renvoyé, ainsi que sur la rapidité avec laquelle un signalement de fraude a été escaladé. Cela implique :
• Votre équipe support doit avoir accès aux journaux de résultats d'authentification, et pas seulement au statut de la transaction, lorsqu'elle répond à un litige.
• Votre documentation de soumission de preuves doit être mise à jour pour inclure les résultats de correspondance/discordance VoP comme un champ standard, une fois que ces données existent dans vos enregistrements de transaction.
• Les SLA internes pour escalader les signalements de fraude suspectée vers votre PSP doivent se resserrer, car le délai devient lui-même un facteur de responsabilité plutôt qu'une simple étape administrative neutre.

Le passage de PSD2 au PSR concerne moins l'apparition de nouvelles obligations surgies de nulle part que la fermeture de lacunes existantes.

Les marchands qui traitaient la responsabilité en cas de fraude, la SCA et les preuves de litige comme « ce que dit la banque locale » constateront que cette réponse ne tient plus une fois qu'un même texte réglementaire s'applique dans chaque État membre. Le travail est administratif — mettre à jour les contrats, les textes du parcours de paiement et les modèles de preuve — mais il doit être fait avant l'application générale, pas après qu'un premier litige sous les nouvelles règles n'ait mis la lacune en évidence.

Rien de tout cela n'exige de refaire entièrement votre parcours de paiement. Cela exige de traiter votre contrat PSP, les coordonnées de votre compte enregistré et vos modèles de preuve de litige comme des documents vivants nécessitant une revue selon un calendrier précis — c'est l'objet de la liste de contrôle ci-dessous.

La date exacte d'application générale dépend de la date à laquelle le Journal officiel publiera le texte final, mais l'enchaînement des étapes, lui, est fixé. Utilisez ceci comme un calendrier de travail plutôt qu'une échéance figée, et confirmez les dates une fois la publication au Journal officiel confirmée.

• D'ici le T4 2026 — La publication au Journal officiel est attendue (juin-juillet 2026). Une fois publiée, calculez votre date ferme d'application générale à 21 mois et inscrivez-la à votre calendrier de conformité. Lancez la revue de vos contrats PSP dès maintenant plutôt que d'attendre l'échéance.
• Au cours de 2027 — Confirmez auprès de votre PSP son plan de mise à jour des conditions marchand pour refléter la répartition de responsabilité du PSR. Vérifiez que le nom légal enregistré de votre compte de règlement correspond à l'image de marque de votre parcours de paiement. Cartographiez quels parcours de paiement utilisent la SCA et documentez la logique d'exemption actuelle afin de pouvoir la comparer aux exigences finalisées du PSR.
• Début 2028 — Testez l'ensemble de votre processus de preuve de litige de bout en bout : votre équipe support peut-elle réellement récupérer les résultats SCA et VoP d'une transaction sur demande, ou cela nécessite-t-il un ticket auprès des équipes techniques ? Corrigez cette lacune avant qu'elle ne soit testée par un litige réel.
• À l'application générale (estimée mars-avril 2028) — Confirmez que les contrats PSP mis à jour sont signés, que les textes du parcours de paiement reflètent toute exigence relative au nom du bénéficiaire, et que votre documentation de litige inclut les nouveaux champs de preuve. Considérez la date d'application générale comme le moment où tout ce qui précède doit déjà fonctionner, pas comme le point de départ.

Cost+ fonctionne sur une tarification IC++ (Interchange Plus Plus) précisément parce que nous pensons que les marchands prennent de meilleures décisions lorsque les composantes d'un paiement — interchange, scheme fee, et notre marge — sont visibles plutôt que regroupées. Le même principe s'applique aux évolutions réglementaires : plus tôt vous voyez ce qui change réellement en matière de responsabilité et d'exigences de preuve, moins la transition est perturbatrice. Si vous souhaitez discuter de la façon dont votre parcours de paiement et votre dispositif de gestion des litiges actuels se positionnent par rapport au calendrier du PSR, contactez notre équipe ou comparez votre structure de frais actuelle avec la tarification low-risk publiée sur notre site pendant que vous révisez vos contrats.