Dans la Fintech, le choix d’un Payment Service Provider (PSP) est souvent perçu comme une décision technique. En réalité, c’est un levier stratégique majeur pour un Product Manager ou un fondateur : il influence directement la conversion, la sécurité et la capacité d’évolution du produit.

Bien comprendre les enjeux du paiement permet donc de faire un choix aligné avec les ambitions de croissance et de scalabilité de son produit.

Dans cet article, David, CTO chez Matters depuis 11 ans ayant accompagné de nombreuses fintech et plateforme e-commerce comme Blank, YesYes, Knave ou encore Carrefour sur une offre de cashback va vous guider pour identifier les bons critères de décision et éviter les erreurs qui freinent la croissance dès les premières étapes.

1. Sous le capot : Comment fonctionne réellement un paiement ?

Derrière l’action de paiement sur un site e-commerce, une chorégraphie complexe s’exécute entre quatre acteurs principaux.

• Le PSP (Payment Service Provider) : C’est l’interface entre votre plateforme et le système de paiement. Il agrège les moyens de paiement (CB, Apple Pay, PayPal…), fournit l’infrastructure technique (API, SDK) et organise le flux de paiement entre les différents acteurs. Exemples : Stripe, Adyen, Checkout.com.
• L’acquéreur (banque acquéreuse) : C’est l’institution financière qui traite le paiement pour le compte du marchand et interagit avec les réseaux de cartes pour demander l’autorisation.
• Le réseau (schemes) : Les “autoroutes” du paiement comme Visa, Mastercard ou CB. Ils acheminent les demandes d’autorisation entre la banque du marchand et celle du client.
• L’émetteur (banque du client) : C’est la banque du porteur de carte. Elle vérifie la transaction (solde, fraude, authentification forte type 3D Secure) et donne la validation finale.

‍

‍

Le parcours d'une transaction

Concrètement, pour un paiement par carte :

Phase 1 - La demande d'autorisation

