Les PSP de paiements transfrontaliers évoluent dans l'ère multi-pistes

Article écrit par A Wang, Web3 Xiao Lü

Les paiements numériques sont entrés dans la mainstream, mais les règlements ne le sont pas encore.

C'est l'avis de Dan Mottice, ancien cadre de Visa et fondateur de Beam. Les transactions Visa sont autorisées dans n'importe quel commerçant du monde, mais le règlement sous-jacent continue de passer par SWIFT — agrégant les transactions par lots, transférant des fonds par virement transfrontalier, en passant par la réglementation locale, les jours fériés et plusieurs intermédiaires, avant que le commerçant n'attende le paiement. Ce n'est pas un problème de Visa, mais une dette structurelle de l'ensemble du secteur. Et les PSP en sont le point le plus concentré.

Cet article se concentre sur les fournisseurs de services de paiement (PSP), qui sont passés d’un simple outil de collecte de paiements à une couche d’infrastructure centrale pour la gestion des flux de fonds, le règlement et la comptabilité. Ils ont été initialement conçus pour une ère plus simple — un système à une seule voie, des processus de transaction linéaires et une infrastructure fortement intégrée.

Dans l'environnement de paiement moderne, un « paiement » n'est plus une transaction unique, mais une série de changements d'état impliquant plusieurs parties prenantes et canaux de paiement. Aujourd'hui, un paiement peut impliquer : une application grand public, un PSP, un fournisseur de services anti-fraude et de vérification d'identité, une banque custode, un ou plusieurs canaux de paiement, ainsi que les systèmes de comptabilité internes de l'entreprise.

Les entreprises doivent prendre en charge simultanément les cartes bancaires, l'ACH, les virements bancaires, le RTP, le FedNow, ainsi qu'un nombre croissant de règlements basés sur des stablecoins. Chaque canal présente des délais de règlement, des modes de défaillance, des formats de données et des exigences opérationnelles différents.

Cet article compile le guide de Modern Treasury et examinera comment les PSP ont évolué, comment leur architecture sous-jacente doit s'adapter aux systèmes de paiement modernes, ainsi que la stratégie que les équipes développant des produits de paiement doivent adopter lors du choix de leur prochain PSP.

Jugement principal

01｜Le paiement numérique est entré dans la mainstream, mais pas le règlement. Visa vous permet d'effectuer une autorisation chez n'importe quel commerçant du monde, mais le règlement sous-jacent continue de passer par SWIFT. L'interface est résolue, la couche fondamentale ne l'est pas.

02｜PSP effectue le paiement, mais ne explique pas le flux de fonds. Stripe vous indique ce qui s'est passé dans sa partie, mais ne peut pas vous dire l'état réel de cet argent à ce moment-là. La couche d'exécution et la couche d'enregistrement sont deux choses différentes.

03｜Chaque voie de paiement est un système opératoire indépendant, pas une variante d’un même modèle. ACH peut être annulé, RTP non ; les réseaux de cartes peuvent faire l’objet de contestations, les stablecoins sont confirmés de manière définitive sur la chaîne. La couche d’abstraction des PSP masque ces différences, mais seulement jusqu’à ce qu’un problème survienne.

04｜ Les paiements en temps réel éliminent les tampons ; le contrôle doit être déplacé en amont. Les logiques de gestion des risques, d'approbation et de rapprochement des PSP traditionnels supposent qu'il reste du temps pour corriger les erreurs. RTP et FedNow rendent cette hypothèse obsolète. Les décisions doivent être prises avant le déplacement des fonds, et non après.

05｜Les stablecoins sont un canal de règlement, pas un nouveau moyen de paiement. Ils ne résolvent pas les problèmes liés à l’interface de paiement, mais la latence entre la « finalisation de la comptabilisation » et le « crédit réel » sur le compte. Le chemin d’adoption le plus concret est une structure en sandwich : entrée en monnaie fiduciaire, circulation sur chaîne, sortie en monnaie fiduciaire — les utilisateurs aux deux extrémités n’ont pas besoin de comprendre les stablecoins.

06｜ Les fonds en transit peuvent générer des revenus, ce qui est presque inexistant dans les systèmes traditionnels. Dans les paiements transfrontaliers, les fonds sont bloqués pendant 24 à 72 heures avant règlement, sans aucun rendement et en occupant du capital d'exploitation. Les stablecoins permettent pour la première fois de générer de la valeur sur les fonds en circulation.

