Stripe is wrongly suspending accounts | Hacker News Reader

Stripe is wrongly suspending accounts

213 pointsnerder92137 comments

context: We are a SaaS for martial arts academies located in Europe. We are using Stripe for our payment integrations and all our academies have their own account connected to our platform using Stripe Connect (standard), since the last couple of days 2 accounts have been suspended due to "suspicious activity".

Stripe has implemented a new fraud detection system that is clearly flawed here. These customers are small gyms in local areas with accounts active for the last 11 months without no issues whatsoever, now all of a sudden they were both suspended (and payout blocked) due to suspicious activity. The suspicious activity is disputed payments, which for SEPA DD (the main payment method used) can simply be that the customer has no money in the bank account.

The Stripe response so far has been vague, to say the least. Has this happened to you?

I believe Stripe is a very good product and we have had no issue with them until now, but this situation is deteriorating trust very fast. Do they literally have the power of taking your funds hostage over a "suspicious" fraudulent activity that is clearly due to a bug in their automatic detection system?

Please let me know if you know someone that can help us here

View on HN

Monthly HN Stripe customer support thread

Yes - more often, in fact. Here are a few of the recent ones:

Stripe account suffered a card test - https://news.ycombinator.com/item?id=33688298 - Nov 2022 (33 comments)

Ask HN: Stripe holding funds for 120 days for no reason - https://news.ycombinator.com/item?id=33299222 - Oct 2022 (114 comments)

Don’t use Stripe. I am trying to save you from my mistake - https://news.ycombinator.com/item?id=33254485 - Oct 2022 (21 comments)

Ask HN: Why do people come to HN for Stripe resolutions? - https://news.ycombinator.com/item?id=33140798 - Oct 2022 (108 comments)

Ask HN: Have you noticed an increase in the number of Stripe Disputes lately? - https://news.ycombinator.com/item?id=33123756 - Oct 2022 (16 comments)

Ask HN: Can I avoid being nuked by Stripe? - https://news.ycombinator.com/item?id=32856237 - Sept 2022 (31 comments)

Stripe has decided to nuke my entire business - https://news.ycombinator.com/item?id=32854528 - Sept 2022 (679 comments)

---

I think we have to start treating this as a MOT (major ongoing topic) and do something about all these follow-ups [1]. I've delayed making this call because of the core principle that we moderate HN less when YC or a YC startup is part of a story [2]. But less does not mean not at all. At some point we have to remember the other core principles of HN moderation too, such as that repetition is bad for curiosity [3].

I don't mean that these incidents aren't real—and obviously they are super important to the users who are personally affected. But from an HN point of view, the question is "is this story new/different enough to support a substantially different discussion", and here the answer is clearly no.

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

Indeed. With the nice addition that now the posts are biased towards small companies that still have not figured out that going single-vendor for online payment is a terrible idea.

Stripe needs to implement real customer support.

When it comes to Stripe, what choice do small businesses have? Tokenized Payment details are not portable, I can't take a saved debit or credit card in Stripe and slide it over to a First Data or Tsys account at whim.

I'm fine with integrating another API (hell, InvoiceNinja already supports most payment gateways), but changing processors when you rely on stored payment details is extremely risky business.

Stripe charges a premium transaction fee for being a no barrier to entry processor, but when they decide to underwrite your account and fail to do so, you end up SOL with a locked account.

Maybe this is a good place to ask the question:

1. Why is stripe a seemingly preferred payment processor for HN crowd? 2. Is there no ( edit: real ) competition or is the competition similarly bad ( or somehow worse )?

edit: Instead of replying individually, I decided to edit this section. Thank you everyone for the background(s). It does answer a lot of the questions I had. I perused their site and I can absolutely see the 'dev first' principle in play.

Once upon a time, it was like a breath of fresh air. Originally pitched as a dev-first payment API, it was vastly easier to get up and running than other options at the time. In recent years it has suffered under the weight of its own success. The simplicity and ease of use it once promised has been buried beneath a now-bloated and obtuse API. The user interface has struggled to keep up with the feature creep and it too has become a challenge to navigate and interact with. The documentation, once considered an industry-leading example of how to write and present such things, has mutated into a frustrating byzantine mess that's riddled with contradictions and obvious omissions.

As an early adopter and someone that was once very fond of this company and its approach to things, I'm disappointed to see the direction it has gone.

Is it that bad? Is anyone doing it right?

It's following the trend of nearly every startup ever made.

* Newcomer trying to gain traction. They'll do just about anything to make and keep customers in the name of top-line growth. This includes expensive labor and human costs.

* Grow into a successful business. Start feeling the pains of "infinite growth".

