Changer de PSP ne déplace pas un simple endpoint. Au jour de la bascule, des autorisations attendent leur capture, des remboursements concernent des paiements anciens, des litiges continuent, des cartes sont représentées par des jetons propriétaires et des vendeurs attendent leur reversement. Un nouveau paiement peut réussir pendant que la finance perd son lien avec la commande.
Le symptôme concret apparaît dans les balances parallèles, les captures impossibles, les remboursements manuels et les écarts de soldes vendeurs. Le risque majeur n’est pas seulement une indisponibilité : c’est un montant correct rattaché au mauvais système, puis compensé une seconde fois.
Le vrai enjeu d’une marketplace opérateur consiste à garder une autorité financière unique pendant le double run. Contre-intuitivement, basculer 100 % des nouveaux paiements le premier jour ne raccourcit pas forcément la migration : les transactions historiques resteront gérées par l’ancien PSP pendant des semaines ou des mois.
La méthode suivante sépare acquisition, opérations après-vente, récurrence, seller funds et rapprochement. Elle construit une correspondance durable entre identifiants, journalise le routage et ferme progressivement l’ancien périmètre. Chaque centime doit retrouver commande, mouvement, PSP et écriture bancaire avant l’arrêt définitif.
Inventorier les flux avant la bascule
Cartographier les opérations et leurs délais
L’inventaire couvre autorisation, authentification, capture, annulation, remboursement, chargeback, frais, réserve, versement et reversement vendeur. Pour chaque opération, il nomme identifiant, délai maximal, dépendances et système capable de l’exécuter après coupure.
Les moyens de paiement, pays, devises, modèles de capture et canaux sont classés. Un flux rare ne doit pas disparaître parce qu’il n’apparaît pas dans une semaine de logs. La finance complète le trafic technique avec les clôtures et exceptions réelles.
Construire une population de référence
Un échantillon contient succès, refus, 3DS, capture différée, remboursement partiel, litige et vendeur multi-commandes. Chaque cas relie commande, paiement, mouvement ledger et versement bancaire. Il servira avant et après la bascule.
La volumétrie décrit pics, montants, ratios et latence, mais aussi âge des transactions ouvertes. Une autorisation de faible montant proche de son expiration peut être plus urgente qu’un paiement récent déjà capturé. Une vérification quotidienne prélève au moins une autorisation, une capture, un remboursement et un versement de chaque route active. La finance relie ces opérations à leur commande, leur écriture ledger et leur ligne bancaire sans interroger directement les deux dashboards PSP. Tout identifiant absent rejoint une file d’écarts avant le palier suivant.
Attribuer chaque décision de migration
Séparer programme, paiement et finance
Le directeur de migration décide du palier, l’équipe paiement du routage technique, la finance du rapprochement et le risque des seuils. Le support traite les dossiers selon un runbook. Aucun rôle ne peut déclarer seul la migration terminée.
Un registre consigne décision, périmètre, date, propriétaire, preuve et rollback. La réunion ne constitue pas la preuve. Le go dépend de contrôles reproductibles et d’une balance signée.
Nommer la source faisant foi
La commande porte la promesse commerciale, le ledger les droits financiers, chaque PSP ses opérations et la banque le règlement externe. Le dashboard réunit ces sources sans les écraser. Un statut PSP ne remplace pas le ledger.
Durant le double run, la règle de routage fait foi pour savoir où effectuer capture ou remboursement. Elle est stockée avec la transaction. La date seule ne suffit pas si un canary ou un fallback a dérogé.
Migrer les moyens de paiement sans exposer les cartes
Accepter que les jetons soient propriétaires
Un jeton d’acquéreur n’est généralement pas portable comme une donnée métier ordinaire. La conversion entre systèmes indépendants peut nécessiter un processus sécurisé impliquant les prestataires et un environnement conforme. L’application ne détokénise jamais elle-même pour accélérer le projet.
L’inventaire distingue cartes migrables, wallets, mandats, abonnements et moyens à renouveler. Certaines références ne peuvent pas être transférées. Le parcours prévoit alors une nouvelle collecte au bon moment, sans bloquer les clients actifs inutilement.
Réconcilier anciens et nouveaux identifiants
Le fichier de correspondance lie client, moyen ancien, moyen nouveau, statut et date. Il est chiffré, contrôlé, transmis par les canaux convenus et importé dans un périmètre restreint. Les données inutiles ne suivent pas la migration.
Après import, un échantillon vérifie réseau, expiration, empreinte autorisée et capacité d’usage, sans exposer le PAN. Les erreurs restent en quarantaine. Le système ne marque pas tout un lot comme réussi à partir du seul nombre de lignes.
Fermer les transactions déjà ouvertes
Garder l’ancien PSP pour ses effets
Une autorisation créée chez l’ancien PSP est capturée, annulée ou expirée chez lui selon ses capacités. Un remboursement suit l’opération d’origine. Le nouveau PSP n’invente pas une transaction équivalente qui casserait le lien avec la banque et les litiges.
La file des ouverts classe autorisations, remboursements, disputes et versements. Chaque élément possède échéance, montant et owner. L’ancien contrat reste opérationnel jusqu’à extinction ou transfert formel de ces obligations.
Prévoir la longue traîne
Chargebacks et retours peuvent arriver après la fin des nouveaux paiements. Le runbook conserve accès, webhooks, comptes bancaires et équipe capable d’agir. La coupure commerciale ne vaut pas fermeture financière.
Une courbe d’extinction montre le nombre et la valeur des dossiers ouverts. Si elle cesse de baisser, la cause est étudiée. Un compte PSP ne doit pas être clôturé pour satisfaire une date de projet tant que des mouvements restent possibles.
Router les nouveaux paiements progressivement
Choisir un canary lisible
Le premier palier utilise pays, moyen de paiement, cohorte client ou pourcentage stable. La règle est déterministe et visible dans le paiement. Un même checkout ne change pas de PSP après un simple retry sans décision explicite.
Le canary mesure acceptation, authentification, latence, fraude, capture et support. Les cohortes tiennent compte des différences de trafic. Une amélioration du taux d’autorisation ne compense pas un défaut de rapprochement.
Borner fallback et rollback
Le fallback vers l’ancien PSP dépend du type d’échec et de l’état de l’intention. Après un résultat inconnu, router ailleurs peut doubler l’autorisation. Le service relit l’opération ou attend le webhook avant de décider.
Le rollback arrête les nouvelles créations sur le PSP cible, mais laisse finir ses transactions déjà engagées. Il conserve la règle de routage par paiement. Le support sait donc où agir même après retour au palier précédent.
Conserver captures et remboursements
Modéliser les opérations partielles
Une commande peut comporter plusieurs captures et remboursements. Le ledger rattache chaque opération à une ligne, un vendeur ou un motif selon le modèle. Les montants cumulés ne dépassent pas les droits restants.
Les clés d’idempotence sont propres à l’effet métier. Rejouer un remboursement après timeout ne crée pas un second mouvement. La lecture du PSP et du ledger précède tout nouvel essai.
Traiter les statuts inconnus
Un PSP peut accepter la commande et appliquer l’effet plus tard. « Pending » n’est ni succès final ni échec. Le workflow attend l’événement, poll selon le contrat et alerte après un délai métier.
Une réponse ou un type inconnu entre en quarantaine avec payload masqué. Il ne devient pas « failed » par défaut, car cette simplification peut déclencher une compensation erronée.
Traiter récurrence et authentification
Conserver le contexte des mandats
Les paiements récurrents dépendent du moyen, du consentement, du mandat et du contexte d’authentification. La migration vérifie ce qui est transférable et ce qui exige une nouvelle action client. Un jeton importé ne prouve pas à lui seul tous les droits d’usage.
Les abonnements gardent date, montant attendu, moyen par défaut et stratégie d’échec. La bascule se fait par échéance ou cohorte. L’ancien PSP reste disponible pour les cycles non migrés.
Préparer l’échec de renouvellement
Un client dont le moyen n’est pas migrable reçoit un parcours de mise à jour avant l’échéance. Le message évite d’exposer la raison technique. La relance respecte les règles de communication et le service rendu.
Le signal faible est une hausse des échecs sur cartes importées ou de l’authentification inattendue. Le canary compare la cohorte et suspend l’extension si l’écart dépasse le seuil convenu.
Protéger les soldes et reversements vendeurs
Reconstituer les droits avant transfert
Le solde vendeur vient des commandes, commissions, remboursements, litiges, réserves et reversements. Il n’est pas copié depuis un total PSP sans détail. Le ledger reconstitue chaque droit au moment de la bascule.
Les vendeurs peuvent rester répartis entre anciens et nouveaux comptes pendant le double run. Le portail agrège sans confondre. Chaque versement indique PSP, compte, période et mouvements couverts.
Migrer onboarding et capacités
Les comptes vendeurs, vérifications et coordonnées bancaires suivent un processus encadré par le nouveau prestataire. Une capacité manquante bloque seulement les flux concernés. Le vendeur voit l’action attendue et l’échéance.
Le support n’ouvre pas un second compte au hasard pour contourner une erreur de mapping. La correspondance entre vendeur interne et comptes PSP est unique, versionnée et revue avant le premier reversement.
Dédupliquer webhooks et commandes
Faire coexister deux vocabulaires
Chaque PSP possède événements et états propres. Une couche d’adaptation produit des faits internes sans perdre code, identifiant et payload source. Les enums inconnues restent visibles. Une normalisation ne doit pas inventer une équivalence.
Les webhooks sont authentifiés, persistés puis traités asynchronement. Les doublons et l’ordre imparfait sont attendus. Le consommateur déduplique l’effet et relit la ressource avant une décision sensible.
Corréler toutes les tentatives
Commande, intention, opération PSP, webhook, mouvement ledger et banque partagent une corrélation. Le support part de la commande et traverse la chaîne sans requête ad hoc. Les données carte restent masquées.
Une tentative abandonnée n’est pas supprimée. Elle garde son résultat inconnu ou terminal. Cette histoire empêche qu’un paiement tardivement accepté soit traité comme une somme inexpliquée.
Normaliser les mouvements dans le ledger
Garder un vocabulaire financier interne
Le ledger enregistre droits et mouvements indépendamment des libellés PSP. Autorisation, capture, remboursement, frais, réserve et versement restent distingués. L’adaptateur traduit les événements vers ce vocabulaire avec une version.
Une écriture ne change pas de sens après migration. Les montants portent devise, signe, bénéficiaire et référence. Les corrections sont compensatoires. La finance peut donc comparer deux fournisseurs sur la même base.
Versionner frais et calendriers
Les frais et délais diffèrent selon le PSP, le moyen et le pays. Le ledger garde le barème appliqué et sépare estimation de valeur confirmée. Un écart de frais n’est pas noyé dans le montant vendeur.
Les dates d’opération, disponibilité et versement ne sont pas interchangeables. La clôture utilise la bonne. Le dashboard explique pourquoi un paiement capturé n’est pas encore réconcilié avec la banque.
Réconcilier les deux PSP et la banque
Construire trois balances
La première rapproche commandes et ledger, la deuxième ledger et opérations PSP, la troisième PSP et règlements bancaires. Les totaux sont ventilés par devise, jour, moyen et statut. Chaque différence retrouve ses identifiants.
Les délais normaux deviennent des états « en transit », pas des erreurs immédiates. Au-delà de la fenêtre, l’écart obtient owner, cause et prochaine action. Une exclusion reste justifiée.
Fermer l’ancien PSP par preuve
L’extinction exige zéro transaction actionnable, zéro solde non expliqué, exports archivés, litiges transférés ou clos et accès de lecture maintenu selon le besoin. La date contractuelle seule ne suffit pas.
Exemple concret : 12 remboursements restent en attente, 2 chargebacks sont ouverts et un versement bancaire n’est pas rapproché. Le compte demeure opérationnel en mode restreint jusqu’à résolution ; les nouveaux paiements restent sur le PSP cible.
Éviter les erreurs fréquentes
Choisir une date unique pour tous les flux
Le big bang ignore la longue traîne des remboursements, litiges et récurrences. Le routage des nouvelles intentions peut basculer vite, mais les effets historiques doivent suivre leur PSP d’origine. Le plan prévoit plusieurs dates.
Autre erreur : considérer les jetons comme exportables par l’application. Le transfert de données sensibles appartient aux prestataires et au périmètre conforme. Les moyens non migrables reçoivent un parcours client.
Comparer seulement les taux d’autorisation
Une meilleure acceptation peut cacher des remboursements impossibles, des frais mal comptés ou des vendeurs non payés. Le verdict inclut cycle complet et rapprochement. Le canary dure assez pour observer les effets différés.
Enfin, fermer trop tôt l’accès à l’ancien dashboard rend les litiges orphelins. L’équipe conserve identités, exports et runbook jusqu’à extinction réelle, avec des droits minimaux.
Plan d’action pour une migration contrôlée
Construire inventaire, mapping et double run
L’équipe documente entrées, sorties, responsabilités, dépendances et seuils par flux. Elle inventorie transactions ouvertes, jetons, mandats, comptes vendeurs et balances. Le mapping relie identifiants anciens, nouveaux, commande et ledger. Une cohorte de référence traverse succès, remboursement, litige et versement. Chaque ligne d’inventaire précise le système autorisé à initier l’opération, celui qui doit la terminer, la date d’extinction probable et la preuve financière attendue. La finance échantillonne ensuite des montants, devises, vendeurs et frais différents afin que le jeu de référence ne représente pas seulement le parcours nominal.
La mise en œuvre prépare routage, files, idempotence, journalisation, monitoring et rollback. Les deux adaptateurs produisent le même vocabulaire interne. Le support dispose d’un runbook par résultat inconnu, échec de capture, remboursement et vendeur bloqué. Un registre de corrélation exportable conserve commande, intention, opération PSP, écriture ledger et ligne de règlement, sans dépendre du libellé humain d’un tableau de bord. Les accès techniques, certificats, adresses de webhook et secrets de signature sont renouvelés et testés avant le canary, avec un propriétaire et une échéance pour chaque dépendance.
Étendre puis fermer l’ancien périmètre
Le canary commence par un moyen et une cohorte. Deux cycles de règlement doivent respecter taux, délais, frais et balances. Un exercice de rollback arrête les nouvelles intentions sans abandonner les opérations déjà créées. La recette injecte un timeout avant et après création distante, rejoue un webhook, retarde un règlement et demande un remboursement partiel sur une transaction ancienne. Le résultat attendu est écrit avant l’essai : propriétaire de la reprise, écriture compensatrice éventuelle, signal d’alerte et délai maximal de résolution. Le support doit retrouver ces informations depuis l’identifiant communiqué par le client.
L’extension attend zéro double effet et moins de 0,1 % d’écarts non expliqués en valeur. Si le seuil est franchi, alors le palier revient en arrière. L’ancien PSP ferme seulement après extinction des ouverts et signature de la balance finale. Une revue quotidienne ventile volumes, autorisations, captures, remboursements, litiges, frais et reversements par route ; les écarts sont suivis en nombre et en valeur. Chaque nouveau palier augmente une seule dimension, par exemple le pays, le moyen de paiement ou la part de trafic. La décision de fermeture exige aussi les exports historiques, la durée d’accès aux preuves et un responsable capable de traiter les derniers litiges après la fin commerciale du contrat.
- À faire d’abord : inventorier les opérations et garder le PSP d’origine par transaction.
- À tester ensuite : timeout, capture différée, remboursement, litige et reversement vendeur.
- À différer : les moyens dont jetons ou mandats ne sont pas prêts.
- À refuser : toute manipulation de données carte hors processus sécurisé.
Guides complémentaires pour l’opérateur
Préparer la migration marketplace
Le cadre de refonte et migration marketplace aide à organiser dépendances, canary et rollback au-delà du seul paiement.
Le MVP marketplace rappelle les flux financiers indispensables avant l’ouverture. Ils servent de population minimale à rejouer chez le nouveau PSP.
Outiller balances et support
Les écrans du back-office opérateur doivent retrouver commande, paiement, vendeur et mouvement depuis une seule corrélation.
Le dossier sur les alertes marketplace et cash complète les seuils de rapprochement pendant le double run.
Conclusion : fermer les deux histoires financières
Une transition PSP ne remplace pas instantanément l’ancien prestataire. Les nouvelles intentions changent de route, tandis que les captures, remboursements, récurrences et litiges historiques suivent leur origine.
Le ledger, le mapping d’identifiants et les commandes idempotentes donnent une continuité financière. Les jetons sont migrés par un processus sécurisé ou renouvelés auprès du client.
Le double run se termine par des balances, pas par une impression de stabilité. L’ancien compte ferme lorsque chaque mouvement et chaque solde possèdent une explication et une issue.
Pour préparer le routage, construire les adaptateurs et sécuriser le rapprochement, Dawap peut vous accompagner dans votre projet de marketplace opérateur, de l’inventaire au dernier versement.
