Live data from Hacker News

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

stripe.dev

21–30 of 56 posts

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

#21

Earlier quoted context omitted.

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

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…

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.

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

#22
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…

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

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

#23

Earlier quoted context omitted.

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

This means you’ve done everything absolutely fucking right

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

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

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

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

#27

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

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

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

#29

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

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

Only Stripe offers a service doing international VAT for you.

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

#30

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.

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

Can you elaborate?

Post reply on HN