Como dominar facilmente os pontos quentes do mercado, tendências tecnológicas, avanços ecológicos e dinâmicas de governança que estão ocorrendo no setor Web3? O programa "Análise do Pulso do Mercado", lançado pela Web3Caff Research, investiga e seleciona em primeira mão os eventos quentes atuais, oferecendo interpretação de valor, comentários e análise dos princípios por trás deles. Veja além da aparência e acompanhe-nos para capturar rapidamente as tendências do mercado Web3 em tempo real.
Autor do artigo: Hendrix, pesquisador da Web3Caff Research
Fonte: Web3Caff Research
As AI agents continue to enhance their capabilities and take on an increasing number of end-to-end tasks, building payment systems for agents has become a necessary evolution for traditional merchants and service providers. However, existing solutions each have their limitations: traditional payment systems, such as credit cards and third-party payment platforms, were originally designed for human users and require complex identity verification and risk assessment processes that are unsuitable for agents; meanwhile, emerging agent payment protocols like x402 (developed and promoted by Coinbase), MPP (Machine Payment Protocol developed by Tempo and Stripe), etc., operate as separate systems entirely built for on-chain payments, processing the entire transaction on-chain and relying on on-chain verification for security. Service providers must therefore build an entirely separate payment infrastructure outside their traditional payment channels, raising the barrier to adoption. Traditional payment solutions and emerging agent payment protocols resemble two parallel lanes that have not been effectively integrated, limiting agents’ ability to autonomously purchase services mostly to Web3-friendly ecosystems, thus preventing large-scale workflow chaining. To address this, Solana Foundation, in collaboration with Google Cloud, has launched Pay.sh, positioned as a “payment gateway between agents and enterprise-grade service infrastructure,” bridging the final step for agents to access a broader range of services.
Aviso de conformidade: O conteúdo a seguir é apenas uma análise objetiva do Pay.sh e de seus princípios e regras técnicas, e não constitui qualquer proposta ou oferta. Por favor, não tome decisões com base nessas informações e cumpra rigorosamente as leis e regulamentos do seu país ou região (leitores da China continental são fortemente aconselhados a ler o documento “Resumo e Pontos Principais das Leis e Regulamentos da China Continental Relacionados a Blockchain e Moedas Virtuais”) e não participem de quaisquer atividades financeiras proibidas por lei em seu país ou região.
Pay.sh permite que os usuários recarreguem rapidamente suas carteiras Solana por meio de cartão de crédito oumoedas estáveisparacarteirasSolana, que podem atuar como agentes de identidade e pagamento no mundo dos recursos Web2. Quando os agentes precisarem acessar serviços, não será mais necessário se registrar ou inserir chaves API; o gateway Pay.sh declarará a identidade legítima do agente, como um sistema de identidade do Google, permitindo que o agente use uma identidade de conta unificada para adquirir recursos de desenvolvimento anteriormente difíceis de obter, como o Google Cloud e a Alibaba Cloud.conta
Os serviços API atualmente suportados pelo Pay.sh. Fonte: site oficial do projeto
O fluxo de pagamento do Pay.sh é semelhante ao protocolo x402, que se tornou popular recentemente, ambos baseados no código de status HTTP 402: quando um agente detecta a necessidade de chamar um serviço externo, ele faz uma requisição ao recurso pago, e o servidor responde com o código de status 402 (pagamento necessário), junto com detalhes completos do pagamento, incluindo valor, plano de pagamento, endereço de recebimento, validade do pagamento, entre outros. O Pay.sh analisa essas informações e solicita autorização à carteira; após o pagamento ser concluído e um comprovante gerado, o Pay.sh reenvia a requisição do serviço com o comprovante e recebe a resposta normal. Contudo, para cobrir diversos cenários de uso de API, o Pay.sh também é compatível com os mecanismos de pagamento x402 e MPP: quando o servidor retorna o código 402, o Pay.sh avalia o método de pagamento do serviço-alvo. Se for um acesso único (pagamento para obter uma única permissão de acesso) ou um acesso baseado em uso (pagamento para obter uma quantidade fixa de acesso), o Pay.sh constrói e transmite na blockchain uma transferência única e de valor fixo. Se for cobrança contínua ou baseada em sessão (pagamento único consolidado conforme o uso), o Pay.sh suporta o credencial de autorização de sessão do protocolo MPP (Machine Payment Protocol), inserindo o limite orçamentário na autorização e retornando-o ao servidor; assim, o agente pode invocar repetidamente o serviço em curto espaço de tempo, evitando autorizações frequentes repetidas. O Pay.sh atualiza o saldo restante em cada chamada e, quando o saldo se esgota ou o serviço expira, automaticamente reinvoca a autorização da sessão. O Pay.sh seleciona automaticamente a via de pagamento mais adequada conforme os requisitos do serviço-alvo, reduzindo custos de uso e gestão. Além disso, o Pay.sh garante que a carteira seja sempre armazenada localmente com segurança e solicita confirmação do usuário apenas quando um pagamento for necessário. Quando há retorno de informações, o Pay.sh distingue entre dados e instruções: todo conteúdo externo retornado pelo provedor de serviço (incluindo título, corpo e descrição da API) é tratado como entrada não confiável; o proxy não executa diretamente as instruções retornadas pelo provedor para evitar injeção de prompt malicioso ou outros ataques.
A principal vantagem do Pay.sh é que ele fornece aos provedores de serviços também uma passagem de pagamento facilmente implantável, permitindo que os provedores integrem a passagem de pagamento em sua rede de serviços sem precisar modificar em grande escala seus canais ou APIs de pagamento. O provedor precisa apenas fornecer um arquivo declarativo especificando os parâmetros relacionados ao pagamento para adaptar-se a diversos cenários complexos, como definir regras de roteamento para permitir que agentes usem o serviço gratuitamente até um determinado limite, e começar a cobrar após exceder a cota, ou até mesmo implementar cobranças escalonadas (preços diferentes conforme o volume utilizado); além disso, o Pay.sh oferece funcionalidade de divisão de pagamento, permitindo que os valores recebidos pelo provedor sejam automaticamente enviados para múltiplos endereços — por exemplo, 2% para direitos autorais de dados de pagamento, 5% para custos de nuvem, e o restante para operações próprias — basta definir diferentes percentuais ou valores ao configurar os endereços de recebimento para realizar o pagamento em múltiplas contas de uma só vez. Após o registro, o provedor pode publicar os dados do serviço API fornecido no Pay Skill Registry, permitindo que agentes descubram e escolham serviços API adequados consultando o registro.
Pay.sh não é um concorrente direto do x402 nem do MPP. Enquanto os protocolos x402 e MPP buscam tornar os pagamentos on-chain para agentes o mais confiável possível, o Pay.sh tem como objetivo conectar os ecossistemas de pagamento Web2 e Web3, atribuindo identidade aos agentes para acessar recursos. A carteira do agente serve como identidade e meio de pagamento, eliminando a necessidade de registrar-se separadamente nos sites dos prestadores de serviço (algo que alguns prestadores podem considerar uma violação, ao tratar agentes como se fossem humanos). Além disso, por meio da parceria com o Google, o Pay.sh permite que agentes executem proxy de API e roteamento de tráfego diretamente na Google Cloud, garantindo controle de acesso e conformidade logística, mantendo o comportamento dos agentes dentro de limites aceitáveis. O Pay.sh oferece um diretório de serviços selecionados e descoberta de preços, permitindo que agentes não precisem descobrir serviços aleatoriamente em ambientes de rede sem proteção, enquanto ainda podem utilizar diferentes métodos de pagamento do x402 e MPP. Todo o processo de serviço pode ser concluído na Google Cloud, atendendo aos requisitos corporativos de conformidade — complementando assim as capacidades de pagamento de agentes que os protocolos x402 e MPP, como canais de pagamento únicos, não conseguem cobrir, além de abrir uma porta para a comercialização de agentes no Web3. Além disso, o Pay.sh também preenche o último elo de pagamento em diversos protocolos comerciais de agentes lançados pelo Google, como o A2A (Agent2Agent Protocol), que permite comunicação e delegação de tarefas entre agentes; o AP2 (Agent Payments Protocol), que realiza validação de conformidade; e o UCP (Universal Commerce Protocol), que realiza descoberta e execução de serviços — enquanto o Pay.sh cuida do encerramento sem atritos do valor do serviço. A chegada do Pay.sh também completa os componentes comerciais de agentes no Web2, tornando-se um ponto de encontro para o fluxo de valor entre os dois mundos. Esse passo representa, ao mesmo tempo, uma oportunidade de evolução para o ecossistema da blockchain Solana. No ambiente do protocolo x402, existem inúmeras APIs disfarçadas, nas quais provedores de serviço violam os termos dos prestadores originais e revendem seus serviços — como coletar indevidamente dados de sites de banco de dados para revenda, ou encapsular APIs de grandes modelos para revenda a terceiros. Nesse cenário, agentes não conseguem distinguir quais serviços são autorizados e quais são maliciosos ou spam. Por meio da passarela de pagamento do Pay.sh e da cooperação com o Google, agentes que utilizam serviços por meio do Pay.sh têm potencial para reduzir riscos. O lançamento do Pay.sh marca a entrada da blockchain Solana para fornecer endosso e infraestrutura para pagamentos de agentes — não apenas atraindo mais fluxo de pagamento Web2 para a própria Solana, mas também aprimorando e acelerando a adoção das carteiras Solana.
No entanto, o Pay.sh ainda está longe de ser uma solução perfeita para gateway de pagamento. O registro de provedores do Pay.sh atualmente carece de mecanismos de acesso e verificação descentralizada, tornando ainda difícil distinguir eficazmente serviços terceirizados não autorizados de serviços maliciosos; agentes correm grande risco de se conectar a serviços falsificados, causando perdas aos usuários. Além disso, como o Pay.sh não projeta os protocolos de pagamento subjacentes, a segurança do processo de pagamento recai principalmente sobre o próprio design dos protocolos subjacentes, introduzindo riscos externos imprevisíveis para o Pay.sh e potencialmente levando a falhas de pagamento devido à adaptação insuficiente a diferentes protocolos. Do ponto de vista dos provedores de serviço, embora haja o respaldo da plataforma Google, fornecedores de API em diferentes países e regiões podem hesitar em oferecer serviços ao Pay.sh devido a exigências regulatórias relacionadas à gestão de privacidade de dados e conformidade com pagamentos. Isso não apenas limitará o número de provedores de serviço que utilizam o Pay.sh, mas também poderá exigir, no futuro, que o Pay.sh realize esforços adicionais em conformidade. Contudo, independentemente disso, o lançamento do Pay.sh marca um passo importante na implementação da integração entre Web2 e Web3 na infraestrutura de pagamentos de agentes, permitindo que carteiras on-chain se tornem uma garantia para agentes participarem de tarefas diversas. Portanto, podemos continuar observando o desenvolvimento subsequente do Pay.sh.
Diagrama de estrutura de pontos:
