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 for a specific signed agreement — bounded by amount, parties, allowed operations, evidence rules, and the settlement rail you chose.
Short version
Create a signed intent → fund it on an approved rail → read the capability_token → authorize tool spend → submit completion evidence → Harbor releases or refunds based on the predicate.
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).x402_usdc_base— Coinbase payment-session authorization succeeds on Base after the/fundhandshake.
Only then does Harbor mint the capability_token. There is no separate “issue capability” API — the token always comes from the intent lifecycle.
Funding vs completion evidence
Stripe payment_intent.succeeded, Coinbase authorization_succeeded, and x402 payment-session payloads are funding signals. Harbor consumes them internally. Tool-completion evidence (API responses, vendor webhooks, signed receipts) is a separate layer submitted after you hold a capability token. See Completion presets.
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 + 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 Enterprise), 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 — predicates evaluate 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.