The month your card stops working mid-project

You shipped the feature. It works. Usage climbs steadily and nobody thinks about the billing page, because it has worked every month so far. Then one morning the top-up fails and the dashboard says the card was declined. Nothing about your code changed, and nothing about your code is going to fix it.

Here is what actually happens next, and the two things worth doing before you touch anything.

Your usage does not pause when your payment does

If you are on a prepaid balance, the balance runs down and then requests start failing. If you are on autopay, the failure happens at the worst possible moment: a renewal you did not know was coming, on a card that changed behaviour silently. Either way the first symptom is usually a 402 in the middle of a run, which people initially read as a code problem.

It is not a code problem. HTTP 402 says the account behind the key has no spendable balance right now. Your prompt, your SDK version and your retry logic are not involved.

Before you change cards, look at the invoice

The instinct is to sort the payment out and get back to work. But the payment failure and the size of the bill are separate problems, and the second one is the one that decides whether the next top-up lasts a week or a month.

Three things move that bill, in roughly this order: how much of your prompt gets re-sent on every turn of an agent loop, whether caching is genuinely passed through by the provider, and whether you are watching the mean request or the large one. The comparison everyone does first, price per million tokens, is usually the smallest of the three.

Then separate the two failure modes

A declined card in a country where the card was issued has its own causes, and they are worth telling apart before you call anyone: international online transactions disabled by default, a merchant category your bank refuses outright, and a 3DS step that fails after you have already entered the code. Those three look identical on screen and need three different responses, and only one is worth a call to the bank.

I wrote the arithmetic out, with the numbers and the levers that actually move a bill, here: the arithmetic behind a bill that keeps climbing.

And if you are stuck a step earlier, on the payment itself, we keep the notes per country rather than pretending it is one problem: the payment notes we keep per country.

We're NovaAPI — a reseller, not DeepSeek, and not an authorised partner.