Je viens de passer du temps à creuser dans le Commerce Payments Protocol, et honnêtement, c’est un peu époustouflant. Les rails cryptographiques ont discrètement résolu la plupart des problèmes qui les tenaient à l’écart du commerce traditionnel. Il ne s’agit pas d’une démo ou d’une théorie, mais d’une démonstration en direct, de l’open-source et du traitement de transactions réelles. Les paiements en crypto-monnaies sont arrivés. 1/ Autorisation instantanée « oui/non ». Les commerçants ont besoin d’une réponse claire : dois-je expédier cet article ? On-chain, c’est trivial. Le protocole donne une réponse Authorized immédiate en appelant authorize(), qui réussit ou annule. Aucune ambiguïté ; Juste une logique déterministe et programmable. 2/ Fonds irrévocables ou garantis par le réseau Avec les cartes traditionnelles, « l’autorisation » met en attente – c’est une promesse, pas un paiement. Dans le rail USDC de Base, l’appel authorize() déplace immédiatement le montant exact dans un contrat intelligent séquestre. Les fonds ne peuvent être débloqués que par capture, remboursement ou annulation - personne ne peut les récupérer. Il remplace l’idée d’une retenue de crédit par une « retenue de débit » : le solde de l’acheteur est réduit instantanément, mais le commerçant ne peut pas le dépenser avant la capture. Le processus reflète le flux en deux étapes du système de cartes, simplement appliqué par des contrats intelligents au lieu de règles centralisées. Si un acheteur n’a pas assez d’USDC, transferWithAuthorization() revient lorsque le montant du transfert dépasse le solde. Pas de partiels. Pas de découvert. Il suffit d’un arrêt brutal, exactement comme le code d’erreur de carte 51 : fonds insuffisants ou limite de crédit. 3/ La protection des acheteurs, restructurée Contrairement aux cartes, où les émetteurs offrent des protections aux acheteurs, les paiements crypto-natifs transfèrent cette responsabilité au PSP ou au portefeuille. Le protocole de commerce de base prend en charge les appels refund(), en utilisant soit le solde du portefeuille du marchand, soit, si nécessaire, les réserves de risque du PSP. La protection existe toujours, mais elle n’est plus imposée par la réglementation. C’est contractuel, soutenu par un bilan. Exemple: Jour 0 : L’acheteur paie →USDC entre dans le séquestre du marchand. Jour 10 : Le produit n’arrive pas → l’acheteur conteste → PSP appelle refund() → les fonds retirés du marchand. Jour 65 : Le marchand fantôme → Portefeuille vide → PSP utilise le pool de risques. Jour 91 : La fenêtre de remboursement a expiré → le remboursement en chaîne n’est plus possible → PSP peut offrir un crédit, ou l’acheteur exerce un recours juridique ou un gel du cercle. 4/ L’outillage et l’UX omniprésents ...