07｜ Le plus grand échec de l'exploitation des paiements est l'incapacité à répondre à une question simple : Où est passée cette somme d'argent ? La réconciliation, la gestion des anomalies et la gestion de la liquidité — ces problèmes ne surgissent pas au moment de l'initiation du paiement, mais après coup. Sans couche de coordination unifiée, chaque fournisseur ne peut vous raconter que sa propre partie de l'histoire.

08｜Le véritable risque stratégique n'est pas d'utiliser ou non des stablecoins. C'est que vos concurrents réinventent leurs coûts de règlement et leur efficacité financière grâce aux stablecoins, tandis que vous attendez le moment parfait pour entrer.

I. Évolution historique du PSP

Au cours des vingt dernières années, le rôle de PSP a subi un changement fondamental.

Au début du commerce électronique, les PSP fonctionnaient principalement comme des passerelles de paiement. Leur rôle était simple : relier les commerçants aux réseaux de cartes et aux banques acquéreuses afin d'autoriser et de régler les transactions.

Ces systèmes PSP ont été conçus pour un monde très spécifique. Les paiements sont principalement effectués par carte, transitent par un seul compte marchand et suivent un cycle de vie linéaire allant de l'autorisation à la règlementation. Les PSP sont optimisés pour traiter efficacement les transactions dans ce modèle.

Au cours des années 2010, les marketplace, les plateformes SaaS et les produits de fintech ont commencé à intégrer directement les paiements dans leurs produits. Les plateformes devaient gérer l’inscription des utilisateurs, le fractionnement des paiements entre plusieurs parties et la gestion des versements. Les PSP ont ainsi évolué en introduisant l’inscription des commerçants, des infrastructures de versement et des outils de prévention de la fraude.

Cependant, malgré l'expansion continue des capacités du PSP, son architecture sous-jacente repose toujours sur un modèle conçu pour des processus de paiement linéaires — principalement optimisé pour le traitement des transactions, et non pour la coordination de mouvements de fonds complexes à plusieurs étapes à travers plusieurs fournisseurs et canaux.

Au début des années 2020, les entreprises ont commencé à opérer sur plusieurs pistes, dans de multiples régions et dans divers scénarios. Les PSP traditionnels continuaient de regrouper de nombreux composants, permettant aux entreprises d’interagir avec une seule plateforme. Mais à mesure que les processus de paiement devenaient plus complexes, un processus de paiement pouvait traverser plusieurs étapes : vérification d’identité, analyse des risques, prise de décision financière, exécution de la piste, suivi interne.

Cette transition a fait évoluer le rôle des PSP de « connecteurs » à « coordinateurs », mais leur architecture n'a pas évolué au même rythme.

The result is: PSPs still handle fund transfers, but operate within a more complex, full transaction payment lifecycle.

Deuxième partie : Stack technologique moderne de paiement PSP

Pour comprendre les limites du PSP, il faut d'abord comprendre l'environnement de paiement plus large dans lequel il s'inscrit.

2.1 Stack technologique PSP

L'environnement de paiement moderne n'est pas une seule plateforme ou un seul fournisseur de services, mais un ensemble de composants d'infrastructure hiérarchisés qui soutiennent ensemble le déplacement, le règlement et la comptabilisation des fonds.

Couche application : plateformes e-commerce de paiement, Marketplace, applications de technologie financière, produits SaaS intégrant des paiements.

Niveau PSP : responsable de l'exécution des instructions de paiement, telles que le routage des transactions vers les réseaux de cartes, le lancement de virements bancaires ou l'intégration aux canaux de paiement. Dans la plupart des cas, cette complexité sous-jacente est abstraite derrière l'interface du PSP, permettant à l'utilisateur d'interagir avec un seul système plutôt que directement avec les multiples fournisseurs impliqués.

Couche de conformité : Les processus de paiement modernes dépendent également de fournisseurs d'authentification d'identité, d'outils de détection de fraude et d'infrastructures de conformité, qui déterminent si un paiement doit être autorisé à progresser.

Niveau bancaire : La banque custode détient les fonds, fournit des comptes réglementés et permet l'accès aux réseaux de paiement tels que ACH, virement bancaire, RTP et FedNow.

Couche de réconciliation interne : système utilisé par les entreprises pour suivre les soldes, indiquer l'état des transactions et maintenir des enregistrements cohérents des activités financières.

