Agent Payments
BKey enables AI agents to autonomously pay for API access when they encounter HTTP 402 responses. The agent never handles money directly — BKey authorizes and signs payments on the user’s behalf, with biometric approval for anything above the spending limit.Two protocols, one approval layer
Both x402 and MPP use the HTTP 402 pattern, but they serve different purposes:| x402 | MPP | |
|---|---|---|
| What it is | Open protocol by Coinbase for on-chain stablecoin payments | Machine Payments Protocol by Stripe + Tempo for fiat and stablecoin payments |
| Payment method | USDC on Base, Polygon, or Solana | Cards, BNPL (via Stripe SPTs), or stablecoins on Tempo |
| Payment model | Atomic — one on-chain transaction per request | Session-based — pre-authorize a spending limit, stream micropayments, batch-settle |
| Infrastructure | Permissionless — no accounts, no signup, any wallet | Requires Stripe account, SPTs are scoped credentials |
| Settlement | On-chain (~200ms), no intermediary | Stripe-mediated or Tempo blockchain |
When to use which
| Scenario | Protocol | Why |
|---|---|---|
| Agent calls a random API once | x402 | No signup, no session overhead — just pay and go |
| High-frequency calls to one service | MPP | Sessions amortize cost, batch-settle instead of per-tx fees |
| User or merchant is fiat-only | MPP | SPTs handle cards; x402 requires crypto |
| No vendor dependency needed | x402 | Permissionless, works with any funded wallet |
| Enterprise audit trails and spend policies | MPP | SPTs are scoped, time-limited, auditable |
| Crypto-native agent ecosystem | x402 | Native on-chain, no intermediary |
Super-simple integration — pick your path
Three entry points. All of them auto-detect the protocol from the 402 response, so your agent never has to know whether the merchant speaks x402 or MPP.| Entry point | What you write | When to use |
|---|---|---|
| BKey skill for Claude Code / MCP | Nothing. The skill runs bkey proxy transparently. | Building a Claude Code / MCP agent. |
bkey proxy CLI | bkey proxy GET https://api.foo.com/premium | Any language, any agent, zero code change. |
@bkey/sdk / bkey-sdk | A few lines around your existing fetch. | You want programmatic control over auto-approve vs biometric prompt. |
Path A — Zero-code (CLI proxy)
📱 Biometric approval required — check your phone. and waits. You can combine vault-backed headers too: bkey proxy GET <url> --header "Authorization: Bearer {vault:api-key}".
Path B — Programmatic (TypeScript SDK)
One reusablepaidFetch() wrapper handles both protocols. Drop it anywhere you use fetch:
Path C — Python (shell out to the CLI)
Python mirrors the same detect-first logic. The idiomatic pattern is to delegate to the CLI:examples/python/agent-checkout.
How auto-detection works
Inside the CLI proxy, the skill, and the SDK’s authorize methods, BKey inspects the 402 response and picks the right protocol:- x402 first, if advertised. No percentage fee, fast finality.
- MPP second, if x402 isn’t advertised but MPP is.
- Fail if neither header is present.
Per-transaction cost
A 10–100x difference at typical microtransaction amounts:| Amount | x402 cost | MPP (Stripe) cost |
|---|---|---|
| $0.10 call | ~$0.001 gas | ~$0.30 Stripe minimum |
| $1 call | ~$0.001 | 0.30) |
| $10 call | ~$0.001 | $0.59 |
| $100 call | ~$0.001 | $3.20 |
Under the hood
x402 path
- Agent makes a request → server returns
HTTP 402withPAYMENT-REQUIRED: <base64 JSON>. - BKey decodes:
{ maxAmountRequired, payTo, network, description, resource }. - BKey calls
POST /v1/x402/authorizewith the amount + recipient. - If within the per-agent spending limit → auto-approved, BKey signs an EIP-3009
ReceiveWithAuthorizationpayload with the user’s on-device secp256k1 key. - If above the limit → BKey sends a biometric push; after the user approves with facial biometrics, the same signed payload is produced.
- Agent retries with
PAYMENT-SIGNATURE: <base64 EIP-3009>. - Server verifies via the Coinbase facilitator, settles on-chain, returns the resource.
MPP path
- Agent makes a request → server returns
HTTP 402withX-Payment-Required: <JSON>. - BKey decodes:
{ amount, currency, paymentMethodId, merchantName, description }. - BKey calls
POST /v1/mpp/authorizewith the amount + payment method. - Auto-approved or biometric (same rules as x402).
- BKey returns a Shared Payment Token (SPT) scoped to this merchant + amount.
- Agent retries presenting the SPT in whatever format the merchant expects (typically a JSON body field).
- Merchant captures via standard Stripe APIs.
Spending limits
Users configure per-agent spending limits in the BKey mobile app. Limits apply to both x402 and MPP payments:| Setting | Effect |
|---|---|
| Daily limit | Maximum spend per 24-hour period |
| Monthly limit | Maximum spend per calendar month |
| Per-transaction cap | Maximum for a single payment |
OAuth scopes
Agent payment capabilities are controlled by three protocol-neutral scopes:| Scope | Description |
|---|---|
payment:authorize | Authorize payments (x402 and MPP) on behalf of the user |
payment:address | Read the user’s payment wallet address |
payment:limits | Read and manage per-agent spending limits |
bkey auth setup-agent.
Security
- Private keys never leave the phone — payments are signed on-device using biometric-derived keys
- Spending limits prevent unauthorized charges — configurable per agent, per protocol
- CIBA biometric approval ensures human-in-the-loop for large payments
- EIP-3009
ReceiveWithAuthorization(x402) prevents front-running by requiring the recipient to submit the transaction - Scoped SPTs (MPP) are merchant-locked, time-limited, and amount-capped
- Short validity windows (< 5 minutes) limit exposure of signed payloads
See also
- CIBA protocol — the biometric approval primitive underneath both x402 and MPP
- CLI reference —
bkey proxy,bkey wrap, and other commands x402-agentexample — end-to-end agent code