🚨Alerta 🚨 alfa @tempo acabou de entrar no ar há poucos minutos. Com o lançamento da mainnet, eles também estão lançando a especificação do Protocolo de Pagamentos Automáticos. Recebi acesso antecipado à especificação e tenho algumas ideias iniciais. Primeiramente, a especificação MPP é uma nova abordagem alternativa ao código http 402 "request for payment". Ele difere fundamentalmente do x402 porque remove o Facilitador da arquitetura. Por um lado, remover um intermediário do fluxo geralmente é uma boa ideia. Por outro lado, ele move a lógica de processamento tratada pelo Facilitador para o servidor comerciante. O tempo dirá se isso é bom ou ruim, mas meu palpite é que existe a crença de que o agente do lado do servidor será capaz de otimizar os fluxos dos comerciantes, então ter um terceiro fazendo isso é redundante. Agora precisamos esperar para ver... A especificação MPP também projeta para diferentes métodos de pagamento além dos estáveis, incluindo suporte para dinheiro fiduciário via cartão de crédito, o que eu acho uma vantagem. Além disso, há uma abordagem agnóstica ao PSP, que eu acho que é uma vitória dupla. Os comerciantes devem poder escolher qualquer método de pagamento que quiserem, processado pelo provedor de serviços de pagamento que desejar. Agora, as perguntas que tenho. Primeiro, para pagamentos com cartão, a especificação possui um método inovador de criptografia onde o Servidor (ou seja, o Comerciante) controla a descriptografia da carga útil do Cliente. Infelizmente, isso levanta questões sobre a conformidade com PCI. O servidor não controla como o Cliente (o agente comprador) gerencia a delegação do cartão. A rota prescrita parece ser DPANs, mas PANs brutos também estão dentro do escopo com base na especificação. Como o servidor não controla a carga útil do CHD, os PANs brutos podem ser criptografados e enviados ao servidor para encaminhamento ao PSP do servidor. Isso, por sua vez, exigiria que o servidor fosse compatível com PCI, a menos que garantisse que a carga útil seja apenas um DPAN. Exigir que todo servidor seja PCI SAQ A ou, pior ainda, compatível com SAQ D não é escalável. Segundo, a especificação permite múltiplos métodos de pagamento, mas não resolve transações globalmente. Embora isso possa parecer normal, para pagamentos agente a agente escalarem, na minha opinião, ter um livro-razão global ao qual todos os agentes possam se conectar é a abordagem ideal. Por quê, você pergunta? Por vários motivos, mas um motivo específico é o estabelecimento da identidade. A identidade do agente estará atrelada a modelagem estatística baseada, em parte, no histórico transacional. O exemplo contemporâneo disso é o perfil de risco de crédito. No entanto, redes de transações compartimentadas levarão a históricos de transações díspares, o que causará problemas ao tentar resolver comportamentos. Parabéns a todos os envolvidos, incluindo nossos parceiros da Visa e da VGS. O espaço está dando grandes avanços. As coisas estão começando a se encaixar, e estamos ansiosos para colocar as peças no lugar.