🚨Alerte alpha 🚨 @tempo vient de se lancer il y a quelques minutes. Avec le lancement du mainnet, ils lancent également la spécification du Machine Payments Protocol. J'ai eu un accès anticipé à la spécification et j'ai quelques premières réflexions. Tout d'abord, la spécification MPP est une nouvelle approche alternative du code http 402 "demande de paiement". Elle diffère fondamentalement du x402 en ce sens qu'elle supprime le Facilitateur de l'architecture. D'une part, retirer un intermédiaire du flux est généralement une bonne idée. D'autre part, cela déplace la logique de traitement gérée par le Facilitateur vers le serveur du commerçant. Le temps nous dira si c'est bon ou mauvais, mais je suppose qu'il y a une croyance selon laquelle l'agent côté serveur sera capable d'optimiser les flux des commerçants, donc avoir un tiers pour le faire est redondant. Maintenant, nous devons attendre et voir... La spécification MPP conçoit également pour différents moyens de paiement au-delà des stables, y compris le support pour les paiements en fiat via carte de crédit, ce que je pense être un avantage. S'ajoute à cela une approche agnostique des PSP, ce qui, je pense, est un double avantage. Les commerçants devraient pouvoir choisir n'importe quel moyen de paiement qu'ils souhaitent, traité par n'importe quel fournisseur de services de paiement qu'ils souhaitent. Passons maintenant aux questions que j'ai. Tout d'abord, pour les paiements par carte, la spécification a une méthode de cryptage novatrice où le Serveur (c'est-à-dire le Commerçant) contrôle le décryptage de la charge utile du Client. Malheureusement, cela soulève des questions sur la conformité PCI. Le Serveur ne contrôle pas comment le Client (l'agent acheteur) gère sa délégation de carte. La voie prescrite semble être les DPAN, mais les PAN bruts sont également dans le champ d'application selon la spécification. Comme le Serveur ne contrôle pas la charge utile CHD, les PAN bruts peuvent être cryptés et envoyés au Serveur pour être transférés au PSP du Serveur. Cela, à son tour, nécessiterait que le Serveur soit conforme PCI à moins qu'il ne puisse garantir que la charge utile est toujours un DPAN. Exiger que chaque Serveur soit conforme PCI SAQ A ou, pire encore, SAQ D n'est pas évolutif. Deuxièmement, la spécification permet plusieurs moyens de paiement, mais ne résout pas les transactions à l'échelle mondiale. Bien que cela puisse sembler normal, pour que les paiements agent à agent se développent, à mon avis, avoir un grand livre global auquel tous les agents peuvent se connecter est l'approche optimale. Pourquoi, demandez-vous ? Pour plusieurs raisons, mais une raison spécifique est l'établissement de l'identité. L'identité de l'agent sera liée à la modélisation statistique basée, en partie, sur l'historique transactionnel. L'exemple contemporain de cela est le profilage du risque de crédit. Cependant, des réseaux de transactions compartimentés entraîneront des historiques de transactions disparates, ce qui posera des problèmes lors de la tentative de résolution du comportement. Félicitations à tous ceux qui ont participé, y compris nos partenaires chez Visa et VGS. Le secteur fait des progrès énormes. Les choses commencent à se mettre en place, et nous sommes impatients de rassembler les pièces.