Original Author: Hendrix, Researcher, Web3Caff Research
How to easily grasp the market hotspots, technological trends, ecological progress, and governance dynamics happening in the Web3 industry...? The "Market Pulse Analysis" column launched by Web3Caff Research will delve into the front lines to explore and filter current hot events, providing value interpretation, commentary, and principle analysis. See the essence through the phenomenon. Follow us now to quickly capture the front-line market trends in Web3.
As AI agents' capabilities continue to strengthen and cover an increasing number of end-to-end tasks, building payment systems for agents has become a necessary change for traditional merchants and service providers. However, existing solutions 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, etc., which are not suitable for agents. Emerging agent payment protocols, such as x402 (promoted by Coinbase) and MPP (the Machine Payment Protocol developed by Tempo and Stripe), are like building separate portals, entirely constructed for on-chain payments, processed on-chain and secured by on-chain verification. Service providers need to build a different payment system besides traditional payment channels, increasing the barrier to entry. Traditional payment solutions and emerging agent payment protocols are like two parallel lanes that are not well integrated. This limits the services agents can autonomously purchase, typically to Web3-friendly ranges, hindering the large-scale connection of workflows. To address this, the Solana Foundation and Google Cloud jointly launched Pay.sh, positioned as a "payment gateway between agents and enterprise-grade service infrastructure" to complete the final step in enabling agents to call more services.
Compliance Note: The following content is merely an objective analysis of Pay.sh, its technical principles, and design rules. It does not constitute any proposal or offer. Please do not make related decisions based on this information and strictly adhere to the laws and regulations of your country or region (readers from Mainland China are strongly advised to read Mainland China's Relevant Laws and Regulations on Blockchain and Virtual Currency Arrangement and Key Points), and do not participate in any financial behaviors prohibited by the laws and regulations of your country or region.
Pay.sh allows users to quickly top up a Solana wallet via credit card or stablecoin. Subsequently, the Solana wallet can act as the identity and payment account proxy for agents in the Web2 resource world. When an agent needs to call a service, there is no need to register an account or enter an API key. The Pay.sh gateway will declare 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 that were previously difficult to access.
Currently supported API services by Pay.sh Source: Project official website
The payment flow of Pay.sh is similar to the recently popular x402 protocol, both built on the HTTP 402 status code: when an agent discovers an external service that needs to be called, it makes a request for the paid resource. The server returns status code 402 (Payment Required), along with payment details, including payment amount, pricing plan, recipient address, payment validity period, etc. Pay.sh parses this content and initiates an authorization request to the wallet. After the wallet completes the payment and generates a payment proof, Pay.sh carries the proof and initiates the service request again to obtain a normal response. However, to cover various API usage scenarios, Pay.sh is compatible with both x402 and MPP payment logics: when the server returns status code 402, Pay.sh further determines the target service's payment method. For one-time data access (payment grants one-time access) or usage-based access (payment grants a fixed amount of access), Pay.sh constructs a one-time fixed-amount transfer and broadcasts it on-chain. For continuous billing or session-based billing (unified bill for usage paid at once), Pay.sh supports the session authorization token introduced by the MPP (Machine Payment Protocol), writing the budget cap into the authorization and sending it back to the server. The agent can then repeatedly call a certain service within a short time, avoiding frequent similar authorization requests. Pay.sh updates the remaining balance with each call and automatically re-initiates session authorization when the balance is depleted or the service expires. Pay.sh automatically selects the more appropriate payment rail based on the target service's requirements, potentially reducing usage and management costs. Pay.sh also ensures the wallet remains securely stored locally, requesting user confirmation only 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 by Pay.sh as untrusted input. The agent must not directly execute instructions returned by the service provider to prevent malicious prompt injection or other attacks.
The biggest advantage of Pay.sh is that it provides a gateway for service providers to easily deploy. Service providers can integrate the payment gateway into their service network without significant modifications to their payment pathways or APIs. By simply providing a declarative file specifying payment-related parameters, service providers can adapt to various complex usage scenarios. For example, by defining routing rules, agents can use a service for free up to a certain limit, with charges applied beyond that quota, or even implement tiered pricing (different prices for different usage levels). Additionally, Pay.sh offers payment splitting functionality. The fees received by the service provider can be automatically sent to multiple addresses, e.g., 2% for data royalty fees, 5% for cloud costs, and the remainder for their own operations. Service providers only need to define different percentages or amounts when setting up the receiving addresses to achieve multi-account settlement at once. After registration, service providers can publish their API service data to the Pay Skill Registry, where agents can discover and select suitable API services by querying the registry.
Pay.sh itself is not a competitor to x402 and MPP. While the x402 and MPP protocols strive to make on-chain agent payments more reliable, Pay.sh aims to bridge the Web2 and Web3 payment ecosystems, providing agents with corresponding identities for resource acquisition. An agent's wallet serves as both identity and payment method. It no longer needs to register accounts on service provider websites to obtain services (currently, some providers might treat agents imitating human registration as a violation). Furthermore, Pay.sh's collaboration with Google enables API proxy and traffic scheduling for agents to be completed on Google Cloud, ensuring access control and log compliance, keeping agent behavior within reasonable bounds. Pay.sh can provide a curated service directory and pricing discovery. Agents do not need to randomly discover services in an unprotected network environment. It can leverage both x402 and MPP payment methods. The service process can meet enterprise compliance requirements on Google Cloud. These aspects complement the agent payment capabilities that the singular payment channels of x402 and MPP cannot cover, while also opening an entry point for agent commerce to flow into Web3. Additionally, Pay.sh can complete the final payment step for multiple agent commerce protocols launched by Google, such as A2A (Agent2Agent Protocol) for agent communication and task delegation, AP2 (Agent Payments Protocol) for compliance verification, and UCP (Universal Commerce Protocol) for service discovery and execution. Pay.sh is responsible for the final, seamless settlement of service value. The emergence of Pay.sh also simultaneously perfects the Web2 agent commerce cycle, becoming the convergence point for value flow between the two worlds. This step also represents an upgrade opportunity for the Solana public chain ecosystem itself. In the x402 protocol environment, there are numerous shell APIs, where service providers might violate the original service provider's terms and resell their services, such as maliciously scraping and reselling data from database websites or encapsulating and reselling large model APIs to others. Agents in such an environment have no way to distinguish between authorized services and malicious, spam services. Through the Pay.sh payment gateway and Google's collaboration, agents using services via Pay.sh are expected to have reduced potential risks. The launch of Pay.sh marks 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 currently far from being a perfect payment gateway solution. Pay.sh's service provider registry currently lacks admission mechanisms and decentralized verification mechanisms, making it still difficult to effectively distinguish between unauthorized third-party shell services and malicious services. Agents run a significant risk of connecting to counterfeit services, potentially causing losses for users. Moreover, since Pay.sh itself does not design the underlying payment protocols, the security of the payment process relies more on the design of those underlying protocols. This introduces uncontrollable external risks to Pay.sh and could also lead to potential payment failures due to insufficient adaptation to different protocols. From the service provider's perspective, despite Google's platform endorsement, API suppliers in different countries and regions might still hesitate to adopt the services provided by Pay.sh due to compliance requirements related to data privacy management inherent to their services and payment compliance requirements. This could not only limit the number of service providers using Pay.sh but might also require Pay.sh to make more compliance efforts in the future. Nonetheless, the launch of Pay.sh marks a step forward in the fusion and practical implementation of Web2 and Web3 for agent payment infrastructure. On-chain wallets will 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 Structure Diagram:
Disclaimer: This report is compiled by Web3Caff Research. The information contained herein is for reference only and does not constitute any prediction, investment advice, proposal, or offer. Investors should not rely on such information to purchase, 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 the Web3, including the blockchain industry, and should not be interpreted as definitive legal opinions or the views of Web3Caff Research. The opinions in this report reflect only the personal views of the author as of the stated date, are independent of the position of Web3Caff Research, and may change following subsequent circumstances. The information and opinions contained in this report come from proprietary and non-proprietary sources that Web3Caff Research considers reliable, do not necessarily cover all data, and do not guarantee their accuracy. Therefore, Web3Caff Research makes no guarantee of their accuracy or reliability in any form and assumes no responsibility for errors and omissions arising in any other way (including liability to any person arising from negligence). This report may contain "forward-looking" information, which may include predictions and forecasts. This article does not constitute a guarantee of any prediction. Whether to rely on the information contained in this report is entirely up to the reader's discretion. This report is for reference 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.
