Solana Foundation hợp tác với Google ra mắt Pay.sh, liệu có thể kết nối luồng thanh toán Web2 và Web3 trong nền kinh tế đại lý AI?

Original Author: Hendrix, Researcher at Web3Caff Research

How to easily grasp the market hotspots, technological trends, ecosystem developments, and governance dynamics unfolding in the Web3 industry? The "Market Pulse Analysis" column launched by Web3Caff Research dives deep into the frontline to screen current hot events, providing value interpretation, commentary, and principle analysis. See through the appearance to perceive the essence, and follow us now to quickly capture the frontline market trends of Web3.

As AI agents become increasingly capable and cover more end-to-end tasks, building payment systems 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, making them unsuitable for agents. Meanwhile, emerging agent payment protocols like x402 (developed and promoted by Coinbase) and MPP (Machine Payment Protocol developed by Tempo and Stripe) seem to start fresh, being constructed entirely for on-chain payments. The entire payment process is handled on-chain, secured by on-chain verification. Service providers need to build a separate payment system outside traditional channels, raising the barrier to entry. Traditional payment solutions and emerging agent payment protocols are like two parallel lanes that haven't been well integrated. This limits the services agents can autonomously purchase to Web3-friendly domains, 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 more services.

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

Pay.sh allows users to quickly top up a Solana wallet using a credit card or stablecoins. Afterward, the Solana wallet can act as the identity and payment account proxy for the agent in the Web2 resource world. When an agent needs to call a service, it no longer needs to register an account or input API keys. The Pay.sh gateway declares the agent's legitimate identity, similar to Google's identity system, allowing the agent to use a unified account identity to purchase development resources like Google Cloud, Alibaba Cloud, and others that were previously hard to obtain.

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

Pay.sh's payment flow is similar to the recently popular x402 protocol, both built upon the HTTP 402 status code: When an agent discovers it needs to call an external service, it sends a request to the paid resource. The server returns status code 402 (Payment Required), along with detailed payment information, including the amount, payment plan, recipient address, payment validity, etc. Pay.sh parses the corresponding content and initiates authorization to the wallet. After the wallet completes the payment and generates a payment credential, Pay.sh uses the credential to make another service request to receive a normal response. However, to cover various API usage scenarios, Pay.sh also 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 once for access) or a usage-based access type (pay for a fixed amount of usage), Pay.sh constructs a one-time fixed amount transfer and broadcasts it on-chain. If it's continuous billing or session-based billing (a single payment for a consolidated usage bill), Pay.sh supports MPP's (Machine Payment Protocol) session authorization credentials. It writes the budget limit into the authorization and sends it back to the server. The agent can then repeatedly call the service within a short period, avoiding frequent similar authorizations. Pay.sh updates the remaining credit with each call, and automatically re-initiates session authorization when the credit is exhausted or the service expires. Pay.sh automatically selects the more suitable payment track based on the target service's requirements, reducing usage and management costs. Pay.sh also ensures the wallet always remains securely stored locally, only requesting user confirmation when 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 text, and API descriptions) is treated as untrusted input by Pay.sh, and the agent must not directly execute instructions returned by the service provider to prevent malicious prompt injection or other attacks.

