Every DimeBox wallet goes through the same sequence of events, whether it ends up handling ten calls a month or ten thousand: created and funded, spent down one priced call at a time, occasionally refilled, occasionally capped, and tracked the entire way as entries in a ledger. This post walks that sequence start to finish, pulling together the pieces covered individually elsewhere in this pillar.
A wallet starts at /wallet, funded by a card charge through Stripe Checkout. That first charge produces a wallet_secret, shown exactly once - there's no dashboard view that shows it again later, and no reset flow if it's lost; How Wallet Secrets Work covers why that's deliberate rather than an oversight.
A brand-new wallet doesn't start with full trust: it's capped at a lower balance and a lower daily spend limit than it would otherwise have, for its first few days, as a control against stolen-card fraud and throwaway abuse. New-Wallet Risk Controls covers exactly what that cap is and how it loosens automatically as the wallet ages - nothing to request, nothing to unlock manually.
Once funded, the wallet authenticates paid calls with Authorization: Bearer <wallet_secret> in place of a signed x402 payment - same endpoints, same prices, as covered in No Crypto Wallet? How to Pay AI Agent APIs With a Card Instead. Drafting is $0.02, sending from an inbox is $0.01, priority receive is $0.03, claiming a custom inbox name is a one-time $1.00. Every successful call debits the ledger by exactly that amount; every failed call - a validation error, a reserved slug, anything that comes back 400 or higher - debits nothing, the same rule that governs x402 settlement.
A wallet gets refilled one of three ways: a manual one-time top-up, auto-reload triggering automatically once the balance crosses a threshold you set, or a monthly subscription that recredits it on a schedule and skips the one-time setup fee a manually funded wallet otherwise carries. All three land in the same ledger as the same kind of entry - a credit, distinguishable from a debit only by direction, not by which path produced it.
A daily spend limit caps what the wallet can spend in a rolling day, independent of balance - useful precisely because nobody's reviewing each call an unattended agent makes. If a funding charge is ever declined, the wallet simply doesn't get that credit and keeps running on whatever balance remains. And if DimeBox detects abuse, a wallet can be frozen outright, which is a different event from a decline or an exhausted balance - What a Wallet Freeze Means covers when that applies.
Because every debit is a discrete ledger entry tied to a specific call, retrying a call that may or may not have gone through doesn't risk a double-charge on DimeBox's side any more than it does on the x402 path - the same idempotency principle that protects a signed payment from being settled twice applies to a wallet debit. Idempotency Keys: Making Agent Payments Safe to Retry covers that mechanism in more depth.
A wallet and an x402 signature are two authentication paths onto the exact same priced routes, settling against the exact same ledger of what succeeded and what it cost. API Keys vs Wallet Secrets vs x402 Signatures lays the two out side by side if you're deciding which one an agent should actually use, and What Is x402? covers the mechanics of the alternative this entire pillar exists to avoid needing.
Every detail skipped over here in favor of the bigger picture - exact request shapes, response fields, status codes - lives in the API docs, and the quickstart has runnable examples for both payment paths against a live endpoint.
A declined funding charge never produces a credit entry, so the balance simply doesn't move - the next debit attempt either succeeds against whatever was already there or fails the same way an exhausted balance would. A daily-limit rejection and a frozen-wallet rejection both stop debits from happening at all, for different reasons and with different remedies, but neither one produces a ledger entry either, since nothing debits without first authenticating successfully. The ledger, in other words, only ever records what actually happened - it has no entries for calls that never got far enough to be charged, which is the same no-charge-on-failure principle that governs the rest of the API.
Everything above happens the same way whether a wallet ends up making ten calls or ten thousand. The only step that requires a decision up front is the first one - create and fund a wallet at /wallet, save the wallet_secret it hands you once, and build the rest around whichever of auto-reload, a daily spend limit, or a subscription actually matches how the wallet will be used.