Agentic Payments

Agentic Payments lets a customer describe a payment in plain language — “pay Alice 10 USDC on base-sepolia every month until December” — and have a hosted payment agent turn it into a reviewable, signable payment plan. The agent drafts; the customer authorizes; the platform executes on schedule.

Alpha — the agentic surface is in early access. Endpoints marked Alpha in the API reference follow the same stability and breaking-change policy as the rest of the API.

The trust model

The defining property of the system is that the agent has no spending authority of its own:

The agent only drafts. A conversation produces proposals — a structured series of actions (create a payee, create a mandate, schedule payments). Nothing is created until your application submits them as instructions.
Nothing fires without a customer-signed mandate. A mandate is a signed spending authorization with hard caps. It is approved by a second recognized signer — never by the agent itself (dual control).
Every payment is re-checked at fire time. When a scheduled payment comes due, the mandate gate re-evaluates the payment against the mandate’s caps at that moment. A revoked agent, an expired mandate, or an exhausted cap means the payment fails safely — it never falls through to a send.

Objects

Object	What it is	Lifecycle
Payment agent	A hosted agent with its own signer key. It can converse and draft, and its signer is what scheduled payments fire under.	`active` → `revoked`
Proposal	A drafted action series returned by the conversation endpoint, with a human-readable summary. Exists only in the API response — nothing is persisted until accepted.	ephemeral
Instruction	An accepted proposal. Actuating it creates the real objects (recipients, mandates, scheduled payments, auto accounts) transactionally — a mid-actuation failure rolls the instruction’s objects back.	`accepted` / `failed`
Mandate	A single-rule spending authorization bound to one signer — the agent’s in this flow, or any signer via the direct create: asset, optional network, per-transaction cap, and per-target caps over a calendar window (`NONE` / `WEEKLY` / `MONTHLY`). Immutable once created — extend authority by creating an additional mandate.	`pending` → `active` → `revoked` / `done` (or `rejected` while pending)
Scheduled payment	One future payment: amount, asset, destination, fire date. Fired by the platform when due, under whatever active mandate covers it at that moment.	`scheduled` → `executed` / `cancelled` / `failed`

The flow at a glance

Drafting through conversation is optional — an application that already knows what it wants can POST /instructions with a hand-built action series, or use the direct POST /mandates and POST /scheduled-payments endpoints, and only the signing step remains.

What the agent can and cannot do


✅ Draft payment plans from text or an attached invoice (PDF/image)	❌ Move money on its own
✅ Answer questions about the account (Account Insights)	❌ Approve its own mandates (the bound signer can never sign §8 actions)
✅ Fire customer-approved payments on schedule	❌ Exceed a mandate cap — the gate denies at fire time
✅ Reuse one mandate across a whole recurring series	❌ Outlive revocation — revoking the agent fails its future fires

Where to go next

Quickstart — agent → wallet access → draft → sign → first payment, end to end
Examples — one-off, recurring, standing authorization, cross-chain, bank offramp
Mandate signing — the canonical payload and the dual-control rules
Webhooks — scheduled_payment.failed and the success path
Account Insights — the deterministic report + advisory chat
Limits — caps, windows, and the support matrix

Playground

Documentation