Pay.sh's biggest advantage is that it also provides a gateway for service providers that can be easily deployed. Service providers can integrate the payment gateway into their service network without making large-scale modifications to their payment channels or APIs. Service providers only need to provide a declarative file specifying payment-related parameters to adapt to various complex usage scenarios. For example, by defining routing rules, they can allow agents to use the service for free up to a certain limit, charge after exceeding the quota, or even implement tiered pricing (charging different prices for different usage levels). Additionally, Pay.sh offers payment splitting functionality. Fees received by the service provider can be automatically sent to multiple addresses. For instance, 2% for data copyright fees, 5% for cloud costs, and the remainder for their own operations. Service providers can achieve multi-account settlement in one go by simply defining different percentages or amounts when setting up recipient addresses. After registration, service providers can publish their offered API service data to the Pay Skill Registry. Agents can 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 strive to make on-chain agent payments more reliable, Pay.sh aims to bridge the Web2 and Web3 payment ecosystems, granting agents the necessary identity to access resources. The agent's wallet serves as both its identity and payment method, eliminating the need for it to register accounts on service providers' official websites to obtain services (currently, some service providers might treat agents mimicking human registration as a violation). Furthermore, through its partnership with Google, Pay.sh allows agents to perform API proxies and traffic scheduling on Google Cloud, ensuring access control and log compliance, thus keeping agent behavior within reasonable boundaries. Pay.sh provides a curated service directory and pricing discovery, protecting agents from randomly discovering services in an unprotected network environment. It also enables the use of different payment methods from 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 also opening an entry point for the commercial flow of agents into Web3. Additionally, Pay.sh can complete the final payment link for several commercial protocols launched by Google, such as A2A (Agent2Agent Protocol) for inter-agent communication and task delegation, AP2 (Agent Payments Protocol) for compliance verification, and UCP (Universal Commerce Protocol) for service discovery and execution. Pay.sh handles the seamless settlement of the service's final value. The emergence of Pay.sh also perfects the Web2 agent commerce ecosystem, becoming a convergence point for value flow between the two worlds. This step is also an upgrade opportunity for the Solana public chain ecosystem itself. In the x402 protocol environment, there are numerous wrapper APIs. Service providers may violate the terms of service of the original providers and resell their services, such as maliciously scraping database website data for resale or encapsulating large model APIs and selling them to others. Agents in this environment cannot distinguish between authorized services and malicious garbage services. With the Pay.sh payment gateway and Google's collaboration, agents using services via Pay.sh can potentially reduce these risks. The launch of Pay.sh marks the Solana public chain's entry into providing endorsement and infrastructure support for agent payments. This not only attracts more Web2 payment traffic to Solana itself but also further enhances the capabilities of Solana wallets and accelerates their adoption.

However, Pay.sh is still far from being a perfect payment gateway solution. The Pay.sh service provider registry currently lacks an admission mechanism and decentralized verification mechanisms. It remains difficult to effectively distinguish unauthorized third-party wrapper services and malicious services, posing a significant risk for agents connecting to fake services and causing user losses. Furthermore, as Pay.sh does not design the underlying payment protocol itself, the security of the payment process largely relies on the design of the underlying protocols. This introduces uncontrollable external risks to Pay.sh and could potentially lead to payment failures due to insufficient adaptation to different protocols. From the service provider's perspective, despite the endorsement from Google, API providers in different countries and regions might still be deterred from using Pay.sh's services due to compliance requirements for data privacy management and payment processing. This may not only limit the number of service providers using Pay.sh but could also require Pay.sh to make more compliance efforts in the future. Regardless, the launch of Pay.sh marks a step towards the convergence of Web2 and Web3 in agent payment infrastructure. On-chain wallets may become the endorsement for agents to participate in diverse tasks. Therefore, we can continue to observe the subsequent developments of Pay.sh.

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, investment advice, proposal, or offer. Investors should not rely on this information to buy or sell any securities, cryptocurrencies, or adopt any investment strategies. The terminology used and the views expressed are intended to help understand industry trends and promote the responsible development of Web3, including the blockchain industry, and should not be interpreted as definitive legal opinions or the views of Web3Caff Research. The views in this report reflect the personal opinions of the author as of the stated date, are independent of the position of Web3Caff Research, and are subject to change based on subsequent circumstances. The information and opinions contained in this report are derived from proprietary and non-proprietary sources believed to be reliable by Web3Caff Research, but do not necessarily include all data, and their accuracy is not guaranteed. Therefore, Web3Caff Research makes no guarantee as to their accuracy or reliability and accepts 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 predictions and forecasts, and this document does not constitute a guarantee of any predictions. Whether to rely on the information contained in this report is entirely at the reader's own 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.