Seu produto vende relatórios de pesquisa por assinatura mensal. O cliente entra, escolhe um tema e volta quando precisa de outra análise.
Agora considere uma compra diferente. Um agente está montando um relatório para alguém e precisa de um dado da sua API. Uma resposta. Uma vez. Dentro de uma tarefa maior.
O dado tem valor. O plano mensal talvez seja a oferta errada para aquela compra.
Antes de pensar na carteira do agente, existe uma decisão comercial: o que você aceita vender separadamente?
A unidade de compra aparece antes do checkout
“Acesso à API” parece uma descrição suficiente até alguém perguntar o que recebe quando paga.
Uma consulta executada? Uma resposta válida? Um relatório concluído? Acesso por um período?
Essas promessas produzem cobranças diferentes. Se você vende uma tentativa, uma consulta sem resultado pode cumprir o contrato. Se vende um relatório concluído, iniciar o processamento não basta.
Considere um serviço de pesquisa de fornecedores. O agente solicita uma lista, mas nenhum fornecedor atende aos critérios. Uma lista vazia é uma resposta útil ou uma compra sem entrega? Não existe resposta universal. Existe a oferta que o vendedor definiu e o comprador aceitou.
Deixar essa regra implícita transfere a discussão para o suporte depois da cobrança.
x402 muda o caminho de compra
O x402 é um padrão aberto para cobrar por acesso a recursos via HTTP. Um cliente compatível recebe as condições e pode seguir o fluxo de pagamento para obter o recurso. Documentação do x402.
Isso aproxima a compra do lugar onde o software já está trabalhando. A requisição não precisa necessariamente terminar numa pessoa abrindo uma página de planos.
Mas o protocolo não escolhe o preço, não financia o comprador e não decide quem pode gastar. Essas responsabilidades continuam existindo.
O Infi Rail é a frente da Infi para pagamentos x402 em APIs HTTP e ferramentas MCP, em early access. Os fluxos, ativos e redes disponíveis precisam ser confirmados antes da integração. Conheça o Infi Rail.
Uma chamada de rede não é a identidade da compra
Suponha que o serviço aceite a requisição e produza o relatório. A conexão cai antes de a resposta chegar.
O agente tenta de novo.
Se cada chamada for tratada como uma compra independente, você pode cobrar duas vezes por uma única intenção. Se toda chamada repetida for gratuita, pode entregar trabalho novo sem cobrar.
A aplicação precisa distinguir recuperação de uma operação anterior de uma nova solicitação. Isso exige uma identidade comercial estável e uma regra para consultar ou recuperar o resultado.
Também precisa definir quando o trabalho começa, qual confirmação de pagamento permite liberar a entrega e o que acontece quando uma dessas etapas fica incerta. São decisões de integração, não consequências automáticas de adicionar um protocolo.
Um novo comprador pode abrir outra linha de receita
Talvez sua assinatura continue sendo a melhor oferta para equipes que pesquisam diariamente. A compra avulsa pode atender quem só precisa de um resultado. Um pacote pode fazer sentido para consumo previsível.
Esses são modelos possíveis de produto, não uma promessa de que todos já estejam disponíveis pelo Rail.
O teste inicial pode ser pequeno: escolher uma operação útil, definir uma unidade comprável e descrever as condições de entrega. Não precisa reorganizar toda a empresa para descobrir se aquela oferta faz sentido.
Na visão de AiFi que usamos na Infi, pessoas e empresas estabelecem as permissões dentro das quais agentes participam da economia. Do lado de quem vende, a oferta precisa ser compreensível por esse comprador.
Escreva uma frase antes de escrever a integração:
“O comprador paga por uma consulta concluída e pode recuperar a mesma resposta se a conexão cair.”
Ela já diz mais sobre seu produto do que “aceitamos pagamentos de agentes”.