←back to thread

Stripe has decided to nuke my entire business

1624 points yaythefuture | 3 comments | 15 Sep 22 16:33 UTC | HN request time: 0.001s | source

Saw https://news.ycombinator.com/item?id=32261868 from a couple weeks ago and figured I'd share my own story.

3 weeks ago, I woke up to a pissed off customer telling me her payments were broken. My startup uses Stripe Connect to accept payments on behalf of our clients, and when I looked into it, I found that Stripe had decided to deactivate her account. Reason listed: 'Other'.

Great.

I contact Stripe via chat, and I learn nothing. Frontline support says "we'll look into it." Days go by, still nothing. Meanwhile, this customer is losing a massive amount of business and suffering.

After a few days, my team and I go at them from as many angles as possible. We're on the phone, we're on Twitter, we're reaching out to connections who work there / used to work there, and of course, we reach out to patio11. All of these support channels give us nothing except "we've got a team looking into it". But Stripe's frontline seems to be prohibited from offering any other info, I assume for liability reasons. "We wouldn't want to accidentally tell you the reason this happened, and have it be a bad one."

We ask: 1. Why was this account flagged? "I don't have that information" 2. What can we do to get this fixed? "I don't have access to that information. 3. Who does? "I don't have access to that information" 4. What can you do about this? "I've escalated your case. It's being reviewed."

I should mention at this point that I've been running this business since 2016, my customers have been more or less the same since then, and I've had (back when it was apparently possible) several phone conversations with Stripe staff about my business model. They know exactly who our customers are and what services we offer, and have approved it as such.

After a week of templated email responses and endless anxiety, we finally got an email from Stripe letting us know that they had reviewed the account and reactivated it. We never got a reason for why any of this had happened, despite asking for one multiple times. Oh well, still good news right? Except nope, this was only the beginning.

This morning I woke up to an email that about 35% of my client accounts had been deactivated and were "Under review", the kicker here being that one of those accounts is the same one they already reviewed last week! This is either the work of incompetent staff or (more likely) a bad algorithm. No reasonable human could make this mistake after last week's drama.

So currently, my product doesn't work for 35% of my customers. Cue torrent of pissed off customer emails.

And the best part is, this time I have an email from Stripe this time: Apparently these accounts are being flagged, despite the notes on our file, and despite the review completed literally last week, as not in compliance with Stripe's ToS. They suggest that if I believe this was done in error, I should reach out to customer support. Oh, you mean the same customer support that can't give me literally any information at all other than "We have a team looking into it"? The same customer support that won't give me any estimates as to how long it's going to take to put this fire out? The same customer support that literally looked into this a week ago and found no issues!?

I feel like I'm going crazy over here. These accounts have hundreds of thousands of dollars in them being held hostage by an utterly incompetent team / algorithm that seems to lack any and all empathy for the havoc they wreak on businesses when they pull the rug out from under them with no warning, nor for the impact they have on customers when they all of a sudden lose all ability to make money. And all that for an account that has been using Stripe for nearly 7 years without issue!

This goes so far beyond "customer support declining at scale." If lack of customer support means that critical integrations start to fail, that's not a customer support failure, that's a fundamental business failure.

Show context
orionint ◴[15 Sep 22 17:04 UTC] No.32855106[source]▶
Used to work for a “high risk” payment processor, we inherited tons of accounts that were terminated by Stripe, Square, and PayPal. Here’s one small bit of inside info that may help the newer businesses out there:

Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process. Underwriting means they look over the business model, financials, etc and make sure the business is an acceptable risk, not doing anything illegal or against their terms, etc. So you’re more likely to be declined initially, but if you’re lit up, you should be good for the future because the underwriters actually saw the deal and approved it.

While I haven’t worked for these other companies, a lot of experience seems to show that Stripe, Square and PayPal operate differently: they light up ANYONE, and then only underwrite when the account hits a critical threshold of revenue. So it’s easy to get an account there, but if you scale up, that’s when you’ll be scrutinized and potentially terminated. It’s a very unethical practice because it ends up hitting businesses at the worst possible time, when the termination or suspension causes a huge financial hit.

So basically, always have a backup processor and use these web based services at small scale to prove out your model, but NEVER rely on them as your sole payment solution.

replies(18): >>32855209 #>>32855229 #>>32855413 #>>32855475 #>>32855511 #>>32855624 #>>32855781 #>>32855816 #>>32855838 #>>32855852 #>>32855879 #>>32856102 #>>32856591 #>>32856799 #>>32859022 #>>32859240 #>>32860210 #>>32860907 #
joecot ◴[15 Sep 22 17:50 UTC] No.32855838[source]▶
The difference is between the company having their own merchant account with a bank (which is what most large companies do) using an online payment gateway, and not having one and leveraging the processor's instead (which is what Stripe, Paypal, etc provide). When you apply for a merchant account you get that approval and underwriting, but with a hefty application fee for obvious reasons. If your payment gateway shut you down, you can just switch to a different one, but there'd be little reason for them to do so. Your bank is much less likely to shut you down, because you were preapproved. The main reason would be for high fraud/chargeback percentages.

