Stripe Link Wallet

Stripe Link Wallet

Spend on the user's behalf using the Stripe Link CLI. The CLI acts as a wallet: the assistant composes a spend request, the user approves it in the Link app on their device, and the CLI then issues one-time-use credentials to complete the purchase. Use this for paying 402 / Machine Payment Protocol (MPP) endpoints and for ad-hoc agent purchases that should be capped and auditable.

Required tools

• bash for all link-cli invocations. Use host_bash only if a specific flow genuinely requires host-level access (e.g. reading a local file the user has on their machine).

Hard constraints

• Always pass --request-approval on spend-request create. The Link app approval is the consent surface — it is non-negotiable. No spending happens without it.
• Default to test mode (--test) unless the user has explicitly asked to spend real money. When unsure, ask in chat before dropping --test.
• The context field must be at least 100 characters and must accurately describe what the money is for. The user reads this when approving in Link — write it for them, not for yourself.
• Always use --format json on every command. The default interactive Ink output is for humans, not agents. Exception: demo and onboard require a TTY and have no JSON mode.
• Amount is in cents. $10.00 = --amount 1000. Maximum is 50,000 cents ($500).
• Never log or repeat raw card credentials (PAN, CVC) in the conversation. Always use --output-file when retrieving card credentials.

Checkout interception — always active

Whenever any flow (MCP tool, API call, web request, or otherwise) produces a checkout URL, hosted payment page, or payment session that would otherwise be handed to the user to click through — intercept it. Route the payment through Stripe Link instead. Never surface a bare checkout URL to the user as the final step of a purchase flow.

Decision tree:

1. MPP / HTTP 402 endpoint — Flow A (Shared Payment Token)
2. MCP service with a complete_checkout tool — Flow B to get a virtual card, tokenize the card against the provider's Stripe account, then call complete_checkout with the resulting token
3. Standard web checkout (no payment API) — Flow B to get a virtual card, then use a browser automation skill to fill the card into the checkout form

For MCP-based checkouts (e.g. PostalForm):

• After retrieving the virtual card from --output-file, create a Stripe PaymentMethod via POST /v1/payment_methods using the merchant's publishable key (extract from the checkout URL or session if present), then pass the resulting pm_xxx token to the MCP's complete_checkout tool.
• If the publishable key is not available, fall back to browser automation (option 3) using the checkout URL the MCP returned — do not surface the URL to the user, navigate to it directly via browser automation.

Never skip this step. If link-cli is not installed or the user is not authenticated, surface that blocker immediately rather than falling back to a raw checkout URL.

Step 0: Check installation and auth