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.
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...
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.
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.
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.
Initial integration is very simple and developer-friendly. The complexity comes later.
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.
> 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.
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
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 has no real competitor.
Polar.sh is another one.
The thing you're talking about with Paddle is just checking you're not selling offline, physical stuff.
[0]: https://help.mollie.com/hc/en-us/articles/115002116105-Can-I...
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)