x402 is the default way to pay a DimeBox route: call it unpaid, get back a 402 describing the price, sign a USDC payment on Base, retry with the signature attached. That works well if your agent already holds a wallet that can produce an EIP-3009 transferWithAuthorization signature. A lot of agents don't, and a lot of teams building them would rather not manage private keys, bridge USDC, or think about gas just to call a $0.02 drafting endpoint. See What Is x402? for the full mechanics of that flow if you haven't read it yet.
A DimeBox wallet is the other way to pay for the same paid routes. Instead of signing a payment per call, you fund a balance once with a card through Stripe Checkout, and every call after that authenticates against the balance with a bearer secret: Authorization: Bearer <wallet_secret>. There's no signature to construct, no retry loop, and no transaction to broadcast per call - the wallet absorbs whatever settlement happens on its side, and you just see a ledger debit.
Compare the two ways to pay for the same drafting call:
# x402 - sign a payment, retry with it
curl -X POST https://dimebox.app/api/emails/generate -H 'Content-Type: application/json' -H 'PAYMENT-SIGNATURE: <signed payment>' -d '{"recipient":"[email protected]","purpose":"follow up"}'
# Wallet - bearer secret, no signing step
curl -X POST https://dimebox.app/api/emails/generate -H 'Content-Type: application/json' -H 'Authorization: Bearer <wallet_secret>' -d '{"recipient":"[email protected]","purpose":"follow up"}'Same endpoint, same request body, same $0.02 price, same response shape. The only thing that changes is how the call authenticates. Everything downstream of that - drafting, sending from an inbox, claiming a custom inbox name, paying for priority receive - works identically on either path, because the payment layer sits in front of the same routes either way.
Every paid route takes either kind of credential, at the same price: drafting is $0.02, sending from an inbox is $0.01, priority (guaranteed) receive is $0.03, and claiming a custom inbox name is a one-time $1.00. None of that shifts based on how you're paying. A wallet is a different front door onto the same priced routes, not a separate pricing tier or a discount for committing to a balance.
The rule that a failed call never gets charged holds on both paths. A validation error, a reserved slug, a non-AI inbox rejecting a drafting request - none of that costs anything whether you authenticated with a signature or a bearer secret, for the same reason covered in Why DimeBox Never Charges for a Failed API Call: settlement only happens once the route's own response comes back under 400.
If your agent already has a funded EVM wallet and a signer wired up, x402 is probably simpler - no card to manage, no balance to refill, no checkout flow. The card path earns its keep when you'd rather not hold crypto in the agent's runtime at all: prototyping without wanting to fund a testnet faucet first, running agents inside environments where one more private key is one more thing that can leak, or paying from a context where "charge a card" is a much easier internal conversation than "custody USDC on a wallet." It's the same tradeoff covered in more depth in API Keys vs Wallet Secrets vs x402 Signatures.
A freshly created wallet isn't trusted with a full balance right away - it's capped at a lower balance and a lower daily spend limit for its first few days, independent of whatever limits you configure yourself. See New-Wallet Risk Controls for exactly what that cap is and why it exists. It loosens on its own as the wallet ages; there's nothing to request or manually unlock.
Create and fund a wallet at /wallet - card in, wallet_secret out, shown once. From there, every call that would otherwise need a signed x402 payment accepts the bearer secret instead, with no other change to how you build against the API. The full endpoint-by-endpoint reference, including what each route expects in its request body, lives in the API docs; the quickstart has runnable examples for both payment paths if you want to see them side by side before picking one.
x402 and a wallet ask for different kinds of trust. With x402, each call settles as its own signed transfer - you're not handing DimeBox custody of anything beyond that single payment, and the transaction itself is verifiable independent of DimeBox saying it happened. A wallet works differently: the card charge that funds it sits as a balance inside DimeBox's own ledger between the moment you fund it and the moment you spend it down, which means you're trusting DimeBox's bookkeeping for whatever balance hasn't been spent yet, the same way you'd trust a prepaid gift card issuer to honor what it says you have left. Neither model is wrong; they're just different tradeoffs between per-call verifiability and day-to-day convenience, and which one matters more depends on how much you need to verify independently versus how much friction you're willing to remove from the calling side.