It is the middle of your busiest day and the balance reaches zero.
In most metered services you know exactly what happens next. Requests start coming back refused. Your integration is down, and it stays down until somebody notices, finds the right card, and gets through a billing page. The outage is not caused by a bug or by load. It is caused by an accounting state.
We do not do that. We throttle, and we do not deny.
What actually happens
The request that arrives to find the balance empty is served. It is not billed, and it is not refused. A signal fires, and the project moves to the free rate, where it keeps relaying for as long as it takes you to top up.
So your traffic does not stop. It slows down. That is a very different problem to have at the wrong moment: a slower integration is something you can work with, while a refused one is a partner asking why their events vanished.
Topping up restores the full rate immediately. A top-up that lands inside the short grace window after depletion means the rate never drops at all.
The one place you do get refused
There is exactly one, and it is deliberate: the separate pool that test keys draw on. Run that dry and a test request is refused, with the reason and the way to fix it in the response.
That is the right behaviour there. A test that quietly keeps running on live credit is worse than a test that stops and tells you. Live traffic never sees it.
Why we built it this way
Because of who the refused request actually lands on.
It is not you. You find out later, from a dashboard or from someone's complaint. The request that gets refused belongs to your partner, your customer, or your own users, none of whom have any relationship with us and none of whom did anything wrong. Some of them will not retry. Whatever that request carried is simply gone.
Degrading is recoverable and denying is not. A slower integration catches up when you top up. A refused request is over.
There is a second reason, and it is less noble but just as real: an outage is a terrible way to ask someone for money. A service that takes your traffic hostage to get a card entered has told you exactly what it will do the next time something is ambiguous.
What you are actually paying for
Billing counts deliveries rather than requests. One request fanned out to three targets is three deliveries, because three of them happened. Size counts too, and every delivery mode is billed the same way per delivery, so choosing queued, synchronous or streaming is a design decision rather than a pricing one.
Deliveries that fail on our side are not charged. Current rates are on the pricing page.
The point
You should be able to put something on the path of your traffic without adding a new way for that traffic to stop. An empty balance is a thing to fix, not an incident, and it should never be the reason your partner's events went missing.
