🚨Alfa-varning 🚨 @tempo gick live för några minuter sedan. Med lanseringen av mainnet lanserar de också Machine Payments Protocol-specifikationen. Jag fick tidig tillgång till specifikationen och har några första tankar. För det första är MPP-specifikationen en ny, alternativ variant av 402 "request for payment" http-koden. Den skiljer sig fundamentalt från x402 genom att den tar bort facilitatorn från arkitekturen. Å ena sidan är det oftast en bra idé att ta bort en mellanhand från flödet. Å andra sidan flyttar den bearbetningslogik som hanteras av facilitatorn till handlarens server. Tiden får utvisa om detta är bra eller dåligt, men min gissning är att man tror att serveragenten kan optimera handlarflödena, så att låta en tredje part göra det är överflödigt. Nu måste vi vänta och se... MPP-specifikationen designar också för andra betalningsmetoder utöver stabila, inklusive stöd för fiat via kreditkortsbetalning, vilket jag tycker är en vinst. Därtill kommer en PSP-agnostisk strategi, vilket jag tycker är en dubbel vinst. Handlare bör kunna välja vilken betalningsmetod de vill, som hanteras av vilken betalningstjänstleverantör de vill. Nu till frågorna jag har. För det första har specifikationen en ny krypteringsmetod för kortbetalningar där servern (dvs. handlaren) kontrollerar dekrypteringen av klientens payload. Tyvärr väcker detta frågor om PCI-efterlevnad. Servern kontrollerar inte hur klienten (köparagenten) hanterar sin kortdelegering. Den föreskrivna rutten verkar vara DPANs, men råa PAN ingår också i omfattningen baserat på specifikationen. Eftersom servern inte kontrollerar CHD-nyttolasten kan råa PAN krypteras och skickas till servern för vidarebefordran till serverns PSP. Detta skulle i sin tur kräva att servern är PCI-kompatibel om den inte kan garantera att nyttolasten bara någonsin är en DPAN. Att kräva att varje server är PCI SAQ A eller, ännu värre, SAQ D-kompatibelt är inte skalbart. För det andra möjliggör specifikationen flera betalningsmetoder, men löser inte transaktioner globalt. Även om detta kan verka normalt, för agent-till-agent-betalningar att skala, är det enligt mig optimalt att ha en global huvudbok som alla agenter kan koppla in sig i. Varför, undrar du? Av flera skäl, men en specifik anledning är identitetsetablering. Agentidentitet kommer att kopplas till statistisk modellering som delvis baseras på transaktionshistorik. Det samtida exemplet på detta är kreditriskprofilering. Dock leder uppdelade transaktionsnätverk till olika transaktionshistorik, vilket orsakar problem vid försök att lösa beteendet. Grattis till alla inblandade, inklusive våra partners på Visa och VGS. Området gör enorma framsteg. Saker börjar falla på plats, och vi ser fram emot att lägga pusselbitarna på plats.