* Realizing revenue can't grow indefinitely, they start cutting costs and see how long they can ride the coat-tails of success.

* The small/cheap accounts start gaining wind that customer support sucks, so they start looking for something else. The big accounts are likely still happy since they're large enough to justify a handler who will make them happy.

* A new startup lurks in the background, likely to follow the same process.

It really just comes down to whether or not the incumbent realizes it's only a matter of time before the major accounts start leaving too.

The Stripe backend and API documentation is incredible with the amount of data and logs they provide. Never seen any service that got it so right.

It does have its quirks, like searching for a stripe customer id won't give you what you're looking for but searching for the amount will.

Mollie on the other hand has like 2 pages where you can see your transactions.

Strips isn't perfect but they're absolutely the best.

And they do have customer support if you really need it.

From a development perspective, Stripe is by far the fastest/easiest to integrate with, the most featureful, and has the best documentation. As I understand it, other payment providers will often require underwriting up front before you can even begin, which can take a while.

Where I am from, Stripe and PayPal seem to be two of the bigger options, apart from regional providers (e.g. provided by banks).

From what I can tell, Stripe's documentation is generally regarded as nice, just have a look at some of the examples: https://stripe.com/docs

That said, PayPal also seems to be okay, for the most part: https://developer.paypal.com/home

Edit: is it just me, or does PayPal's UI kind of break, when you choose the "horizontal" layout in their integration builder? Example: https://imgur.com/a/IvBdYeI

Both of them seem to have some scary stories around them, in regards to frozen funds or closed accounts, but what are you going to do about that? For many, there aren't many options, since any of the other platforms out there are likely to have similar power over your finances if you go with them.

One reason might be that the founders and some key employees are active on hn. Also, they have services like Atlas that may help the typical HN crowd.

Stripe is a ycombinator company

monthly find stripe edwin's reply thread

At this point, I don’t know how any founder on HN doesn’t make their business…

1) Multi-cloud

and…

2) Multi-payment processor

These stories are horrifying. These cloud and payment processors simply do not care. They print money and provide no human support. Any venture that I make in the future will be cloud-agnostic containers on several cloud providers with at least two payment processors handling an even share of the load. Double work be damned. Stripe and GCP simply do not care.

My most important overhaul for our business was abstracting over payments and ensuring we weren’t dependent on any one processor for online checkouts. It doesn’t matter who you are with or how flexible they are, sooner or later, for logistical, account, network, or other issues, if you have only one payment provider it is going to be unavailable and you’re going to be losing money.

If you’re on the .NET stack, our abstraction [0] is over PayPal, PayPal credit card, Stripe, ChargeBee, CoinBase, Amazon Payments, and other providers that have since been replaced with no-op exceptions because the payment processors have gone under.

[0]: https://www.nuget.org/packages/NeoSmart.Payments/

Reminds me of PHP's Omnipay

https://github.com/thephpleague/omnipay

It’s nowhere near as comprehensive, of course. It only features the providers we’ve used ourselves.

I think abstracting over payment APIs has gotten so much more difficult this side of 2014 or so. They’re doing all they can to achieve consumer lock-in and trying mighty hard to each offer their own custom services that they try really hard to convince you need and can’t live without, and invariably there might be something in there you want to support in your abstraction, sometimes necessitating cascading architectural changes. This is probably the third “major overhaul” of the abstractions we’ve written as a result.

Omnipay does not support Stripe SCA and is basically abandonware.

Or rather, get a contract with your cloud provider and payment processor that clearly lays out the terms under which they will and won't suspend you.

My previous company had a business contract with GCP and so wouldn't be cut off for, for example, a dodgy employee account tied to the business in some way.

It's amazing how many people put their email and credit card in a form, pay sticker price for a service, and have their entire business depend on it. The terms of those contracts necessarily have to protect the service from all sorts of malicious users who just click sign-up. Talk to a person, get a contract, and the whole conversation changes (and yes GCP has account managers for this).

This x 1000!

Do kids these days not realize you can negotiate anything and everything with your vendors/suppliers/partners?

Yes, most SaaS companies LOVE it when you sign up for one of their standard plans, using THEIR standard T&C's, and standard payments.

But, DID YOU KNOW, if something is critical to your business, you can negotiate directly with pretty much every business on the face of the planet, and if your spend is large enough, or you're willing to pay, you can negotiate anything????

It's nuts, I know :)))))

How much do you need to spend to negotiate with Google?

Short generic answer for all SaaS/cloud: remarkably little. If you're a legit business, who can make payments as a business (rather than on a personal card), and have any small amount of spend, you should have no problem getting a basic contract that provides you some reliability for your business.

