Payments for AI agents: gasless USDC on Base + JIT single-use virtual cards, PAN never in context.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
We haven't yet run this listing's install command through our automated sandbox check. This isn't a red flag β we're steadily working through the catalog.
π‘ Paste into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
Inspect callable tools, capabilities, and parameters exposed to AI agents by Z Zero Mcp.
list_cardsList all virtual card aliases and balances
check_balanceCheck spendable USD balance for a card alias
get_deposit_addressesGet your Base deposit address to top up with USDC (stablecoin on Base)
set_api_keyActivate a new Passport Key instantly, no restart needed
show_api_key_statusCheck if a Passport Key is currently loaded (prefix only)
request_payment_tokenIssue a JIT single-use virtual-card token for a specific amount (1hr TTL). Pass `cart`, `criteria`, and `ship_to` to create the signed issuance record
AI Agents today can plan, reason, and code β but they are financially blind. They cannot hold money, make payments, or prove their trustworthiness. Every purchase still requires a human to copy-paste a credit card number.
Z-ZERO fixes that. One MCP server gives your agent (Claude, Cursor, any MCP-compatible client) two payment rails β gasless USDC on Base for crypto-native checkouts, and JIT single-use virtual cards for the 99% of the web that only takes cards β while the model never sees a real card number.
What makes it different:
get_merchant_hints serves platform-specific checkout playbooks (Shopify, Etsy, WooCommerceβ¦).execute_payment hands those criteria back and requires a second call with go or pause; a confirmed purchase seals the answer into the signed receipt. The record is inspectable without pretending the platform judged whether the agent told the truth.failure_class (automatically, not only when an agent remembers to report) and stored as evidence for the merchant knowledge base. Facts are promoted into shared hints only after a later outcome or review verifies them.0xdfd1f2f8β¦5d7aThe AI agent never touches card data β it only handles single-use tokens. Real card details are injected by Playwright at the last step and wiped from RAM.
Crypto checkout branch: when
auto_pay_checkoutdetects a crypto-native checkout (EIP-681), it skips the card flow entirely and settles as a gasless USDC transfer on Base β see above.
Z-ZERO is not a checkout bot β it's payment infrastructure for the agentic-commerce era (agentic transactions are projected to reach $1.5T by 2030 β Juniper Research).
Today, the web is built for humans: agents must fill forms and click buttons, and every purchase still needs a human's card. Z-ZERO solves that now β JIT single-use virtual cards + gasless USDC on Base, with card data isolated from the model. Tomorrow, agent payments become a standardized protocol β and what we build along the way is the long-term value:
π Full vision & architecture: The Z-Zero Whitebook
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
Get your Passport Key at: z-zero.xyz/dashboard/agents
The key you copy from the dashboard (or paste into a chat) is only a one-time bootstrap ticket. The moment your agent connects with it, the MCP server silently swaps it for a fresh key:
~/.z-zero/credentials (mode 0600). It never appears in any LLM conversation, tool result, or config file.~/.z-zero/credentials first; the Z_ZERO_API_KEY env var is only a bootstrap fallback.One key = one machine. All agents on the same machine (Claude Desktop, Claude Code, Cursor, β¦) share the same MCP install and the same credentials file β install once, every agent can pay. Connecting a different machine with a copied key rotates it, which instantly disconnects the original machine. That is deliberate: it blocks key sharing and doubles as an intrusion alarm β if your agent suddenly fails auth, someone else used your key; go to the dashboard and revoke.
Older self-hosted backends without the rotate endpoint keep working β the pasted key simply stays active as before.
zk_live_, get it from the dashboard above| Tool | Description |
|---|---|
list_cards | List all virtual card aliases and balances |
check_balance | Check spendable USD balance for a card alias |
get_deposit_addresses | Get your Base deposit address to top up with USDC (stablecoin on Base) |
set_api_key | Activate a new Passport Key instantly, no restart needed |
show_api_key_status | Check if a Passport Key is currently loaded (prefix only) |
| Tool | Description |
|---|---|
request_payment_token | Issue a JIT single-use virtual-card token for a specific amount (1hr TTL). Pass cart, criteria, and ship_to to create the signed issuance record |
execute_payment | Two calls required: first without recheck returns the locked criteria and charges nothing; second supplies recheck: { page_shows, decision: go|pause }. pause does not fill the card; confirmed go returns a signed receipt |
cancel_payment_token | Cancel an unused token and refund to wallet |
request_human_approval | Pause and request human confirmation before proceeding |
| Tool | Description |
|---|---|
auto_pay_checkout | Fully autonomous checkout β auto-detects Web3 or Fiat and completes payment |
get_merchant_hints | Fetch platform-specific checkout playbook (pre-steps + selectors) from Knowledge Base |
report_checkout_fail | Report a failed checkout with a structured failure_class (14-class enum) β feeds the self-healing loop |
verify_receipt | Verify a signed receipt by id β prove a purchase happened instead of claiming it |
π Note: Version checking is handled automatically in each API call. No separate tool needed.
Four linked records and controls an agent can use here that it cannot get from a normal virtual card alone.
Pass the cart when you request a token:
Z-ZERO signs that statement (EIP-191) during issuance. It is a tamper-evident record of the criteria the agent supplied as the owner's instruction β not an independent proof that the human personally approved every line. The shipping address is stored as a hash, never raw.
Before you request a token, compare the checkout page with what the user actually asked for β same items, same quantity, same variant, same destination. A mismatch you catch there costs nothing. After the token, it costs a card.
go or pauseexecute_payment is deliberately a two-call tool:
Use decision: "pause" when anything differs. The card is not filled and the
token remains active and refundable. On go, the checkout runs; if the merchant
confirms the order, the declaration is sealed into the signed receipt with the
outcome. The platform records what the agent declared; it does not independently
inspect the page or certify that the declaration was true.
On a confirmed payment you get back:
diff is the part that matters: it is what the merchant actually did versus what
was authorized. Share verify_url with the user β the page is public and anyone
can check it. Verification is three checks: the signature is valid, the signer is
Z-ZERO, and the fields shown still hash to what was signed (so editing the record
afterwards is detectable, including by us).
What a valid receipt does and does not prove. It proves the record is signed by
Z-ZERO and unaltered. It does not by itself prove the merchant charged what the
receipt says β most fields start life as the agent's reading of a web page. Every
receipt therefore carries provenance per field: zzero_issued (the limit we set),
issuer_captured (confirmed by the card issuer's capture webhook β settlement
evidence), agent_reported (unverified), human_verified. Until the capture webhook
lands, this is a signed execution receipt, not settlement proof, and it says so.
report_checkout_fail takes a fixed enum, not free text:
card_declined_issuer Β· card_declined_bin_block Β· avs_mismatch Β· 3ds_required Β·
bot_detected Β· form_changed Β· price_changed Β· out_of_stock Β·
shipping_unsupported Β· login_required Β· timeout Β· outcome_unconfirmed Β·
intent_mismatch Β· unknown
Failed runs are also labeled automatically from the browser outcome, so the network learns even when nobody remembers to report. Card numbers are redacted at capture β they never reach a log, screenshot or DOM dump.
The Z-ZERO backend is hosted at https://z-zero.xyz. All endpoints require a Bearer token using your Passport Key.
β οΈ Use the MCP tools above instead of calling REST directly. If you must call REST, use the exact paths below.
GET /api/tokens/cardsReturns your card list, balance, and deposit addresses.
Aliases (also work):
GET /api/v1/cards β for agents that guess REST-style pathsPOST /api/tokens/issueIssue a JIT payment token.
POST /api/tokens/resolveResolve a token to card data (server-side only).
POST /api/tokens/burnBurn a used token.
POST /api/tokens/cancelCancel an unused token (refunds balance).
zk_live_)Z_ZERO_API_KEYzk_live_c0g3l)/api/v1/cards/api/tokens/cards directly.Security: the key you paste is never kept β it rotates the moment your agent first connects, and the fresh key lives only in a local owner-only file (~/.z-zero/credentials, mode 0600), never in any LLM conversation. Card data exists only in volatile RAM during execution.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/z-zero-mcp)<a href="https://allmcps.com/mcp/z-zero-mcp"><img src="https://allmcps.com/api/badge/z-zero-mcp?style=directory" alt="Z Zero Mcp on AllMCPs" /></a>