alt Hacker NewsStripe's Payment APIs: the first 10 years (2020)
Comments
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.
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.
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.
> 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.