I’m sure payments are convoluted, but I’d still imagine they could be meaningfully easier for the bulk 80% of use case?
I’m sure payments are convoluted, but I’d still imagine they could be meaningfully easier for the bulk 80% of use case?
Docs are a mess, API is a mess, web portal is stuck in the 90's, things that are a form on Stripe are an email at best, a call/meeting at worse.
For one processor I had to have 4-5 calls before they would give me a key and let me buy hardware. I doggedly jumped over every barrier, worked with their shit docs, called their terrible API and in the end, <2 weeks before I was going live, found that in production over half my credit cards were failing to be charged. When I asked them about it they said "contact your bank", as if that was a valid response for why 4 of my 6 credit cards threw an error (with no recourse/message).
In <2 week I had Stripe hardware and completely re-wrote the implementation in time for launch.
Stripe is not the cheapest by far, but you'd have to pay me quite a bit of money to consider using anyone else.
The moat protecting their high margins is temporary.
Competitors will obviously improve their developer experience over time, and then win on price.
Stripe are stuck. They know they need to lower rates over the long term, but since they already make so much profit overcharging existing customers, they are hesitant to do so, meaning new competitors will enter with a price advantage without a competitive response from Strioe.
So far it hasn't happened and they've had the time. Point me at an API better than Stripe's with lower fees and I'll be interested but so far I haven't seen anything like that.
For example, redirect-based payment methods (iDEAL, Bancontact, Sofort) are a huge source of complexity, and handling all the additional states a payment can be in is far from obvious. Stripe mostly just drops them in your lap and says "deal with it".
We have this workshop thing we make most new joiners go through where they integrate our own APIs into a demo app and the number 1 response from anyone familiar with the wider payments industry is that we should aim to make our docs more like Stripe's lol
I worked on this at Stripe in 2022. We were the first teams to start building v2 APIs and data models to solve exactly this problem. The first target launch date (in Feb 2022) was November 2022. It was launched in May of 2025.
My reporting line, as an EM, was Netflix, Oracle, Oracle. No one had startup experience. It was drenched in politics. The engineers were largely brilliant, kind, and hardworking.
I still love the company and believe in Patrick. Believe me, he deeply understands what you're saying and wants it to be the best it can be. But it was clear to me, even then, that they'd lost a lot of what made them special. They could maintain it, but I wasn't sure they could do it again. Banking-as-a-Service was one opportunity, Link was another, and now this will be a third. We'll see. (I say this with a lot of love for Stripe and Stripes.)
Coincidentally, I had a conversation with a recruiter at Anthropic and saw them doing something very similar. They were starting a new team in a new vertical and wanted someone with experience running an org of 100+ people. I would bet real money that it will be a fraction of the product/impact it could be (though still probably make money!)
Well that brings back some memories. I remember there was a third Oracle in that chain, but he left earlier compared to the others.
What really happened is that Stripe's products used to be simple. If you're only accepting credit cards and only serving the US market, the API surface is extremely simple. Once you start going multinational and accepting different types of payments it gets much more complex.
For example, OXXO gives users a barcode and lets them take it to a physical location and complete the purchase, so instead of a system like Visa which can confirm a transaction in a maximum of O(seconds), you also have to support methods where confirmations take O(days). Building custom API endpoints for each payment method isn't realistic, since there are hundreds worldwide, and merchants want a single integration point that can support anything from credit cards to coupon-based systems like OXXO.
TL;DR -- Stripe's APIs are definitely more complex now, but it's not because of poor design, it's because they simply have to be in order to serve the customers and markets the company is now reaching.