🚨Alerta de Alpha 🚨 @tempo acaba de salir en vivo hace unos minutos. Con el lanzamiento de la mainnet, también están lanzando la especificación del Protocolo de Pagos de Máquinas. Recibí acceso anticipado a la especificación y tengo algunas ideas iniciales. Primero, la especificación del MPP es una nueva y alternativa interpretación del código http 402 "solicitud de pago". Se diferencia fundamentalmente del x402 en que elimina al Facilitador de la arquitectura. Por un lado, eliminar un intermediario del flujo suele ser una buena idea. Por otro lado, traslada la lógica de procesamiento que manejaba el Facilitador al Servidor del comerciante. El tiempo dirá si esto es bueno o malo, pero mi suposición es que hay una creencia de que el agente del lado del servidor podrá optimizar los flujos del comerciante, por lo que tener a un tercero haciendo eso es redundante. Ahora necesitamos esperar y ver... La especificación del MPP también está diseñada para diferentes métodos de pago más allá de los estables, incluyendo soporte para fiat a través de pagos con tarjeta de crédito, lo cual creo que es una victoria. A esto se suma un enfoque agnóstico a PSP, que considero una doble victoria. Los comerciantes deberían poder elegir cualquier método de pago que deseen, procesado por cualquier proveedor de servicios de pago que deseen. Ahora pasemos a las preguntas que tengo. Primero, para los pagos con tarjeta, la especificación tiene un método de encriptación novedoso donde el Servidor (es decir, el Comerciante) controla la desencriptación de la carga útil del Cliente. Desafortunadamente, esto plantea preguntas sobre el cumplimiento de PCI. El Servidor no controla cómo el Cliente (el agente comprador) gestiona su delegación de tarjeta. La ruta prescrita parece ser DPANs, pero los PANs en bruto también están en el alcance según la especificación. Debido a que el Servidor no controla la carga útil de CHD, los PANs en bruto pueden ser encriptados y enviados al Servidor para su reenvío al PSP del Servidor. Esto, a su vez, requeriría que el Servidor sea compatible con PCI a menos que pueda garantizar que la carga útil sea siempre un DPAN. Requerir que cada Servidor sea compatible con PCI SAQ A o, peor aún, SAQ D no es escalable. En segundo lugar, la especificación permite múltiples métodos de pago, pero no resuelve transacciones a nivel global. Si bien esto puede parecer normal, para que los pagos de agente a agente escalen, en mi opinión, tener un libro mayor global al que todos los agentes puedan conectarse es el enfoque óptimo. ¿Por qué preguntas? Por varias razones, pero una razón específica es el establecimiento de identidad. La identidad del agente estará vinculada a un modelado estadístico basado, en parte, en el historial transaccional. El ejemplo contemporáneo de esto es el perfil de riesgo crediticio. Sin embargo, las redes de transacciones compartimentadas llevarán a un historial transaccional dispar, lo que causará problemas al intentar resolver comportamientos. Felicitaciones a todos los involucrados, incluidos nuestros socios en Visa y VGS. El espacio está haciendo enormes avances. Las cosas están comenzando a encajar, y estamos ansiosos por poner las piezas en su lugar.