Skip to main content
PayAo vivo

Uma chamada governada.Qualquer trilho.

Seu agente chama pay uma vez. O runtime confere o mandato, escolhe o trilho — USDC via x402, Pix no Brasil — e sela o recibo. O agente nunca nomeia um provedor; quem faz isso é o router.

pay() · rastro da chamada
Checagem de mandatoAssinadoOK
RouterPixSelecionado
LiquidaçãoR$142.50Asaas
Reciborcpt_9f2c1a4eSelado

Os nomes dos campos e a sequência são reais — checagem de mandato, depois roteamento, depois liquidação, depois um recibo selado. A linha de liquidação cita um provedor de Pix de saída: a linha de Pix do Mercado Pago cria uma cobrança de entrada, então o router não a usa no pay.

O problema

Pagar um fornecedor não devia exigir três integrações.

Rotear dinheiro pra um fornecedor, um prestador, ou um payout internacional hoje significa plugar um PSP de Pix, uma processadora de cartão e uma wallet de stablecoin — três SDKs, três políticas de retry, três relatórios de reconciliação pra bater à mão. O Pay junta tudo isso numa chamada só.

Integração
Plugar três SDKs separados — um PSP de Pix, uma processadora de cartão, uma wallet de stablecoin — cada um com sua própria autenticação e setup.
Uma chamada codespar_pay. O router já fala com todo trilho.
Retry e idempotência
Cada trilho retenta e deduplica diferente — um timeout numa integração pode duplicar o pagamento em outra.
Uma chamada governada, conferida contra o mandato antes de qualquer coisa se mover.
Escolha do trilho
Seu código tem que decidir de antemão qual trilho chamar pra cada destino.
O agente nunca nomeia um trilho — o router escolhe a partir do mandato e do destino.
Reconciliação
Reconciliar o gasto significa bater recibos de três dashboards diferentes à mão.
Todo pagamento liquidado volta com um recibo selado, no mesmo formato, não importa qual trilho liquidou.
Como funciona

O mandato decide o que é permitido. O router decide como.

Uma chamada, conferida contra o mandato assinado antes de qualquer coisa se mover, e depois roteada pro trilho que encaixa: USDC liquidando via x402, Pix pra BRL. USDC/x402 é um slot da mesma wallet; a linha Pix roda no mesmo runtime, não é uma integração separada.

A chamada, passo a passo
1Seu agente chama pay() uma vez — valor, destino, nada além disso.
2O runtime confere a chamada contra o mandato assinado antes de qualquer coisa se mover.
3O runtime resolve o trilho: o router escolhe o provedor pra Pix, cartão e USDC via x402; um boleto liquida pela linha digitável.
4O trilho liquida e um recibo selado volta pro agente.
No código

A chamada que seu agente realmente faz.

Seu agente chama pay uma vez — valor, destino, e a referência do mandato. Não tem parâmetro de provedor pra setar. O runtime confere a chamada contra o mandato assinado primeiro, porque o teto tem que valer antes do dinheiro se mover, não depois — daí resolve a chamada pro provedor que encaixa.

pay-supplier.ts
const session = await codespar.sessions.create({
  mandate: mandate.id,
});

const payment = await session.execute("codespar_pay", {
  input: {
    amount: 14250,              // R$142.50 in centavos
    currency: "BRL",
    destination: "supplier_8f21a",
    mandateRef: mandate.id,     // cap enforced before the call executes
    // no `rail` field — the router picks Pix, boleto, card, or USDC
  },
});

console.log(payment.result);
// → { receiptId: "rcpt_9f2c1a4e", rail: "pix", status: "settled" }
✓ rcpt_9f2c1a4e · settled via pix

codespar_pay é a mesma chamada não importa o que liquida por baixo — Asaas ou Celcoin pro Pix hoje, outro provedor amanhã, sem o código do seu agente mudar.

O que essa cadeia de chamadas faz

  • O mandato é checado antes da chamada executar — gastar além do teto simplesmente não acontece
  • Sem campo de provedor — pra Pix, cartão e USDC só o router escolhe quem liquida
  • Um único recibo volta, não importa qual rail moveu o dinheiro de fato
Cobertura

Onde cada trilho realmente está.

