Tunnel de paiement : qui fait quoi entre l'agence, le PSP et la plateforme

EcommerceMag.fr organise une matinale consacrée aux grandes tendances du paiement 2026. Au-delà des nouveautés annoncées, un constat revient chez la plupart des marchands : quand une commande échoue au paiement, personne ne sait qui doit intervenir. L'agence renvoie vers le prestataire de paiement, celui-ci vers la plateforme, et le marchand perd des ventes pendant que les courriels circulent. Ce point se règle au moment du devis, pas au moment de la panne.

Commencez par poser les trois périmètres. La plateforme fournit le tunnel de commande natif, les points d'extension et les mises à jour de sécurité. Le prestataire de services de paiement, souvent appelé PSP, encaisse, route les transactions, gère l'authentification forte, l'analyse du risque de fraude, les remboursements, les litiges et la réconciliation comptable. L'agence intègre, configure, teste, adapte l'expérience utilisateur et surveille les indicateurs. Trois acteurs, trois responsabilités qui ne se recouvrent pas.

Formalisez ensuite un tableau de responsabilités dans le contrat, en listant les scénarios réels plutôt que les fonctions. Qui intervient quand le taux d'échec de paiement grimpe soudainement ? Qui met à jour le module de paiement lors d'une nouvelle version de la plateforme, et sous quel délai ? Qui traite une commande créée sans paiement encaissé, ou un paiement encaissé sans commande ? Qui reçoit les alertes techniques ? Quel est le délai d'intervention garanti et existe-t-il une astreinte en période de forte activité ?

Les questions à poser aux agences pendant la consultation : quelles intégrations avez-vous déjà réalisées avec mon prestataire de paiement et sur ma plateforme ; qui écrit et exécute le plan de tests, y compris les cas d'authentification refusée et de paiement abandonné ; comment gérez-vous les notifications automatiques envoyées par le prestataire lorsqu'elles échouent ; que se passe-t-il si le module utilisé n'est plus maintenu ; prévoyez-vous un environnement de test permanent, distinct de la production.

Isolez les coûts, car ils sont de nature différente. Les commissions du prestataire de paiement sont un coût variable qui vous est facturé directement et qui n'a rien à faire dans le devis de l'agence. Les licences ou modules constituent un coût récurrent. L'intégration est un coût de projet. La supervision après mise en ligne relève d'un contrat de maintenance. Un devis qui fond ces quatre natures dans un forfait unique vous empêchera de renégocier quoi que ce soit dans un an.

Signaux d'alerte : une agence qui vous impose un prestataire de paiement sans comparer les offres, et qui perçoit une commission d'apport sans le déclarer ; l'absence de plan de tests écrit ; aucun suivi du taux d'acceptation ni du taux d'échec après la mise en ligne ; des messages d'erreur de paiement génériques qui n'expliquent rien au client ; une seule méthode de paiement proposée alors que votre clientèle est mixte ; l'impossibilité de rejouer une transaction en environnement de test.

Côté mesure, suivez un petit nombre d'indicateurs sur un tableau partagé par les trois parties : taux d'aboutissement étape par étape dans le tunnel, taux d'acceptation par moyen de paiement, taux d'échec à l'authentification, part des abandons après affichage des frais de livraison, délai moyen de résolution d'un incident. Ces indicateurs permettent d'objectiver la performance de chacun et de repérer immédiatement à qui incombe un problème.

Enfin, instaurez une revue trimestrielle réunissant votre référent interne, l'agence et le prestataire de paiement, avec un ordre du jour fixe : incidents survenus, évolutions réglementaires, moyens de paiement à ajouter ou à retirer, renégociation des commissions au vu des volumes. Trente minutes par trimestre suffisent, et ce rituel évite la situation la plus coûteuse pour un marchand : découvrir un problème de paiement le jour de son pic de ventes.