z-zero-payments

Z-Zero Payments

Give this agent the ability to buy things — SaaS subscriptions, API credits, physical goods — without ever seeing a card number.

Z-Zero is a payment MCP server with two rails behind one interface:

• Gasless USDC on Base for crypto-native checkouts (sponsored by Coinbase Paymaster — the wallet holds only USDC, no ETH, no gas UX).
• JIT single-use virtual cards for the 99% of the web that only takes cards: issued with one amount cap and a 1-hour token TTL, then burned after a confirmed use.

The security model (read this first)

This skill is deliberately boring about money. Four boundaries matter:

1. The model never sees card data. No PAN, no CVV, no expiry ever enters your context. You only ever handle single-use tokens; the real card details are injected into the merchant's checkout form by a local Playwright process and wiped from RAM. If you ever think you need a card number, you are off the rails — stop.
2. Human approval is a required workflow, not yet a server-side gate. Before any payment executes, call request_human_approval with the exact final total and wait for confirmation. The current tool returns an approval prompt for the agent to follow; independent out-of-band enforcement is roadmap, so never describe approval as cryptographically enforced today.
3. Blast radius is capped per card. The issuer enforces the per-card amount cap and single use. The merchant named at issuance is compared in the receipt, but a different merchant is not currently declined at authorization; do not call that an issuer-enforced merchant lock.
4. Keys rotate on connect (v1.5.0+). Any Passport Key that was pasted into a conversation is treated as burned: on first connect the server swaps it for a fresh key stored only in ~/.z-zero/credentials (0600) — the live key never exists in any LLM context. One key = one machine; all agents on the machine share it, and a connect from a different machine disconnects this one (built-in intrusion alarm).