We use Stripe as our payment processor for normal card payments. They just sent us a notice asking us to "link our bank account" to Stripe. (It's an "ask" but I don't think that they're going to take no for an answer.)

What they're looking for is ongoing access to our bank account data, including current and historical balances, full transaction history, and account metadata. They explicitly say this data can be shared with third parties. This goes well beyond traditional payment processing and is closer to applying for a loan or credit product, except it's being framed as a general account requirement, and perpetually ongoing.

It's kind of insane, tbh. We've signed up with PayPal/Braintree and Authorize.Net and are thinking that we might make the switch next week.

Stripe owes me 3k for over 3 years and refuses to issue the payout based on their tos, without specifying the concrete issue. They stopped accepting new tickets from my account, and I've no way to contact the them. Get far away from these scammers.

Don't agree to dumb contract terms, nor fail to push back/negotiate over-reaches. I would not say this is representative of the Stripe that most know. We can expect companies to employ aggressive sales teams and business is often about extracting the most possible, especially at "enterprise" level.

Your "we had no idea" "advice to others: add redundancy to payments stack" is what, supposed to be sage advice? It's sort of basic SOP.

If you guys agreed to the gouge and are now playing victim, are we supposed to cry for your stupidity? I'm sorry. Not sorry, it's business. Not saying "stripe sales are right" just "you get what you sign up for". Dont' be a fool then come looking for sympathy and blaming, you exp[ect the competitive marketplace to grant you passage and add gold with no loss? Bah! Double bah! Triple humbug!

Your post may curry favor with devs (those innocents, those pure-of-heart) but those "at the corp level" will not be so easily fooled, deceiver!

I'm only slightly joking.

Stripe has become shitty for big and small players over the years. Small guys get screwed and just plain scammed, big players just push and pushed into higher fees. Have seen it in many projects as a freelancer.

You can maybe use them for a quick prototype because the APIs/SDK just work well, but for anything serious look for alternatives.

Stripe is the Hetzner of payment processors.

Given that you are processing that much volume, wouldn't it make sense to explore interchange plus pricing with a processor that connects directly to the card networks? I don't know much about the car rental business, but my experience has been that they typically require credit cards rather than debit cards. The ratio of debit to credit card usage obviously makes a big difference given that average credit card interchange cost hovers around 200 basis points while debit is closer to 50 basis points. If most of your transactions are credit card, then you're kind of stuck with the higher interchange rates even before Stripe adds their markup.

At my company, we started off with Stripe since the API's make it very easy to get started, but since then we have added backup integrations with Adyen and Fis. Stripe API's are still the gold standard, but as you have experienced, that vendor lock in limits your options when they decide to jack up prices.

For businesses that do recurring payments/subscription, one important consideration when you get started is whether you can port out the tokenized card data if you do decide to move to a different processor. Definitely don't want to have to ask subscribers to re-enter their card details because the payment details they provided via Stripe cannot be ported.

At your size, I would think bringing payments in-house would be financially worthwhile. I worked at a company doing less than $1B in revenuesand we had our own payment processor integrations. It requires some work in each country/region. In the US our partner was Chase.

With that much revenue, maybe it's time to look into your ratios of payment processing method being used.

For example, if 90% use Credit card, go with a simpler and cheaper payment provider and implement a mechanism that switches between them based on some frontend configuration.

I've worked for a company that they've essentially done that.

I know you might then need to handle having two places where you have invoices etc, but for the amount you are transactioning, it might be the right way to go.

This isn't important only to reduce how much you pay, but your lock-in and dependency on them, otherwise you have no leverage on those negotiations.

Your pain, their profit!