Chacune de ces couches joue un rôle dans le déplacement des fonds, mais aucune ne fournit une image complète de ce qui se passe réellement après l'initiation d'un paiement. C'est précisément pourquoi la couche de réconciliation interne devient indispensable.

2.2 Synchronisation et asynchronisation

Les PSP traditionnels présentent un défaut de conception fondamental : ils se contentent d'envoyer l'argent, sans suivre ce qui se passe après.

Le problème réside dans le fait que « après l'envoi » est précisément la partie la plus complexe du paiement.

La logique de l'API PSP est synchrone — vous envoyez une commande et elle retourne un résultat. Mais les flux de fonds réels sont asynchrones : le règlement est effectué ultérieurement, les échecs apparaissent avec retard, et les remboursements ou les corrections peuvent être réinjectés à tout moment. Ce déséquilibre crée une faille informationnelle persistante.

La manifestation concrète du trou noir est la fragmentation d'état :

Aucun nœud ne peut vous dire quel est l'état réel de cet argent en ce moment.

À titre d’exemple avec le retrait d’un vendeur sur une plateforme de marché, le processus complet constitue une chaîne longue : vérification de l’éligibilité → conformité et gestion des risques → confirmation des fonds → émission d’une instruction → exécution sur le réseau → retour de confirmation → règlement postérieur → mise à jour du registre. Le PSP ne couvre que quelques étapes intermédiaires ; les décisions initiales et le rapprochement final ne relèvent pas de sa responsabilité. En cas d’échec ou de remboursement de ce virement, aucun système ne peut fournir une réponse complète.

C’est précisément le rôle de la couche de réconciliation interne : elle ne remplace pas le PSP dans l’exécution des paiements, mais établit au-dessus de toute la chaîne une couche d’observation unifiée — traduisant en continu des événements asynchrones provenant de différents fournisseurs, à des moments différents et dans des formats variés, en un seul état fiable au sein de l’entreprise. Quel que soit le nombre d’étapes intermédiaires parcourues par l’argent, il existe toujours un endroit capable de répondre à la question fondamentale : où se trouve exactement cet argent, maintenant ?

Trois. Limites de paiement des PSP traditionnels

La couche d'abstraction des PSP traditionnels est construite autour des paiements par carte bancaire : autorisation, capture, règlement — un cycle de vie prévisible. Bien qu'il existe des exceptions (comme les litiges et les rétrofacturations), la structure globale est prévisible et bien comprise. Ce modèle a façonné la conception des PSP.

Avec l'émergence de nouveaux modes de paiement, les PSP étendent leur prise en charge à davantage de canaux, mais ces canaux se comportent différemment des cartes bancaires et ne respectent pas les mêmes hypothèses :

• Virement ACH : un délai a été introduit, ainsi qu'une possibilité de rétrofacturation pouvant survenir plusieurs jours après l'initiation du paiement.
• Wire transfer: Faster settlement, but typically requires manual processes and higher costs.
• Les réseaux de paiement en temps réel tels que RTP et FedNow : permettent le transfert immédiat des fonds, mais les transactions sont généralement irrévocables une fois effectuées.
• Transferts de stablecoins : fonctionnent sur des infrastructures complètement différentes, avec des mécanismes de garantie et des considérations opérationnelles distincts.

Par exemple, avec un virement d'une entreprise américaine à un fournisseur philippin :

• Via ACH, livraison en T+2, mais les banques des Philippines ne reçoivent pas directement les virements ACH ; un transfert intermédiaire via un réseau local est nécessaire, ce qui peut retarder la livraison à T+4. Pendant cette période, le virement peut être rejeté à tout moment en raison d'un désaccord des informations de compte.
• Par virement bancaire, plus rapide, mais soumettez-le avant la coupure de 15 h, reporté en cas de jour férié. Les frais SWIFT s'élèvent à 25 $ à 45 $, et la banque du bénéficiaire peut également prélever des frais intermédiaires, ce qui fait que le montant reçu ne correspond pas au montant envoyé.
• Utilisez le sandwich de stablecoin : USDC est envoyé depuis un compte américain, confirmé en quelques secondes sur la chaîne ; après réception, votre partenaire aux Philippines le convertit en pesos et le dépose sur un compte local — tout le processus prend moins d’une heure et coûte moins de 1 % du montant transféré.

