Feito para compradores que não são humanos.
Cada link de pagamento da CryptoPayIn e cada loja também funciona como um checkout legível por máquina. Um agente de IA descobre o que você vende, cria uma fatura e paga on-chain em três chamadas HTTP — sem navegador, sem chave de API, sem humano no processo. Entrega incluída, em JSON.
Três chamadas. Essa é toda a integração.
Pegue qualquer link — digamos, https://cryptopaylink.co/pay/PL-XXXXXXX.
Acrescente .json e o fluxo de máquina começa. Tudo abaixo já está em produção hoje, em todo link.
O que é vendido, o preço, os ativos aceitos e os campos exatos que a chamada de fatura espera — autodescritivo, de modo que o agente não precisa de nenhum conhecimento prévio sobre o lojista.
{
"protocol": "cpi-agent-checkout/1",
"link": {
"id": "PL-XXXXXXX", "state": "ok",
"title": "Pro license — 1 seat",
"pricing": { "currency": "USD", "type": "fixed", "amount": "12.00" },
"delivery": { "type": "keys", "description": "A unique key reserved for you…" }
},
"payment_assets": [ { "asset": "BTC", "network": "mainnet", "min_usd": "5.00" }, … ],
"checkout": { "create_invoice": { "method": "POST", "url": "…/invoice" }, … }
}Um único corpo JSON — o ativo, mais o que o link exigir (valor para preços abertos, variante,
campos do comprador, envio para produtos físicos). Envie um cabeçalho Idempotency-Key e as novas tentativas nunca geram fatura duplicada.
curl -X POST https://cryptopaylink.co/pay/PL-XXXXXXX/invoice \
-H "Content-Type: application/json" \
-H "Idempotency-Key: agent-run-42" \
-d '{ "asset": "BTC", "fields": { "Discord username": "buyer#0001" } }'
{ "ok": true, "invoice": {
"payment": "P-XXXXXXXXXX",
"pay": { "asset": "BTC", "network": "mainnet",
"address": "bc1q…", "amount": "0.0001867",
"uri": "bitcoin:bc1q…?amount=0.0001867" },
"expires_at": "2026-07-20T11:00:25Z",
"receipt": "…/receipt?p=P-XXXXXXXXXX" } }O valor é exato e a taxa de câmbio é travada — o agente envia precisamente
pay.amount em pay.network a partir de qualquer carteira que controle. Sem SDK, sem esquema de assinatura, sem facilitador.
Consulte a cada poucos segundos. As confirmações avançam e, no momento em que o pagamento é concluído, a resposta contém a entrega — conteúdo, link ou uma chave de licença reservada exatamente para esse pagamento.
As lojas falam o mesmo protocolo. GET /s/SH-x.json lista o catálogo completo
de uma loja (produtos, variantes, estoque em tempo real); um único POST /s/SH-x/order transforma um carrinho em uma fatura
pagável — o recibo fica em /s/SH-x/o/ORD-…/receipt.
{ "ok": true, "receipt": {
"payment": "P-XXXXXXXXXX", "status": "completed",
"paid_at": "2026-07-20T10:30:58Z",
"delivery": { "type": "keys", "key": "LICENSE-XXXX-YYYY",
"note": "Delivered once, tied to this payment — store it now." },
"next": "done" } }Engenharia sóbria, de propósito
As faturas de agentes passam exatamente pela mesma validação, travamento de taxa e derivação de endereço que a página hospedada — um único caminho de código, sem implementação paralela para divergir ou ser explorada.
Os endpoints de agentes consomem os mesmos limites de taxa e tetos de faturas pendentes que a página. Ativar agentes não adiciona nenhuma capacidade extra para esgotamento de endereços ou spam.
Sem cookies, sem sessões, sem superfície de CSRF no domínio de pagamento. O ID de pagamento é a única capacidade, exatamente como na URL de recibo para humanos.
O cabeçalho Idempotency-Key torna a criação de faturas segura contra reenvios; a mesma chave com um corpo diferente é recusada com 409.
O checkout para agentes é configurado por conta e vem ativado por padrão. Desativado significa 403 nos endpoints de máquina, enquanto toda página para humanos continua funcionando.
As páginas para humanos enviam Link: …/pay/PL-x.json; rel="alternate", e esse contrato é resumido em llms.txt para mecanismos de resposta.
Tudo o que um link de pagamento pode vender
Conteúdo em texto, URLs privadas, chaves de licença de uso único — entregues no JSON do recibo, reservados por pagamento, protegidos contra condições de corrida sob limites de estoque.
Preços fixos em qualquer uma das 30 moedas fiduciárias, ou valores abertos (gorjetas, faturas, recargas) com mínimo/máximo definidos pelo lojista — o agente informa "amount".
Variantes de produto com estoque individual, além de campos obrigatórios personalizados (nomes de usuário, observações do pedido) declarados no documento de descoberta.
A chamada de fatura aceita um endereço de envio estruturado, validado conforme o país de destino — agentes podem encomendar itens que chegam em caixas.
GET /s/SH-x.json expõe o catálogo completo de uma loja com estoque em tempo real; um único POST …/order valida o carrinho, reserva o estoque e retorna a fatura.
Vender para agentes é o lado do comprador. Se você está construindo o lado do lojista — criando links, consultando saldos, sacando — isso é a API REST para lojistas, e ela é igualmente programável.
Perguntas sobre agentes, respondidas com clareza
Um agente precisa de uma chave de API ou de uma conta?
Não. A descoberta, a criação da fatura e o recibo são endpoints públicos vinculados a um único link de pagamento — exatamente como a página de checkout para humanos. O ID de pagamento retornado na criação é a única credencial de que o agente precisa para consultar seu próprio recibo. As chaves de API de lojista existem para vendedores, não para compradores.
Como o agente efetivamente paga?
A resposta da fatura contém um endereço de depósito, um valor exato e uma URI no estilo BIP-21. Qualquer carteira controlada pelo agente — uma carteira BTC, um signatário EVM, um par de chaves Solana, uma carteira Monero — envia esse valor na rede indicada. Não há esquema de assinatura proprietário para integrar.
Isso é x402?
É independente de protocolo. Qualquer stack capaz de fazer chamadas HTTPS e transmitir uma transação em cripto pode pagar — sem facilitador, sem SDK de carteira especial. Se o seu framework fala x402 ou AP2, basta encapsular a chamada de fatura na sua ferramenta de pagamento; o contrato JSON se alinha perfeitamente a um fluxo no estilo 402, e a negociação nativa de x402 está no roteiro.
Quais links e lojas podem ser pagos por agentes?
Todo link de pagamento ativo e toda loja ativa, por padrão — preços fixos, valores abertos, variantes de produto, campos do comprador, produtos físicos com envio e catálogos completos de loja com estoque em tempo real. Os lojistas podem desativar o checkout para agentes por conta em Configurações; os endpoints passam então a responder 403, enquanto as páginas para humanos continuam funcionando.
O que o agente recebe depois de pagar?
O endpoint de recibo retorna a entrega em JSON no momento em que o pagamento é concluído: o conteúdo, o link privado ou uma chave de licença reservada para aquele pagamento. Pedidos físicos confirmam que o lojista recebeu o endereço de envio.
Um agente mal-intencionado pode abusar dos endpoints?
As chamadas de agentes compartilham exatamente os mesmos limites de taxa, tetos de fatura e regras de idempotência da página de checkout hospedada — elas não acrescentam nenhuma capacidade extra de ataque. Não há cookies nem sessões no domínio de pagamento, portanto não existe estado que uma chamada entre sites possa explorar.
Seu próximo cliente pode ser um script.
Sua conta está a um clique — sem KYC, sem espera. Uma taxa fixa de 1% por transação. Sem mensalidades, sem custos de configuração.