One governed call.Any rail.
Your agent calls pay once. The runtime checks the mandate, picks the rail — USDC over x402, Pix in Brazil — and seals the receipt. The agent never names a provider; the router does.
Field names and sequence are real — mandate check, then routing, then settlement, then a sealed receipt. The settlement row names an outbound Pix provider: Mercado Pago's Pix line creates an inbound charge, so the router does not use it for pay.
Paying a supplier shouldn't take three integrations.
Route money to a supplier, a contractor, or a payout across the border today, and you're wiring up a Pix PSP, a card processor, and a stablecoin wallet — three SDKs, three retry policies, three reconciliation reports to match up by hand. Pay collapses all of that into one call.
The mandate decides what's allowed. The router decides how.
One call, checked against the signed mandate before anything moves, then routed to whichever rail fits: USDC settling over x402, Pix for BRL. USDC/x402 is one slot of the same wallet; the Pix lane runs on the same runtime, not a separate integration.
The call, step by stepThe call your agent actually makes.
Your agent calls pay once — amount, destination, and the mandate reference. There's no provider parameter to set. The runtime checks the call against the signed mandate first, because the cap has to hold before money moves, not after — then it resolves the call to whichever provider fits.
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" }
codespar_pay is the same call regardless of what settles underneath it — Asaas or Celcoin for Pix today, another provider tomorrow, without your agent's code changing.
What this call chain does
- The mandate is checked before the call executes — spend past the cap simply doesn't happen
- No provider field — for Pix, card and USDC the router alone picks who settles it
- One receipt comes back regardless of which rail actually moved the money
Where each rail actually stands.
One rule for this list: what the code does today, and how far each rail has been proven. Pix payouts route to the outbound providers on this surface, Asaas and Celcoin, and failover stays inside the rail. Mercado Pago's Pix line creates an inbound charge, so the router refuses it for pay. Boleto skips the router: codespar_pay settles an existing boleto on its own consult-then-confirm path, exercised end to end against the provider's sandbox. Card and USDC over x402 are named in the same governed call. Each row says what the code does with that rail; where a rail has only run against a provider's sandbox, the row says sandbox.
One codespar_pay call, two different destinations. The router reads the mandate and picks the rail — the call your agent writes doesn't change.
- Pix routes to an outbound provider, Asaas or Celcoin, chosen by the router
- Boleto settles on its own consult-then-confirm path, inside the same governed call
- Every call is checked against the mandate before it executes
- Every settled payment returns a sealed, auditable receipt
- Billing is active for early organizations at the published rate
- Pix via Celcoin moving from sandbox to production settlement
- Card and USDC/x402 confirmed production-live for every account
- Billing turned on for every organization, not just the rollout cohort
10 bps, floor R$0.05, cap R$2.00 per transaction.
That's the published rate for money moved under mandate. Billing is rolling out org by org, not universally charged yet — your dashboard billing page shows whether it's active on your account.
LivePix payouts route to the outbound providers on this surface, Asaas and Celcoin.
Pay, answered
It doesn't. The agent calls pay once; the runtime picks the rail based on the mandate and what's available, then seals the receipt.
Not through Mercado Pago: its Pix line creates an inbound charge, so the router does not use it for pay. codespar_pay routes Pix to an outbound provider, Asaas or Celcoin, and Celcoin is proven in sandbox, not yet settling production traffic.
Pix, boleto, card and USDC over x402 are named in the same governed call. How far each one has been proven differs by rail, and the coverage section on this page says which is which.
The mandate — checked before the call executes, not after.
The published rate is 10 bps, floor R$0.05, cap R$2.00 per transaction. Billing is rolling out account by account.
No. Agents never name a provider — the router does, and every decision is audited.
The call fails closed. Nothing settles outside the mandate, and the failure is recorded on the receipt the same way a success would be.
No. CodeSpar holds the rail connections; your agent only ever calls pay.
Five business cases, one governed call.
Each one below is a real use case built on this product, not a hypothetical — the same mandate-and-rail flow, applied to its own scenario.
Accounts payable agent
Pays Pix and boleto on each invoice's due date, inside the operations mandate.
See the use case →Cross-border payout orchestrator
Routes the payout to the cheapest rail per destination — Pix, SPEI, or USDC — every transfer mandate-signed.
See the use case →Contractor payroll agent
Runs the monthly contractor payout over Pix inside a capped mandate, one sealed receipt per payee.
See the use case →Support refund agent
Refunds the customer on the original rail the moment the ticket clears, inside the agent's spend limit.
See the use case →Machine spend (x402)
Settles the x402 quote in USDC from the wallet slot, inside the per-call cap, receipt sealed to the mandate.
See the use case →Pay anything with one governed call.
The mandate decides what's allowed; the router decides how.
pay: Pix payouts route to the outbound providers on this surface, Asaas and Celcoin.