request_virtual_cardLABSCO SUMMARY
The card is never in the context window.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
Follow the published steps — Save your card into the encrypted local vault (one-time): npx -y pop-pay init-vault
USE CASES
Letting an agent buy something without handing it your card
Have the virtual card injected into the page directly, with the page checked for hidden instructions first.
Getting through the billing form too
Fill name, address, email and phone from the vault rather than pasting them into the conversation.
Paying for an API call mid-task
Settle it over the x402 protocol instead of failing the run.
Capping what a mistake can cost
Set the per-transaction and daily limits, and restrict which vendor categories are allowed.
Stopping a retry loop from paying twice
Leave the loop guard on so a repeated attempt is refused rather than charged.
Keeping the vault safe from an agent with a shell
Protect it with a passphrase and unlock it once per session.
3 tools
Listed in project docs. Your client may show a different list.
request_purchaser_inforequest_x402_paymentBEFORE YOU INSTALL
What to know first
Tools you get
3 tools named in the project's documentation.
Requires
- npx on PATH
- Node.js 18+
- A payment card of your own, saved into the local encrypted vault
Where it runs
All 4 documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
Save your card into the encrypted local vault (one-time):
npx -y pop-pay init-vaultLaunch the Chromium that pop-pay writes the card into — it opens with remote debugging on http://localhost:9222: npx -y pop-pay launch
Add pop-pay to your client with one of the tabs below; the client starts it with npx -y pop-pay launch-mcp
MCP Clients
Claude Code
claude mcp add --scope user pop-pay -- npx -y pop-pay launch-mcpCursor, Windsurf
{
"mcpServers": {
"pop-pay": {
"command": "npx",
"args": [
"-y",
"pop-pay",
"launch-mcp"
],
"env": {
"POP_CDP_URL": "http://localhost:9222"
}
}
}
}VS Code
{
"servers": {
"pop-pay": {
"command": "npx",
"args": [
"-y",
"pop-pay",
"launch-mcp"
],
"env": {
"POP_CDP_URL": "http://localhost:9222"
}
}
}
}