When you use Stripe or Paypal or similar, you don't apply for your own merchant account. You make transactions using their merchant account. If there's a fraud or chargeback percentage issue, the banks will have a problem with them, not you, but it also means the service needs to be proactive in policing their clients so the banks never come after their merchant accounts.

When starting up a company, use a Stripe or a Paypal to get up quickly, but probably ramp up to using multiple quickly, so you have backups. As your revenue increases, apply for a merchant account and move your transactions over to that. There is an upfront cost, but the processing fees are significantly cheaper, and no one will pull the rug out from under you without quite a bit of correspondence. Even when using your own merchant account, you can find processors who will handle all the credit card input and transmission on their end instead of on your site, which greatly limits your PCI compliance requirements. Regardless, when you build your service, abstract the payment process such that you can easily add or switch providers. Don't be married to a single one, because at the least you should be switching to a merchant account when the application fee is lower than the transaction fee percentage difference.

Source: I also worked for (and was the principle developer of) a high risk payment processor, providing a processing gateway for individual merchant accounts serviced by an ISO. We tried to look at becoming an IPSP (I think that's the acronym), letting customers leverage our merchant accounts like Stripe or Paypal do, but it was significantly more work and process with credit card companies than we wanted to deal with.

replies(5): >>32856208 #>>32857084 #>>32857827 #>>32859270 #>>32860674 #
hartator ◴[15 Sep 22 18:18 UTC] No.32856208[source]▶
Interesting. What will be the provider you recommend? Any local banks?
replies(3): >>32856378 #>>32856892 #>>32857826 #
tough ◴[15 Sep 22 18:59 UTC] No.32856892[source]▶
I think the best solution here, is add a payments orchestration solution to your stack.

There are others, I know of this spanish startup integrating with stripe.

In this way,you can have both your bank TPV/ Payments and Stripe working alongside, if any fails just put the other, or the one giving better prices by default, etc

https://monei.com/es/features/payments-orchestration/

replies(4): >>32856978 #>>32857762 #>>32859002 #>>32866122 #
joecot ◴[15 Sep 22 19:05 UTC] No.32856978[source]▶
If someone uses WooCommerce for their store, they have 79 different payment integrations, including Stripe, Paypal, Amazon Payments, along with merchant account gateways like Authorize.net. Some of them are paid extensions but rather cheap considering the use.

https://woocommerce.com/product-category/woocommerce-extensi...

replies(2): >>32857527 #>>32858338 #
tough ◴[15 Sep 22 19:45 UTC] No.32857527[source]▶
What Im talking about is to add another abstraction layer, so you can have both payment processors and decide which use on the fly, both integrated with any ecommerce framework you use
replies(1): >>32860170 #
1. bigiain ◴[16 Sep 22 00:02 UTC] No.32860170[source]▶
You're still going to have some grief is you sign up 2 years worth of customers to recurring subscription via Stripe and then have them pull the rug out from under you. Sure you can switch to your backup processor(s) for new customers, but you'll need to go back to all your existing subscription customers and ask them to re sign up to their recurring subscriptions with the new processor.

Its much harder to engineer a payment abstraction layer with recurring payments where you're not relying on Stripe's subscription features that are not migratable to another payment processor.

replies(2): >>32860773 #>>32861067 #
2. __d ◴[16 Sep 22 01:16 UTC] No.32860773[source]▶
When building out your business, you need to look for possible points of failure, assess the risk of each point, and then consider mitigations.

Payment processing is a possible point of failure. Chances of it failing? I think anyone who's read HN/Reddit/etc would have to evaluate the chances as fairly high. Cost to the business of it failing? Often extremely high.

Having done this analysis, you can look at mitigations: sign up with both PayPal and Stripe, get a merchant account, etc.

Then build the redundancy into your system. Yes, this probably means you cannot use the fancy features because there's no good cross-provider abstraction. That's the cost: you might have to implement recurring transactions yourself.

This happens over and over again. Your individual business is worth basically nothing to your cloud provider, your payments provider, your CDN, your domain registry, etc. They do not care if it breaks.

You have to have redundancy for anything you cannot operate without.

3. noisy_boy ◴[16 Sep 22 01:50 UTC] No.32861067[source]▶
Maybe the abstraction can be a selling point for your customers. They can sign-up for the recurring Stripe subscription but it comes with the risk of suspension. If they are ok with it, atleast they can't claim "I didn't know this" if/when it happens (this risk can be included in the contract to deal with executives leaving/"amnesia"). Or they can also have redundancy, which of course costs extra but can be thought of as an insurance and the abstraction does the rest.