One link.Agent or human, either pays it.
One link any agent can pay in USDC, and any Brazilian can pay in Pix. You fulfill only after it's verified — no card acquirer, no checkout to build.
Illustrative example. Either rail settles the same link — nothing to configure on your side.
At a glance
Stop running two payment stacks for one sale.
Getting paid by both agents and humans today usually means building two payment stacks end to end — a checkout page for people, a separate API for agent and USDC rails. Collect collapses both into one link.
- A checkout page for human buyers, wired for card or Pix
- A separate API integration for agent and USDC payments
- Two verification paths, easy to let drift out of sync
- Two fulfillment triggers and two reconciliation trails
- One link, one payment object — agent or human pays it
- One rail-agnostic API, no branching on your side
- One verification step before anything ships
- One fulfillment trigger, one reconciliation trail
Same link, two ways to pay it.
An agent hits the link and pays in USDC. A person opens the same link and pays with Pix. Either way, you don't fulfill until the payment is verified and the receipt is sealed.
agent → link → USDC
human → same link → Pix
Same URL, same verification step, same seal — the only thing that changes is which rail the payer is on.
One codespar_charge call, either rail settles it.
Collect is a single meta-tool call. You create one charge object with both rails accepted — the SDK hands back a link, and whichever side pays first is the one that settles it.
const session = await codespar.sessions.create(); // one charge accepts either rail — the link works for // both a human buyer and an agent, no branching on your end const charge = await session.execute("codespar_charge", { amount: 9640, // minor units (R$96.40) currency: "BRL", accept: ["pix", "usdc"], description: "Order #4821", }); console.log(charge.link); // → "gw.codespar.dev/pay/you/4821" // poll until either side settles it — same call regardless of rail const status = await session.verificationStatus(charge.toolCallId); // → { status: "verified", rail: "pix", receipt: "rcpt_9kLmQx" }
What this call chain does
- One charge object accepts either rail — nothing to branch on in your code
- The same link settles whether an agent pays in USDC or a person pays in Pix
- One poll on verificationStatus tells you which rail actually cleared it
- A single receipt either way, sealed the moment it settles
One link, watched from both sides.
Whichever side pays, you see the same shape: a link, a payment, a verified receipt.
Illustrative example, not a real transaction. What's real: you never fulfill until the payment on either side is verified and sealed.
Live rails
A link today. A full merchant stack next.
Collect is one payment link right now. The registry vision is bigger — here's the honest line between what works today and what's still ahead.
- One payment link, created in minutes
- Agents pay it in USDC
- People pay the same link in Pix
- Payment verified and receipt sealed before you fulfill
- Dedicated Pix QR / copia e cola flow
- Boleto
- A hosted checkout page
- Per-seller split and payout
- Card
Free until general availability.
R$0 while Collect is in early access. Pricing is locked to the published rate card once it reaches GA — no surprise increase later.
Early accessEarly access.
The same charge, already live in two builds.
Collect's Pix-charge mechanism isn't only a standalone link — these use cases run the same primitive in-context. See it inside a real flow.
WhatsApp commerce bot
Generates the inline Pix QR the bot charges against mid-conversation — the same Pix-charge mechanism Collect exposes as a link, used in-chat instead of sent as a URL.
See the use case →Auto top-up
Mints the dynamic Pix charge that refills the BRL float when it runs low — the same Pix-charge mechanism Collect exposes as a link, triggered automatically instead of sent as a URL.
See the use case →Collect, answered
Anyone. An agent pays in USDC; a person pays the same link with Pix.
No — Pix and USDC settle today without one, and CodeSpar carries that relationship for you. Card is on the roadmap the same way, so you'll never need your own acquirer stack.
R$0, while it's in early access. Once it reaches general availability, pricing follows the published rate card.
Not yet. Today Collect is a payment link; a hosted checkout page is on the roadmap, not built.
Not yet. Per-seller split and payout is on the roadmap alongside boleto, card, and a dedicated Pix QR / copia e cola flow.
It's verified and the receipt is sealed before you ship anything — you're never fulfilling on an unconfirmed payment.
Not yet — it's on the roadmap alongside card, the dedicated Pix QR flow, hosted checkout, and split payout.
In your CodeSpar wallet — USDC and BRL held in separate slots. You don't need a separate crypto wallet to receive the agent-side payments.
Nothing ships. The link stays open and the charge sits unverified — you only fulfill once it's confirmed and the receipt is sealed.
One link. Either side can pay it.
No card acquirer, no checkout to build — an agent pays USDC, a person pays Pix.
collect: Early access.