Ask HN: Can I avoid being nuked by Stripe?

I'd suggest reaching out to Stripe support in advance, documenting that you are beginning a product launch and expect a change in volume. Just as a heads up to them basically. Also, definitely have a second choice payment processor available and integrated with your invoicing tool as a fallback. Finally, if this is at all feasible for you, be ready to deliver now and collect payment later.

I get the concern, but a lot of credit card processors will review accounts. As part of a more traditional credit card processing account you provide your average transaction and a max transaction along with bank statements for underwriting. You should reach out to Stripe and let them know your concern. Stripe and Banks work similar in the US that transactions can be held and it's normal due to Know Your Customer.

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.

Yes, reviewing accounts for fraud is absolutely standard and no cause for concern in and of itself.

Its a legal requirement. Banks loose their license if they don't use KYC

Is there a list of alternatives to Stripe with a link to their API, terms, conditions? That would be helpful.

Anecdotally I've found Braintree to be at least mostly comparable in terms of their API. But I'm not aware of a list that compares this sort of stuff.

The idea behind these payment processors was that they were to be like utilities.

We can't keep letting them get away with screwing the little guy like this.

> 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".

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.

I'm worried about it as well (single person business, barely started). I was advised by a friend to have an account at another payment processing platform, and be ready to switch very quickly if needed.

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.

I recently saw Adyen and was interested, however, you need a minimum of £5M a year they told me :(

Another alternative to fully preparing a separate billing pipeline (which could be quite a lot of work) would be to add a “free switch” you can hit which allows users to sign up m, have them confirm a plan, and gives them access to the product, to be billed at a later date.

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.

I run a platform which has many connected Stripe accounts. Collectively they’ve now transacted over $10M through the platform with very peaky seasonal patterns. I’ve seen many accounts get flagged, I’ve never ever seen one get “nuked”. They may ask for additional verification. Rarely they may place a 30 day hold on some portion of your funds. If these things happen and you feel they’re unjustified, talk to someone about it. It’s a decision that can be changed or reversed like any other. Explain the situation and demonstrate why you aren’t a risk. They’ll listen.

If you’re worried about being flagged, talk to them about your expected increase in volume _now_.

I saw once a guy suggested to contact stripe for an account manager. I don't think he was very specific and I'm not sure if you can simply create a ticket or email them but I think that is a good step

Have they ever been sued for this? I'm curious if their user agreements protect them from it at all, but when these platforms destroy people's businesses it seems like the exact reason lawsuits exist.

I'm sure their bevy of lawyers has reviewed the TOS which absolves them from anything ever.

You're better off spending the effort on having a backup replacement ready to go (or even balance between them in normal operation).

In order to use Stripe, you agree to use arbitration rather than courts. Pretty standard from most T&Cs for online services. So, no probably not.

There's Paddle, but last I heard they had strict mrr requirements

They at least partially use Stripe as they credit card processor. Not sure if that indirection would be helpful.

How much? Can't find anything on the topic other than some people saying they could set it up without any MRR.

It seems like you're worried about something that may happen, if you sit around worrying about everything that could possibly happen you'll never go anywhere.

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.

Switch to Clover products. They're great!

Do they have some guarentee not to ban you? Relying on reputation alone will lead to exactly the same situation

I've used Clover, I've coded for their POS system, I've used their API. They are far from great. They are owned by CardConnect/FirstData and CardConnect's system is garbage (I tried to switch to them from Stripe, worst mistake I ever made). I've not particular love/loyalty to Stripe but Clover is not a good alternative. Especially if you want to in-person, their terminals are disgustingly expensive and their Bolt SDK is a mess. Their support is somehow worse than Stripe.

Seriously look at other payment processors.

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.

Mostly, just use multiple providers. There's no reason to put all your eggs with Stripe. Setting up with Paypal, Google Payments, Amazon Payments, etc, requires essentially no business overhead. Just the extra overhead of needing to setup multiple payment providers in your software.

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.

The issue would be subscriptions if I am not mistaken. If I allow a user to pay a monthly subscription, I am obviously going to depend on Stripe or another provider to hold the information for me, and if they deactivate my account, then I am screwed, a fallback would involve having the user come back in and give you permission to charge their other account (say stripe bans you, you want to use PayPal as a fallback). It's just bad.

Yes, this is a risk. Which is why instead of putting all your subscriptions towards one company, it is a good idea to balance your subscriptions across providers. That way, you might lose some customers or have to ask them to come sign up again, but you don't lose all or even most of them.

Is it an option to tokenize the recurring payments across both providers, but only charge on one provider at a time?

at least with paypal it's possible to allow future deductions without explicit authorization through paypal every time.

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.

Yes but it's complicated.

* 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.

> 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).