bitroadbitroad
Using the marketplace

Agent payments & spend caps

Payment envelopes, per-tx/daily/total caps, settlement, refunds back to source.

Buyers & agent developers

Agent-friendly payments let a Principal delegate spending authority to an AI agent: the agent purchases off-session, within a Principal-set spending envelope, without waking the human for every checkout. It sits behind a two-gate feature flag — the AGENT_ENVELOPES_ENABLED=true env var (kill switch) plus the principals.envelopes_enabled per-principal allowlist. The mandate text requires counsel review before the flag is enabled in production.

Companion doc: delegation.md — delegation scope mechanics.

Approach

The envelope lives in Bitroad's database, layered on Stripe's off-session payment machinery (a SetupIntent plus merchant-initiated transactions), not on Stripe's preview agentic primitives. The off-session/MIT path is generally available, UK-supported, and well understood by issuers. Bitroad is the merchant of record; the agent exists at the application layer, invisible to the card scheme.

Flow

  1. Setup — one-time, on-session, full SCA. The Principal completes a SetupIntent (usage = off_session) authenticating their card and accepting the mandate. The mandate describes the marketplace relationship and the spending arrangement: Bitroad may charge the card up to the Principal's cap for purchases the agent makes within policy.
  2. Authorization — server-side. Bitroad stores an Envelope row keyed to the payment_method and the policy (cap, expiry, allowed seller categories, per-transaction max). Every agent-initiated checkout decrements the envelope server-side before charging.
  3. Capture — off-session, MIT. Each agent-initiated purchase is a fresh PaymentIntent with off_session = true, confirm = true, the saved payment_method, and the mandate id, submitted as a merchant-initiated transaction. If the issuer challenges, a 3DS step-up is surfaced to the Principal asynchronously.
  4. Audit trail. Every charge logs (envelope_id, agent_id, principal_id, mandate_id, intent_chain), recording the principal/agent/mandate triple required on every agent-initiated charge.

Requirements

  • Mandate text approved by counsel before launch, covering variable-merchant MIT against a stored credential with a stated cap and expiry. The off-session charges have no clean legal basis without it.
  • Issuer-decline fallback. Variable-merchant MIT charges can be soft-declined with a 3DS challenge, so a fallback to per-transaction on-session SCA — a step-up the agent hands back to the Principal — must exist.
  • Spending caps. A per-transaction and per-period cap below which agent charges fire without intervention, and above which the agent must request fresh on-session confirmation. This is the core policy primitive.
  • Keys stay server-side. The agent calls Bitroad's internal API; Bitroad's backend holds the only Stripe keys — no card tokens in the browser, and every charge carries an explicit agent identity.