Negotiating significant discounts needs a bit more work, commitment, or growth story. Discounts tend to scale with spend.

(Disclaimer, I now happen to work at Google, unrelated to cloud, but this was my experience at my previous employer)

I got decent support from actual human beings for Google Cloud even when spending ~£100/monthly.

Not sure if this has changed recently, but this was in about 2018/2019.

They might like you being on their basic contract and high sticker price, but you know what they love even more? Having a person they can do sales calls with. It's amazing how much you can get out of companies just by, you know, talking to them.

How do you make a SLA were the compliance guy doesn't randomly kick you off, because he found your dark theme scary or don't understand your business model?

How big would a business have to be for this to work with a company like Stripe?

Getting a better contract, probably not big at all. That's more about the company being more verified than someone just signing up a landing page. Negotiating a better rate? I really don't know. We did it at ~6 figures per year in the very early stages of Stripe, but we were a UK beta account for them. I believe we continued to renegotiate at 7 and 8 figures per year, but we already had that relationship.

By all means use another payment provider as leverage to negotiate better contracts and rates, but I think it's unnecessary from a business reliability standpoint until you're very big and Stripe's downtime level (very small) is a material business risk. Spoiler: almost no one is this big.

So how do you get Stripe to send you a signed contract?

Presumably, you'd have to start by talking to their sales people. There's a button near the bottom of their home page that leads to a sales contact form: https://stripe.com/contact/sales

Admirable, but neither of these are light lifts. Most startups are potentially better off just gambling they won't be in the %0.1 that get shut down due to big company shenanigans.

Any company that doesn't take steps that basically amount to insurance - and insurance is "just in case shit happens" - deserves the pain when the unthinkable happens.

With backups - onsite, offsite, security, code reviews, pen testing, separate environments for testing, etc... all things that take time and aren't "light lifts".

If you skip and don't cover your bases? You're going to fall and you'll deserve the broken leg - or worse - when it happens.

This is a terrible attitude to have, some startups are cobbled together by 1 or 2 people and get off the ground, yet you are expecting them to have a team of at least 12 and additional retainer resource of lawyers and similar otherwise "they deserve to fail"?

In the real world, many businesses aren't created in the Silicon Valley by established founders and friends with VC funds, who can afford the time and cost to have all this.

Edit: To clarify, I am not saying that the things suggested are unimportant or not vital to an established business.. But that the bottom line for a brand new business with very few people involved is to survive and be stable enough to have the change of introduce backing on/off site, distaster recovery plans, paying for pen testing, security consultants, dedicated QA, etc.

Whether you're 1 person or 10,000... if you skimp? you're going to get bit where your weakest.

I didn't say "they deserve to fail"... I said karma will happen. Deserve or not? If you don't have "insurance" then you'll pay eventually.

If you don't have backups? Good luck when the Cyrpo Locker hits. if you don't have redundant hard drives? Good luck when the click of doom hits you.

If you only have one payment processor who is known to randomly lock accounts without recourse? Then it's a matter of time until it happens to you.

I do get that shortcuts have to be made when starting... but those short cuts don't sidestep reality.

Do not take this advice.

Why? Can’t you have a dormant or lightly used gumroad account integrated into your site/app. It’s not trivial, but could be worth it. Most frameworks have these services already integrated.

How would Gumroad prevent this? Hell Gumroad has an entire FAQ devoted to account suspensions so it's clearly an issue for them too.

An alternate processor while stripe figures out the mess - revenue keeps coming in.

Gumroad has their own failures, but if ANY issue with payment processing is intolerable, don’t bother running a business.

In this case, it’s likely that they have set up recurring SEPA debit payments. Changing the payment provider won’t keep the revenue coming in - it would require every customer to sign up for debit again. And when stripe figures out the mess, you need to consolidate the two providers or you’ll end up debiting twice.

I wonder of a health club is preventing account cancelation, playing games, and end users are doing chargebacks.

Isn’t Gumroad runs on top of Stripe itself?

Looks like that might be the case. I might have been confusing Gumroad with Braintree. I was only attempting to give an example, not advocating for one specific processor.

A dormant account that suddenly gets a large influx of new users sounds like a great way to get auto-banned by some stupid automated process as well, just when you most need them to work :-}

Recurring payments have massive lock-in - typically there is no way to switch payment providers without requiring the user re-enter their payment details.

You'll typically lose ~half the user's each time you do that...

Startup idea: wrapper around payments providers.

And then the wrapper company gets massive and starts wrongfully suspending customers...