Trois chemins, le même montant d'argent, un délai de règlement de 96 heures, un coût différent de plusieurs dizaines de dollars et une traçabilité complètement différente. Ce n'est pas une différence d'expérience produit, mais une différence entre trois systèmes d'exploitation. La couche d'abstraction du PSP ne peut pas masquer ces différences ; elle ne fait que les transférer aux développeurs et aux équipes opérationnelles pour qu'ils les gèrent.

Ce ne sont pas des variantes du même modèle de paiement, mais des modèles opérationnels fondamentalement différents.

La réponse des PSP traditionnels consiste à exposer des API et des définitions d'état différentes pour chaque piste — sans unifier réellement les différences, mais en les transférant aux développeurs. Les équipes techniques ont commencé à écrire des logiques spécifiques pour chaque piste, les équipes opérationnelles à gérer manuellement les différents modes de défaillance, et les équipes financières à effectuer des rapprochements pour des transactions similaires suivant des chemins complètement différents.

C'est une fuite d'abstraction : la complexité des pistes censées être masquées commence à s'infiltrer au niveau de l'application.

Au fur et à mesure que de nouvelles voies sont ajoutées, l’environnement de paiement devient une série d’intégrations lâchement connectées, plutôt qu’une couche abstraite unifiée. Sur les voies plus lentes, la latence offre une fenêtre de temps pour détecter les problèmes. Sur la voie en temps réel, cette fenêtre disparaît — les paiements sont réglés en quelques secondes, les erreurs ne peuvent pas être facilement annulées, et les décisions doivent être prises avant le déplacement des fonds, et non après.

Quatrièmement, les paiements en temps réel obligent les PSP à déplacer le contrôle en amont.

La transition vers un réseau de paiement en temps réel ne fait pas seulement accélérer la vitesse des flux de fonds — elle modifie fondamentalement les exigences de conception de l'infrastructure de paiement.

À l'époque des ACH et des virements bancaires, le temps est un tampon.

Les transactions ACH peuvent nécessiter plusieurs jours pour être réglées, les transactions par carte bancaire peuvent faire l'objet d'une contestation après autorisation, et les virements bancaires impliquent souvent des étapes de vérification manuelle. Ces délais, bien qu'ils entraînent une perte d'efficacité, offrent également l'opportunité de détecter des erreurs, d'intervenir en cas d'activité suspecte et de réaliser les rapprochements avant la finalisation du règlement.

Le modèle PSP traditionnel est précisément construit autour de ce tampon.

Cependant, des réseaux de paiement en temps réel tels que RTP et FedNow ont complètement remis en question cette hypothèse. Les fonds circulent directement entre comptes en quelques secondes, et les paiements sont généralement irréversibles une fois effectués.

• La détection de fraude doit être effectuée plus tôt
• Le filtrage de conformité doit être effectué en temps réel
• Les décisions de financement doivent être prises avec précision à l'instant de la libération du paiement.
• L'occasion de corriger les erreurs après coup n'existe plus

Les plateformes offrant des paiements instantanés ne peuvent pas s'appuyer sur des flux de travail conçus pour des règlements différés. Les systèmes internes d'entreprise gérant les fonds de paiement sur plusieurs comptes ne peuvent pas déterminer instantanément la liquidité. Les équipes de service client ne peuvent pas garantir la réversibilité lorsque les infrastructures sous-jacentes ne le permettent pas.

Le résultat est un transfert de responsabilité : les PSP doivent évoluer pour soutenir les systèmes internes qui déterminent quand le paiement doit être exécuté. Autrement dit, le contrôle doit être déplacé en amont.

L'infrastructure de paiement doit être conçue de manière à ce que l'approbation, la logique de financement, la vérification des risques et la validation d'état soient effectuées avant le déplacement des fonds, et non après. Cela exige une vision plus coordonnée des soldes, de l'état des transactions et des conditions inter-providers que ce que les architectures PSP traditionnelles peuvent offrir.

L'orbite en temps réel n'est pas un état final, mais un point de bascule. L'arrivée des stablecoins élèvera davantage la problématique.

V. Les stablecoins : un nouveau parcours, pas un nouveau moyen de paiement

Le point le plus souvent mal compris concernant les stablecoins est de les considérer comme un nouveau produit de paiement. Ce n’est pas le cas. Ce sont une nouvelle voie de règlement, destinée à résoudre le délai entre la « finalisation de la comptabilisation » et le « crédit effectif des fonds ».

Contrairement aux cartes, ACH et virements bancaires, les transactions en stablecoins fonctionnent sur des réseaux blockchain :

