Sur cette mission, mon rôle était de piloter le changement de PSP d’un e-commerçant européen de la beauté, présent dans une vingtaine de pays, sans toucher au parcours de ses clients.  

La migration a aussi été l’occasion d’élargir l’offre de paiement : en partant des moyens existants, principalement la carte, nous avons activé près d’une dizaine de nouveaux moyens selon les pays. Le projet arrivait toutefois à un moment délicat.  

Le tunnel de commande venait d’être refondu et n’était pas encore stabilisé. Le connecteur de paiement, très personnalisé au fil des années, demandait beaucoup de maintenance et cassait au moindre changement. Sur un site présent dans de nombreux pays européens, cela se traduisait par des incidents de paiement et des ventes perdues. 

L’objectif principal était de maintenir le taux de conversion. C’est, pour moi, le vrai enjeu d’une migration de PSP : faire en sorte que le client ne voie aucune différence. 

Ce que l’on sous-estime facilement 

Certains pièges reviennent dans presque toutes les migrations de PSP. Voici ceux que j’ai appris à anticiper. 

On connaît surtout son PSP quand tout se passe bien, beaucoup moins dans les cas particuliers. Nous avons ainsi découvert des mécanismes peu documentés : des statuts de commande intermédiaires dont dépendaient d’autres systèmes, des champs propres à l’ancien connecteur repris dans les exports vers l’ERP, ou l’ordre de débit entre carte cadeau et carte bancaire en paiement mixte. Avant de migrer, je recommande de faire l’inventaire de ce qui fonctionne, de ce qui est obsolète et de ce que l’on veut améliorer¹. Vue la fragilité de l’ancien connecteur, nous avons construit et testé le nouveau de façon isolée avant de l’intégrer au site. 

Le paiement ne s’arrête pas non plus au checkout : la commande part vers l’ERP, le service client et la comptabilité, et changer de PSP modifie les statuts, les codes qui identifient chaque moyen de paiement et les formats d’export. Chez nous, une partie de ces flux n’est apparue qu’en cours de projet, avec un vrai risque sur le planning. 

La recette ne montre pas tout non plus. Même en production cachée, avec de vrais paiements, ce sont toujours les mêmes personnes et les mêmes cartes qui testent ; le PSP finit par les reconnaître, et il devient difficile de déclencher un challenge 3D Secure, un refus

ou une erreur de carte. Nous ne parvenions parfois même plus à provoquer un simple refus. Certains comportements n’apparaissent qu’avec du trafic réel, et le tracking peut cesser de fonctionner sans que personne ne s’en aperçoive². 

Enfin, il faut anticiper une éventuelle baisse du taux d’acceptation après la bascule, l’un des pièges les plus cités³. L’essentiel est de la repérer sans réagir trop vite : j’attends pour ma part des résultats statistiquement fiables, par pays et par moyen de paiement, avant de conclure.

Ce que je referais autrement 

La fraude, d’abord. Nous avons repoussé le choix de l’outil antifraude après le lancement et démarré avec la configuration native du PSP ; les règles ajoutées ensuite se sont révélées trop strictes et ont bloqué de bons clients avant d’être assouplies. Si la fraude sur la carte n’a jamais été aussi basse en France, le paiement en ligne reste le canal le plus exposé⁴, et le risque porte désormais sur les transactions exemptées d’authentification, les abus des clients eux-mêmes et les bons clients refusés à tort : près de quatre marchands sur dix pensent en refuser entre 2 et 5 %⁵. Aujourd’hui, je choisirais l’outil et les règles de départ avant la bascule, et je prévoirais un suivi quotidien des commandes bloquées pendant les premières semaines. 

Le 3D Secure, ensuite. Lui aussi était en configuration native, avec peu de données transmises à la banque, puis déclenché par un seuil fixe en montant plutôt que par une analyse du risque. Or la banque décide mieux d’authentifier ou non avec des informations complètes. En France, depuis mai 2025, un paiement par carte émise en France ne peut quasiment plus être accepté hors 3D Secure, et même les demandes d’exemption passent par le protocole⁴ : son paramétrage est un sujet de conversion à part entière. 

Les moyens de paiement locaux, enfin, comme Bizum en Espagne, MB WAY au Portugal ou TWINT en Suisse, très ancrés dans les habitudes de paiement locales. Selon le moyen de paiement et le parcours proposé, le client peut être amené à valider son paiement dans une application avant de revenir sur le site marchand. Ce retour sur mobile avait été trop peu testé, et l’expiration de la session est devenue la première cause d’échec sur certains moyens. Il faut donc préparer très tôt les comptes de test, ce qui suppose souvent un compte bancaire dans le pays, un numéro local ou des testeurs qui utilisent réellement le moyen de paiement concerné. 