Why the wrapper needs to be some open source software not owned or depending on anyone.

We just need a payment-wrapper-wrapper company! (We have to go deeper!)

New challenge unlocked: design your application in an wrapper agnostic way to avoid getting locked out when the wrapper service bans you.

There used to be one (Spreedly) but then it went out of business or changed models so I had to convert everyone anyway!

We use VGS to tokenize credit cards. Makes it much easier to switch payment provers.

Better than losing all users though…?

Being multi-payment processor still doesn't protect you fully. We had separate instances where Google In-App Purchases and Stripe halted payment processing until we were able to escalate via friends who worked at those companies to fix our issues. Customers on Stripe subscriptions through Google aren't going to all of a sudden switch. I guess it does limit blast radius somewhat, but it still sucks. It also forces us into the lowest common denominator of features supported across platforms (e.g., can't run a price reduction and an increased free trial period at the same time because of one payment provider).

The reason is simple. Cost. It makes everything a lot harder (and thus costly) at a time a startup can afford neither.

I've been a founder and worked founder level for a long time.

Unless uptime or payment processing are core to your business (newsflash, they're not for most startups), this would be a waste of time and a velocity drag on _everything_ we do in the future.

Way, way more important to get traction than worry about theoretical risks.

> Multi-payment processing

I work for a company the does exactly this [0]

It’s amazing to see companies who not only optimize their business logic. But also their payments and how that generates direct revenue. Being able to switch payment providers at the push of a button has really opened up opportunities for growth and derisked a critical part of their business.

[0]: https://primer.io

Does it have a multiparty payment solution like Stripe Connect or is that per method, nothing to do with Primer?

On multi-cloud, it's rather don't be GCP only. On payment processors, used to be don't be just PayPal, then not just Stripe, and in general, yes, you want more than one.

In the late 90s we wrote code to distribute and aggregate fraud checking, card payment processing, settlement accounting, receipt reporting, and refunds across multiple gateways so we could handle mega live event signups. That needs to be an OSS product.

Way more than double the work to integrate two, since you need to define a generic API and product workflow on top of similar-but-different underlying APIs.

In particular payments are a nightmare to generalize. Either they assume directly interacting with the user (do you have your customer enter their data twice?) or you have to collect the info and ensure you capture the superset of fields required (particularly onerous for international) and then have a process for handling KYC/fraud cases on each. Payment routing becomes more complex, each rail has its own timing you need to learn, exception cases, support protocols, and so on.

For cloud infra if you pick your APIs carefully you can make it fairly easy to lift-n-shift (eg using k8s and running your own Kafka) but it’s not going to be trivial if you use hosted services such as RDS, SQS, etc.

IMO you are WAY more likely to die from running out of runway than because of problems with your payment rail. These are bad when they come up, but remember you are seeing the worst cases highlighted here, and not the 99.9(…)% of customers that don’t have business-impacting issues. TANSTAAFL etc.

VPs and PMs focused on updating things that are “concrete” to them like buttons, and logos soak up engineering agency.

Aggregate engineering and customer experience are cost centers.

Our management culture is irreparably broken. Somehow the Linux kernel runs the world without them. Very few CRUD apps out there need a literal people pipeline to copy-paste React deps into git.

We’re missionaries for nation state currency, sharing the wealth we create with our neighbors through make-work tasks. We’re not engineers engaged in craft.

Have not used it myself yet, but Google has something called “Anthos” that seemed like it would reduce the work from 2x on the cloud front...

I can't imagine that existing on the payment front though. Even as a separate startup, a payment processing multiplexer just seems precarious, like “OK my business is now less dependent on Stripe but it's entirely dependent on the availability of this tiny company.”

This is not a new idea -- it's a whole field of infrastructure called "Payments Orchestration". It probably doesn't make sense for small startups, but companies that process more than about $10M+ USD per year can (and do) definitely benefit from multiplexing transactions across multiple providers.

> Any venture that I make in the future will be cloud-agnostic containers on several cloud providers with at least two payment processors handling an even share of the load.

Are you running any businesses this way now? What were the challenges?

Or you could just get your own merchant account for payment processing and do all the diligence and requirements upfront. And you get to talk to someone and explain what you're doing to resolve issues upfront.

How exactly does that help? We had a customer who told the payment processor he's going to be selling X. They were told it's perfectly fine. After a month, payment processor told the customer they found they're selling X and can't sell X using their service.

Due diligence, lol. In fact, the world is just a huge mess, and you have to have backup plans for all the important things in your business, or not care for downtime.

Because merchant account is a contract with you and the bank. You get an individual merchant account that If any card provider doesn't like you, they can ban you. Stripe, you're using their merchant account. If banks ban that merchant account, they ban all stripe customers. Key difference in risk for your payment processor. I have had banks ban my merchant account but my payment processor didn't care.

This is the best argument for bitcoin.

Even Democratic “rule of law” places like Canada can seize your funds for engaging in “politically incorrect” behavior.

Just hope that your startup will make enough to pay for egress.

Are there any integrators that shim out multi payment processors?

EDIT: Did I just leak a b dollar idea? Have fun :)

https://github.com/killbill/killbill

What's the actual "idea" here?

I mean, the answer is obviously yes, depending on what you consider integrators.

A layer that makes it more palatable to switch between payment processors

Can you email me (smca@stripe.com) with more detail? I'll look into this.

We don’t typically comment in detail on individual cases, but we do think it’s important for onlookers to know that we take every single case like this seriously. It looks like what happened here was an edge case involving SEPA payments that resulted in a dispute rate that’s far in excess of what’s generally permitted by financial partners. When we do this, our interventions are partly to protect financial partners/Stripe, partly to protect end customers, and in part to protect the businesses themselves. (For example, Visa will fine businesses that maintain high dispute rates.) This case is actually a bit more complicated still, since you said that you’re using Connect. In these cases, we also take seriously the importance of defending the platform (i.e. you) against users who are trying to defraud you.

More broadly, we work hard to balance the rules of the financial ecosystem, ease of use, protection against fraudulent businesses, consumer protection, and continuity for businesses. We support millions of businesses across dozens of countries and payment methods, and we discover new scenarios every day. We plan to blog about our work here in more detail before too long (including some of our key metrics). If any HNers have suggestions as to what we should include, feel free to reply here. We’ll try to share anything helpful that’s not too sensitive.

Before you edited the answer it said you cannot sustain clients with more than 0.1% chargeback rate. Or 1%, iForgot.

This is all fine when your clients have 1 million sales per month. But in this case they have umm... "To put this into context, we are talking about a small local gym, with 33 active memberships."

You need a better metric than 0.1% or 1% or just turn down small clients? They're just disproportionate support costs anyway so they shouldn't be allowed to run a business online :)

