¿Cómo comprender fácilmente los puntos calientes del mercado, las tendencias tecnológicas, los avances ecológicos y la situación de gobernanza que están ocurriendo en la industria Web3? La sección «Análisis del pulso del mercado», lanzada por Web3Caff Research, investigará y seleccionará en primera línea los eventos actuales más relevantes, ofreciendo interpretaciones de valor, comentarios y análisis de principios. Mire más allá de la superficie y siga inmediatamente nuestros pasos para captar rápidamente las tendencias del mercado Web3 en tiempo real.
Autor del artículo: Hendrix, investigador de Web3Caff Research
Fuente: Web3Caff Research
As AI agents continue to enhance their capabilities and take on an increasing number of end-to-end tasks, building payment systems for agents has become a necessary evolution for traditional merchants and service providers. However, existing solutions each have their own limitations: traditional payment systems, such as credit cards and third-party payment platforms, were originally designed for human users and require complex identity verification and risk assessment processes that are not suitable for agents; meanwhile, emerging agent payment protocols like x402 (developed and promoted by Coinbase), MPP (Machine Payment Protocol developed by Tempo and Stripe), etc., operate as separate systems entirely built for on-chain payments, processing the entire transaction on-chain and relying on on-chain verification for security. Service providers must therefore build an entirely separate payment infrastructure outside their traditional payment channels, raising the barrier to adoption. Traditional payment solutions and emerging agent payment protocols resemble two parallel lanes that have not been effectively integrated, limiting agents’ ability to autonomously purchase services mostly to Web3-friendly ecosystems, thus preventing large-scale workflow chaining. To address this, Solana Foundation and Google Cloud have jointly launched Pay.sh, positioned as a “payment gateway between agents and enterprise-grade service infrastructure,” bridging the final step for agents to access a broader range of services.
Advertencia de cumplimiento: El contenido a continuación es únicamente un análisis objetivo de Pay.sh y sus principios técnicos y reglas de diseño, y no constituye ninguna propuesta u oferta. Por favor, no tome decisiones basadas en esta información y asegúrese de cumplir estrictamente con las leyes y regulaciones de su país o región (se recomienda encarecidamente a los lectores de la China continental que lean “Recopilación y resumen de las leyes y regulaciones chinas sobre blockchain y criptomonedas”). No participe en ninguna actividad financiera prohibida por las leyes de su país o región.
Pay.sh permite a los usuarios recargar rápidamente su billetera Solana mediante tarjeta de crédito omonedas establesparabilleteraSolana, que puede actuar como agente de identidad y cuenta de pago en el mundo de los recursos Web2. Cuando el agente necesite acceder a servicios, ya no será necesario registrarse ni ingresar claves API; la puerta de enlace Pay.sh declarará la identidad legítima del agente, como lo hace el sistema de identidad de Google, permitiendo que el agente utilice una identidad de cuenta unificada para comprar recursos de desarrollo anteriormente difíciles de obtener, como Google Cloud o Alibaba Cloud.cuenta
Los servicios API actualmente admitidos por Pay.sh. Fuente: sitio web oficial del proyecto
El flujo de pago de Pay.sh es similar al protocolo x402, que se volvió muy popular hace poco, ya que ambos se basan en el código de estado HTTP 402: cuando un agente detecta que necesita llamar a un servicio externo, realiza una solicitud al recurso de pago, y el servidor responde con el código de estado 402 (requiere pago), junto con detalles completos del pago, incluyendo el monto, el plan de pago, la dirección de recepción, la vigencia del pago, entre otros. Pay.sh analiza esta información y solicita autorización al monedero; una vez que el monedero completa el pago y genera un comprobante, Pay.sh vuelve a enviar la solicitud del servicio junto con el comprobante para obtener una respuesta normal. Sin embargo, para cubrir diversos escenarios de uso de API, Pay.sh también es compatible con los lógicas de pago de x402 y MPP: cuando el servidor devuelve el código de estado 402, Pay.sh determina el método de pago del servicio objetivo; si se trata de un acceso a datos único (pago que otorga un solo acceso) o de un acceso basado en uso (pago que otorga una cantidad fija de accesos), Pay.sh genera y transmite en la cadena una transferencia única de monto fijo; si se trata de facturación continua o por sesión (pago único consolidado según el uso), Pay.sh admite el certificado de autorización de sesión del protocolo MPP (Machine Payment Protocol), escribiendo el límite presupuestario en la autorización y devolviéndolo al servidor; en este caso, el agente puede invocar repetidamente el servicio en un corto período de tiempo, evitando autorizaciones frecuentes del mismo tipo; Pay.sh actualiza el saldo restante en cada invocación y, cuando se agota el saldo o expira el servicio, reinicia automáticamente la autorización de sesión. Pay.sh selecciona automáticamente la vía de pago más adecuada según los requisitos del servicio objetivo, reduciendo así los costos de uso y gestión. Además, Pay.sh garantiza que el monedero siempre se almacene de forma segura en el dispositivo local y solo solicita confirmación del usuario cuando es necesario realizar un pago. Cuando se reciben datos, Pay.sh distingue entre información e instrucciones: todo el contenido externo devuelto por el proveedor (incluyendo título, cuerpo y descripción de la API) se considera entrada no confiable; el proxy no ejecuta directamente las instrucciones devueltas por el proveedor para prevenir inyecciones maliciosas de prompts u otros ataques.
La principal ventaja de Pay.sh es que también proporciona a los proveedores de servicios una puerta de enlace fácil de implementar, permitiendo integrar la puerta de enlace de pago en su red de servicios sin necesidad de modificar en gran medida sus propios canales de pago o API. Solo es necesario proporcionar un archivo declarativo que especifique los parámetros relacionados con el pago para adaptarse a diversos escenarios complejos, como definir reglas de enrutamiento para permitir que los agentes utilicen el servicio gratuitamente hasta un cierto límite, y comenzar a cobrar una vez superado ese umbral, e incluso implementar tarifas escalonadas (diferentes precios según el volumen de uso); además, Pay.sh ofrece la función de división de pagos, permitiendo que los ingresos recibidos por el proveedor se envíen automáticamente a múltiples direcciones, por ejemplo, 2% para derechos de autor de los datos de pago, 5% para costos en la nube, y el resto para operaciones propias; el proveedor solo necesita definir diferentes porcentajes o montos al configurar las direcciones de recepción para lograr un liquidación simultánea en múltiples cuentas. Tras completar el registro, el proveedor puede publicar los datos de su servicio API en Pay Skill Registry, permitiendo que los agentes descubran y seleccionen servicios API adecuados consultando el registro.
Pay.sh en sí mismo no es un competidor de x402 ni de MPP. Mientras que los protocolos x402 y MPP buscan hacer que los pagos a agentes en cadena sean lo más confiables posible, Pay.sh tiene como objetivo conectar los ecosistemas de pago Web2 y Web3, otorgando identidad a los agentes para acceder a recursos. La billetera del agente es tanto una identidad como un método de pago, eliminando la necesidad de registrarse manualmente en los sitios web de los proveedores de servicios (algunos proveedores actualmente consideran como infracción el hecho de que los agentes se registren simulando a humanos). Además, mediante la colaboración con Google, Pay.sh permite que los agentes ejecuten proxy de API y gestión de tráfico dentro de Google Cloud, garantizando el control de acceso y el cumplimiento de registros, manteniendo así el comportamiento de los agentes dentro de límites razonables. Pay.sh ofrece un directorio de servicios seleccionados y descubrimiento de precios, evitando que los agentes busquen servicios aleatoriamente en entornos web sin protección, mientras también pueden utilizar distintos métodos de pago de x402 y MPP. El proceso de servicio se completa dentro de Google Cloud, cumpliendo con los requisitos empresariales de conformidad, lo que complementa las capacidades de pago de agentes que x402 y MPP, como simples canales de pago, no pueden cubrir, y abre al mismo tiempo una puerta para que los negocios de agentes fluyan hacia Web3. Además, Pay.sh completa el último eslabón de pago para múltiples protocolos comerciales de agentes lanzados por Google: A2A (Agent2Agent Protocol) permite la comunicación y asignación de tareas entre agentes; AP2 (Agent Payments Protocol) realiza la verificación de conformidad; UCP (Universal Commerce Protocol) logra el descubrimiento y ejecución de servicios; y Pay.sh se encarga del cierre sin fricciones del valor del servicio. La aparición de Pay.sh también completa el ecosistema comercial de agentes en Web2, convirtiéndose en un punto de encuentro para el flujo de valor entre ambos mundos. Este paso representa además una oportunidad de mejora para el ecosistema de la cadena Solana. En el entorno del protocolo x402 existen numerosas API envueltas, donde proveedores violan los términos de servicio originales y revenden servicios, como extraer datos ilegalmente de sitios web de bases de datos para revenderlos, o empaquetar APIs de grandes modelos para revenderlas a terceros. En este entorno, los agentes no pueden distinguir entre servicios autorizados y servicios maliciosos o basura; sin embargo, mediante la puerta de enlace de pago Pay.sh y su cooperación con Google, los agentes que utilizan servicios a través de Pay.sh podrán reducir riesgos potenciales. El lanzamiento de Pay.sh marca que la cadena Solana entra directamente en el ámbito del pago para agentes, brindando respaldo e infraestructura. Esto no solo atraerá más flujo de pagos Web2 hacia Solana, sino que también mejorará y acelerará la adopción de las billeteras Solana.
Sin embargo, Pay.sh aún está muy lejos de ser una solución de pasarela de pago perfecta. El registro de proveedores de Pay.sh actualmente carece de mecanismos de acceso y verificación descentralizada, lo que sigue dificultando la distinción efectiva entre servicios de terceros no autorizados y servicios maliciosos; los agentes corren un gran riesgo de conectarse a servicios falsos, causando pérdidas a los usuarios. Además, dado que Pay.sh no diseña los protocolos de pago subyacentes, la seguridad del proceso de pago recae principalmente en el diseño mismo de los protocolos subyacentes, lo que introduce riesgos externos incontrolables para Pay.sh y también podría provocar fallos potenciales en los pagos debido a una adaptación insuficiente a diferentes protocolos. Desde la perspectiva de los proveedores de servicios, aunque cuentan con el respaldo de la plataforma Google, los proveedores de API en diferentes países y regiones podrían abstenerse de ofrecer servicios a Pay.sh debido a requisitos regulatorios relacionados con la gestión de privacidad de datos y el cumplimiento normativo en pagos. Esto no solo limitará el número de proveedores de servicios que utilicen Pay.sh, sino que también podría exigir en el futuro que Pay.sh realice mayores esfuerzos de cumplimiento. Sin embargo, de cualquier manera, el lanzamiento de Pay.sh marca un paso importante hacia la implementación práctica de la integración entre Web2 y Web3 en la infraestructura de pagos para agentes, permitiendo que las billeteras en cadena se conviertan en aval para que los agentes participen en diversas tareas. Por lo tanto, podemos seguir observando el desarrollo posterior de Pay.sh.
Diagrama de estructura de puntos clave:
