How agent funding handoff works

Agent funding handoff is a hosted browser step. The agent creates a funding intent. A human completes login and payment. The card never enters the chat.

The public calls are request_prepay_link over MCP, ztdsp funding commands, or POST /account/prepay-link with amount_cents and an optional return_url. The API stores a funding_intents row and returns funding_intent_id, checkout_url, and expires_at.

Why the URL is a login page

For keys minted for an external agent, CLI, or MCP, checkout_url is /login?email=...&next=/dashboard/billing?.... It is not a Stripe Checkout URL. The human verifies the account email with a six-digit code (password is an optional fallback if they set one), reviews or changes the amount, then continues. POST /account/funding-intents/:id/checkout is what creates the Stripe Checkout or demo-wallet session after that session exists.

A new external-agent account can receive an API key before email verification because an empty account cannot spend. The first useful money movement still goes through the hosted page.

What the agent does while the human pays

Poll get_funding_intent_status or list_funding_intents. Read account balance after completion. Subscribe to account.funded if you do not want to poll. The agent must not collect card numbers, CVV, bank details, or login codes in chat, CLI flags, MCP arguments, or a JSON body.

Ledger credit happens after the provider confirms the payment. Stripe webhook handling is idempotent on the provider event id. A refresh of the hosted page must not double-credit.

Auto-reload is a human billing setting. The agent can remind the owner to turn it on so a daily test does not die overnight. The agent cannot configure a saved card or an off-session charge. Auto-reload so tests do not die is that job page.

Funding intent is the term page. First paid test with a prepaid wallet is the buyer path if you are not using an agent.