Skip to main content
PayLive

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.

pay() · call trace
Mandate checkSignedOK
RouterPixSelected
SettlementR$142.50Mercado Pago
Receiptrcpt_9f2c1a4eSealed

Field names and sequence are real — mandate check, then routing, then settlement, then a sealed receipt. Pix through Mercado Pago is the one rail in this trace that's actually settling in production today.

The problem

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.

Integration
Wire up three separate SDKs — a Pix PSP, a card processor, a stablecoin wallet — each with its own auth and setup.
One codespar_pay call. The router already speaks to every rail.
Retries & idempotency
Every rail retries and dedupes differently — a timeout on one integration can double-pay on another.
One governed call, checked against the mandate before anything moves.
Rail selection
Your code has to decide up front which rail to call for which destination.
The agent never names a rail — the router picks it from the mandate and the destination.
Reconciliation
Reconciling spend means matching receipts across three separate dashboards by hand.
Every settled payment returns one sealed receipt, same shape no matter which rail settled it.
How it works

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 step
1Your agent calls pay() once — amount, destination, nothing else.
2The runtime checks the call against the signed mandate before anything moves.
3The router picks the rail that fits: Pix, boleto, card, or USDC over x402.
4The rail settles and a sealed receipt comes back to the agent.
In code

The call your agent actually makes.

Your agent calls pay once — amount, destination, and the mandate reference. There's no rail 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 the router resolves it to whichever provider fits.

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 is the same call regardless of what settles underneath it — Mercado Pago 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 rail field — the router alone decides Pix, boleto, DDA, card, or USDC
  • One receipt comes back regardless of which rail actually moved the money
Coverage

Where each rail actually stands.

Pix is proven in production in Brazil today, through Mercado Pago. A second Pix provider (Celcoin) is sandbox-proven, not yet settling production traffic. Boleto and DDA settle in production too. Card and USDC/x402 resources are named in the same governed call; check the dashboard for which are live on your account today.

Pix · Mercado Pago
Live in production
Pix · Celcoin
Sandbox-proven
Boleto
Live in production
DDA
Live in production
Card
Named in the call
USDC · x402
Named in the call
Same call, two rails

One codespar_pay call, two different destinations. The router reads the mandate and picks the rail — the call your agent writes doesn't change.

pay() · domestic supplier
Mandate checkSignedOK
RouterPixSelected
SettlementR$3,200.00Mercado Pago
Receiptrcpt_7a41c9b0Sealed
pay() · cross-border payout
Mandate checkSignedOK
RouterUSDCSelected
Settlement$1,240.00 USDCx402
Receiptrcpt_4b7f9d21Sealed
Rail status
Live today
  • Pix settles in production through Mercado Pago
  • Boleto and DDA settle in production, 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
Rolling out
  • 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
Pricing

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.

10bps
Take rate
On money moved under mandate
R$0.05
Floor
Minimum charge per transaction
R$2.00
Cap
Maximum charge per transaction
5
Rails routed
Named in one governed call

LiveLive — Pix already proven in production in Brazil.

FAQ

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.

Yes, through Mercado Pago. A second Pix provider is proven in sandbox but not yet settling production traffic.

Pix, boleto, and DDA settle in production today; card and USDC/x402 resources are named in the same governed call, rolling out account by account.

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.

Pay anything with one governed call.

The mandate decides what's allowed; the router decides how.

pay: Live — Pix already proven in production in Brazil.

Pay — one governed call that pays anything | CodeSpar | CodeSpar