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.
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.
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.
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.
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.
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.
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.
The migration I did was from the basic Stripe product to the complex one. I did it because we were legally required to do the transition. Stripe was the only major vendor with the technology ready for that migration.
> 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.
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.
Stripe's fees are well above interchange fees (especially in Europe). On top of that Stripe's pricing for other features (e.g. invoicing and subscriptions) is also a percentage, so you end up paying a ton for those features.
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.
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.
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.
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)
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.
> 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!
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.
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.
Last I checked, Polar was using Stripe under the hood.
EDIT: Yup. Via their pricing page:
Polar is currently built on Stripe, and we cover their 2.9% + 30¢ fee from ours. However, they impose a few additional fees for certain transactions that we need to pass on.
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.
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.
> 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.
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.
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.
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
there are a lot of payment providers. what features do you like about Stripe that keeps you with Stripe?
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.
Maintain two billing providers and migrate new subscriptions as they onboard. Then slowly migrate existing subscriptions.
It's also a good bargaining chip.
Are there any good Stripe Connect competitors? I haven't found any.
Zoneless is an open-source Stripe Connect alternative
Only Stripe offers a service doing international VAT for you.
Isn't that largely the selling point of every MoR? Paddle, Polar.sh and so on.
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.
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.
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.
The migration I did was from the basic Stripe product to the complex one. I did it because we were legally required to do the transition. Stripe was the only major vendor with the technology ready for that migration.
> 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.
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.
How is that different than any other payment processor? Interchange isn't free anywhere
Stripe's fees are well above interchange fees (especially in Europe). On top of that Stripe's pricing for other features (e.g. invoicing and subscriptions) is also a percentage, so you end up paying a ton for those features.
And other payment processors don't charge a fee for invoicing and subscriptions?
I'm not sure if they all charge a percentage of your money transfers for that. At work we decided to migrate that part to an internal system anyway.
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.
This means you’ve done everything absolutely fucking right
thats a bit my point, you get there at around 18-20K mrr already
Fair point, just saw your other comment.
> 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.
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.
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
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.
> 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!
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.
I can't believe no one has mentioned the original oh so hacker name: pay-daemon
thats a neet website
bro, just use Paddle, it's a MOR
Stripe (I work there) also offers a mor-like product called “managed payments”: https://docs.stripe.com/payments/managed-payments Feel free to check it out
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.
It has lots of competitors. They bought out LemonSqueezy exactly because it was a competitor that quickly gained a lot of mindshare.
Polar.sh is another one.
The thing you're talking about with Paddle is just checking you're not selling offline, physical stuff.
Last I checked, Polar was using Stripe under the hood.
EDIT: Yup. Via their pricing page:
Mollie might be a direct competitor
Isnt Mollie Europe only?
Mollie seems to only provide services to business based in European Economic Area, Switzerland and the UK [0], so yes?
[0]: https://help.mollie.com/hc/en-us/articles/115002116105-Can-I...
And they also have a minimum turnover limits. They rejected us as too small.
Stripe is trialing a MoR solution (managed payments) right now.
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.
> "they don't like my debit card provider"
Can you elaborate?
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.
Wait, why does your debit card involve forex fees and spreads?
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)
With Wise it does not, but with my legacy bank it does, because the base currency is one of the non-euro European ones.