• The settlement is ongoing, not batched.
• Confirmation finale quasi instantanée (dépend du réseau)
• Fonctionne 7j/7 et 24h/24, sans restriction de horaires de fin de banque ni de jours fériés
• Not dependent on specific domestic payment systems
• Les primitives pour suivre les soldes, la propriété et l'historique des transactions sont totalement différentes

L'architecture traditionnelle des PSP est construite autour de l'intégration avec les banques et les réseaux de paiement, tandis que les stablecoins introduisent des réseaux indépendants de ces intermédiaires. La création, le règlement et la tenue des comptes se produisent en dehors de la conception d'origine. Une entreprise peut avoir besoin de coordonner simultanément les canaux bancaires, les réseaux en temps réel et les règlements sur chaîne, chaque type ayant des hypothèses différentes en matière de finalité, de temporisation et de contrôle — ces différences ne peuvent pas être unifiées par une seule API, rendant de plus en plus difficile la position des PSP en tant que couche d'abstraction unique.

Comme les systèmes de paiement en temps réel remettent en question les hypothèses concernant la séquence et la révocabilité, les stablecoins remettent en question les hypothèses concernant l'endroit et la forme où les paiements ont lieu.

During this process, they introduced a new layer of complexity.

Le sandwich de stablecoin est le chemin le plus pratique actuel : fiat entrant → circulation sur chaîne → fiat sortant.

Les clients et fournisseurs aux deux extrémités n'ont pas besoin de comprendre les stablecoins ; les stablecoins ne servent que de canal intermédiaire, spécifiquement conçu pour résoudre les problèmes de lenteur, de coût élevé et d'instabilité des règlements transfrontaliers traditionnels. Les applications les plus précieuses se concentrent sur les « canaux difficiles » : les scénarios transfrontaliers où les méthodes traditionnelles sont lentes, coûteuses ou tout simplement inaccessibles.

Les entreprises ne devraient pas et ne le feront pas tout miser sur les stablecoins ; le chemin réaliste consiste à sélectionner un ou deux cas d'utilisation spécifiques pour un remplacement partiel, puis à étendre après avoir établi une compréhension.

Les stablecoins apportent également une dimension supplémentaire : les revenus générés pendant le transit des fonds, presque inexistants dans les systèmes traditionnels. Dans les processus de paiement traditionnels, les fonds mettent entre 24 et 72 heures pour passer de l'émetteur au destinataire, sans générer de revenus tout en bloquant du capital d'exploitation. Les stablecoins sur chaîne peuvent générer des revenus pendant leur transit — ce n'est pas une simple optimisation des coûts de paiement, mais une refonte de l'ensemble du modèle d'efficacité des fonds.

Six : Écosystème actuel : dix niveaux de spécialisation et le niveau manquant

Au fur et à mesure que les infrastructures de paiement s'étendent à davantage de canaux, de fournisseurs et de types d'infrastructures, la définition du rôle des PSP devient de plus en plus difficile.

Les responsabilités de mouvement de fonds, autrefois regroupées au sein d'un seul PSP, sont désormais réparties sur plusieurs niveaux de la pile technologique.

Le rôle du PSP ne se limite plus à déplacer des fonds, mais consiste à expliquer le flux des fonds.

Ce changement reflète une transformation plus profonde : l'exécution ne suffit plus. Les PSP doivent désormais soutenir les systèmes internes des entreprises pour leur permettre de représenter, comptabiliser et rapprocher le flux des fonds à travers différents environnements.

① Plateforme de niveau produit : Intégrer les paiements dans le logiciel

Les plateformes logicielles verticales telles que Shopify, Square, Toast, Mindbody, ServiceTitan et Housecall Pro intègrent directement les paiements dans leurs produits.

Dans ces scénarios, le paiement est intégré à l'expérience application, et non traité comme un système de paiement indépendant. Ces plateformes s'appuient généralement sur des PSP sous-jacents, des partenaires bancaires et des fournisseurs d'infrastructure, ajoutant une couche d'abstraction supplémentaire entre l'application et le flux de fonds.

② Couche d'exécution : transfert de fonds entre pistes

Le cœur de la pile technologique est constitué des fournisseurs de services de paiement responsables de l'exécution des paiements. Cela inclut des PSP traditionnels tels que Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei et dLocal, dont le rôle consiste à connecter les entreprises aux réseaux de paiement et à faciliter le transfert de fonds.

