In short: intent funding is where the spend limit for one job gets money behind it, so the agent has something real to spend against. Intent funding is how Paybond reserves budget for one commercial commitment before an agent runs a paid or side-effecting tool.
It is not the same as your Paybond workspace subscription. Platform billing pays for the product. Intent funding puts money into escrow (held until a completion rule is met) for a specific signed agreement — bounded by amount, parties, allowed operations, evidence rules, and the settlement rail you chose.
Two layers to keep separate
| Layer | What it pays for | Who configures it |
|---|---|---|
| Platform billing | Paybond workspace access, usage meters, console features | Owner at /signup and Configuration → Billing |
| Intent funding | Budget for one agent spend boundary (one intent lifecycle) | Tenant admin configures rails; your app creates and funds intents |
Confusing the two is a common integration mistake. You can have a paid workspace with settlement rails configured and still need a funded intent before paybond.spendGuard authorizes a tool call.
The funding lifecycle
From settlement config to guarded tool calls
Production funding has four steps. Sandbox skips live rails and uses simulator bootstrap instead.
0. Configure rails
1. Create intent
2. Fund
3. Authorize spend
After funding, the intent continues through evidence submission and deterministic settlement — release, refund, or dispute. See How agent settlement works for that full arc.
What “funded” means
An intent reaches funded when the underlying rail confirms funding authorization:
stripe_connect— card PaymentIntent authorized (often during create).stripe_ach_debit— bank debit confirmed after Stripe reports success (delayed).stripe_mpp— Payment Auth credential verified and charge or Tempo session deposit confirmed onPOST /intents/{id}/fund.x402_usdc_base— Coinbase payment-session authorization succeeds on Base after the/fundhandshake.
Only then does Paybond mint the capability_token. There is no separate “issue capability” API — the token always comes from the intent lifecycle.
Sandbox vs production
| Environment | Funding path | Real money? |
|---|---|---|
| Sandbox (Free Developer) | paybond.guardrails.bootstrapSandbox(...) or simulator events | No — simulated funded intents |
| Production | paybond.intents.create and paybond.intents.fund when needed | Yes — live rails after console setup |
Sandbox rehearses lifecycle and webhooks without Stripe or Coinbase credentials. Production requires a paid self-serve plan (or sales-led custom), live settlement configuration, and production API keys.
Common mistakes
- Passing settlement destinations from client code — Paybond resolves payee rails server-side from tenant configuration.
- Treating platform checkout as intent funding — subscription billing does not fund individual agent tool calls.
- Submitting funding webhooks as payee evidence — the completion rule evaluates tool-completion payloads, not PaymentIntent ids or x402 session ids.
- Calling tools before
funded— spend guard verification fails without a validcapability_token.
Deep dives in this series
For operators and tenant admins
Link Stripe Connect, mark ACH ready, register Base USDC addresses, and choose allowed rails in the console before production intents can fund.
For application developers
Create signed intents, fund per rail with Paybond Kit, read capability_token, and wire spend guard middleware before paid tools execute.