Uma regra pra esta lista: o que o código faz hoje, e até onde cada trilho foi provado. Pagamentos Pix são roteados para os provedores de saída desta superfície, Asaas e Celcoin, e o failover fica dentro do trilho. A linha de Pix do Mercado Pago cria uma cobrança de entrada, então o router a recusa no pay. Boleto não passa pelo router: o codespar_pay liquida um boleto existente num caminho próprio de consulta e confirmação, exercitado ponta a ponta contra o sandbox do provedor. Cartão e USDC via x402 estão citados na mesma chamada governada. Cada linha diz o que o código faz com aquele trilho; quando um trilho só rodou contra o sandbox do provedor, a linha diz sandbox.

Pix · Asaas
Transferência de saída, roteada pelo pay
Pix · Mercado Pago
Cobrança de entrada, não roteada pelo pay
Pix · Celcoin
Provado em sandbox
Boleto
Caminho de liquidação, provado em sandbox
DDA
O provedor não autorizou DDA nas nossas credenciais
Cartão
Citado na chamada
USDC · x402
Base mainnet com opt-in do operador, Base Sepolia caso contrário
Mesma chamada, dois trilhos

Uma chamada codespar_pay, dois destinos diferentes. O router lê o mandato e escolhe o trilho — a chamada que seu agente escreve não muda.

pay() · fornecedor doméstico
Checagem de mandatoAssinadoOK
RouterPixSelecionado
LiquidaçãoR$3,200.00Asaas
Reciborcpt_7a41c9b0Selado
pay() · payout cross-border
Checagem de mandatoAssinadoOK
RouterUSDCSelecionado
Liquidação$1,240.00 USDCx402
Reciborcpt_4b7f9d21Selado
Status dos trilhos
Ao vivo hoje
  • Pix é roteado para um provedor de saída, Asaas ou Celcoin, escolhido pelo router
  • Boleto liquida num caminho próprio de consulta e confirmação, dentro da mesma chamada governada
  • Toda chamada é conferida contra o mandato antes de executar
  • Todo pagamento liquidado retorna um recibo selado e auditável
  • A cobrança já está ativa pras primeiras organizações, na taxa publicada
Em rollout
  • Pix via Celcoin saindo do sandbox pra liquidação em produção
  • Cartão e USDC/x402 confirmados ao vivo em produção pra toda conta
  • Cobrança ligada pra toda organização, não só o grupo do rollout
Preço

10 bps, piso R$0,05, teto R$2,00 por transação.

Essa é a taxa publicada pra dinheiro movido sob mandato. A cobrança está sendo ligada org por org, ainda não é cobrada universalmente — sua página de billing no dashboard mostra se está ativa na sua conta.

10bps
Taxa
Sobre dinheiro movido sob mandato
R$0.05
Piso
Cobrança mínima por transação
R$2.00
Teto
Cobrança máxima por transação
5
Trilhos citados
Citados numa única chamada governada

Ao vivoPagamentos Pix são roteados para os provedores de saída desta superfície, Asaas e Celcoin.

FAQ

Pay, respondido

Ele não escolhe. O agente chama pay uma vez; o runtime escolhe o trilho com base no mandato e no que está disponível, e sela o recibo.

Não via Mercado Pago: a linha de Pix dele cria uma cobrança de entrada, então o router não a usa no pay. O codespar_pay roteia Pix para um provedor de saída, Asaas ou Celcoin, e a Celcoin está provada em sandbox, ainda não liquidando tráfego de produção.

Pix, boleto, cartão e USDC via x402 estão citados na mesma chamada governada. Até onde cada um foi provado varia por trilho, e a seção de cobertura desta página diz qual é qual.

O mandato — conferido antes da chamada executar, não depois.

A taxa publicada é 10 bps, piso R$0,05, teto R$2,00 por transação. A cobrança está sendo ligada conta por conta.

Não. Agentes nunca nomeiam um provedor — quem faz isso é o router, e toda decisão é auditada.

A chamada falha fechada. Nada liquida fora do mandato, e a falha fica registrada no recibo do mesmo jeito que um sucesso ficaria.

Não. A CodeSpar segura as conexões com os trilhos; seu agente só chama pay.

Pague qualquer coisa com uma chamada governada.

O mandato decide o que é permitido; o router decide como.

pay: Pagamentos Pix são roteados para os provedores de saída desta superfície, Asaas e Celcoin.

Pay — uma chamada governada que paga qualquer coisa | CodeSpar | CodeSpar