Solana Foundation ร่วมมือกับ Google เปิดตัว Pay.sh จะสามารถเชื่อมต่อช่องทางการชำระเงินระหว่าง Web2 และ Web3 ในระบบเศรษฐกิจของ AI Agent ได้หรือไม่?

Original Author: Hendrix, Researcher at Web3Caff Research

How to easily grasp the ongoing market hotspots, technological trends, ecosystem developments, and governance dynamics in the Web3 industry? The "Market Pulse Analysis" column launched by Web3Caff Research delves into the front lines to screen current hot events, providing value interpretations, commentary, and principle analysis. Seeing through the surface to the essence, follow us now to quickly capture the pulse of the Web3 frontline market.

As the capabilities of AI agents continue to strengthen and cover an increasing number of end-to-end tasks, building payment systems tailored for agents has become a necessary change 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 real human users, requiring complex identity verification, risk assessment, and other processes that are unsuitable for agents. Meanwhile, emerging agent payment protocols, such as x402 (developed and promoted by Coinbase) and MPP (Machine Payment Protocol developed by Tempo and Stripe), seem to be building a separate framework entirely based on on-chain payments. The entire payment process is handled on-chain, with security ensured through on-chain verification. This requires service providers to set up a different payment system alongside traditional payment channels, raising the barrier to entry. Traditional payment solutions and emerging agent payment protocols are like two parallel lanes that do not integrate well, restricting the services that agents can autonomously purchase to Web3-friendly domains and thus preventing large-scale workflow orchestration. To address this, the Solana Foundation, in collaboration with Google Cloud, launched Pay.sh, positioning it as a "payment gateway between agents and enterprise-grade service infrastructure," bridging the final step for agents to access a wider range of services.

Compliance Note: The following content is solely an objective analysis of Pay.sh, its technical principles, and design rules. It does not constitute any proposal or offer. Please do not make any decisions based on this information, and strictly adhere to the laws and regulations of your country or region (Mainland China readers are strongly advised to read the "Compilation and Key Points of Laws and Regulations Related to Blockchain and Virtual Currencies in Mainland China"). Do not engage in any financial activities prohibited by the laws of your country or region.

Pay.sh allows users to quickly fund a Solana wallet via credit card or stablecoins. Subsequently, this Solana wallet can function as both the identity and payment account proxy for the agent in the Web2 resource world. When an agent needs to invoke a service, it no longer needs to register an account or input an API key. The Pay.sh gateway declares the agent's legitimate identity, similar to Google's identity system, enabling the agent to use a unified account identity to purchase development resources that were previously difficult to obtain, such as Google Cloud or Alibaba Cloud.

Currently supported API services by Pay.sh Source: Project Website

The payment flow of Pay.sh is similar to the once-popular x402 protocol, both built upon the HTTP 402 status code. When an agent identifies an external service it needs to invoke, it sends a request to the paid resource. The server responds with status code 402 (Payment Required), along with detailed payment information, including the amount, pricing plan, receiving address, payment validity period, etc. Pay.sh parses this information and initiates an authorization request to the wallet. After the wallet completes the payment and generates a payment receipt, Pay.sh re-initiates the service request with the receipt to obtain a normal response. To cover various API usage scenarios, Pay.sh concurrently supports the payment logic of both x402 and MPP. When the server returns status code 402, Pay.sh further determines the target service's payment method. If it's a one-time data access (pay to obtain a single access permission) or a usage-based access type (pay to obtain a fixed amount of access), Pay.sh constructs a one-time fixed-amount transaction and broadcasts it on-chain. If it's continuous billing or session-based billing (a unified bill for usage paid at once), Pay.sh supports the session authorization credentials introduced by the MPP (Machine Payment Protocol). It writes the budget limit into the authorization and transmits it back to the server. The agent can then repeatedly invoke a service within a short period without frequently initiating similar authorizations. Pay.sh updates the remaining quota after each call. When the quota is exhausted or the service expires, it automatically re-initiates session authorization. Pay.sh automatically selects the more suitable payment track based on the target service's requirements, reducing usage and management costs. Pay.sh simultaneously ensures the wallet always remains locally stored and securely managed, only requesting user confirmation when a payment is needed. When information is returned, Pay.sh distinguishes between data and instructions. All external content returned by the service provider (including titles, body, and API descriptions) is treated as untrusted input by Pay.sh. The agent must not directly execute instructions returned by the service provider to prevent malicious prompt injection or other attacks.

Pay.sh's greatest advantage is that it also provides service providers with an easily deployable gateway. Service providers can integrate the payment gateway into their service network without needing extensive modifications to their payment channels or APIs. A service provider only needs to provide a declarative file specifying payment-related parameters to adapt to various complex usage scenarios. For example, by defining routing rules, an agent can use a service for free up to a certain limit, after which billing begins. It can even implement tiered pricing (different prices for different usage volumes). Additionally, Pay.sh offers payment splitting functionality. Fees received by the service provider can be automatically distributed to multiple addresses, e.g., 2% for data copyright fees, 5% for cloud costs, and the remainder for operational expenses. The service provider only needs to define different percentages or amounts when setting up receiving addresses to achieve multi-account settlement in one go. After registration, service providers can publish their API service data to the Pay Skill Registry, allowing agents to discover and select suitable API services by querying the registry.

