Adyen is a possibility. I never used their services so I cannot say if they are a good alternative. But they exist, and some people swear by them.
Now, I am concerned that a significant change in velocity/volume like this is going to set off a flag with Stripe, and I fear that my Stripe account will get nuked, kill the launch, all the momentum I've been building, my reputation, and all my regular business to boot -- if I lose access to Stripe I lose a very significant portion of my business. Even if its just for a couple weeks while I'm "being reviewed".
There seem to be many threads here on HN about getting killed by Stripe without explanation, without easy recourse, without customer support or quick resolution -- especially as a small fry like me.
Are there any suggestions for a non developer, one-person-shop to avoid this seemingly common pitfall?
Why do I think I'll get flagged? In recent history had one invoice that was unusually large for my transaction history -- I landed a really good project. I feared this would set off a trigger with Stripe, and sure enough I was flagged "as a part of our ongoing account review process".
Stripe sent very vague and *very "phishy"* seeming emails. After logging into Stripe I had to give access to my bank accounts and get through a "review" of my business.
I really feared I was going to be cut off then. So, I harbor no illusions that it will happen again next time should I enjoy a modicum of unusual success. I certainly learned that in the future I have to invoice large projects in smaller incremental chunks and not in the one-lump that the client preferred.
But I don't know how to handle if the velocity of transactions changes.
Adyen is a possibility. I never used their services so I cannot say if they are a good alternative. But they exist, and some people swear by them.
That means that in a crisis you can still sign users up, and take a few days to sort out the billing situation.
Could save some time up front, and if Stripe ends up never causing a problem you didn’t waste effort on unneeded complexity.
You are overthinking this - if you have to use game theory and uncertainty to plan your relationship with a vendor (instead of picking up a phone or sending an e-mail to ask or solve your issues), you need to find a new vendor.
Use multiple providers, if one shuts you down you still have other options. When you're large enough that it makes financial sense, apply for your own merchant account and use a processor like Authorize.net for that too.
i don't know if their terms allow this to be used for recurring payments, it is used e.g. for services such as steam and humble bundle, where you can choose to remember your payment method.
* It's possible that you could tokenize to each provider before making a transaction. But you'd need to see if the provider has a timeout on those tokens if you don't actually make a transaction with it. You'd also need to make sure your processor will even allow you to connect to them directly and authorize a transaction with that token later without consumer interaction.
* You can tokenize the card number and expiration, but not the CVV. Some cards you would be able to get an auth without a CVV, with a slightly higher processing fee (that may or may not get passed on to you). But some will just get declined without the CVV. You are not allowed to store the CVV.
* You're really supposed to get the CVV for any transaction that's an initial transaction. This is a recurring transaction, but since you are changing the agreement (by moving providers and a completely different merchant account), it's really a new initial transaction. Your customer will see a different descriptor on their credit card statement, they may complain, it could end up being a whole thing. And if you're worried about needing to use multiple providers, you don't have your own merchant account, so the bank doesn't come to you, they go to Paypal, or Stripe, etc. Now you have to explain to them why there's a new transaction with no consumer interaction, if they contact you to ask at all before shutting you off.
* Unless you're using a plugin like Stripe's for every processor, quickly doing a request to your processor directly in the user's browser and submitting each of the tokens to yourself, doing this would require you to at least accept and transmit credit cards yourself, not sending the consumer onto the processor's site to fill it out. You are now transmitting credit card data yourself, which means you'll have to go through the PCI Compliance process. It's a self-assessment, and you can skip a lot of steps if you're at least not storing the card number (which you probably should not), but it still a bit of an arduous process. No one's going to check you on this unless there's some sort of breach, but you should still definitely do it.
This is the biggest hurdle to tokenizing at multiple providers by far. As soon as you actually "touch" that credit card number (not Stripe/etc's SDK or iFrame) everything changes. Also the PCI Compliance process is a bitch and a half and is confusing as fuck. For me it was a janky web-app form that was not clear and lead to me answering wrong multiple times then being very confused at the questions it was asking me (I had to call in and their support knew the pitfalls and were able to steer me back but the instructions/question-wording is terrible).
If you are that worried about Stripe that it is keeping you up at night, just move off to another payment processor, sure their documentation will suck, and you may need to use some really terrible library, but besides that it's the exact same. You may even safe a few cents a transaction as Stripes fees are not that cheap.
Past HN comments on Stripe the person never really said what they were selling, which is also a huge part of processing credit cards as the sponsor bank also signs off on the products that are sold as well, not just Stripe.
We can't keep letting them get away with screwing the little guy like this.
I'm not going to defend Stripe as I've had my fair share of frustration with them, unfortunately they are the best game in town that I can see [0]. I can comment on change in velocity/volume on the Stripe platform. I've gone from testing amounts of traffic (so <$100/mo or so), to $500-$2000/day for 2-3 months, to $20K-$40K/day for 2-3 days, to then $100K+ for 1-2 days, then back to $0-100 for ~9 months, rinse and repeat (it's software for festivals). I did all of that without needing to pre-clear anything with Stripe and without issue.
Maybe the semi-gradual ramp-up kept me under detection levels (though I was a little worried about the $20K+ days as it was 10x+ normal) but I wanted to provide a data point to you.
[0] I'm open to other options but before you comment know that the following is what I consider baseline: iOS/Android/Web SDKs that support Credit/Debit/Apple Pay/Google Pay, same or better rates as Stripe, decent docs/api, decent dashboard. I've tried alternatives and their docs are a mess, their API is confusing, their dashboards are dated/broken, their support is somehow worse than Stripe, and sometimes you find out one of their SDK's just doesn't support Credit, Debit, Apple Pay, or Google Pay. Also I need in-person hardware support (bluetooth connection to a phone/table, not wifi, not ethernet), ideally paying in-person would result in lower rates.
If you’re worried about being flagged, talk to them about your expected increase in volume _now_.
You're better off spending the effort on having a backup replacement ready to go (or even balance between them in normal operation).