That's why I only code against Spreedly [1] instead of directly against any payment processor. One API instead of 53, switch processors just by changing a variable, and you can securely store customers' payment info without locking yourself into any processor's vaulting solution either.
Payment processors are in the risk business -- becoming a risky account to underwrite, or their making a mistake in evaluating the risk, means you lose your account, any money that hasn't yet made it to your bank, and any customer info you have stored. Because the processor bears all the risk for chargebacks and bankruptcies of its merchants, it's an extremely thin margin business.
Spreedly is in the secure API business. They don't care much about the health of your business, the risk associated with your transactions, or anything else the processors care about. They just have to pass around messages and get paid a fee every time they do. It's a fat margin business.
The risk of losing a Spreedly account is much lower than losing a payment account. The risk of Spreedly suddenly going out of business is much lower than the risk of a small merchant account provider/reseller going out of business. And if you choose to stop relying on Spreedly, they'll hand you all your customer data (securely) to take elsewhere, which most gateways with card vaulting refuse to do. It's not a choice of who to commit to, it's freedom from vendor lock-in.
1: https://spreedly.com/