AWS keeps failing my prepaid at invoice time — what are you billing cloud on?

Three AWS accounts, combined bill runs $400 to $1,200 a month depending on what's spun up. Two prepaid cards have now died on the same step and I'd like to know what people are actually billing cloud on before I burn a third.

The failure mode is not the initial add. Card attaches fine, the $1 verification auth clears, and then the first real invoice at the end of the month comes back as:

Payment method declined.
Reason: 05 - Do not honour
Retry scheduled: +3 days

IME that from AWS specifically means the issuer refused a variable-amount recurring auth rather than the balance being short - I had $900 sitting on it at the time. FWIW the retry three days later failed identically.

What I care about is the 3am case. Account goes past due, instances get throttled, and I find out from a customer. So I'm not looking for the cheapest, I'm looking for the one that doesn't do this.

05 is a bucket. it means the issuer said no and declined to say why. you're reading intent into a code that carries none

AWS decline for me also. I give up and move to host who take crypto direct.

I have thin data on this but it's data. Three cards against AWS invoices over eleven months, one account, bill between $180 and $640:

Card	Invoices attempted	Cleared first try	Cleared on retry
PrivCards	9	8	1
Bitget Wallet	7	7	0
PayPaw	4	2	1

n is too small to rank anything and I'd say so if someone else posted it. What I will say is that the one failure I could actually explain was a balance that dropped under the invoice between the estimate and the charge, which is not a card problem, it's a me problem.

Over how many invoices did your two cards fail? If it's one each you have no pattern yet.

Four invoices across the two, three of them declined. Balance was covered every time - I check because I got bitten by exactly that in a previous life.

Worth saying out loud: the AWS account already has your identity on it. Phone, email, usage patterns, IPs, and a full history of what you deployed and when.

A no-KYC card in front of that buys you nothing except a payment rail that AWS's risk engine has never seen before, which is precisely why it declines. You are paying a privacy premium for a privacy gain of zero.

If the account isn't in your name and the card isn't either, fine, that's a threat model. If the account is yours, use a card that clears and stop optimising the wrong layer.

For variable recurring specifically, the cards that behave best are the ones that hold a real fiat balance rather than converting at authorisation. RedotPay handles that side well and the limits are absurd for your size, but it is full KYC plus AML, which may be the whole reason you're in this thread.

If that's a no, then the answer is boring: keep three or four times the invoice sitting on whatever card you use and accept the idle float as the price.

KYC is a no. Idle float I can live with. Three times the invoice on a $1,200 month is a lot of dead money though.

3.6k idle is not a lot of dead money, it's a fortnight of usdc yield you're not earning. move on

Reserved instances. Fixed amount. Problem was never the card.

Five months on and I still don't have a clean answer, so for anyone who lands here from search: I gave up on solving it and split the bill instead. Two accounts on one card with a padded balance, the third on a card I only use for that, and a calendar reminder three days before each invoice date.

Still get a decline maybe one month in four. The retry catches it. It is not a solution, it's a workaround with a reminder attached.

Following, exact same thing on two accounts.