Ils restent des composants clés de la pile de paiement, mais opèrent principalement au niveau de l'exécution — ils initient les paiements, rapportent les statuts et exposent des API, mais ne fournissent pas eux-mêmes un modèle complet de la manière dont les fonds circulent entre les fournisseurs et les systèmes internes.

Vous demandez à Stripe « Où est cet argent exactement maintenant ? », et elle ne peut vous dire que ce qui s'est produit dans sa propre partie. Stripe n'est qu'un nœud parmi d'autres ; cette transaction peut impliquer cinq ou six étapes, notamment un PSP, une banque, un réseau, des livres internes, mais ce qu'elle voit est toujours partiel, pas global.

③ Couche d'organisation et de routage : connexion aux fournisseurs d'exécution

À mesure que les entreprises adoptent plusieurs PSP et méthodes de paiement, des plateformes d'orchestration émergent pour gérer le routage entre prestataires. Des entreprises telles que Primer, Gr4vy, Spreedly, Paydock et CellPoint Digital permettent aux entreprises de diriger les transactions en fonction de la région, du coût ou des performances. Ces systèmes augmentent la flexibilité au niveau de l'exécution, mais ne fournissent pas de modèle unifié pour les comportements après l'initiation du paiement.

④ Couche de gestion des risques et de conformité : décide si les fonds doivent être déplacés

Un ensemble de fournisseurs indépendants sont chargés de déterminer si le paiement doit être autorisé à progresser. Les systèmes d’authentification d’identité, de détection de fraude et de conformité de fournisseurs tels que Persona, Sardine, Alloy, Unit21, Sift et Sumsub évaluent les utilisateurs et les transactions avant exécution. Dans un environnement en temps réel, ces décisions doivent être prises avant tout mouvement de fonds ; les contrôles clés sont donc déplacés en dehors du PSP.

⑤ Couche d'infrastructure bancaire : détient les fonds et permet l'accès

Les banques custodiales telles que Cross River Bank, Lead Bank, Column et Sutton Bank offrent des comptes réglementés et un accès aux réseaux de paiement. Elles détiennent les fonds des clients, gèrent la liquidité et servent de passerelle vers des systèmes tels que ACH, virements bancaires, RTP et FedNow. Cette couche est essentielle pour l'accès au système financier, mais fonctionne indépendamment de la logique applicative et des API PSP.

⑥ Niveau d'émission de cartes : extension des fonctionnalités de paiement

Les plateformes d'émission de cartes telles que Marqeta, Lithic et Rain permettent aux entreprises d'émettre des cartes de débit et de crédit en tant que partie intégrante de leurs produits, en soutenant des scénarios d'utilisation tels que la gestion des frais, les cartes d'entreprise et la consommation sur les marchés. Les plateformes d'émission relient les banques et les réseaux de cartes, mais opèrent comme une couche indépendante dans la pile technologique, introduisant des flux de travail, des mécanismes de contrôle et des états supplémentaires qui nécessitent une coordination avec les autres composants de la pile de paiement.

⑦ Couche de paiement : réseau d'exécution sous-jacent

Les voies de paiement sont des réseaux permettant de transférer des fonds entre institutions financières. Les voies traditionnelles incluent ACH, les virements bancaires et les réseaux de cartes, tandis que de nouveaux réseaux tels que RTP et FedNow permettent un règlement en temps réel. Chaque voie repose sur des hypothèses différentes en matière de temporisation, d'irrévocabilité et de révocabilité, créant des incohérences que les PSP doivent exposer ou contourner (et non entièrement abstraire).

⑧ Couche réseau des stablecoins : Extension au-delà de l'infrastructure bancaire

Les réseaux de stablecoins tels qu’Ethereum, Solana, Polygon et Base ont introduit une nouvelle forme d’infrastructure de paiement fonctionnant en dehors du système bancaire traditionnel. Ces réseaux permettent le transfert de dollars numériques sur une infrastructure mondiale, en utilisant différents modèles de règlement et mécanismes de garantie. Ils étendent la portée des systèmes de paiement au-delà des canaux bancaires, ajoutant une couche de complexité supplémentaire qui doit être intégrée dans les flux de travail existants.

⑨ Couche Bank-as-a-Service : relier les applications aux banques

Les plateformes de banking-as-a-service (BaaS) telles que Unit, Galileo et Treasury Prime fournissent l'infrastructure pour relier les applications fintech à des banques réglementées. Elles permettent aux entreprises d'offrir des comptes, des cartes et des capacités de paiement sans avoir à devenir une banque. Ce niveau simplifie l'accès à l'infrastructure bancaire, mais ajoute une autre partie intermédiaire entre l'application, le PSP et les flux de fonds sous-jacents.

