Comment by arp242 | Hacker News Reader

Comment by arp242 | Hacker News Reader

I recently built a Stripe integration, and can't say I'm especially impressed.

Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for transactions! IMO a good API design should be more thoughtful than providing an interface to your database.

I don't think the documentation is especially well written, although it's not bad either. What's worse is that the stripe API docs hijacks my CTRL+F key so using my browser search is a massive PITA. This is such a fucking annoying fucking thing that I'll break my "don't say fuck on discussion forums"-rule for this. I fucking hate it. I tried disabling JS but that results in every navigation doing a full page refresh which easily takes over 5 seconds.

Also, browsing the docs isn't super slow or anything, but it's also not quite fast enough to feel "natural".

The checkout docs actually are pretty meh. Much of it is written in "tutorial" form and unclear on details.

As for the site design ... it often takes >5 seconds to load anything after clicking and it easily uses more than 100M of memory per tab. I recently wanted to load a bunch of customers so I opened them in about 10 different and my entire laptop just ground to a halt. I've actually been procrastinating on some Stripe stuff I need to do for the last week because I dislike using the UI so much.

Is it all absolutely terrible? No; it's passable, I guess. But do I share any of the enthusiasm in this article? Not even close.

I think you're seeing what the benefit is, though: it feels like you're just using an API to some company's DB.

Payment processing is one area is that just a complete nonstarter to homebrew on your own. It's fucking awful. There's no choice. Bank's still require you to transfer them files via ftp to make transactions.

And god forbid the legal, and technical mess when you want to accept foreign currency, or even multiple CC providers.

Yeah, I have no doubt that it's better than what the banks are offering.

"Homebrew on your own" is more or less what Stripe's API felt like though; the perspective I'm coming from is that I run a little one-person SaaS company with a simple and fairly standard subscription model, and I was surprised by the amount of "plumbing" you need to do for this.

That's why companies like Paddle.com exist.

I used them for a side project. Once you find the right documentation it's straightforward to integrate, but finding it took 3 days and 2 support requests.

Work in fintech, can confirm. Moving money around the global banking system is a pus-drenched no man's land of technological anguish and despair. Every time you think you've seen the worst of it, you find out you were wrong.

Agreed. I had to implement a transaction audit using SOAP in 2019.

We actively maintain multiple SOAP servers so an OEM can connect as a client, and send us data.

The OEM required us to stand-up the servers so they could send us the data.

We also still use FTP for some vendors (we host).

Cryptocurrency gets a bad rap here (most of it rightfully so), but one thing is for sure, once you use it you realize how broken digital payment infrastructure is. With crypto, I can trivially send any amount of money very cheaply across any sort of borders. Also, accepting crypto as a merchant is extremely easy even to roll your own custom solution.

(Edwin from Stripe here.) Most people like our built-in search since it lets you quickly navigate and see related things. But if you don't, you can hit Ctrl+F+F to use native browser search. You can turn it off entirely by unchecking "Open on Ctrl-F."

Docs now save to your cache, so loading should feel pretty immediate.

What should we be more clear about in the Checkout docs? We're working on improving them, but it'd be useful to hear what you think. (Could you email me [edwin@stripe.com] and jackerman@stripe.com?)

We also made the Stripe Dashboard 20% faster since March. There's more work to be done here, though—and performace (specifically the customer page) is at the top of the list.

I just started implementing checkout in Rails on a side project and the step by step docs don't cover CORS and CSP. I get a bunch of errors. Really the docs should cover every little detail leaving nothing to be researched. Any time I follow a how to doc that leaves details out I lose flow which in turns slows me down and makes me less happy.

Hi Edwin. Will you guys ever add the ability to "pause" subscriptions? The only way to do that right now is to resort to various "hacks", such as adding a 100% discount coupon and then taking it off when unpausing.

Yes! We added this in March: https://stripe.com/docs/billing/subscriptions/pause.

As much as I love Stripe, I agree with you. Just did a Stripe Checkout implementation :

- Checkout docs are definitely not good, there is a "Getting started" and then good luck

- the CTRL+F hijack is the most annoying thing I've stumbled upon recently. Please don't do that.

If you cmd+f twice in a row that should bypass you to your browser’s native search. There’s also a toggle in the search UI so that you can opt out of the modal entirely and go straight to browser search every time. It’s in the bottom right corner of the search modal iirc (writing this comment from mobile).

Disclosure: I work at Stripe. Will pass this feedback along :)

" it mostly just seems like an interface to their database. "

Payments are a huge, institutional mess under the hood, what they offer is light years better than what was there previously.

Honestly it's what 'you don't see' that's the good part.

It helps that basically the only other option, PayPal, is a complete disaster.

So, even if Stripe is suboptimal, everybody is so much happier to be away from PayPal that they're ecstatic.

It's the equivalent of having a mediocre sandwich when you're starving.

People forget Braintree Payments from PayPal.

While the docs are confusing and the API info incomplete, once past that the experience has been good. Having a pre-written embeddable JS widget that takes care of adding support for credit cards/PayPal/Apple Pay/Google Pay was a real time saver over Stripe.

The kicker is the default fees are higher than Stripe, but Braintree will negotiate.

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare.

What do you mean by "there's no support for transactions"?

He means database transactions. I.e. the ability to do a series of operations atomically.

I haven't really worked with PayPal, so I can't really compare. I did some payments years ago with ... I forgot, so I can't really compare it to other competitors.

With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL.

Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be.

There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated.

The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".

I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in the distributed systems world there are no transactions.

I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway.

So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first.

Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?"

With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back.

* If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic.

The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once.

Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.

Reply on news.ycombinator.com