"Is it secure" is the wrong first question to ask about any payment protocol — the better question is "secure against what, and who's trusting whom." x402 shifts some trust decisions away from where they sit in account-based billing and introduces a few new ones specific to signed, per-call payments. Here's what actually needs to hold for a pay-per-call API like DimeBox's to be safe to build on, from both a caller's side and a server's side.
The most obvious worry with any signed-authorization scheme is replay: can a signature captured once be submitted again to pay twice, or submitted by someone who intercepted it rather than the original caller? EIP-3009's nonce mechanism closes this at the token-contract level — each authorization carries a nonce that the contract marks used on first successful submission, so a second submission of the identical signature fails outright. Combined with the exact scheme's per-request binding (a signature matches one specific quoted request, not a standing amount), a captured signature is only ever worth exactly what it was signed for, once. See what EIP-3009 actually does for where that nonce lives in the signed message.
A facilitator sits in the middle of every settlement, verifying signatures and submitting them on-chain — see x402 facilitators explained for its exact role. That's a real trust dependency: if a facilitator is compromised or simply buggy, it could in principle misreport whether a payment settled. It's a narrower dependency than it sounds, though, because a facilitator never gets to decide the terms of a payment — those are fixed in the PAYMENT-REQUIRED header the API server generated — and DimeBox's own rule that a route's response has to come back under 400 to settle anything means a facilitator reporting a bad settlement doesn't, on its own, cause an uncharged action to appear charged on DimeBox's side.
The charging rule underneath every DimeBox route is simple and absolute: payment only settles if the route's own response is under 400. A validation error, an unreachable facilitator, a malformed signature — none of these result in a charge, regardless of how far into the request they happened. This is also why idempotent retries are safe by default rather than something a caller has to engineer around: retrying a call that failed costs nothing extra, because the failed attempt was never charged in the first place. See idempotency keys: making agent payments safe to retry for the cases that are less automatic than this — specifically, what happens on a timeout where the caller genuinely doesn't know if the first attempt succeeded.
A valid, correctly verified payment signature proves exactly one thing: the signer authorized this exact amount for this exact request. It says nothing about whether the wallet behind that signature has a history of abuse, whether the request content itself is malicious, or whether the caller should be trusted with whatever the route is about to do. Those are separate questions that a payment gate alone can't answer, and treating "the payment checked out" as a stand-in for "this caller is trustworthy" would be a mistake specific to how x402 is used, not a flaw in the protocol itself.
An EIP-3009 authorization is only valid between its signed validAfter and validBefore timestamps. A client that signs an authorization with an unnecessarily long window leaves a captured signature exploitable for longer than it needs to be, even though it can still only be redeemed once. Keeping that window tight — just long enough to cover the retry and settlement round trip, not hours — is one of the few security decisions that sits with the client's own x402 library configuration rather than with the protocol or with DimeBox.
x402 answers "was this call paid for." It has nothing to say about whether the caller should be trusted with what the call actually does — that's a separate layer of controls. DimeBox's own abuse surface — a fresh wallet with no payment history, a free inbox-creation route that has to be rate-limited regardless of whether anyone's paying — is handled by controls that sit next to the payment gate, not inside it. new-wallet risk controls: why fresh wallets start capped covers the specific caps DimeBox applies to wallets with no track record yet, which exist precisely because a valid payment signature says nothing about whether the wallet behind it is trustworthy.
x402 is secure for what it's actually built to do: binding a specific payment to a specific request, in a way that can't be replayed and doesn't get charged unless the underlying call succeeds. It isn't, and doesn't claim to be, a general-purpose fraud or abuse-prevention system — that's layered on top, deliberately, rather than folded into the payment protocol itself. Understanding where that line sits is most of what "is x402 secure" is actually asking.