Hacker News new | ask | show | jobs
by JonoBB 1350 days ago
The one part of this article that I totally agree with is how terrible the API integration has become. In the early days, Stripe sold itself on a few things, one of which was the simplicity of integration. Since the whole PaymentIntents and SetupIntents introduction (along with the documentation fiasco that happened at the same time), integrating with Stripe is something like PayPal from 10 years ago. Its shit.

PaymentIntents workflow (including the necessity to listen for webhooks) deserves a special place in hell. Its like they decided to copy Paypal IPN.

I have used, recommended and intgrated Stripe to multiple businesses over the years (generating hundreds of US$ millions). For the past 2 years or so, I have migrated most of them away from Stripe, and any new integrations are done through other payment processors.

5 comments

PaymentIntents and webhooks are required because of SCA (3d secure) and other type of payments flow (Apple pay, Google pay or just Stripe Checkout) where the user might be redirected to some external services leading to the capture being validated asynchronously.
Yes, to be fair to Stripe I think much of this is domain complexity that there are no easy answers for.
I have used many other payment providers (in the UK) that deal with 3D Secure (and have done for decades), there's nothing about 3DS that requires things to be asynchronous.

I am currently involved in a project to add Stripe support to a product, and it's a lot more complicated to set up a simple payment than other APIs on the market.

From everything I'd heard about Stripe, I thought the API would be really simple, but it's not.

When I had to integrate the new intents APIs back when SCA launched it seemed pretty clear to me that they tried to come up with an API that covers many use cases (relatively) uniformly but therefore coming at the cost of a huge complexity boost over ther initial "charge a credit card" experience, which, combined with hugely lacking docs on some corner cases we encountered, seemed like a pretty poor decision to me based on what made them useful in the first place when they launched. As things stand I would look elsewhere now for integrating payments
I'm not an expert dealing with PSP, but situations where a payment is validated through a "return to merchant URL" is risky and could lead to payment being captured without the merchant being notified.

Stripe abstracts away all the complexity having to deal with dozens of payments methods behind this single PaymentIntent API, which let you query the status of a payment at anytime (and webhooks are just a way to listen for updates in realtime).

> I'm not an expert dealing with PSP, but situations where a payment is validated through a "return to merchant URL" is risky and could lead to payment being captured without the merchant being notified.

There are ways to deal with that - a very simple one is a "mop up" process, as suggested by the GOV.UK Pay Service:

https://docs.payments.service.gov.uk/integrate_with_govuk_pa...

But then how is this simpler or better than listening for webhooks (push)? Also, PaymentIntent allows you to query its state (pull) as described in your link.
I feel this comment.

I'm working though Stripe integration for the first time. It's one of the worst APIs I've ever dealt with.

I couldn't find a single place advising which webhooks to listen to - or what their payloads should be - for simple subscription behavior. It's actually inconsistent in places.

They built and accrued all of this complex billing behavior for all of these incredible upmarket needs, and in the meantime they forgot about the simple cases.

I almost used PayPal or Square. Perhaps I should have.

Stripe seems to have moved on to upmarket.

> I'm working though Stripe integration for the first time. It's one of the worst APIs I've ever dealt with.

Braintree user here, have I got news for you. I regularly have to waste weeks of developer time on payment processing. The documentation is terrible and fragmented, some things are not explained anywhere, support response times hover around two weeks (I'm not kidding), and the canned support responses rarely fit my use case, so there's always a back-and-forth.

This would all be fine if I could just get it done once, but the thing rears its head regularly, what with the newer PSD2 regulations or something else.

As an example, after having done all the 3DS2 integration work (well, it was closer to re-work, as extensive changes were required), Braintree now tells me that 3DS1 is being deprecated (fine) and some of my transactions are 3DS1. Well, which ones, and WHY? I have no idea. I asked support on Sep 27, that was 12 days ago, no answer.

I looked at Stripe and had a really hard time understanding how I can fit my subscription SaaS into it. I think if you fit the simplest common use case and you're willing to outsource everything, Stripe could be simple to use. If you want to be independent in any way, or want to maintain the relation to the customer yourself, things quickly get difficult. But the real reason why I can't even consider Stripe is multiple currencies: I want to settle in three currencies (including USD), and Stripe will only settle in USD to a bank account based in the US. Good luck getting a US bank account if you are an EU small business. Also, pricing looks reasonable at a first glance, until you notice the currency conversion fees and the extra "billing" fee. In my specific case I would end up at about 5.4%.

On the specific point about getting a US bank account in the EU. I’m in the UK and have used Wise [1] (née Transferwise) to set up a ‘virtual’ US bank account. You get a US account number to send to your client / plug into Stripe, and the funds are paid into the Wise account, which you can then transfer into your home currency account at your leisure. It’s worked really well for me and the fees are very reasonable.

[1] https://wise.com/

Echo this, works really well. Saves many many thousands a month sending Stripe -> Wise US "virtual" account -> UK bank account vs Stripe -> UK bank account.

Stripe's forex fees are horrendous. Wise charges <0.5%, Stripe >3%. The spread here is similar to the credit card charge in the first place!

You might find https://www.airwallex.com useful for your multi currency needs. Not related to them, simply a happy user.
I was lead to believe a stripe API integration would take maybe a month of my time, for a subscription based service.

Genuinely 3 months of development, with more roadblocks than I could have ever imagined.

I found Stripe API really well organized and thought out. Everything is crisp and explained well. It is complex not because of bad design choices, but because payments, especially subscriptions are complex. I've integrated both payonce and subscription payments, takes a lot of effort but that's not Stripe's fault. Payments are insanely complicated and I am actually shocked that Stripe makes all of this possible. They've really tried to make it the best posssible API. It reeks of quality. I would rather have full control than to obscure everything under the rug to make it easy.

I don't get the complaints here. Yea, it is hard to write payments workflows. Learn to properly organize your backend to account for all edge cases. Use stripe test clocks. Use mock objects and stripe CLI. Everything has been handed to you on a silver platter by Stripe IMO.

What are the other payment processors that you prefer now?
This is so true.

PaymentIntents and SetupIntents make setting up a basic subscription Billing interface incredibly painful. The documentation is awful and spread across multiple sections of the Help pages so you have to read multiple articles to piece together how it's supposed to work in your specific scenario.

Even understanding when a PaymentIntent is recommended vs when a SetupIntent is needed takes some doing.

And don't get me started on trying to understand whether I need to use the confirmCardPayment or the confirmPayment or confirmCardSetup etc etc functions.