🚨Alfa-alarm 🚨 @tempo gikk live for noen minutter siden. Med lanseringen av hovednettet lanserer de også Machine Payments Protocol-spesifikasjonen. Jeg fikk tidlig tilgang til spesifikasjonen, og har noen innledende tanker. Først og fremst er MPP-spesifikasjonen en ny, alternativ versjon av 402 "request for payment" http-koden. Den skiller seg fundamentalt fra x402 ved at den fjerner Facilitator fra arkitekturen. På den ene siden er det vanligvis en god idé å fjerne en mellommann fra strømmen. På den annen side flytter den prosesseringslogikken som håndteres av Facilitator til handelsserveren. Tiden vil vise om dette er bra eller dårlig, men mitt gjetning er at det er en tro på at serveragenten vil kunne optimalisere handelsflytene, så å ha en tredjepart til det er overflødig. Nå må vi vente og se... MPP-spesifikasjonen designer også for andre betalingsmetoder utover stabile, inkludert støtte for fiat via kredittkortbetaling, noe jeg mener er en seier. I tillegg til dette er en PSP-agnostisk tilnærming, som jeg mener er en dobbel seier. Forhandlere bør kunne velge hvilken som helst betalingsmetode de ønsker, behandlet av hvilken som helst betalingstjenesteleverandør de ønsker. Nå til spørsmålene jeg har. For det første, for kortbetalinger har spesifikasjonen en ny krypteringsmetode hvor serveren (dvs. forhandleren) kontrollerer dekrypteringen av klientens nyttelast. Dessverre reiser dette spørsmål om PCI-samsvar. Serveren kontrollerer ikke hvordan klienten (kjøpsagenten) håndterer kortdelegeringen. Den foreskrevne ruten ser ut til å være DPANs, men rå PAN er også innenfor omfanget basert på spesifikasjonen. Fordi serveren ikke kontrollerer CHD-nyttelasten, kan rå PAN-er krypteres og sendes til serveren for videresending til serverens PSP. Dette vil igjen kreve at serveren er PCI-kompatibel med mindre den kan garantere at nyttelasten kun er en DPAN. Å kreve at hver server er PCI SAQ A eller, enda verre, SAQ D-kompatibel, er ikke skalerbart. For det andre muliggjør spesifikasjonen flere betalingsmetoder, men løser ikke transaksjoner globalt. Selv om dette kan virke normalt, for at agent-til-agent-betalinger skalerer, er det etter min mening best å ha en global hovedbok som alle agenter kan koble seg til. Hvorfor, spør du? Av flere grunner, men én spesifikk grunn er identitetsetablering. Agentidentitet vil være knyttet til statistisk modellering, delvis basert på transaksjonshistorikk. Det moderne eksempelet på dette er kredittrisikoprofilering. Imidlertid vil oppdelte transaksjonsnettverk føre til ulik transaksjonshistorikk, noe som vil skape problemer når man prøver å løse atferd. Gratulerer til alle involverte, inkludert våre partnere hos Visa og VGS. Bransjen gjør enorme fremskritt. Ting begynner å falle på plass, og vi ser frem til å sette brikkene på plass.