The rule is simple and absolute: a payment only settles if the route's own response comes back under 400. Anything else - a 402 for missing payment, a 415 for the wrong content type, a 422 for failed validation, a 502 if the payment facilitator itself is unreachable - is never charged, on any route, including ones that normally require payment to succeed. Failure, for any reason, costs nothing.
It would be easy to build this the other way - attempt settlement first, then run the business logic, and eat the cost of refunding failures after the fact. DimeBox's gate runs in the opposite order deliberately: the route's logic executes first, the response status is decided, and settlement is the very last thing that happens, conditioned entirely on that status. If the status is a failure, settlement simply never executes. There's no charge to refund because there was never an attempt to charge.
Walk through what that looks like in practice. An agent tries to claim an inbox name that turns out to be reserved - the call fails validation with a 422, before the payment gate even has a chance to settle anything, so the attempt costs nothing even though it included a signed payment. An agent sends a request with the wrong Content-Type header - a 415, rejected earlier still, also free. An agent's payment itself is malformed or for the wrong amount - a 402, which is simply the unpaid case restated, also free. In every one of these, the only thing that changed between a free failure and a billed success is whether the underlying action actually happened.
That consistency is worth emphasizing because it would be easy to get subtly wrong in a less centralized implementation - a route that checks payment before validation, say, would charge for requests that were never going to succeed in the first place. Deciding the response status before touching settlement, every time, is what keeps that mistake from being possible at all.
A human hitting a validation error reads it, fixes the one thing wrong, and resubmits once. An agent calling the same API at machine speed generates more failures as a matter of course - a slug that turns out to be taken, a reserved word it didn't know to avoid, a content-type header an earlier step in its own pipeline got wrong, a malformed field from an upstream model's output. None of that is abuse; it's just what automated trial-and-error looks like when the caller isn't a person reading an error message once. If every one of those attempts cost money, an agent learning the correct request shape would be paying, repeatedly, for its own debugging - which punishes exactly the kind of automated correction a machine caller is supposed to be good at.
Charging nothing for failure keeps the cost signal pointed at the right thing. Charging in cents at all is meant to make overuse visible - but overuse means successful calls made unnecessarily, not failed attempts made while getting the request right. Mixing those two signals together would make the price noisy in a way that tells you nothing useful about either one.
This isn't a special case bolted onto a few routes - every paid route in DimeBox is wrapped in the same payment gate, so "failures aren't charged" is a property of the gate itself rather than something each endpoint has to remember to implement correctly. See why every paid route shares one gate for what that consistency buys beyond this specific rule - mainly, that there's exactly one place to get this right instead of N places that could each get it wrong slightly differently.
Not charging for failure solves "don't bill me for getting the request wrong." It doesn't solve a different problem: a request that actually succeeded, where the response was lost in transit and the caller retries, risking a double charge for one real action. That's what idempotency keys are for - a mechanism aimed at making retries of successful calls safe, not at making failed calls free. The two together cover both halves of "a retry should never cost more than it should": never bill failures, and never double-bill successes that only look like failures because a response got lost.
The net effect is a pricing model where the only thing that ever costs money is work that actually got done - an email actually drafted, actually sent, actually delivered with priority. Every dead end along the way - wrong field, taken name, bad header, unreachable facilitator - is free to hit and free to learn from. For a caller that's going to make mistakes at machine speed and machine volume, that's not a generous policy so much as the only one that keeps the price attached to the thing it's supposed to measure.