DEV Community

CAI
CAI

Posted on

One CAI wallet, a dozen subscriptions: how payment mandates handle recurring agent billing

One CAI wallet, a dozen subscriptions: how payment mandates handle recurring agent billing

Your agent runs every Monday morning. It pulls data from a market research API, cross-references it against a paid news feed, queries a domain-specific LLM, and publishes a report to your cloud storage. Each service costs $5 to $50 per month. Multiply by 5 agents and you are managing 15 to 20 separate billing relationships.

This is the quiet problem behind every autonomous agent pipeline. The credit card model assumes a human sits at a checkout page once a month. But agents have no hands, no browser session, and no capacity to remember which subscription renewed. What they need is a single payment address that the developer funds once and the agent draws from, with hard limits per subscription.

CAI payment mandates are the solution. A mandate is a standing instruction: "Agent X may spend up to $Y per month on service Z, auto-billed from wallet W." The agent calls POST /x402-payment-prepare when it hits a paywall. If the service, amount, and recurring cadence are within the mandate's bounds, the call succeeds without any human in the loop. The developer sees every draw in GET /wallet-activity-list, a single view of all agent spending instead of 15 separate invoices.

How it works

The developer creates a mandate via POST /payment-mandate-create with three core parameters: the target service domain (merchant_domain), a per-payment maximum (max_amount_per_payment_usd), and a daily cap (daily_cap_usd). CAI's custodial engine maps each mandate to the developer's wallet. The agent never handles the wallet keys or sees the balance. When the agent calls POST /x402-payment-prepare with the service's recipient_address, amount, chain, token, and merchant_domain, CAI checks three things:

  1. The recipient matches an active mandate's target domain.
  2. The transaction amount is within the mandate's remaining per-payment limit.
  3. The total spend across all mandates does not exceed the wallet's daily cap (default $200, adjustable in the Dashboard).

If all three pass, the payment is approved and the mandate's running counter is decremented. No redirect, no confirmation dialog, no manual approval. Just a 200 response with an attempt_id.

What the developer sees

Every mandate draw lands in GET /wallet-activity-list with the mandate's metadata. The developer can filter by mandate to see exactly which agent spent what, on which service. If a mandate approaches its limit, the agent's next prepare call returns a signal. The developer adds funds or the agent rounds down to what the mandate still covers.

New services that were not in the original mandate set require explicit developer confirmation before the first payment. The first time an agent tries to pay a recipient that has no active mandate, the prepare call returns requires_user_confirm: true with the recipient and amount. Only after the developer confirms via POST /x402-payment-execute with user_confirmed: true does the payment go through. Subsequent payments to the same recipient within the same mandate are automatic. This is the new-recipient confirmation pattern: one explicit yes per new service, then the agent runs on its own.

The cash-in-pocket rule

Every mandate-bound payment settles from the developer's custodial wallet. There is no overdraft and no credit line. If the wallet balance on the target chain or token is insufficient, the payment fails immediately. This is intentional: agents should not accumulate debt. The developer sees the exact balance via POST /get-wallet-balances and can top up via POST /create-hosted-action with action_type: "deposit", which returns a hosted deposit URL.

The vault connection

Site credentials stored in CAI's vault are encrypted and accessible only via GET /user-site-credentials. Mandates and vault credentials are separate systems. A mandate controls spending limits while vault credentials control identity. For the recurring billing use case, the developer typically needs both: the agent uses vault credentials to authenticate to the paid service and a mandate to pay the bill.

Putting it together

The developer's setup takes about ten minutes:

  1. Fund the CAI wallet via POST /create-hosted-action with action_type: "deposit" or the fiat on-ramp.
  2. Create a mandate per service via POST /payment-mandate-create.
  3. Equip each agent with the CAI MCP server (npm i -g @cailab/mcp), the wallet API key, and the mandate parameters for each service it pays.
  4. Each agent calls POST /x402-payment-prepare before a paid request. If the mandate covers it, the payment executes automatically.

The result is one wallet, one login, one activity feed, and zero manual subscription management. Every service gets paid on time because the agent never forgets a renewal date, and the developer never enters a credit card number again.

Bug reports for this workflow should describe the mandate creation step where the issue occurs. Call GET /payment-mandate-status after creation to confirm the mandate is active. If the wallet activity feed shows a failed payment for a service that should be within budget, check the mandate's daily_cap_usd and the wallet's current balance. Every comment on this article gets read. Bug reports will be replied to within 24 hours.

Top comments (0)