Bien préparer la bascule en amont 

En revanche, nous avons pris le temps de tout décider en amont, et c’est ce que je recommanderais en priorité. Notre plan de bascule comptait cinq phases, chaque tâche ayant un responsable, un remplaçant et sa procédure de retour arrière. Le nouveau parcours a d’abord été mis en production cachée, accessible à un groupe de testeurs : chaque jour de déploiement, une commande par moyen de paiement et par pays était vérifiée jusqu’à l’ERP, pendant que l’ancien PSP restait surveillé pour les pays non basculés⁶. Le plan couvrait aussi la finance, les contenus légaux et le CRM, avec quatre semaines d’hypercare. 

Le Go/No-Go de chaque pays reposait sur ces éléments : un seul critère bloquant au rouge reportait l’ouverture. Le premier a validé toute l’infrastructure, les suivants se limitaient à une checklist propre au pays, ouverte par les enseignements de la veille. L’après ouverture était aussi prévu, en fixant quelle gravité déclenche quelle décision et qui la prend. Notre premier levier était de refermer l’accès au nouveau parcours, instantanément et sans toucher au code. J’ajouterais deux règles : refermer avant de corriger, et ne rouvrir qu’après avoir vérifié la correction. Il faut aussi penser aux commandes déjà payées sur le nouveau PSP : un retour arrière du code ne les annule pas, et il vaut mieux savoir à l’avance comment les traiter. 

Se laisser du temps entre deux vagues 

Nous avons commencé par les marchés à faible volume, puis, en raison de contraintes extérieures au projet, ouvert les deux plus grands la même semaine, deux semaines seulement après la vague précédente. C’est le point sur lequel je serais aujourd’hui le plus vigilante : quand le contexte le permet, ce qui n’était pas notre cas, il faut se laisser beaucoup plus de temps avant les grands marchés. Le temps fait remonter des bugs et des signaux que ni les tests ni le monitoring quotidien ne voient tout de suite ; plusieurs de nos correctifs importants sont arrivés après l’ouverture des grands pays, alors qu’ils auraient pu la précéder et épargner l’expérience client. Ce passage mérite son propre Go/No-Go : statistiques stables par pays et par moyen de paiement, un cycle complet de versements et de remboursements, aucun nouveau signal du service client. 

Pendant cette période, le service client, le chat et les bots du site comptent autant que les tableaux de bord. Un testeur finit par refaire le parcours de façon mécanique et un log ne voit que ce qu’on lui demande de surveiller ; les clients, eux, utilisent le checkout en conditions réelles. C’est par eux qu’est remonté un bug qui empêchait de repayer après un premier échec. 

Mesurer à partir de ses propres clients 

Même quand on quitte un PSP décevant, il est utile de mesurer sa performance avant de partir, avec des définitions réutilisables : les benchmarks du marché donnent un repère, mais le comportement de ses clients ne se lit que dans ses propres données. Je recommande de raisonner en taux, par pays et par moyen de paiement, et de suivre un succès net par achat : un client qui repaie dans les deux heures après un échec n’est pas une vente perdue. 

Comparer deux PSP sur nos propres clients a été pour nous un exercice ponctuel et complexe, car les seules comparaisons fiables se font en parallèle, sur un trafic comparable et avec les mêmes définitions¹. Pour les grands acteurs multi-PSP, c’est devenu un fonctionnement courant.

Ce que font les grands acteurs multi-PSP 

Selon une enquête du cabinet PaymentGenes auprès d’une soixantaine de grands marchands, 84 % envisagent de changer de PSP mais ne le font pas, freinés par la complexité de l’intégration, le manque de ressources et leurs contrats ; environ deux tiers utilisent ou prévoient plutôt un orchestrateur de paiement⁷. 

Un orchestrateur est une couche placée entre le site et plusieurs PSP. Le marchand s’y intègre une seule fois, puis l’orchestrateur oriente chaque transaction vers le prestataire le plus adapté selon le pays, le moyen de paiement ou le type de carte, avec une solution de repli en cas de panne ou de refus. Ce qui distingue aujourd’hui les orchestrateurs, c’est surtout leur façon de choisir le bon prestataire et la qualité des données qu’ils restituent⁸. 

