Worst case, if AWS or Google decide to fuck you over, let the bill bounce. This way you've still got funds on hand to deal with the fall out and some leverage to negotiate a solution.
The problem (in the article at least) isn't being surreptitiously billed a large amount, it is cost of a critical service changing dramatically without warning.
Also, nothing gets them talking to you faster than a bounced invoice :)
It's when a big bill lands in error or is introduced sneakily that having a separate "cloud only card" can save you. In that case, it's the supplier that's gone nuclear and you're just responding in kind.
Sorry, but this is the risk of using somebody else's service -- especially Google's -- as a critical component of a business. It may be marvellous for developers not to bother with infrastructure for their own service, but this strategy likes to come back and bite in the ass.
I only wish setting up virtual cards were as easy as setting up a new mail box. I know there are services out there that lets you do this, but I've yet to find one that works globally and is easy to work with.
The second bank account is really more for protecting you against black swan events. If all your accounts are under the same bank and have the same owner, there's nothing stopping the bank taking funds from one of your accounts to make up for shortfalls in another.
I'm wary of giving my card information to companies outside India because I don't have this protection.
True for Indian companies but what if you get charged via Forex abroad? For me - Google or Steam - don't required 2FA. All I have to do is to enter my number, confirm CVV then zap. It gets debited. I do get a call from my bank (HDFC) asking if this transaction has been initiated by me, if I say yes, they let go.
The Flash UI looks like this http://mayoyo.tokyo/jJ7.png
They used to have a mobile app but it was discontinued since it didn't support 2FA.
The only reason I don't use them for everything is because I get better cashback/points with other cards.
> Is Emburse available outside of the U.S.?
> Only companies incorporated within the U.S. may register for an Emburse account. In addition, the primary account owner must be a resident of the United States with a Social Security number and a verifiable physical U.S. street address (no P.O. Boxes). We do not offer Emburse accounts to residents of Puerto Rico, Guam, the U.S. Virgin Islands, American Samoa, and other U.S. territories.
> What countries are you available in?
> We're only available in the United States at the moment.
But Paypal, for instance, can only empty a bank account that is used for nothing else, any service like this (open-ended liabilities with shitty/no support) is isolated to debit cards, etc. Nobody gets permission to charge open-ended amounts to credit cards, and nobody gets automation rights to the "real" bank accounts, period.
There's a business model here somewhere for someone to automate all of this. It involves substantially more time to keep organized than my prior two-banks/two-credit cards model. Personal finance apps just aren't designed to treat, for instance, debit cards as transient.
As others note, sure, services that do something like this can still come after you. But who has the money in their pocket right now matters a lot when resolving disputes like this.
After all, they're just being helpful in managing your money and paying your suppliers.
I'd advise not using debit cards for anything, under any circumstances, and relying on the better protections that credit cards provide, but it's a losing battle. My debit card is ATM-only.
This is generally a good approach for all sorts of reasons, not just protection from over enthusiastic cloud bills.
Keep most of your funds in one bank (and never use the cards). Transfer from this account to one or more other accounts with other banks and use the cards on these secondary accounts to pay for things. This way you're protected from suppliers over billing and banks going crazy with unarranged overdrafts (which aren't secured so absolute worst case you just tell them to fuck off and default on it).
Basically, the trick is holding on to your cash. Much harder to fix things rapidly if you're having to negotiate with a third party between you and the supplier (which is the case with a credit card company).
I thought what they were doing is applying all your debits, charging you if that puts you into overdraft, and then applying any credits. If they applied the credits first, you wouldn't go below zero.
Either way, you're trying to charge $46 against an account with $20, but one method results in 1 fee and one method results in 3 fees. The issue of credits vs debits you mentioned can compound this issue.
Consider a bank account with $20 in it, the day before payday, when you forget your World of Warcraft subscription hits today instead of tomorrow. That's $15. But you buy:
* Lunch: $5
* Coffee: $2
* Dinner: $5
* A late-night snack: $5
If the transactions happened in-order, the subscription causes the overdraft, and you're charged $25 or whatever (yeah they are very high). But in the way banks used to do it, they'd take your total ledger for the day, and order it by highest $ first. So, subscription first, $5 left. Lunch, $0 left. Coffee, dinner, and snack are three transactions when overdrawn, so that's $25 * 3 = $75 in fees instead.
Banks claimed that this process was because you'd probably want your highest-amounts paid first, as it'd be something like rent money. In the end, it means way more fees for them, though.
$75 in fees is especially brutal when you don't have much money in the first place; it pretty much caused me to not be able to even go to 7-11 for a candy bar for two months.
Edit: just remembered we're using Google's Cloud Vision API and that's billed to the same debit card. So, for UK accounts at least, they take debit cards.
EDIT: I have no affiliation with privacy.com; I'm just a satisfied user.