Every paid API needs some way to know who's calling and whether they're allowed to. The three models in common use today — a static API key, a funded-balance secret, and a per-request signed payment — look similar on the wire (they're all usually an Authorization header) but behave very differently once something goes wrong.
The familiar model: generate a key once, store it in an environment variable, attach it to every request indefinitely. It's simple to integrate and simple to reason about, which is why it's the default for most human-operated applications. The cost shows up at the edges — a leaked key is valid until someone notices and rotates it, and "someone notices" usually means after the damage is done. There's also no inherent cap on what a leaked key can do: if the underlying account has a $10,000 monthly limit, a leaked key can spend toward all of it before anyone's alerted.
A wallet secret (wsec_...) is bearer-token shaped, like an API key, but it's scoped to a specific funded balance rather than an open-ended account. See how wallet secrets work for the full mechanics. The practical difference: a leaked wallet secret can only drain what's actually in that wallet, and an owner can set a daily spend limit that caps the damage further, or freeze the wallet outright. It's still a long-lived credential — there's no password reset, so losing it is final — but the blast radius is bounded by design in a way a traditional API key usually isn't.
x402 removes the stored credential entirely. Instead of presenting something that proves who you are, each call signs a payment authorization that proves you're paying for exactly this one request, right now. See how a 402 Payment Required response actually works for the mechanics. There's nothing to leak that grants ongoing access — a captured signature is tied to one specific payment and can't be replayed for a second one. The tradeoff is that the caller needs a wallet capable of signing (see what EIP-3009 actually does) and a payment on every call, which is more moving parts than sending a static header.
| Model | What leaks if the credential is exposed | How you revoke it |
|---|---|---|
| Static API key | Full account access until rotated | Manually rotate the key |
| Wallet secret | Only that wallet's remaining balance, capped further by any spend limit | Freeze or drain the wallet; the secret itself can't be reset |
| x402 signature | Nothing — a captured signature authorizes one already-spent payment only | Nothing to revoke; there's no standing credential |
These aren't mutually exclusive — DimeBox supports wallet secrets specifically as a lower-friction alternative to signing x402 payments per call, for callers who'd rather fund a balance once than hold a signing wallet. If your agent already holds USDC and can sign, x402 removes the standing-credential risk entirely. If it can't, a wallet secret with a sensible daily spend limit is the next-best bound on what a leak can cost you. A traditional unscoped API key is the model worth being most careful with, simply because nothing about it limits the damage automatically.
None of this matters if a model is too much work to integrate. A static API key is the easiest to wire up — one header, set once, done. A wallet secret is nearly as easy: fund a wallet through Stripe Checkout once, store the resulting secret, attach it as a Bearer token on every call. x402 is the most work up front — your agent needs a wallet capable of signing an EIP-3009 authorization, and your client needs to handle the 402-then-retry flow, usually via an existing client library rather than hand-rolled signing code. That extra integration cost buys the strongest security property of the three: nothing stored, nothing to leak.
A card-funded wallet sits behind Stripe, which means normal card-network dispute processes apply to how the wallet was funded — if a funding charge is disputed, that's resolved the same way any Stripe charge dispute is, independent of how the wallet's balance was later spent. A direct x402 payment settles on-chain in USDC with no card network involved at all, so there's no chargeback mechanism in the traditional sense — a settled on-chain payment is final the way a cash transaction is. That's worth knowing before choosing a payment path: card-funded wallets inherit card-network protections (and their disputes process); x402 payments don't, because there's no card in the loop to dispute through.
A wallet secret is a single header on a single request — no round trip beyond the call itself. An x402 payment is at minimum two round trips: the first unpaid call to learn the price from the 402's PAYMENT-REQUIRED header, then a second call carrying the signed PAYMENT-SIGNATURE. Signing itself is local and fast, but a caller that hasn't cached the price ahead of time pays for that extra round trip on every single request. For an agent making one email call as part of a longer task, that's negligible. For a tight loop making many calls back to back, caching the expected price (or using a wallet secret instead) avoids repeating the discovery step every time. See discovering DimeBox's live prices programmatically for a way around paying that round trip on every call.