I see no valid excuses here. "we process millions of transactions so we can't provide proper service" no, just like every other buisiness that wants to scale to collecting money from millions of users while only paying tens of employees, profit margin and founder pay is no fundamental excusable reason for doing a bad job at your job.

That makes sense for cards but if most of the payments are SEPA transfers, then it doesn't make that much sense since there's no chargebacks for SEPA transfers.

Maybe the issue is a fraud system designed for cards that's not well thought out for other forms of payments.

This is exactly my point, SEPA DD is by design high dispute because the customer can dispute a payment on a no-question-asked basis over a span of 8 weeks.

This can also happen due to insufficient funds, or as it happens if the mandate you (Stripe) send them is wrong. We previously have an issue with this exact same account where the reason for the disputes was an incorrect mandate and we were refunded for those.

There’s no chargeback for SEPA transfers that are initiated by the customer, but the OP is using SEPA direct debit which is initiated by the vendor and has chargeback.

an exception to that is Bank of America Merchant services. I have 2 clients with chargeback ratio above 3% for close to 5 years now, and processing volume about $1MM a month. I imagine they are simply too small of a fish for BOA to care about their CB ratio. I seen them getting accounts shut down with basically any other processor, most sensitive being Wells Fargo underwriter but somehow they remain open with BOA so maybe its worth a shot?

BOA implements First Data gateway by default these days, so most likely your previous processor is utilizing same solution as well, so less work to switch.

wait you are NOT edwin, who are you?

SEPA payments also support chargebacks. Gyms are notorious for making it easy to sign up and hard to cancel, so the other explanation is that people are upset with some of your gyms and disputing the subscription renewals.

Stripe customer support is beyond useless, so I totally get your frustration, but I would encourage you to get to the bottom of this and verify that that your "insufficient funds" theory is correct by calling the customers with the failed payments.

Hey, @gizmo thank you for your reply, I indeed checked. As I said the account affected here is a local business, they make like 1.1K MRR from the same people forever. I've checked personally the disputes and they are all due to these "insufficient funds", also one issue that happened like 3 weeks ago on the same account was that Stripe was incorrectly crafting the SEPA Mandate and for the reason the bank rejected it.

It seems like their own mistake has caused their automatic fraud detection algorithm to incorrectly flag this account. This is speculation obviously, but with this timing...