⑩ La couche manquante : un PSP unifié couvrant tout le cycle de vie des flux de fonds

En observant les neuf niveaux ci-dessus, la règle est cohérente : chaque fournisseur gère une fonction spécifique, et aucun ne peut offrir une vision complète du flux de fonds — y compris sa compréhension, son contrôle et son rapprochement.

L'exécution est gérée par un fournisseur, les décisions de risque par un autre, et les fonds sont détenus en banque ; le processus de paiement peut s'étendre à travers des réseaux de cartes, des canaux en temps réel et des systèmes sur chaîne. Chaque système expose des données, des calendriers et des définitions d'état différents.

Dans un environnement fragmenté, ce problème ne se manifeste pas au stade de l'initiation — il apparaît après coup : lorsque le système présente des divergences, que les fonds sont retardés ou remboursés, ou que l'équipe a besoin de réponses. C'est précisément là que le système de paiement commence à s'effondrer.

Sept. Où la gestion des paiements échoue

Vendredi à 14h55, l'équipe financière a soumis un virement bancaire de 50 000 $ à un fournisseur. À 15h00, la coupure des virements bancaires. Le système affiche « Soumis », mais aucun e-mail de confirmation n'est arrivé.

À 16 heures, le fournisseur a envoyé un message pour demander l'état du paiement. La comptabilité a consulté l'interface PSP, qui affichait « En cours de traitement ». Elle a ensuite vérifié le compte bancaire, qui affichait « En attente de règlement ». Deux systèmes, un même paiement, deux états différents, aucun ne permettant de déterminer à quel niveau se trouve l'argent.

À 17 heures vendredi, le service client de la banque ferme. Les fournisseurs attendent l'organisation du paiement pour la livraison du week-end. L'équipe financière ne sait pas quoi dire aux fournisseurs, ni si l'argent arrivera automatiquement lundi matin ou s'il a été retourné et doit être réexpédié.

Ce n'est pas une situation extrême, c'est un scénario que l'équipe d'exploitation des paiements vit chaque semaine. Il n'apparaît pas dans le manuel produit du PSP, mais il figure dans les registres de travail de chaque équipe de paiements transfrontaliers.

Les problèmes les plus délicats dans les paiements se situent souvent non pas au moment de l'initiation, mais après coup — lorsque l'équipe doit expliquer ce qui s'est réellement passé.

La carte du marché du chapitre précédent a révélé l'étendue de l'écosystème de paiement. Un paiement apparemment simple traverse souvent plusieurs fournisseurs de la pile technologique avant que le règlement ne soit effectué. Chaque partie peut avoir une représentation différente du même mouvement de fonds, avec des séquences temporelles différentes, des états différents, des documents qui arrivent selon des calendriers distincts, et des anomalies signalées via des canaux variés.

C'est précisément là où les opérations de paiement deviennent difficiles.

Reconciliation : plusieurs versions du même événement

L'équipe financière doit faire correspondre les livres internes avec les relevés bancaires, les rapports de règlement et les données des traiteurs. Si un fournisseur indique qu'un paiement est terminé, tandis qu'un autre indique qu'il est encore en cours, l'entreprise a besoin d'un modèle pour résoudre ces écarts. Si un remboursement arrive après que le solde interne a déjà été mis à jour, le livre doit être annulé ou ajusté en conséquence.

Gestion des exceptions : pannes sans attribution claire

Un retrait peut échouer en raison d'un compte destinataire invalide, de l'utilisation d'un compte de fonds incorrect, d'une suspension due à une vérification de conformité ou du dépassement du délai de traitement. Ces échecs ne sont pas identiques et ne se produisent pas en même temps. Toutefois, les utilisateurs s'attendent toujours à obtenir une réponse cohérente, et les équipes internes doivent toujours gérer le processus.

Liquidity and funding: The money is in the wrong place

Les entreprises qui opèrent sur plusieurs fournisseurs et comptes doivent s'assurer que les fonds corrects apparaissent au bon moment sur le bon compte. Même si le solde global est suffisant, si les fonds restent sur un compte incorrect, l'exécution des paiements peut échouer — créant ainsi un écart entre la logique produit et la réalité opérationnelle.

Auditabilité et contrôle : Rétablir ce qui s'est produit

