Solana Foundation and Google Partner to Launch Pay.sh: Can It Bridge the Payment Link between Web2 and Web3 in the Agentic Economy?

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 interpretation, commentary, and principle analysis. Seeing through the surface to the core, follow us to quickly capture the pulse of the Web3 market.

As the capabilities of AI agents continue to strengthen, covering more and 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 and risk assessment 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 be creating a separate system, constructed entirely for on-chain payments. The entire payment process is handled on-chain, with security ensured through on-chain verification. Service providers need to set up a completely different payment system outside of traditional payment channels, raising the barrier to entry. Traditional payment solutions and emerging agent payment protocols appear to be two parallel tracks that do not integrate well, causing the services that agents can autonomously purchase to be generally limited to Web3-friendly scopes, thus hindering 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," aiming to bridge 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 any decisions based on this information, and strictly adhere to the laws and regulations of your country or region (Readers in Mainland China are strongly advised to read the “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 their Solana wallet using credit cards or stablecoins. Subsequently, the Solana wallet can act as the agent's identity and payment account proxy within 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, allowing the agent to use a unified account identity to purchase development resources like Google Cloud and Alibaba Cloud, which were previously difficult to obtain.

API services currently supported 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 returns status code 402 (Payment Required), along with detailed payment information, including the payment amount, pricing plan, recipient address, payment validity period, etc. Pay.sh parses the relevant content and requests authorization from the wallet. Once the wallet completes the payment and generates a payment proof, Pay.sh re-sends the service request with the proof and receives a normal response. However, to cover various API usage scenarios, Pay.sh is also compatible with the payment logic of x402 and MPP. When the server returns status code 402, Pay.sh further determines the payment method of the target service. If it is a one-time data access (pay to get one-time access permission) or a usage-based access type (pay to get a fixed amount of access permission), Pay.sh constructs a one-time fixed-amount transfer and broadcasts it on-chain. If it is continuous billing or session-based billing (paying a unified bill based on usage), Pay.sh supports the session authorization credential introduced by the MPP (Machine Payment Protocol). It writes the budget limit into the authorization and sends it back to the server. The agent can then repeatedly invoke a service within a short period, avoiding frequent initiation of the same type of authorization. Pay.sh updates the remaining allowance with each call, and automatically re-initiates session authorization when the allowance is exhausted or the service expires. Pay.sh automatically selects the more suitable payment track based on the requirements of the target service, reducing usage and management costs. Pay.sh also ensures the wallet always remains securely stored locally, 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 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 injections or other attacks.

Pay.sh's greatest 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 requiring massive modifications to their payment channels or APIs. 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, agents can use the service for free up to a certain limit, after which charges begin, or even implement tiered pricing (different prices for different usage levels). Furthermore, Pay.sh offers payment splitting functionality, allowing fees received by the service provider to be automatically sent to multiple addresses. For instance, 2% for data copyright fees, 5% for cloud costs, and the remainder for the provider's own operations. The provider only needs to define different percentages or amounts when setting up the receiving addresses for one-time multi-account settlement. 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 this registry.

Pay.sh itself is not a competitor to x402 and MPP. While x402 and MPP protocols strive to make on-chain agent payments more reliable, Pay.sh aims to bridge the Web2 and Web3 payment ecosystems, granting agents the appropriate identity to acquire resources. The agent's wallet serves as both its identity and payment method, eliminating the need to register accounts on service provider websites (some providers currently treat agents imitating human account registration as a violation). Additionally, through its collaboration with Google, Pay.sh enables agents to execute API proxies and traffic scheduling within Google Cloud, ensuring access control and log compliance, and keeping agent behavior within reasonable bounds. Pay.sh provides curated service directories and price discovery, allowing agents to find services without randomly navigating unprotected network environments. It can also utilize different payment methods from x402 and MPP. The service process can meet enterprise compliance requirements on Google Cloud. These features complement the agent payment capabilities that x402 and MPP, as singular payment channels, cannot cover, while also opening an entry point for agent commerce to flow into Web3. Furthermore, Pay.sh can complete the final payment link for several agent commerce protocols launched by Google. For example, A2A (Agent2Agent Protocol) handles inter-agent communication and task delegation, AP2 (Agent Payments Protocol) handles compliance verification, and UCP (Universal Commerce Protocol) handles service discovery and execution. Pay.sh is responsible for the seamless settlement of the final service value. The emergence of Pay.sh also perfects the Web2 agent commerce loop, becoming a convergence point for value flow between the two worlds. This step also represents an opportunity for the Solana public chain ecosystem itself to upgrade. In the x402 protocol environment, there are numerous shell APIs, where service providers violate the terms of service of original providers and resell their services. Examples include maliciously scraping database website data for resale or packaging large model APIs for resale to others. In such an environment, agents cannot distinguish between authorized services and malicious spam services. With the cooperation of the Pay.sh payment gateway and Google, agents using services through Pay.sh can potentially reduce these risks. The launch of Pay.sh signifies the Solana public chain stepping in to provide endorsement and infrastructure support for agent payments. This can not only attract more Web2 payment traffic to Solana itself but also further enhance the capabilities and accelerate the adoption of Solana wallets.

However, Pay.sh is still far from being a perfect payment gateway solution. The Pay.sh service provider registry currently lacks an access mechanism and decentralized verification mechanism. It remains difficult to effectively distinguish between unauthorized third-party shell services and malicious services, posing a significant risk for agents to connect to counterfeit services and cause losses for users. Furthermore, since Pay.sh does not design the underlying payment protocols, the security of the payment process largely depends on the design of the underlying protocols themselves. This introduces uncontrollable external risks for Pay.sh and also carries the potential for payment failures due to insufficient adaptation to different protocols. From the service provider's perspective, despite the endorsement of the Google platform, API suppliers in different countries and regions may still be deterred by the compliance requirements for data privacy management and payment related to their services. This could not only limit the number of service providers using Pay.sh but may also require Pay.sh to make more compliance efforts in the future. Regardless, the launch of Pay.sh marks a step towards integrating Web2 and Web3 in agent payment infrastructure. On-chain wallets now have the opportunity to become the endorsement for agents participating in diverse tasks. Therefore, we can continue to observe the subsequent development of Pay.sh.

Key Points 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 such information to buy or sell any securities, cryptocurrencies, or adopt any investment strategy. The terminology used and views expressed herein are intended to help understand industry trends and promote 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 only the personal opinions of the author as of the date stated and are subject to change upon subsequent circumstances, and are independent of 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, which may not encompass all data, and their accuracy is not guaranteed. Accordingly, Web3Caff Research makes no representations as to its accuracy or reliability, and assumes no liability for errors or omissions arising in any other manner (including liability to any person by reason of negligence). This report may contain "forward-looking" information, which may include forecasts and projections, and nothing herein constitutes a guarantee of any projection. 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.