Stripe, PayPal, Adyen et Mangopay peuvent tous apparaître dans un parcours de paiement, mais ils ne résolvent pas nécessairement le même modèle de flux. Les comparer seulement sur les frais ou le nombre de méthodes masque l’onboarding, les litiges, les reversements et le rapprochement qui feront vivre le SI.
Le vrai enjeu consiste à choisir une chaîne que produit, support, risque et finance savent opérer. Un checkout fluide ne suffit pas si un remboursement partiel devient manuel, si un vendeur reste bloqué ou si le versement net ne peut pas être expliqué.
Cette matrice vous aide à décider les scénarios et preuves avant le fournisseur. Elle s’inscrit dans une intégration API cohérente, puis se décline dans le socle d’API paiement adapté au modèle.
Deux livrables comptent davantage qu’un tableau de fonctionnalités :
- La carte des mouvements : qui paie, qui encaisse, qui détient, qui rembourse et qui reçoit le net.
- Le registre des preuves : événement, montant, frais, statut, facture, écriture et owner de chaque exception.
1. Partir du modèle de flux
Qualifier le besoin avant le fournisseur
Un e-commerce direct, un abonnement, une marketplace, un parcours B2B et un réseau omnicanal n’ont pas les mêmes responsabilités. Le cadrage décrit client, marchand, vendeur, plateforme, finance et bénéficiaire final avant de parler d’API ou de SDK.
Les scénarios couvrent autorisation, capture, échec, annulation, remboursement partiel, litige et versement. Ils précisent devises, pays, canaux, récurrence, délais et données sensibles. Cette liste révèle les capacités vraiment discriminantes.
Les offres, tarifs et fonctions évoluent : chaque affirmation fournisseur doit être vérifiée dans la documentation et le contrat actuels. La décision conserve donc une date, un périmètre et les hypothèses commerciales plutôt qu’un classement présenté comme universel.
2. Cartographier l’argent
Suivre brut, frais, net et dette
La carte relie commande, intention de paiement, autorisation, capture, remboursement, dispute, commission et versement. Elle indique le système qui déclenche et celui qui confirme. Un statut commercial ne remplace jamais un événement financier.
Pour une marketplace, le schéma ajoute vendeurs, wallets ou comptes, commissions, réserve et payout. Pour le B2B, il ajoute facture, acompte, avoir et échéance. Le même mot « payé » peut recouvrir des états différents selon le modèle.
Chaque flèche possède une référence de rapprochement et une preuve attendue. Lorsqu’une correspondance reste incertaine, elle rejoint une file finance. Cette discipline empêche que le reporting reconnaisse un cash seulement prévu ou qu’un remboursement disparaisse dans un agrégat.
3. Cadrer e-commerce et abonnement
Comparer conversion et exploitabilité
Un parcours direct évalue méthodes, expérience, authentification, récurrence, capture différée et gestion des moyens enregistrés selon les besoins réels. Stripe ou PayPal peuvent répondre à des intentions et habitudes différentes ; la mesure doit être segmentée plutôt qu’idéologique.
L’abonnement ajoute renouvellement, échec, relance, changement de plan, prorata et résiliation. Le produit conserve un modèle interne afin de ne pas confondre contrat commercial et objet du PSP. Les webhooks mettent à jour l’état sans devenir l’unique source de vérité.
Le choix inclut le support. Un paiement refusé doit être expliqué sans exposer une donnée sensible ; un client qui change de méthode doit garder son service selon la règle convenue. La qualité se mesure jusqu’à la résolution, pas seulement à la conversion initiale.
4. Décider pour une marketplace
Faire passer gouvernance et conformité avant l’interface
La marketplace décrit qui contracte, encaisse, contrôle le vendeur, retient la commission et déclenche le payout. Onboarding, KYC ou KYB, comptes, wallets et reversements forment une chaîne métier. Stripe Connect, Mangopay ou Adyen for Platforms doivent être évalués sur ce modèle précis.
Le connecteur gère les états d’éligibilité sans prétendre décider la conformité. Un vendeur incomplet, refusé ou à réviser ne reçoit pas le même parcours. Le support voit la prochaine pièce ou action autorisée sans accéder aux documents au-delà de ses droits.
Les reversements suivent commandes, retours, disputes et réserves. Le système calcule ce qui est attendu, puis rapproche le payout réellement confirmé. Un simple total vendeur ne suffit pas lorsque plusieurs opérations expliquent le net.
5. Évaluer l’omnicanal
Unifier l’identifiant sans nier les canaux
L’omnicanal relie paiement en ligne, point de vente, commande, remboursement croisé et reporting. Adyen peut entrer dans cette réflexion, mais sa pertinence dépend des pays, terminaux, méthodes et responsabilités à intégrer. La capacité actuelle est vérifiée avant le choix.
Le modèle interne conserve canal, marchand, terminal éventuel, commande et références financières. Il permet au support de retrouver une opération même lorsque la vente et le remboursement n’ont pas commencé au même endroit.
La finance exige une vue commune sur brut, frais, net et versement, tout en gardant les détails nécessaires par entité. Une consolidation trop précoce masque les écarts ; une séparation totale oblige à rapprocher plusieurs mondes à la main.
6. Relier paiement et facture B2B
Brancher le PSP sur l’order-to-cash
Le B2B combine acompte, facture, validation interne, échéance, paiement partiel et avoir. L’identifiant de commande ne suffit pas : le rapprochement vise parfois plusieurs factures ou plusieurs opérations sur une même créance.
L’ERP reste propriétaire des documents comptables et du solde client. Le PSP fournit les événements de paiement ; le connecteur propose les correspondances et isole les ambiguïtés. Une règle explicite gère tolérance, devise et frais.
Le support commercial doit savoir ce qui est payé, en cours ou en erreur, sans confondre autorisation et encaissement. La finance valide les écritures. Ce partage des responsabilités évite de transformer le dashboard PSP en comptabilité parallèle.
7. Traiter fraude et litiges
Mesurer les décisions et leur coût
La fraude ne se résume pas à un taux de blocage. Le dispositif observe acceptation, faux positifs, pertes, charge de revue et expérience client. La décision de risque reste traçable avec sa règle, son signal et son résultat.
Les disputes possèdent motifs, délais, pièces et issue. Le modèle commun relie la contestation au paiement, à la commande et aux actions support. Il conserve les différences PSP sans forcer toutes les procédures dans un statut vague.
Le coût caché apparaît quand personne ne possède les exceptions : litige visible au PSP, commande encore livrable et finance non informée. Le runbook définit qui suspend, qui documente, qui répond et qui comptabilise l’issue.
8. Rendre le cash rapprochable
Concevoir la preuve avant l’export
La finance attend une chaîne entre transaction, capture, frais, refund, dispute, payout et banque. Le connecteur conserve les références de chaque étape et la devise. Il n’essaie pas de deviner une égalité lorsque le versement agrège plusieurs jours.
La réconciliation associe automatiquement les cas déterministes et place les autres en file. Chaque écart indique montant, date, cause possible et pièces. L’opérateur corrige ou valide sans modifier les données brutes.
Cas concret : si plus de 1 % du montant versé reste non rapproché après 2 jours ouvrés, alors la finance bloque l’élargissement du périmètre et analyse frais, remboursements et décalages. Ce seuil commande une action ; il ne sert pas seulement de KPI décoratif.
9. Justifier un multi-PSP
Comparer le gain à la complexité ajoutée
Un second PSP peut apporter une méthode, une couverture, une résilience ou une optimisation d’acceptation. Il ajoute aussi routing, statuts, webhooks, remboursements, reporting et support. Le bénéfice doit être mesuré sur un scénario explicite.
Le modèle interne normalise paiement, autorisation, capture, remboursement, contestation et rapprochement. Les adaptateurs conservent les champs spécifiques. Une bascule ne doit pas rendre une opération impossible à retrouver ou rembourser dans son PSP d’origine.
Paradoxalement, un seul PSP bien instrumenté peut être plus résilient qu’un double dispositif jamais testé. La résilience exige déclencheur, capacité de repli, mode retour, responsabilités et exercices. Sans eux, le second fournisseur double surtout la surface d’incident.
10. Construire la matrice de décision
Pondérer les scénarios bloquants
La matrice liste capacités obligatoires, souhaitables et différables. Elle couvre modèle de flux, pays, méthodes, conformité, récurrence, support, finance, données, migration et coût total. Chaque critère possède une preuve de test.
Une capacité indispensable élimine un candidat si elle ne peut pas être obtenue dans le périmètre contractuel. En revanche, un écart secondaire peut être accepté si son contournement reste sûr et peu coûteux. La pondération ne doit pas transformer un blocage en moyenne acceptable.
Les finalistes passent par les mêmes scénarios sandbox : paiement, échec, capture, refund partiel, dispute, export et reprise de webhook. La comparaison porte sur le résultat, la preuve et le temps opérateur, pas sur la seule élégance du SDK.
11. Éviter les erreurs fréquentes
Refuser le comparatif hors contexte
Comparer un tarif facial sans simuler méthodes, pays, fraude, refunds et charge finance produit une illusion de coût. L’autre erreur consiste à choisir une fonctionnalité marketplace avant d’avoir défini le rôle légal et le mouvement de l’argent.
Un webhook traité comme une commande fiable peut arriver en double ou hors ordre. Le système persiste, vérifie la signature, applique idempotence et réconcilie avec l’API. Les secrets, tokens et données carte ne doivent jamais apparaître dans les logs métier.
Enfin, un second PSP installé « pour plus tard » vieillit sans être testé. Si la bascule ne possède pas d’owner et d’exercice, alors elle ne constitue pas une continuité crédible. À éviter également : la normalisation qui supprime le statut spécifique nécessaire au litige.
- Ne pas choisir avant la carte des flux.
- Ne pas moyenner un critère bloquant.
- Ne pas reconnaître le cash avant le rapprochement.
- Ne pas multiplier les PSP sans modèle interne.
12. Plan d’action pour choisir
Passer des scénarios à une décision testée
La première phase réunit produit, finance, risque, support, commerce et technique. Elle dessine mouvements d’argent, responsabilités et exceptions. Les volumes, pays, méthodes et exigences de délai sont bornés pour éviter un cahier des charges universel.
La deuxième phase construit la matrice et vérifie les offres actuelles des fournisseurs. Le contrat, la tarification, la résidence des données et les mécanismes de sortie sont examinés. Les inconnues restent visibles au lieu d’être notées favorablement.
La troisième phase implémente une preuve verticale dans chaque finaliste. Les entrées, payloads, webhooks, queue, retry, idempotence, monitoring et exports finance utilisent le même jeu de scénarios. La sandbox ne remplace pas le test des opérations de run.
La quatrième phase chiffre intégration, exploitation, support et migration. Le choix est signé avec hypothèses, risques acceptés et conditions de révision. Un rollback protège le pilote avant toute généralisation.
Homologuer les cas qui cassent la moyenne
Le test envoie un webhook en double, un refund partiel après capture et une dispute ouverte pendant un payout. Le système doit préserver l’ordre logique, empêcher le double effet et présenter une chronologie unique au support.
Un deuxième scénario coupe le PSP après soumission. Le retry commence par rechercher l’opération avec la clé d’idempotence. Le timeout reste « inconnu » tant qu’aucune preuve ne confirme échec ou succès. Cette prudence évite le double débit.
La finance rapproche un versement agrégé contenant ventes, frais et remboursements. Les éléments déterministes sont liés ; l’écart rejoint la file sans bloquer le reste. Le rapport conserve le contrat de mapping et la source brute.
Pour une marketplace, un vendeur change d’état KYC pendant qu’un remboursement est demandé. Le runbook doit protéger le client, respecter les actions autorisées et empêcher un payout incohérent. Le support ne contourne jamais le contrôle dans la base.
Décider l’ordre d’exécution
D’abord, sécuriser encaissement, refund et rapprochement. Ensuite, traiter dispute et support. En priorité, couvrir les flux qui portent le cash et la conformité. À différer : les méthodes rares. À refuser : le multi-PSP sans propriétaire.
La mise en production commence sur un périmètre borné avec alertes, journalisation et rollback. La revue quotidienne qualifie chaque correction manuelle et contrôle le compte bancaire ou le payout attendu. Les écarts réels deviennent des tests.
Après trente jours, le verdict compare conversion, exceptions, temps support et montant non rapproché. Le fournisseur n’est confirmé que si le run tient. Une belle intégration qui déplace le travail vers la finance reste incomplète.
- D’abord : cartographier chaque mouvement d’argent.
- Ensuite : tester remboursements et litiges.
- En priorité : prouver le net versé.
- À différer : les parcours sans usage proche.
- À refuser : un choix impossible à migrer.
Comparer le coût total sur une cohorte réelle
La comparaison économique part d’un mois ou d’une cohorte représentative, anonymisée lorsque nécessaire. Elle rejoue nombre de paiements, panier, devises, méthodes, refunds, disputes et versements. Les frais contractuels sont vérifiés avec chaque candidat et séparés des hypothèses. Le modèle ajoute le développement initial, la maintenance, les opérations manuelles et le coût des incidents. Une différence de commission ne doit pas masquer plusieurs jours de rapprochement ou un parcours vendeur qui exige un traitement supplémentaire à chaque payout.
La conversion est évaluée avec la même prudence. Les résultats historiques d’un moyen de paiement ou d’un marché ne garantissent pas le comportement du futur checkout. Le pilote compare populations compatibles, périodes et causes de refus, puis indique les limites. Une amélioration apparente peut venir d’un mix client différent. Le verdict relie acceptation, marge, fraude et support ; il refuse de promouvoir un taux isolé au rang de preuve absolue.
La charge de run est chronométrée par scénario. Le support traite un refus, une annulation, un remboursement partiel et une contestation ; la finance rapproche un versement ; la technique rejoue un webhook. Les temps, écrans et escalades sont consignés. Un fournisseur qui demande davantage d’étapes peut rester pertinent si ces gestes sont rares et bien prouvés. En revanche, une exception quotidienne sans API, export ou owner devient une dette récurrente que le coût total doit rendre visible.
La sortie est une fourchette et non une précision trompeuse. Elle présente scénario nominal, scénario de croissance et scénario dégradé, avec hypothèses de volume et taux d’exception. Si le choix change dès qu’une hypothèse bouge légèrement, alors la décision reste fragile et mérite un pilote plus long. Si le même candidat reste adapté dans les trois cas, l’équipe dispose d’un argument plus solide pour engager la migration et organiser le run.
Préparer la sortie avant de signer
Le dossier de réversibilité inventorie les identifiants, tokens, moyens enregistrés, abonnements, comptes vendeurs, historiques et rapports nécessaires. Il distingue ce qui peut être exporté, migré, recréé ou seulement conservé en lecture. Les obligations contractuelles et techniques sont vérifiées avec le fournisseur. Cette cartographie évite de découvrir après plusieurs années qu’un objet critique ne possède aucune correspondance portable dans le modèle interne.
Le scénario de sortie teste une petite cohorte : nouvelles transactions routées vers la cible, anciennes opérations remboursées dans leur PSP d’origine et finance capable de rapprocher les deux périodes. Le support retrouve l’emplacement de chaque action depuis le back-office commun. La migration conserve les journaux et les droits nécessaires jusqu’à extinction des litiges et remboursements ouverts. La réversibilité devient ainsi un run contrôlé, pas une clause abstraite du contrat. Son coût, son délai et ses dépendances sont revus chaque année pour rester crédibles face aux évolutions du produit et des fournisseurs.
13. Approfondir les PSP
Passer de la matrice aux architectures spécialisées
Pour une plateforme multi-vendeurs centrée sur KYC, wallets et reversements, poursuivez avec l’intégration Mangopay. Elle détaille les preuves propres au modèle marketplace.
Pour un contexte omnicanal et son rapprochement, relisez l’architecture Adyen. Pour le double fournisseur, le duo PayPal et Stripe montre la dette de back-office à anticiper.
Ces lectures ne produisent pas un gagnant absolu. Elles donnent des scénarios et des risques à intégrer dans la matrice, puis à vérifier avec l’offre et la documentation actuelles de chaque PSP.
14. Conclusion : payer, c’est prouver
Choisir une chaîne financière exploitable
Le bon PSP permet d’encaisser, rembourser, contester, verser et rapprocher selon le modèle réel de l’entreprise. Son logo et son SDK ne compensent pas une responsabilité ou une preuve manquante.
Stripe, PayPal, Adyen et Mangopay doivent être évalués sur les mêmes scénarios bloquants, avec leurs conditions actuelles. La décision protège d’abord le cash, le support et la capacité de migration.
Le geste utile consiste à cartographier une verticale et à homologuer ses exceptions avant de généraliser. Cette discipline transforme un choix fournisseur en architecture opérable.
Dawap peut vous accompagner pour structurer cette matrice, ses preuves financières, sa réversibilité et son runbook de production auditable dans la durée, avec vos équipes produit, support, risque et finance : cadrez votre intégration API.
