alt.hn

4/20/2026 at 5:05:43 AM

Stripe's Payment APIs: the first 10 years (2020)

 https://stripe.dev/blog/payment-api-design

by tibbar

4/20/2026 at 9:18:04 AM

> 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.

by egorfine

4/20/2026 at 1:36:42 PM

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.

by ralusek

4/20/2026 at 2:03:20 PM

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...

by egorfine

4/20/2026 at 9:48:26 AM

there are a lot of payment providers. what features do you like about Stripe that keeps you with Stripe?

by logicallee

4/20/2026 at 11:38:17 AM

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.

by SkiFire13

4/20/2026 at 12:42:10 PM

Are there any good Stripe Connect competitors? I haven't found any.

by satvikpendem

4/20/2026 at 12:57:28 PM

Zoneless is an open-source Stripe Connect alternative

by tinyprojects

4/20/2026 at 10:30:06 AM

Only Stripe offers a service doing international VAT for you.

by StrauXX

4/20/2026 at 11:11:52 AM

Isn't that largely the selling point of every MoR? Paddle, Polar.sh and so on.

by deaux

4/20/2026 at 2:08:42 PM

thats a neet website

by dullynotsonumb

4/20/2026 at 7:09:49 AM

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.

by echelon

4/20/2026 at 2:05:35 PM

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.

by emursebrian

4/20/2026 at 7:16:03 AM

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.

by danpalmer

4/20/2026 at 7:28:12 AM

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.

by wouldbecouldbe

4/20/2026 at 9:12:28 AM

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

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

by egorfine

4/20/2026 at 8:17:38 AM

> 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.

by rrr_oh_man

4/20/2026 at 8:35:05 AM

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

by wouldbecouldbe

4/20/2026 at 8:48:05 AM

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.

by OtherShrezzing

4/20/2026 at 9:13:38 AM

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.

by wouldbecouldbe

4/20/2026 at 1:31:30 PM

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

by malfist

4/20/2026 at 8:58:36 AM

This means you’ve done everything absolutely fucking right

by rrr_oh_man

4/20/2026 at 9:14:51 AM

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

by wouldbecouldbe

4/20/2026 at 9:54:47 AM

Fair point, just saw your other comment.

by rrr_oh_man

4/20/2026 at 9:14:45 AM

> 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.

by lol768

4/20/2026 at 9:11:29 AM

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

by egorfine

4/20/2026 at 8:50:41 AM

> 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!

by pbowyer

4/20/2026 at 9:02:18 AM

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.

by zrn900

4/20/2026 at 10:46:05 AM

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.

by andrewshadura

4/20/2026 at 7:45:18 AM

bro, just use Paddle, it's a MOR

by roxana_haidiner

4/20/2026 at 7:54:48 AM

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.

by NetOpWibby

4/20/2026 at 11:19:05 AM

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.

by deaux

4/20/2026 at 8:17:11 AM

Mollie might be a direct competitor

by lucrbvi

4/20/2026 at 8:44:58 AM

Isnt Mollie Europe only?

by sumedh

4/20/2026 at 8:56:53 AM

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...

by lucrbvi

4/20/2026 at 12:35:15 PM

And they also have a minimum turnover limits. They rejected us as too small.

by andrewshadura

4/20/2026 at 9:03:06 AM

Stripe is trialing a MoR solution (managed payments) right now.

by zrn900

4/20/2026 at 9:08:33 AM

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.

by neonstatic

4/20/2026 at 10:44:27 AM

> "they don't like my debit card provider"

Can you elaborate?

by rrr_oh_man

4/20/2026 at 12:29:35 PM

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.

by neonstatic

4/20/2026 at 1:34:52 PM

Wait, why does your debit card involve forex fees and spreads?

by malfist

4/20/2026 at 1:49:05 PM

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)

by pjc50