Les opérations d'approbation, de mise en suspens, de libération et de rapprochement se produisent entre équipes et systèmes ; les entreprises ont besoin d'enregistrer de manière fiable qui a effectué quelle action, à quel moment et pourquoi. Cela répond non seulement aux exigences de conformité, mais constitue également la base indispensable pour retracer l'historique des transactions en cas de problème.

Ces questions sont à la fois opérationnelles et architecturales.

Le plus grand échec en matière de paiement survient souvent lorsque l'équipe ne parvient pas à répondre à une question simple : Où est passée cette somme ?

Ce qui manque, ce n'est pas un autre fournisseur de services de paiement qui effectue des paiements, route des transactions ou détient des fonds au sein des modèles existants, mais un PSP évolué capable de coordonner toutes ces fonctions, de suivre l'état à travers les fournisseurs de services, de gérer les flux de fonds et de maintenir des registres financiers fiables dans le temps.

Huitième : La prochaine évolution du PSP

Le défi ne réside pas dans l'intégration de l'infrastructure de paiement, mais dans la capacité à maintenir une compréhension cohérente et fiable du mode de circulation des fonds.

La répartition actuelle de l'écosystème : PSP effectuent les paiements, les banques détiennent les fonds, les systèmes de conformité évaluent les risques, et les outils d'orchestration acheminent les transactions. Toutefois, aucun fournisseur unique ne assure une vue complète et cohérente du flux de fonds sur l'ensemble du cycle de vie des paiements.

La prochaine évolution de PSP consiste à offrir une visibilité cohérente sur toute la pile technologique — permettant de comprendre, de comptabiliser et de faire confiance à chaque paiement, depuis son initiation jusqu'à son règlement final.

Ce niveau doit pouvoir :

• Effectuer des paiements entre banques, réseaux traditionnels et réseaux de stablecoins
• Maintenir un système de registres cohérent via un livre interne
• Gestion des flux de travail pour l'approbation, les fonds et le traitement des anomalies
• Réconcilier les activités externes avec l'état financier interne
• À mesure de l'expansion, intégrez la conformité, l'infrastructure de comptes et les connexions pour une croissance continue.

Conclusion : Par où commencer

L'infrastructure de paiement moderne n'est plus définie par un seul processeur ou un seul canal. Elle constitue un environnement composé de plusieurs fournisseurs, chacun responsable d'une étape différente du flux de fonds, de l'approbation, du règlement et de la comptabilisation.

En revisant ce guide, nous avons pu observer l'évolution de cet environnement :

Les fournisseurs de paiement ont dépassé le cadre du traitement des transactions, les voies de paiement ne cessent de s'élargir, les systèmes en temps réel ont éliminé le filet de sécurité des règlements différés, et de nouvelles infrastructures telles que les stablecoins ont encore étendu l'ensemble du système.

Pour les équipes qui construisent des produits financiers ou intègrent des paiements dans des logiciels, le chemin d'entrée est plus important que les discussions stratégiques.

Ne commencez pas par la question « Faut-il adopter pleinement les stablecoins » ; identifiez plutôt un problème concret : un canal transfrontalier trop lent pour les règlements, un processus de paiement fournisseur trop manuel, ou des fonds inactifs qui ne génèrent aucun rendement en transit. Choisissez un cas d’utilisation, ouvrez un compte et effectuez un paiement réel. Commencez par un test interne, en vous concentrant sur les scénarios de gestion de trésorerie (treasury), et non pas en modifiant directement les processus côté client. Cela permet de maîtriser les risques tout en développant une compréhension.

Au niveau de la conformité, les règles telles que le KYC, l'AML et le filtrage des sanctions restent entièrement applicables ; les stablecoins ne représentent qu'un changement de fondement. Le cadre réglementaire s'est considérablement clarifié depuis l'adoption de la loi GENIUS Act, et ne devrait pas constituer un obstacle au déploiement du pilote.

Le véritable risque stratégique n'est pas d'utiliser ou non des stablecoins, mais que vos concurrents réinventent leurs coûts de règlement et leur efficacité financière grâce aux stablecoins, tandis que vous attendez un moment parfait pour entrer.

En l'absence d'une couche de coordination unifiée, la complexité s'accumule à mesure de la croissance. Avec celle-ci, les entreprises peuvent gérer leurs flux de trésorerie avec clarté, contrôle et confiance.

Certaines informations proviennent de : Modern Treasury — A Practical Guide to PSPs in 2026