Original Author:Hendrix, Researcher at Web3Caff Research

How to easily grasp the market hotspots, technological trends, ecological progress, and governance situations happening in the Web3 industry? The "Market Pulse Analysis" column launched by Web3Caff Research will delve into the front lines to explore and select the current hot events, providing value interpretation, commentary, and principle analysis. Looking at the essence through the phenomenon, immediately follow us to quickly capture the market trends in the Web3 frontline.

As the capabilities of AI agents continue to enhance and cover more end-to-end tasks, building payment systems for agents has become a change that traditional merchants and service providers must make. However, existing solutions have their limitations: traditional payment systems, such as credit cards and third-party payment platforms, are originally designed for real human users, requiring complex identity verification and risk assessment processes that are not applicable to agents; while emerging agent payment protocols, such as x402 (developed and promoted by Coinbase) and MPP (the Machine Payment Protocol developed by Tempo and Stripe), seem to set up a separate system, completely oriented towards on-chain payments, where the entire payment is processed on-chain, relying on on-chain verification to ensure security, requiring service providers to build a different payment system outside traditional payment channels, which increases the usage threshold. Traditional payment solutions and emerging agent payment protocols are like two parallel lanes and have not integrated well, leading to the fact that services that agents can independently purchase are usually limited to Web3-friendly areas, making it difficult to connect workflows at scale. To address this, the Solana Foundation and Google Cloud have jointly launched Pay.sh, positioned as "a payment gateway between agents and enterprise service facilities," enabling agents to call more services.