• Le client arrive sur la page de paiement du site (le checkout), saisit son numéro de carte, la date d'expiration et le code à trois chiffres au dos.
• Le PSP reçoit ces informations et les sécurise en les transformant en un jeton chiffré (tokenisation), puis transmet une demande d'autorisation à l'acquéreur.
• L'acquéreur fait suivre la demande au réseau de cartes (Visa, Mastercard, CB), qui interroge la banque du client.
• La banque vérifie que le compte est suffisamment approvisionné, que la carte est valide, et peut demander au client de confirmer son identité via son application bancaire (c'est le 3D Secure).
• Si tout est en ordre, la banque autorise la transaction. La réponse remonte toute la chaîne en quelques centièmes de seconde.

À ce stade, aucun argent n'a bougé. La banque du client a simplement réservé le montant, il apparaît souvent comme "en attente" sur le relevé bancaire.

Phase 2 - Le mouvement des fonds

• Capture : Quelques heures ou jours plus tard, le marchand confirme qu'il souhaite effectivement encaisser le montant. Sur un site e-commerce, c'est typiquement déclenché au moment de l'expédition du colis.
• Clearing : Les banques des deux côtés (celle du client et celle du marchand) échangent les informations via le réseau de cartes et calculent les frais qui reviennent à chaque acteur de la chaîne.
• Settlement : Les fonds, nets de frais, sont versés sur le compte du marchand. Selon le PSP, ce délai varie d'un à sept jours ouvrés.

Le cycle complet : autorisation → capture → clearing → settlement. La première étape prend quelques secondes. Les trois suivantes prennent quelques jours.Tous les PSP ne gèrent pas ces mécanismes de la même manière, en particulier sur les moyens de paiement alternatifs (wallets, virements instantanés, BNPL, etc.), qui introduisent des logiques différentes.

Enfin, un PSP moderne doit orchestrer une grande diversité de méthodes de paiement : cartes, wallets (Apple Pay, Google Pay, PayPal), virements SEPA et instantanés, ou encore solutions de type BNPL (Klarna, Alma, Scalapay). C’est souvent dans la gestion de ces spécificités que les différences entre PSP deviennent réellement visibles.

‍

2. Time-to-Market : Les erreurs classiques qui freinent votre lancement

Sous-estimer la qualification réglementaire

Un produit qui encaisse pour son propre compte (e-commerce classique) n’a pas les mêmes contraintes qu’un produit qui encaisse pour le compte de tiers (marketplace, plateforme collaborative, néo banque, etc).

Dans le second cas, on entre dans le champ des services de paiement régulés : il faut soit obtenir un agrément d’établissement de paiement, soit passer par un PSP agent (Lemonway, Mangopay, Stripe Connect, Adyen for Platforms) capable de gérer la ségrégation des fonds et le KYC des bénéficiaires.

Confondre ces deux modèles dès la phase de design conduit très souvent à une refonte architecturale complète de la brique paiement quelques semaines avant le lancement.

Négliger le KYC/KYB et l'onboarding marchand

Sur les modèles marketplace ou multi-vendeurs, l’onboarding des vendeurs (KYB pour les entreprises, KYC pour les particuliers) est un parcours produit à part entière.

Tous les PSP n’offrent pas le même niveau de flexibilité sur les parcours, ni les mêmes délais de validation ou exigences documentaires. Un KYC qui prend 5 jours ouvrés au lieu de 24h peut ralentir l’ expérience d'onboarding et par la même occasion réduire votre taux de conversion.

Oublier la gestion des échecs

Un taux d’autorisation de 85 % contre 92 % à volume égal représente une perte directe de chiffre d’affaires.

Pourtant, beaucoup d’équipes intègrent trop tard des mécanismes essentiels comme le retry intelligent, la mise à jour automatique des cartes expirées ou le renouvellement d’abonnements en erreur, les prélèvements récurrents qui échouent ou la gestion des cartes expirées. Ces briques, souvent sous-estimées, ne sont pas uniformément proposées par les PSP ou sont facturées en supplément.

Choisir sur le prix affiché

La grille tarifaire “visible” (ex : 1,4 % + 0,25 €) est rarement représentative du coût réel.

En pratique, le coût total inclut : scheme fees, frais 3DS, chargebacks, remboursements, frais de payout, minimums mensuels, et surtout les conditions de négociation liées au volume.

Et un point souvent sous-estimé en cas de paiement hors-euro : la gestion des devises (FX). Le simple choix de la devise peut faire varier significativement les marges, via les taux de change et les FX markups appliqués (souvent autour de 2% selon les PSP). Sur des volumes internationaux, ce “détail” devient un levier majeur de rentabilité.

Ignorer la réversibilité

Un PSP stocke les tokens de carte de vos clients. Migrer ces tokens vers un autre fournisseur est possible (processus PCI de “card migration”), mais rarement simple, ni rapide, ni gratuit.

Tous les PSP n’acceptent pas la sortie de ces actifs, ce qui peut créer un verrou technologique fort.

Anticiper cette portabilité dès l’intégration, voire envisager une stratégie multi-PSP, permet d’éviter une dépendance structurelle difficile à corriger. Au-delà de la simple abstraction technique, une orchestration de paiement permet également d’optimiser la performance des transactions (via le routage intelligent ou le failover), tout en centralisant la gestion des règles métiers et du monitoring.

Traiter la fraude comme une option

La fraude n’est pas un sujet secondaire : c’est un composant structurant de l’architecture de paiement.
Les outils natifs (ex: Stripe Radar, Adyen RevenueProtect) permettent de démarrer rapidement mais à mesure que la solution évolue d’autres outils peuvent s’avérer nécessaires pour aller plus loin.

Au-delà de la fraude avérée, un enjeu souvent sous-estimé est celui des faux positifs : des transactions légitimes refusées à tort. Plutôt restrictives, les règles de détection peuvent parfois dégrader le taux de conversion et générer une perte de revenus difficile à déceler. 

Ne pas intégrer la fraude dès la conception, c’est donc non seulement s’exposer au risque, mais aussi risquer de pénaliser sa propre croissance.

3. Comment choisir son PSP selon son modèle

Il n’existe pas de “meilleur PSP” dans l’absolu. Le bon choix dépend de votre modèle économique, de votre géographie, de votre niveau de maturité produit et de la feuille de route produit à 18-24 mois.

Plutôt que de raisonner uniquement en liste de fonctionnalités, il est souvent plus utile de se représenter les PSP comme des logiques produit différentes :

‍

‍

En pratique, votre choix dépend surtout de 4 questions simples : Suis-je en phase de lancement rapide ou de scalabilité ? Mon modèle est-il e-commerce, SaaS ou marketplace ? Ai-je une exposition internationale forte dès le départ ? Mon enjeu principal est-il la vitesse, la performance ou le contrôle ?

Et surtout : il n’y a pas de bon choix sans projection. Un PSP n’est pas seulement un outil d’encaissement, c’est une brique structurante de votre modèle économique. Ce qui fonctionne en phase 1 peut devenir un frein en phase 2. Si vous êtes face à ce type de dilemme… choisir, comparer ou refondre votre stack de paiement n’est pas seulement une décision technique c’est un choix structurant pour votre croissance.

Chez Matters, on vous aide à clarifier votre stratégie de paiement selon votre modèle, sélectionner le PSP le plus adapté à votre trajectoire, et surtout, l’implémenter concrètement dans votre produit. On s’en parle ? 

‍

‍