Son apport le plus concret porte sur le changement de PSP. On ne bascule plus d’un coup, mais on oriente une petite part du trafic vers le nouveau prestataire, on compare les deux sur des transactions comparables¹, puis on augmente progressivement, et revenir en arrière consiste à modifier une règle de routage. C’est, en plus souple, ce que nous avons construit nous-mêmes avec la production cachée et les vagues. 

L’autre usage est de travailler avec plusieurs PSP selon les pays. Un acquéreur local traite la transaction comme domestique, ce qui peut jouer sur l’acceptation et le coût ; un prestataire local couvre souvent mieux les moyens de paiement du pays, et plusieurs PSP protègent en cas de panne. Mais chaque prestataire ajoute un contrat, un reporting et des fichiers de règlement à réconcilier, un coût souvent sous-estimé et porté par la finance. Et deux contrats sans vraie logique de bascule font payer les deux modèles sans la résilience d’aucun¹. 

En France, Purse illustre cette évolution. Né d’un projet commun à des enseignes de la famille Mulliez, à partir d’une technologie développée chez Decathlon⁹, il revendique plus de 80 moyens de paiement connectés et propose notamment le routage par type de carte, la relance d’un paiement refusé chez un autre PSP, la tokenisation et l’intégration aux ERP comptables¹⁰. Parmi ses clients, Kiabi cherchait à faire évoluer ses moyens de paiement et ses PSP sans projet informatique à chaque changement¹¹, et Vertbaudet, présent sur neuf marchés, à gagner en simplicité et en visibilité¹⁰. Les PSP eux-mêmes s’y mettent : Stripe a présenté en 2025 une offre de routage vers d’autres prestataires⁶. 

Il faut cependant garder en tête ses limites. Un orchestrateur ne supprime pas la première migration : il faut s’y raccorder, avec un connecteur vers la plateforme e-commerce, une recette et une bascule. Il simplifie en revanche les suivantes, avec un format unique de données et de statuts, une vue consolidée des PSP et, s’il a son propre coffre à cartes, des cartes enregistrées utilisables partout. Il ne remplace ni la méthode, ni un responsable paiement interne pour piloter le routage, et il crée une nouvelle dépendance : avant de signer, mieux vaut savoir si l’on récupère ses cartes en le quittant. 

Dans notre cas, un orchestrateur aurait simplifié les formats de données vers l’ERP et la comparaison entre ancien et nouveau PSP, mais la qualité des données 3D Secure, les tests des moyens de paiement locaux et la décision antifraude seraient restés de notre ressort. Pour notre client, qui n’avait pas envisagé le multi-PSP et dont un seul PSP couvrait tous les marchés, il aurait été prématuré. Pour un marchand qui s’y prépare, c’est l’inverse : mieux vaut poser cette couche avant le deuxième PSP, pour n’intégrer qu’une fois. 

Ce que je retiens 

Au début du projet, maintenir le taux de conversion me paraissait un objectif modeste. C’était en réalité très exigeant. Pour y parvenir, il faut bien connaître l’existant, décider avant le jour J, se laisser du temps entre les vagues et écouter ses clients autant que ses tableaux de bord. 

Au fond, une migration est réussie quand le client n’a rien remarqué. Et pour les plus grands acteurs, quand la suivante s’annonce plus simple. 

Sources ¹ Shuttle, How to switch payment providers without losing customers et Global PSP vs local acquirers ² Ubertesters, What breaks when you switch a PSP ³ Basis Theory, Challenges in migrating payment processor ⁴ Banque de France, Observatoire de la sécurité des moyens de paiement, rapport 2025 (septembre 2026) et mesures de prévention de la fraude hors 3-D Secure (janvier 2026) ⁵ Merchant Risk Council, 2026 Global eCommerce Payments & Fraud Report, cité par Signifyd ⁶ Stripe, How to switch payment processors et Multiprocessor guide ⁷ The Paypers / PaymentGenes, PSP switching strategy, mai 2026 ⁸ The Paypers / Edgar, Dunn & Company, From connectivity to intelligence, novembre 2026 ⁹ Le Journal des Entreprises ; Maddyness, mars 2024 ¹⁰ E-Commerce Nation, Qu’est-ce qu’une plateforme d’orchestration de paiements ? et Étude de cas Vertbaudet ¹¹ Republik Retail, Pourquoi Kiabi revoit toute sa stratégie de paiement