Compliance Note: The following content only provides an objective analysis of Pay.sh and its technical principles and design rules, and does not constitute any proposals or offers. Please do not make related decisions based on this information, and please strictly comply with the laws and regulations of your country or region (readers from mainland China are strongly advised to read the "Compilation and Key Points of Relevant Laws and Regulations on Blockchain and Virtual Currency 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 recharge their Solana wallets with credit cards or stablecoins. After that, the Solana wallet can act as an 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 like Google's identity system, allowing agents to use a unified account identity to purchase development resources that were previously difficult to obtain, such as Google Cloud and Alibaba Cloud.

Current API services supported by Pay.sh Image source: Project Official Website

The payment process of Pay.sh is similar to the x402 protocol that became popular recently, both built on the HTTP 402 status code: when an agent discovers an external service that needs to be called, it will initiate a request for paid resources, and the server will return status code 402 (payment required), simultaneously providing payment details, including payment amount, payment plan, recipient address, payment validity, and more. Pay.sh will parse the corresponding content and initiate authorization to the wallet. Once the wallet completes the payment and generates a payment certificate, Pay.sh will carry the certificate to initiate the service request again to obtain a normal response. However, to cover various API use scenarios, Pay.sh is also compatible with both x402 and MPP's payment logic: when the server returns status code 402, Pay.sh will further assess the payment method for the target service. If it is a one-time data access (payment grants one-time access permission), or a usage-based access type (payment grants fixed amount of access), Pay.sh will construct a one-time fixed-amount transfer and broadcast it on-chain; if it is continuous billing or session-based billing (payment for a unified bill according to usage), Pay.sh will support the session authorization certificate introduced by MPP, writing the budget cap into the authorization and returning it to the server. In this case, the agent can repeatedly call a service within a short time, avoiding frequent initiation of similar authorizations. Pay.sh will update the remaining budget with each call, and automatically re-initiate session authorization when the budget is exhausted or the service expires. Pay.sh will automatically choose a more suitable payment track according to the target service's requirements, which can reduce usage and management costs. Pay.sh will also ensure that the wallet is always securely stored locally, only requesting user confirmation when payment is needed. When information is returned, Pay.sh will differentiate between data and instructions. All external content returned by the service provider (including titles, body text, and API descriptions) will be treated as untrusted input by Pay.sh, and the agent must not directly execute the instructions returned by the service provider to prevent malicious prompt injection or other attacks.

The greatest advantage of Pay.sh is that it provides a set of easily deployable gateways for service providers, allowing them to integrate the payment gateway into their service networks without large-scale modifications to their payment channels or APIs. Service providers only need to provide a declarative file outlining payment-related parameters to adapt to various complex usage scenarios. For example, by defining routing rules, agents can use services for free within a certain amount, incur charges beyond the limit, or even implement tiered pricing (charging different prices for different usages); additionally, Pay.sh also offers payment splitting, allowing fees received by service providers to be automatically sent to multiple addresses, such as 2% for paying data copyright fees, 5% for cloud costs, and the remaining portion retained for self-operation. Service providers only need to define different percentages or amounts when setting up collection addresses to achieve multi-account settlement in one go. After registration, service providers can publish their provided API service data to the Pay Skill Registry, and agents can discover and select appropriate API services by querying the registry.

Pay.sh itself is not a competitor to x402 and MPP. While the x402 and MPP protocols aim to make on-chain agent payments more reliable, Pay.sh's goal is to connect Web2 and Web3 payment ecosystems, granting corresponding identities to agents to access resources. An agent's wallet serves as both identity and payment method, eliminating the need to register an account on the service provider's official website to obtain services (some service providers may currently treat agents imitating humans to register for services as violations). Additionally, through cooperation with Google, Pay.sh enables agents to perform API proxy and traffic scheduling on Google Cloud, ensuring access control and logging compliance, normalizing agents' behavior within reasonable bounds. Pay.sh can provide a filtered service directory and pricing discovery, allowing agents to avoid randomly discovering services in unprotected network environments while being able to call upon different payment methods of x402 and MPP, with the service process fulfilling corporate compliance requirements on Google Cloud. These all enhance the agent payment capability that x402 and MPP as single payment channels cannot cover, while also opening the gateway for agent business to flow into Web3. Furthermore, Pay.sh can also supplement the final payment link for several agent business protocols launched by Google, such as A2A (Agent2Agent Protocol) for communication and task delegation between agents, AP2 (Agent Payments Protocol) for compliance verification, and UCP (Universal Commerce Protocol) for service discovery and execution, while Pay.sh is responsible for the final seamless service value settlement. The emergence of Pay.sh also perfects the aspects of Web2 agent business, becoming a convergence point of value flow between the two worlds. This also represents an upgrade opportunity for the Solana public chain ecosystem itself. In the environment of the x402 protocol, there are many shell APIs, and service providers may violate the original service provider's terms and resell their services, 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 which services are authorized and which are malicious junk services. Through the Pay.sh payment gateway and cooperation with Google, agents are expected to reduce potential risks when using services via Pay.sh. The launch of Pay.sh marks the Solana public chain stepping in to provide endorsement and infrastructure support for agent payments, which not only attracts more Web2 payment traffic to Solana itself but also further enhances the capabilities of the Solana wallet and accelerates its adoption.

However, Pay.sh is currently far from a perfect payment gateway solution. The service provider registry of Pay.sh currently lacks access mechanisms and decentralized verification mechanisms, making it still difficult to effectively distinguish unauthorized third-party shell services and malicious services, posing a significant risk for agents to access counterfeit services, potentially causing user losses. In addition, since Pay.sh itself does not engage in the design of underlying payment protocols, the security of the payment process relies more on the design of the underlying protocols themselves, introducing uncontrollable external risks for Pay.sh, and also possibly leading to potential payment failures due to insufficient adaptation to different protocols. From the perspective of service providers, despite the endorsement of the Google platform, API providers may still hesitate to use Pay.sh's services due to compliance needs for data privacy management and payment compliance regarding their services in different countries and regions. This could not only limit the number of service providers using Pay.sh but also potentially demand more compliance efforts from Pay.sh in the future. Nevertheless, the launch of Pay.sh marks a step forward in the foundational infrastructure of agent payments, embodying the integration of Web2 and Web3. On-chain wallets are expected to become endorsements for agents to participate in diverse tasks. Thus, we can continue to observe the subsequent developments of Pay.sh.

Key Point Structure Diagram:

Disclaimer: This report is prepared by Web3Caff Research. The information contained herein is for reference only and does not constitute any predictions or investment advice, proposals, or offers. Investors are advised not to rely on such information for buying or selling any securities, cryptocurrencies, or taking any investment strategies. The terms used and views expressed in the report aim to assist in understanding industry trends and promote responsible development of the Web3, including the blockchain industry, and should not be interpreted as explicit legal opinions or the views of Web3Caff Research. The opinions in the report only reflect the personal opinions of the author as of the stated date, unrelated to the position of Web3Caff Research, and may change as circumstances evolve. The information and views contained in this report come from sources believed to be reliable by Web3Caff Research but may not cover all data and do not guarantee accuracy. Therefore, Web3Caff Research does not offer any form of warranty regarding accuracy and reliability and will not bear responsibility for any errors and omissions arising in any other way (including liability to anyone arising from negligence). This report may contain "forward-looking" information, which may include predictions and forecasts, and this document does not constitute guarantees regarding any predictions. Relying on the information contained in this report is entirely at the reader's discretion. This report is for reference only and does not constitute investment advice, proposals, or offers for purchasing or selling any securities, cryptocurrencies, or taking any investment strategies, and please strictly comply with the relevant laws and regulations in your country or region.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。