Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple.
You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should trigger which product decisions, and there is no guidance on which events and states are authoritative or take precedence.
Stripe is no longer the correct shape for small startups. They are wonderful for big business, but startups need something smaller to go faster. Your Stripe integration will slow you down.
Stripe APIs being simple and easy is a meme from the 2010s. It isn't anymore.
They're great for big business at scale, but they lost how to cater to startups.
danpalmer•Apr 20, 2026
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.
wouldbecouldbe•Apr 20, 2026
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.
rrr_oh_man•Apr 20, 2026
> 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.
wouldbecouldbe•Apr 20, 2026
and then without knowing it you are paying 1000's a month to stripe
OtherShrezzing•Apr 20, 2026
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.
wouldbecouldbe•Apr 20, 2026
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.
malfist•Apr 20, 2026
How is that different than any other payment processor? Interchange isn't free anywhere
wouldbecouldbe•Apr 20, 2026
because stripe on purpose hide fees, constantly asks you to try out new features and then secretly charges you more then market price when you say yes. See radar, managed payment, stripe billing management etc.
rrr_oh_man•Apr 20, 2026
This means you’ve done everything absolutely fucking right
wouldbecouldbe•Apr 20, 2026
thats a bit my point, you get there at around 18-20K mrr already
rrr_oh_man•Apr 20, 2026
Fair point, just saw your other comment.
egorfine•Apr 20, 2026
> Having done a major migration with Stripe, at a startup, I disagree
Initial integration is very simple and developer-friendly. The complexity comes later.
pbowyer•Apr 20, 2026
> 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!
zrn900•Apr 20, 2026
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.
egorfine•Apr 20, 2026
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)
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.
emursebrian•Apr 20, 2026
We're using Stripe to run our marketplace where teachers can sell their language courses. It does MOST of what we want/need.
I've done numerous checkout/payment processing integrations over the years. Stripe is still pretty easy to use and full-featured compared to what I've used in the past. It does have its annoyances, shortcomings and API inconsistencies - but it's still better than the alternatives, in my view.
Support has been good when I needed more documentation on something. Their chatbot performs very poorly, however.
roxana_haidiner•Apr 20, 2026
bro, just use Paddle, it's a MOR
NetOpWibby•Apr 20, 2026
In my experience, you couldn’t just setup an account and start selling, you had to contact their sales team and they let you know if they want your business.
Stripe has no real competitor.
lucrbvi•Apr 20, 2026
Mollie might be a direct competitor
sumedh•Apr 20, 2026
Isnt Mollie Europe only?
lucrbvi•Apr 20, 2026
Mollie seems to only provide services to business based in European Economic Area, Switzerland and the UK [0], so yes?
I refuse to see Stripe as anything other than inconvenience. They refuse all my payments, because they don't like my debit card provider. When a service uses Stripe for payments, I just assume they don't want me as a client.
rrr_oh_man•Apr 20, 2026
> "they don't like my debit card provider"
Can you elaborate?
neonstatic•Apr 20, 2026
The provider is Wise - an "e-money" institution. I've been using them for well over a decade. They are very good. Never had any issues until recently - a service I was interested in uses Stripe to "verify" the card before charging. Stripe rejected all Wise cards - physical and digital. I had to use my legacy bank's debit card. Problem is, the legacy bank charges outrageous forex fees and has an awful spread on top of it, so if I can't use Wise card after "verification", I will have to give up on the service. I asked them what could be done and they just said they use Stripe and that's it.
malfist•Apr 20, 2026
Wait, why does your debit card involve forex fees and spreads?
pjc50•Apr 20, 2026
Somebody's got to do the currency conversion. If you let the merchant do it, it's usually even worse.
(Implicit is the OP buying a bunch of stuff in a currency which is not the one they earn it; probably only one of those is dollars)
neonstatic•Apr 20, 2026
With Wise it does not, but with my legacy bank it does, because the base currency is one of the non-euro European ones.
egorfine•Apr 20, 2026
> Introducing PaymentIntents and PaymentMethods
Stripe will soon run out of names for their ever growing levels of abstractions.
I loved Stripe from the inception until about a year or two ago when their developers discovered the joy of AI. Now I dread every new Stripe SDK update, because it means more mental tax to me, more work for exactly zero value - all for the satisfaction of their architects.
It looks developer-friendly in the beginning (and it is), but once you cave in to the lure, you'll be hit with a flow of SDK updates with incredible type gymnastics.
logicallee•Apr 20, 2026
there are a lot of payment providers. what features do you like about Stripe that keeps you with Stripe?
StrauXX•Apr 20, 2026
Only Stripe offers a service doing international VAT for you.
deaux•Apr 20, 2026
Isn't that largely the selling point of every MoR? Paddle, Polar.sh and so on.
SkiFire13•Apr 20, 2026
If you use them for subscriptions you are effectively locked with them. The cost of migrating to a different provider (including existing subscriptions AND payment methods) plus the risk of something breaking the renewals is too high for most companies.
echelon•Apr 20, 2026
Maintain two billing providers and migrate new subscriptions as they onboard. Then slowly migrate existing subscriptions.
It's also a good bargaining chip.
satvikpendem•Apr 20, 2026
Are there any good Stripe Connect competitors? I haven't found any.
tinyprojects•Apr 20, 2026
Zoneless is an open-source Stripe Connect alternative
ralusek•Apr 20, 2026
PaymentMethods = a specific credit card, debit card, etc. Payment Method is basically a term of art so ubiquitous that it's user-facing in UIs and has nothing to do with Stripe.
PaymentIntents is definitely a Stripe abstraction, however, but that's one that I like. It's been a while since I used it, but I remember liking that it allowed me to bundle up everything related to the payment, i.e. the amount, the payment method, etc, and pass it around between server, client, and different views in the client, such that you could really build the exact payment flow you want without touching PCI data.
The Stripe abstractions I have always felt are much clunkier are the distinctions between Products/Prices/Subscriptions/SubscriptionSchedules, etc. A lot of "what lives where?" with those; very clunky to work with.
egorfine•Apr 20, 2026
I'm pretty sure that all Stripe abstractions and layers they do have a merit. No doubt and I'm being serious here.
However:
PaymentIntent, InvoiceCreationIntent, InvoiceCreationSession, InvoiceCharge. InvoiceChargeIntent, InvoiceChargeSession, InvoiceChargeSessionIntent, InvoiceChargeSessionIntentSession, InvoiceChargeSucceed, InvoicePaid, InvoiceFinalized, and so on.
All of those can absolutely be explained in a way that justifies their existence.
But in the end systems end up incurring so much mental tax that no one wants to really have to do anything with it.
Stripe began as a company to outsource complexity to and then grew to become a source of complexity itself.
Stripe's API is great, especially the pre-built checkout and the ability to attach any metadata to charges. In my small shop, I use it as a make-shift order tracking system, adding fields like order_status, invoice_number, order_number, tracking_url, custom delivery details etc.
6 Comments
You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should trigger which product decisions, and there is no guidance on which events and states are authoritative or take precedence.
Stripe is no longer the correct shape for small startups. They are wonderful for big business, but startups need something smaller to go faster. Your Stripe integration will slow you down.
Stripe APIs being simple and easy is a meme from the 2010s. It isn't anymore.
They're great for big business at scale, but they lost how to cater to startups.
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.
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.
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.
Initial integration is very simple and developer-friendly. The complexity comes later.
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!
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
> 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.
I've done numerous checkout/payment processing integrations over the years. Stripe is still pretty easy to use and full-featured compared to what I've used in the past. It does have its annoyances, shortcomings and API inconsistencies - but it's still better than the alternatives, in my view.
Support has been good when I needed more documentation on something. Their chatbot performs very poorly, however.
Stripe has no real competitor.
[0]: https://help.mollie.com/hc/en-us/articles/115002116105-Can-I...
Polar.sh is another one.
The thing you're talking about with Paddle is just checking you're not selling offline, physical stuff.
Can you elaborate?
(Implicit is the OP buying a bunch of stuff in a currency which is not the one they earn it; probably only one of those is dollars)
Stripe will soon run out of names for their ever growing levels of abstractions.
I loved Stripe from the inception until about a year or two ago when their developers discovered the joy of AI. Now I dread every new Stripe SDK update, because it means more mental tax to me, more work for exactly zero value - all for the satisfaction of their architects.
It looks developer-friendly in the beginning (and it is), but once you cave in to the lure, you'll be hit with a flow of SDK updates with incredible type gymnastics.
It's also a good bargaining chip.
PaymentIntents is definitely a Stripe abstraction, however, but that's one that I like. It's been a while since I used it, but I remember liking that it allowed me to bundle up everything related to the payment, i.e. the amount, the payment method, etc, and pass it around between server, client, and different views in the client, such that you could really build the exact payment flow you want without touching PCI data.
The Stripe abstractions I have always felt are much clunkier are the distinctions between Products/Prices/Subscriptions/SubscriptionSchedules, etc. A lot of "what lives where?" with those; very clunky to work with.
However:
PaymentIntent, InvoiceCreationIntent, InvoiceCreationSession, InvoiceCharge. InvoiceChargeIntent, InvoiceChargeSession, InvoiceChargeSessionIntent, InvoiceChargeSessionIntentSession, InvoiceChargeSucceed, InvoicePaid, InvoiceFinalized, and so on.
All of those can absolutely be explained in a way that justifies their existence.
But in the end systems end up incurring so much mental tax that no one wants to really have to do anything with it.
Stripe began as a company to outsource complexity to and then grew to become a source of complexity itself.
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...