Are these insufficient funds on long-standing accounts, or relatively new accounts? It seems like it would be pretty easy for a competitor to target a small gym by signing up several new accounts, paying for a month or two, then emptying all the bank accounts at once, causing transactions to fail. If the gym has 1.1K MRR and charges $100/mo per subscriber (that's what my private gym charges for open gym w/o personal training), you're talking about ~11 transactions per month. Failing 3 out of 11 transactions (27%) would probably trigger automated fraud systems.

To put this into context, we are talking about a small local gym, with 33 active memberships.

This is exactly my thinking process tho. The other account blocked was just starting, had like 8 payments and one dispute and got blocked.

I'm really afraid for our other accounts now, seems like is just a matter of time until they get blocked.

The suspicious activity is disputed payments, which for SEPA DD (the main payment method used) can simply be that the customer has no money in the bank account.

Sudden changes of circumstances like trading for 11 months and then seeing multiple declined payments from multiple parties does sound quite suspicious to be fair. I imagine Stripe have extensive amounts of data about that sort of thing. That's not to say Stripe are in the right here, but I can see why they wouldn't just assume their threat model is wrong based on your word that the payments are valid.

To add another piece of context here, less than a month ago we receive this email from Stripe for the same account:

Hello,

We’re reaching out to notify you that some SEPA Direct Debit payments created between September 26th to October 4th incorrectly show as disputed when they actually failed. We have confirmed this issue is resolved, and SEPA Direct Debits created after October 4th 04:00 UTC will not incorrectly show as disputed. Please note that as SEPA Direct Debit is an asynchronous payment method, you still may see new disputes on payments created before October 4th.

We have compiled a list of all currently-known payments impacted by this issue, which you can download by clicking this link:

We will be refunding any charges for the affected payments and disputes.

We are very sorry for any inconvenience this may have caused. If you have any further questions please let us know.

—The Stripe team

Is speculation of course, but seems to me that their own mistake caused their fraud detection algorithm to go off summing up with the normal disputes that the gym receives (ie: insufficient founds)

A small business nightmare with stripe this year. Given a small online subscription business, we don't have techie 24x7. We started receiving micro-payments from credit cards every other second on our stripe account. We immediately reported to stripe as soon as we noticed, multiple times. Every time same response. We will look into it. We wanted to avoid deactivating and hiring techies to reintegrate again. Eventually we did not get any support from Stripe. So, we did the nuclear option and deactivated stripe all together and also hired a techie to do it as we are not really sure.

Then our real nightmare happened. We are subject to potential dispute fee running to several tens of thousands of dollars. We wanted to avoid disputes and so we requested Stripe to help us immediately refund all the money so we can avoid disputes. They again did not respond to solve. So, we painstakingly manually returned every payment, one payment at a time. Finally they agreed to cover the dispute fee (which would have sunk our company) of whatever was disputed (thanks to them). But they warned us they won't cover next time. uff, how do we even control that.

And then, they briefly suspended our account. And then revoked after some days saying it was a mistake. And then we activated security radar, which basically is blocking most genuine payments now. But, we don't know what the alternative is. Is there an alternative?

This is terrible. I'm going to start looking into alternatives, which is shame, because we initially built around the Stripe API.

We recently had one customer forget to cancel their subscription, and then without contacting us first they filed a dispute for 6 months of charges. That's 6 individual disputes, each with a $15 ($90) dispute fee. We got in touch and mentioned we'd have investigated, found the license unused, and refunded for those months. They contacted their bank to withdraw, but the bank and Stripe are just pushing ahead.

Then our real nightmare happened. We are subject to potential dispute fee running more than $50-80k. We wanted to avoid disputes and so we requested Stripe to help us immediately refund all the money. They again did not respond. So, we painstakingly manually returned every payment one payment at a time. Finally they agreed to cover the dispute fee (which would have sunk our company). With the promise that they won't cover next time. uff, how do we even control that,

And then, they briefly suspended our account. And then revoked after some days saying it was a mistake. And then activated security radar, which basically is blocking all genuine payments now. But, we don't know what the alternative is. Is there an alternative?

We are constantly working on the nightmare that any

'Thank you very much Stripe, for suspending and killing my business accounts for little to no reason.'. [1] [2] [3] [4]

Thank you.

[1] https://news.ycombinator.com/item?id=28085706

[2] https://news.ycombinator.com/item?id=33299222

[3] https://news.ycombinator.com/item?id=23881643

[4] https://twitter.com/zhovner/status/1384568453844066305

This is a B2B service. Do they really demand a "we can terminate at our discretion" clause? Can your lawyers negotiate better terms when you sign up, like 30 days notice and termination only if binding arbitration says the provider can do it?

Had a similar thing happening. Never any problems. Then account disabled.

I thought, well this is Stripe, they’re awesome. I’ll email them. They’ll help.

Well, big surprise. Customer support was just bots and boilerplate answers, after weeks of waiting.

Mentioned my issue in passing on a thread here (I resent having to make a fuss on social media just to get some special attention). I was told to contact one of their people directly. I did that a few months ago. And he actually did email me back. But then he first forgot about my case for another two weeks. And then he said he would look into it immediately, but all I got is a bunch of automated emails asking me to validate my email address and things kind that. I did all of that, but it changed nothing. And my account is still suspended.

I will continue to use Stripe for MVPs and such. But I now consider it a toy solution that can’t be trusted for running a business.

Stripe cut off my revenue and deactivated customer facing payment pages. They did so without giving me prior notice, and I haven’t found a single person to talk to who would know what is going on in almost half a year now.

They’re putting their customers in serious risk of financial losses and potential insolvency. And they do not care, do not help and do not even explain.

That is the inverse of customer obsession. I wonder if the Collison brothers have lost interest in running their business like Bezos did with Amazon a few years ago.

> I will continue to use Stripe for MVPs and such

Can I ask why? Wouldn't inertia see to it that it stays in place in some circumstances? I'd be moving to something else at every stage if it were me

Perhaps you are right. It’s not something I have thought a lot about. It looks good, and I know how to implement it. So I thought for money I don’t actually need it might still be usable.

But you’re right about inertia. There’s a real danger I’d end up sticking with them and hoping for the best, and then being in the same situation again.

Thing is, after having such problems with Stripe, in whom I had a lot of trust, I am very much interested in cutting out the middleman as much as possible.

See, a physical bank would never be allowed to simply turn off my ability to receive money without prior notice. And if they did, I could sue the hell out of them. But with all of these Internet companies, I don’t feel I have that security.

I have heard that the European Union plans to offer their own payment system. So perhaps the government sector will catch up. The idea that one should depend on private sector companies in order to participate in commerce seems quite odd.

Otherwise, these issues have made me a lot more willing to go old school and just send out invoices. That sounds like the 1990s, and surely has its own problems. But at least I am in control.

I am definitely open for suggestions though! Interested in hearing what you would suggest.

I'm sorry you're going through this. I'm sure someone from Stripe will pop-in here and help out. If they do not, you have other payment providers:

- Paddle

- Mollie

- Paypal

Many upstart small businesses will face false fraud inquiries, but you have to roll with the punches and move to a new processor if Stripe is not responsive.

They're using connect, so they're a marketplace (accepting payments on behalf of customers for their customers, and taking a cut). Not sure if any of these support that model (pretty sure Paypal doesn't).

Yes, this was a big selling point for us, we are a SaaS/Marketplace for martial arts academies and part of our business models also rely on transaction fees we get from the payment integration.

We are attempting to support mollie also to enter the dutch market but we are only 2 people writing the code here. :(

How does HN feel about Braintree?

Other than being owned by Paypal, it's fine. The APIs work and are well-documented. A company I worked for used them for ~7 years and never had any significant problems that I recall.

If I recall, PayPal bought them a number of years ago, but I haven't heard of any horror stories from that specific PayPal product.

You should research this more. Stripe is not a good product because this problem is widespread.

Stripe is a fine product; the loudest complaints just rise to the top.

They have an incredible number of customers just going about their business and not experiencing issues like what’s in this thread.

Good advise is always to have a backup processor (similar to ESP). The thing is while initially regular MSP may not want to do business with you, if you get Stripe account in somewhat good standing for 3 months, you will have hard time finding MSP that will not accept you to process. Once you have 3 months with Stripe, which I imagine you didn't start with tens of thousands of dollars in processing day one, get yourself another MSP which should be top priority. Either have your system split 25% second MSP, first the rest, OR if you are unable, at least do few "test" transactions a month to make sure your backup gateway remains open. Without backup sad thing is that its irrelevant whether Stripe had standing or you got suspended as an error - the bottom line is you cannot process and that hits your bottom line.

Hope this advise helps someone going forward.

I have the same problem.

If only there were a system to transfer money between two people that didn't require a trusted third party...

Fed now instant payments will go live in US next year. EU has similar cross country solution in work. Majority of Asia already switched or in the phase.

In India, most purchases go through UPI already which is p2p without a middleman.

It's tough time to be in payments and will only get worse as many custom integration with lending companies break down due to huge losses.

We only need some way to integrate those.

In India, you can pick any payment gateway for UPI. They are easily replaceable.

No payment gateway in India charges for UPI transaction too. So if similar payment system is incorporated in US, I won't expect stripe to be able to charge for it.

The only major functionality these payment gateway provide is checking if transaction went through.

They are wrappers on top of bank APIs such as federal bank.

Anyone can generate a QR code for their payment ID and request payment without needing a gateway but it's manual. Most street vendors confirm payments manually since it happens in person.

Additionally, we have other standardized framework for requesting account information from banks such as RBI account aggregator framework. So you don't need something like plaid to fetch bank statements from all your bank accounts.

Recurring payments are also setup on the bank end as a mandate.

Yes, you will end up using an off the shelf solution but you are not at the mercy of them if you accept UPI only.

You can't transfer money from the India system to somebody using the EU or Brazil one.

There’s an odd juxtaposition between the net negative sentiment towards The Technology That Shall Not Be Named and the near daily “X banned my accounts and my business will never recover please help” posts.

It really is the elephant in the room at this point.

Negative sentiment towards paper cash? Haven't seen any on HN, aside from stories about civil forfeiture.

Impossible, because it's the 3rd party (government) that makes money money. Without a system of law, courts, and and people with guns to back them up you can't have trade or commerce at any kind of scale.

http://www.daviddfriedman.com/The_Machinery_of_Freedom_.pdf ¯\_(ツ)_/¯

And be reversible?

Yes, if the application and its users demand it. Reversibility is possible in peer-to-peer and decentralized payment systems. But not every app needs reversibility and the centralized intermediaries that come with that.

What use case of money transfer doesn’t require reversibility for fraud prevention?

I love credit cards because I can dispute transactions.

Craigslist explicitly tells people selling on it to avoid accepting online payments (like, PayPal) and only work with cash because the online payments are reversible and sellers constantly get scammed. You have to remember that transactions involve two parties, and it isn't somehow always the case that only the ones on one side matter.

The power balance simply isn't always "seller who is selling a large quantity of easily-replaceable items that might be a dud can easily amortize the cost of fraud across all of their payments by high margins"... sometimes it really is "seller who is selling a small quantity of expensive or precious items tends to get scammed by anonymous buyers who abuse chargebacks ".

> ...sometimes it really is "seller who is selling a small quantity of expensive or precious items tends to get scammed by anonymous buyers who abuse chargebacks ".

This. He's right you know.

The chargeback system is rife with extreme abuse, and the banks will always give in to friendly fraud without checking the contents of the dispute. Both the customer and the merchant lose to chargebacks and friendly fraud.

Venmo[1] does not have reversibility. Cash does not have reversibility.

If users really wanted credit card functionality at the expense of its costs, you could build that as a layer on top, without forcing everybody in the system to use it.

And consider, most disputes is not just about the quality of a product. That is handled with regular refunds. Credit card disputes are a lot of times because of fraud or card skimming, which is very often because the system is not very secure to begin with. Secure cryptography can remove a lot of this type of fraud.

[1] https://help.venmo.com/hc/en-us/articles/235171088-Cancel-Pa....

We already have that system - debit cards, cash, venmo, apple pay, etc. What does crypto solve other than anonymization of payments?

Open source, public and permissionless infrastructure for the web. Very different than Venmo which is owned by PayPal and limited to USA, and not programmable, no interop.

about the OP’s thread: centralized services like PayPal, Venmo and Stripe can close your account. Nobody can close your private key, even if you are on a L2 for fast payments you can use the escape hatch to withdraw without possibility of censorship.

Ethereum has ERC20R which is for reversible transactions

You're implicitly trusting the 3rd parties developing the software & protocols you use to send money anyways.

ZK rollup with validity proofs and trustless escape hatches should really be the dominant mode of bridging and storing assets in the future.[1]

To the OP: sorry to hear what you are going through.

[1] See https://vitalik.ca/general/2021/01/05/rollup.html and https://vitalik.ca/general/2022/11/19/proof_of_solvency.html

Seems like the payment processing is monopolised by stripe - Are there any good alternatives to stripe?

> Are there any good alternatives to stripe?

Yes, several. They're nowhere near any kind of monopoly.

Braintree

No way. Braintree was brain dead when i looked into them awhile ago. Despite the flaws of Stripe (and its downward trajectory in quality) it’s still better than Braintree.

Maybe add Mollie.com as backup?

sounds like you need to use https://www.twispay.com/en

twinspay doesn't support SEPA direct debit payments

Just waiting for Stripe to send in that Edwin guy for the 900th time instead of fixing their support

Use monero.

Go Crypto!! There are stable coins that you can use for payments.

Like "US dollars". Those are pretty stable. Still have this problem, though.

Reply on news.ycombinator.com