PayBox: non-custodial wallet for AI agents over MCP

PayBox: a non-custodial wallet for AI agents. You connect wallets, cards, and secrets once. The agent pays, signs, and authenticates inside limits you set — over a single MCP connector.

That connector is the whole product surface for most builders:

https://api.paybox.sh/mcp

Paste it into Claude, Grok, ChatGPT (developer connectors), or any MCP host. The user signs in with email + passkey, picks which credentials this agent may use, and chooses how strict approval should be. From then on the agent calls tools — it never receives a seed phrase, a key share, or a full card number.

PayBox is from MoonPay. Wallet keys live in MoonX MPC; signing finishes client-side. The marketing site is paybox.sh, the vault app is app.paybox.sh, and the docs live at docs.paybox.sh. There is also an llms.txt if you want agents to read the product map directly.

Click to zoom

The problem it solves

Agents that book travel, rebalance a portfolio, or hit paid APIs need real money and real credentials. The naive path is to paste a private key or card into the prompt. That is unsafe, unrevocable, and impossible to audit.

PayBox splits the job. The human vaults a credential once. The agent client gets a scoped OAuth grant. Tools return only what the agent needs to finish the task: a signature, a one-time virtual card, or a short-lived secret token. Sensitive steps can pause for a passkey. Revoking the agent does not force you to rotate the underlying wallet or card.

If you already care about x402 pay-per-call APIs, think of PayBox as the wallet side of that story — the thing that holds funds and signs, while services like Milypay or Gecko sit on the provider or tooling side.

How connection works

Official guide: Connect over MCP. The endpoint speaks streamable HTTP MCP. Under the hood, adding the URL starts OAuth 2.1 + PKCE. No long-lived API key is required for interactive agents.

Hit the URL without a token and you get a clean 401 pointing at discovery metadata:

WWW-Authenticate: Bearer realm="paybox",
  resource_metadata="https://api.paybox.sh/.well-known/oauth-protected-resource"

For scripts and backends you can still mint a personal pbx_live_* key in the app and send it as Authorization: Bearer …. Same tools, different client shape.

Getting started path in the product is short: sign in → vault a wallet, card, or secret → connect the MCP URL → approve the grant. See Getting started.

What you are actually granting

The mental model from their data model docs is worth learning before you write tool loops:

• A credential is a wallet (EVM family or Solana family), a card (vaulted via Basis Theory), or a secret.
• A client is the agent or app connecting over MCP or OAuth.
• A grant is the slice of credentials that client may use.
• An approval mode is either always_approve (passkey on every operation) or autonomous (run inside the grant without a tap each time).

EVM wallets share one address across chains. Solana is its own family. That matters when you ask the agent to check balances or sign: use the right credential, not a generic “main wallet” assumption.

The tool loop (this is the important part)

Full tool list: MCP tools reference. Almost every write returns a status envelope, not a silent success. Branch on it.

Start every session with list_credentials. That returns the credential_id values you pass into everything else, plus display metadata (last4, address, chain family) — never raw secrets. Ungranted items show up only as counts, so the agent cannot fish for wallets you did not share.

Then the agent does work:

• request_wallet_sign — messages, typed data, EVM or Solana transactions. You pass an intent; PayBox builds the bytes and the signing window completes it. Keys never leave MPC.
• request_payment — issue a merchant-scoped one-time virtual card (amount, currency, real merchant_url).
• claim_payment_credentials — after human approval, pull the usable card details once (the poll response deliberately redacts them).
• request_swap — intent-based swaps.
• get_portfolio / verify_solana_balance — balances before you spend.
• discover_services, pay_x402, use_service — find and pay x402 endpoints from the granted wallet.
• request_secret — short-lived secret access when the grant allows it.

Write tools often come back as pending_approval, pending_signature, pending_confirmation, or similar. When that happens, show the user the approval_url if present, then poll get_request with the request_id.

Do not call the write tool again to “finish” it. A second call starts a second operation. That is the number-one integration bug. Lifecycle detail: request lifecycle.

list_credentials
    → pick credential_id
request_* (pay / sign / swap / …)
    → status: success | pending_* | denied | error
if pending_* → open approval_url if needed
              → poll get_request(request_id) until terminal
if success  → use output (on-chain success means confirmed)

Without an MCP host

Same capabilities over HTTP via the Node SDK and CLI:

npm i @paybox-sh/sdk
npx @paybox-sh/sdk login
npx @paybox-sh/sdk credentials

Package: @paybox-sh/sdk. Guides: SDK & CLI, API reference. Use this when your agent runs in CI, a worker, or a custom runtime that is not an MCP chat client.

A sensible first build

1. Create an account on app.paybox.sh and vault a small Solana or EVM wallet.
2. Connect https://api.paybox.sh/mcp with always_approve so every spend is obvious.
3. In the agent: list_credentials, then get_portfolio or verify_solana_balance.
4. Try one low-risk sign or a tiny x402 call. Confirm you handle pending_approval and poll get_request.
5. Only then loosen grants or switch selected credentials to autonomous mode with hard caps.

Production apps should keep tokens server-side, never log one-time card claims, and treat the attester/signing path with the same seriousness you give a hot wallet.

Where it sits in the agent stack

PayBox is not an API translator and not an airdrop gate. It is the credential and payment rail for the agent:

• Runtime — Claude, Grok, or your MCP host calls tools
• PayBox — grants, passkeys, audit trail
• MoonX MPC — non-custodial signatures
• x402 services — pay-per-call APIs the wallet can settle

Use Gecko-class tooling when the hard part is making an arbitrary API agent-safe. Use PayBox when the hard part is letting the agent spend or sign without eating the keys.

Resources

• paybox.sh
• MCP endpoint
• Docs · MCP connect · Tools
• llms.txt
• @paybox-sh/sdk
• PayBox on DevRels
• x402 · Gecko · Milypay

Bottom line

PayBox makes “my agent can pay” a grant problem instead of a key management disaster. One MCP URL, scoped credentials, passkey when you want it, and a strict poll-based request lifecycle. Build the loop around list_credentials and get_request, keep early grants tight, and you get Solana- and EVM-capable agent spend without putting a wallet seed in the model context.