←back to thread

Stripe has decided to nuke my entire business

1624 points yaythefuture | 7 comments | 15 Sep 22 16:33 UTC | HN request time: 1.716s | source | bottom

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
brightball ◴[15 Sep 22 17:08 UTC] No.32855155[source]▶
Stuff like this is why I think a business should have a system that abstracts away the payment processor.

I use Stripe for invoices, but I can easily send an invoice through another platform if needed.

For processing transactions on the web, I would always lean toward using a service like ChargeBee that allows me to setup multiple payment gateways.

Getting off the ground quickly is one thing, but the moment that you have reliable revenue is the moment that you need to put some serious emphasis on redundancy across your business to plan for disasters, outages, etc. It's worth it to pay the fees to maintain a 2nd (or 3rd) payment processor once you have that type of revenue coming in.

replies(8): >>32855295 #>>32855442 #>>32855463 #>>32855474 #>>32855479 #>>32855597 #>>32855655 #>>32855991 #
BiteCode_dev ◴[15 Sep 22 17:17 UTC] No.32855295[source]▶
And if ChargeBee bans you, you are still dead because that's a single point of failure. No, you should have several payment processors, and rotate them regularly to check they work.
replies(4): >>32855332 #>>32855344 #>>32855987 #>>32865985 #
eropple ◴[15 Sep 22 17:19 UTC] No.32855332[source]▶
It's been a while since I dealt with this side of ecommerce - how can you have several payment processors, and rotate them, without having to handle card data yourself? (Most folks aren't really equipped to do that.)
replies(3): >>32855404 #>>32855523 #>>32856036 #
1. yamtaddle ◴[15 Sep 22 18:04 UTC] No.32856036[source]▶

    display_cc_form_that_handles_cc_data_so_we_do_not_have_to() {
        which_one = random_number(3)
        switch which_one {
            case 1:
                display_authorizedotnet_form()
                break
            case 2:
                display_stripe_form()
                break
            default:
                display_paypal_form()
        }
    }
Plus the same integration work for each one that you'd have to do anyway (which may be little or none if you're using a platform that integrates all of them via plugins or settings or whatever)

Like maybe don't literally randomize it request-by-request, but that's how you'd be ready to use multiple processors, and you could do something a little more complex to, say, rotate which one you're on every Wednesday, or whatever. Or just have it ready so a one-line code change or config toggle switches which one you're on (that's only worse because if something's not used frequently in prod, there's a good chance it doesn't actually work, even if it once did)

replies(3): >>32856121 #>>32856296 #>>32857787 #
2. pc86 ◴[15 Sep 22 18:12 UTC] No.32856121[source]▶
It's been a long time since I've worked in eCommerce but at my last ecom role we used two payment processors and simply stored the card data with both for every customer, and the relevant IDs in the customer record in the database. Whenever anything got charged we'd check which processor we were supposed to use and off we went.

Yes this has an increased cost if your processor charges by number of customers, but I don't think that's particularly common - these two were just revenue + monthly fee.

replies(1): >>32857047 #
3. PeterisP ◴[15 Sep 22 18:24 UTC] No.32856296[source]▶
The problem is with recurring payments. If you used this approach and 1/3 of your customers were initially billed through Stripe, then if Stripe bans you then you can't charge the next month's bill through something else because you don't have the stored data for it, you have to ask them to re-enter data in another processor's system.
replies(1): >>32856985 #
4. yamtaddle ◴[15 Sep 22 19:06 UTC] No.32856985[source]▶
Another wrinkle, in practice, is that you can often negotiate significant discounts on fees, based on volume, if you've got enough of it. Yes, including with Stripe and other places that have fairly-transparent public pricing—the big-boys don't pay those rates, they pay lower ones negotiated with a sales rep.

Splitting up your payments reduces your volume with each one, which can mean you're paying higher rates overall. Or, if you go the "keep an unused alternative on standby" route, you'll likely at least have some initial traffic that pays higher public-pricing rates until you can convince them to give you a better rate, and put it in effect.

Still might be worth it as a kind of insurance premium, but it's something to consider.

5. exhilaration ◴[15 Sep 22 19:09 UTC] No.32857047[source]▶
Great solution, I wouldn't have thought of this. Did you ever get complaints about the charge description looking different month to month, or did both processors pass the same description to the customer's credit card?
replies(1): >>32857674 #
6. pc86 ◴[15 Sep 22 19:57 UTC] No.32857674{3}[source]▶
I don't remember for sure (this was pushing 10 years ago and early in my career), but I don't recall any complaints of that type.
7. eropple ◴[15 Sep 22 20:06 UTC] No.32857787[source]▶
This isn't "rotating payment providers", though, this is sharding customers across them. Which may be a good idea, insofar as it could reduce your blast radius, but it doesn't allow for portable customers--which seemed to be what the GGP was implying.

'pc86 has an interesting solution in a sibling comment, but I don't think you can do this across the high-touch providers, eg Stripe+Paypal.