> They're great for big business at scale

> They are wonderful for big business

I (sadly) completely disagree with this. There are still so many basic things they don't expose, and it feels like you're fighting an abstraction designed for a start-up that doesn't want to think about the complexities of payments at all. For example, you have to fight a battle to get the card IIN exposed to you. There's no way to see the electronicCommerceIndicator (ECI) for Wallet payments (it clearly has it, since it's shown in the dashboard if you dig deep enough, but it's kept from you). For their Direct Debit integration, they apply limits on the payment amounts you can initiate, but there's no way to actually see the current value of what these limits are. The same Direct Debit integration also doesn't let you customise the payment references used (GoCardless lets you do this to identify e.g. individual invoices on customer bank statements).

Some of the APIs clearly haven't been thought through - e.g. for disputes you can't programmatically retrieve the evidence submitted by the card issuer. Which means you can't build any sort of sensible custom integration for handling disputes. And besides, they don't even support pre-arbitration (which the card issuers know about and take advantage of frequently because they know their decisions outwith the card scheme chargeback guidelines cannot be challenged effectively).

Their Google Wallet integration is worse that Braintree's and doesn't support the web-based flow.

There's not nearly enough visibility when things go wrong, particularly with their 3DS integration (which was failing for Samsung Internet browser users for us, and we had to fight to get looked at - nothing ever got published on the status page despite the fact this significantly affected your chances of securing liability shift) and you have to escalate via an account manager to get any sort of useful support case response.

Having done a major migration with Stripe, at a startup, I disagree.

They have lots of products, but you don't need most of them and can ignore them. What's left is, in my experience, the correct amount of complexity. We looked at Braintree, and it was just missing things that we were legally required to support, we looked at Judopay and it was... lacking (a nearby founder describe Judopay as treating payments like a hobby).

If your business is just ecommerce and you can use Shopify instead, sure, do that. If you just need to take dumb payments, just use Stripe Checkout. But if you need any control over your payments, Stripe is the only good option for startups. As you grow it becomes easier to justify more complex integrations such as Adyen, Klarna, etc, but Stripe is definitely the best starting place I've seen.

Huh? Stripe is still the easiest payment provider to build a subscription on. The complexity with payments does not come from APIs. It comes from payment types, regulations, and the need to avoid losing customers. That doesn't change with or without Stripe.

He is right, reading the docs you have no idea which events leads to what. Nowadays with llm's it's easy before that I still dont know which events mean what.

> Having done a major migration with Stripe, at a startup, I disagree

Initial integration is very simple and developer-friendly. The complexity comes later.

So much this.

Releasing two MAJOR SDK versions with breaking changes in a single week doesn't help either. [1] I dread every time they release a new SDK version because for me it means only more work for zero value.

I've got so incredibly tired of their constant flow of "innovation" in the API and SDK that I have finally gave up and created another SDK for Stripe from scratch: https://github.com/egorFiNE/simple-stripe-sdk (not yet released)

[1] https://github.com/stripe/stripe-node/releases/tag/v21.0.0 and https://github.com/stripe/stripe-node/releases/tag/v22.0.0

> Stripe APIs being simple and easy is a meme from the 2010s. It isn't anymore.

I'm working with Stripe subscriptions at the moment for a charity taking donations via their website. The subtle differences between subscriptions done through Stripe checkout and subscriptions set up yourself using Stripe elements are by turn infuriating and frustrating.

The documentation is geared towards people using checkout. Stripe's own AI help could find us a bit of information which going through the documentation didn't give us, and it even struggled to find the reference in the docs for it.

One product, two different ways to use it, and slightly diverging feature sets between the two. Argh!

> If you just need to take dumb payments, just use Stripe Checkout.

Could not agree more. Offload as much complexity (receipts, invoices, tax, customer info, etc.) to Stripe as humanly possible in the beginning. Don't build for edge cases or UX polish. If people want your product, they will buy it.

and then without knowing it you are paying 1000's a month to stripe

This is kind of the tradeoff you need to make when launching a product though. You cleave off some of the product's margin & send it to a third party so that you can get the thing launched. If it's unsuccessful, that's fine, you'll pay no money to the vendor. If it's successful..? Great! Now you can afford to pay someone to build a checkout that doesn't cost me thousands a month in fees.

Stripe takes 1.5-2.5%, so if you're sending them 1,000s a month, your revenues from that checkout are approaching the $millions p/a. Certainly enough to hire an expert in the domain.

This means you’ve done everything absolutely fucking right

It costs much more then that, that's their feeds on top of CC, conversion etc. at 20K mrr you are easily paying 1k p/m in Stripe & Processing fees.

thats a bit my point, you get there at around 18-20K mrr already

How is that different than any other payment processor? Interchange isn't free anywhere

Fair point, just saw your other comment.