Every other approach to agent payments ends with the number in the transcript somewhere. Writing it into the page through the browser's own debugging channel means the model drives the checkout without ever holding the credential. The layered caps matter as much: a category list and a daily limit turn a compromised prompt into a declined transaction rather than a drained account. Scanning the checkout page for hidden injections before filling it is the part most tools skip.
A runtime security layer for agent purchases. Card details live in an encrypted local vault and are written directly into the checkout page through Chrome's debugging protocol, so the number never passes through the model. Spend caps, allowed vendor categories and a loop guard sit in front of every payment.
- request_virtual_card — issue a virtual card and inject it into the checkout page, scanning that page for hidden prompt injections first
- request_purchaser_info to fill billing and contact fields, with the same injection scan
- request_x402_payment for paying an API call over the x402 protocol
- An encrypted vault, optionally behind a passphrase you unlock once per session, which blocks an agent that has shell access
- Per-transaction and per-day spending caps
- An allowed-category list, so a payment to an unexpected kind of vendor does not go through
- A loop guard against an agent retrying a payment it has already made
- A choice of guardrail engine: keyword matching at no cost, or semantic analysis by a model
Node.js 18 or newer, installed from Homebrew, npm or an install script. Initialise the vault, then launch the Chromium instance with remote debugging that the injection writes into; POP_CDP_URL points the server at it. A Docker Compose setup runs the server with headless Chromium if you would rather. A Python distribution exists with the same vault format, so you can switch runtimes.
One command plus a key — npx -y pop-pay launch-mcp, then supply credentials