Pay.sh itself is not a competitor to x402 and MPP. While x402 and MPP protocols aim to make on-chain agent payments more reliable, Pay.sh seeks to bridge the Web2 and Web3 payment ecosystems, granting agents the corresponding identity to access resources. The agent's wallet serves as both identity and payment method. It no longer needs to register an account on the service provider's website to obtain services (currently, some service providers may treat agents mimicking humans for registration as a violation). Furthermore, through its collaboration with Google, Pay.sh allows agents to execute API proxies and traffic scheduling on Google Cloud, ensuring access control and log compliance, keeping agent behavior within reasonable bounds. Pay.sh provides a curated service directory and pricing discovery, preventing agents from randomly discovering services in an unprotected network environment. It can leverage different payment methods from both x402 and MPP, and the service process can meet enterprise compliance requirements on Google Cloud. These features complement the agent payment capabilities that x402 and MPP, as single payment channels, cannot cover, while opening a gateway for agent commerce to flow into Web3. Additionally, Pay.sh can add the final payment layer to several agent commerce protocols launched by Google. For instance, A2A (Agent2Agent Protocol) handles communication and task delegation between agents, AP2 (Agent Payments Protocol ) handles compliance verification, and UCP (Universal Commerce Protocol) handles service discovery and execution. Pay.sh then manages the seamless settlement of the final service value. The emergence of Pay.sh also completes the Web2 agent commerce loop, acting as a confluence point for value flow between the two worlds. This step also represents an upgrading opportunity for the Solana public chain ecosystem itself. In the x402 protocol environment, there are numerous reselling APIs where service providers violate the terms of service of original providers, such as maliciously scraping database website data for resale or packaging and reselling large model APIs to others. In such an environment, agents cannot distinguish between authorized services and malicious or junk services. Through the Pay.sh payment gateway and collaboration with Google, agents using Pay.sh are expected to experience reduced potential risks. The launch of Pay.sh marks the Solana public chain's entry into endorsing and providing infrastructure support for agent payments. This not only attracts more Web2 payment traffic to Solana itself but also enhances the capabilities and accelerates the adoption of Solana wallets.

However, Pay.sh is currently far from a perfect payment gateway solution. The Pay.sh service provider registry lacks an access control mechanism and decentralized verification mechanism. It remains difficult to effectively distinguish between unauthorized third-party reselling services and malicious services, posing a significant risk for agents to connect to counterfeit services, potentially causing losses for users. Furthermore, since Pay.sh does not design the underlying payment protocol itself, the security of the payment process largely falls on the design of the underlying protocol. This introduces uncontrollable external risks for Pay.sh and could potentially lead to payment failures due to inadequate adaptation to different protocols. From the service provider's perspective, despite the endorsement of the Google platform, API providers in different countries and regions might still hesitate to use Pay.sh's services due to compliance requirements for data privacy management and payment regulations specific to their services. This not only limits the number of service providers using Pay.sh but may also require Pay.sh to make greater compliance efforts in the future. Regardless, the launch of Pay.sh marks a significant step towards the integration and practical application of Web2 and Web3 in the agent payment infrastructure. On-chain wallets have the potential to become the endorsing identity for agents participating in diverse tasks. Therefore, we can continue to observe Pay.sh's subsequent developments.

Key Points Structure Diagram:

Disclaimer:   This report is prepared by Web3Caff Research. The information contained herein is for informational purposes only and does not constitute any prediction or investment advice, proposal, or offer. Investors should not rely on this information to buy or sell any securities, cryptocurrencies, or adopt any investment strategy. The terminology used and views expressed in this report are intended to help understand industry trends and promote the responsible development of Web3, including the blockchain industry, and should not be construed as definitive legal opinions or the views of Web3Caff Research. The views in this report reflect the personal opinions of the author only as of the stated date and are subject to change based on subsequent circumstances. They do not necessarily represent the position of Web3Caff Research. The information and opinions contained in this report are derived from proprietary and non-proprietary sources deemed reliable by Web3Caff Research but do not necessarily encompass all data, and their accuracy is not guaranteed. Therefore, Web3Caff Research makes no warranties, express or implied, regarding their accuracy or reliability, and assumes no liability for errors or omissions arising in any other manner (including liability for negligence to any person). This report may contain "forward-looking" information, which may include forecasts and projections. This document does not constitute a guarantee of any prediction. Whether to rely on the information contained in this report is solely at the reader's discretion. This report is for informational purposes only and does not constitute investment advice, a proposal, or an offer to buy or sell any securities, cryptocurrencies, or adopt any investment strategy. Please strictly comply with the relevant laws and regulations of your country or region.