Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stripe.dev

Post reply on HN
Print view View original

41–50 of 56 posts

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

#41

Post by ralusek »

egorfine wrote: post #24

> 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 develope…

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.

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

#42

Post by pjc50 »

malfist wrote: post #40
neonstatic wrote: post #35

Earlier quoted context omitted.

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…

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)

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

#43

Post by egorfine »

ralusek wrote: post #41
egorfine wrote: post #24

> 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 develope…

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 m…

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

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

#44

Post by emursebrian »

echelon wrote: post #2

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 tr…

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.

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

#47

Post by neonstatic »

malfist wrote: post #40
neonstatic wrote: post #35

Earlier quoted context omitted.

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…

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

With Wise it does not, but with my legacy bank it does, because the base currency is one of the non-euro European ones.

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

#48

Post by wouldbecouldbe »

malfist wrote: post #39
wouldbecouldbe wrote: post #21

Earlier quoted context omitted.

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

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.

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

#49

Post by echelon »

SkiFire13 wrote: post #34
logicallee wrote: post #27

Earlier quoted context omitted.

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.

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

#50

Post by SkiFire13 »

malfist wrote: post #39
wouldbecouldbe wrote: post #21

Earlier quoted context omitted.

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.
Post reply on HN