Stripe is by far the best developer experience I’ve had in my career working with third party APIs/services. The attention to detail is just second to none, and documentation is a big part of this.
1. Paypal (the worst - docs are horrible and UI is not consistent with most of the help material out there because it changes all the time. Have you tried their support? That's a beauty)
2. Facebook (same story but manageable compared to paypal)
God, I haaaaaaaaate PayPal. Not as a dev, but as a casual private user, a real-world entertainment venue business owner, an online retail business owner, an eBay user, a seeker of capital loan sources, and just a UI and customer service utilizer.
If ever there was an example of a company with "first out of the gate" advantage leading to such a large head-start that theyy could afford to constantly give the middle finger to everyone, PayPal is it. I cannot wait for legit altternatives to catch up.
Stripe is doing pretty well, but unless they somehow tap into the casual online user they won't disrupt PayPal's stranglehold to any significant extent.
I swear it honestly seems like PayPal tries to make their site as hard to use and bloated as possible. I've never personally used their API, but if it's anything like their site, I'm thankful.
Same here, I just hate PayPal documentation, and the way they managed to keep it shitty over the years.
Braintree (A division of PayPal) has nice documentation though.
The Twilio Dashboard _really_ needs a refresh. It's still in a world where every button is a complete page refresh. It's painfully slow to interact with.
I can live with the full page refresh, but my biggest pain point is working with sub accounts on trello. They store the sub account in a cookie instead of in the URL, so if I want to share what I'm looking at with a colleague it's a faff.
And Amazon sellers API (Amazon MWS). Rarely seen such an inconsistent mess of often poorly documented SOAP-ish calls, that so many external partners base their livelyhood on.
Some APIs you can choose to use. Other APIs you have to use. The ones you have to use tend to not care much about the developer experience... Because why should they? No one's going to avoid Amazon because their API was annoying. People need to make money.
This actually explains a lot of other things. Like the DMV.
The API is not not SOAPish, it just uses XML. They probably choose it so that they can use XML Schema to check incoming data (which is exactly the right decision here).
For those interested, the demo instance is at https://sandbox.ebay.com/ The message at the top says "eBay and PayPal will be separate companies soon", even though they became seperate companies 4 years ago.
Mousing over the links there to see where they go, the first interesting-looking one was the supported/unsupported features list, over at https://ebaydts.com/eBayKBDetails?KBid=684. Ah, I see - a wall of text reminscent of "system requirements", except it's a list of things you don't get instead.
But then going up to https://ebaydts.com, I met with... a blank page. But it has a title, so something's blown up. I hit F12 half expecting to be met with some kind of implosion, and even then I was cynically amused: the page has `<body style="display:none;>`, with no closing quote, and while Chrome parses it properly the devtools don't, so the CSS editor leaks bits of HTML.
On the one hand my infosec-sense says there's probably some awesome stuff hiding in here... but on the other hand, between the 1000 feet of bureaucracy I'd have to all but drown to report _anything_ I found, and the tenterhooks I'd be on while poking around establishing there's anything there beyond plausible deniability... not worth it?
Okay, it's not just me (demo instance). Ebay's APIs and their SDK documentation (or lack thereof) are making me re-think my app's monetization model. Docs are shockingly bad, full of screenshots that look like ebay from the early 2000s.
I was shocked at how bad the documentation for Facebook was. I assumed wiring up login would be super simple, it’s amazing how hard it was to find in their documentation. I guess when you’re paying devs to implant a shitty custom currency you can’t invest in docs for one of your biggest integrations.
Alternate reason: you'll figure it out anyway, because it's one of their biggest integrations. It doesn't matter how hard it is if your users and your business wants it.
They have no incentive to improve their docs. They're Facebook, there's no competition at all.
I’ve had a good experience with Facebook up until a few months ago when they started shutting off APIs that SHOULD be public without giving any notice and implementing silly requirements like “can’t post to your own business page without giving Facebook a login to your app and letting Facebook post on your company’s behalf”.
Thanks! We still have a lot of work to do. (Making our integration experience simpler -- now that Stripe's functionality has grown so much -- is an area of current focus. If any HN readers happen to have specific suggestions on this front, feel free to email sebas@stripe.com.)
Hey, from a security angle, can I express my appreciation for how much your team has worked to make security best practices and shared responsibility extremely clear? https://stripe.com/docs/security
Apologies for the hijack, just wanted to say thanks.
I love the backwards compatibility that Stripe provides. Thank you so much!
We launched a SaaS product on the 2016-03 API version. Since then[1] the API has basically changed completely around subscriptions (even the top-level objects aren't called the same anymore), to the point it would probably be easiest to just start a rewrite from scratch (which probably would take a week or two). But the fact that the old API continues to work to this day and that we have been able to rely on it and focus on other things has been amazing. New customers get to enjoy the new API while our business continues to chug along with zero modifications to the payment parts. That is impressive from both a technical and from a business point of view, and ensures we will keep using Stripe forever.
The best part is that you guys keep the logs for the last events and webhooks you sent with the request and response... this is such a time saver that I can't figure out why you are the only big players doing it.
Honestly, the only problem I ran into with Stripe ever was administrating subscriptions. IIRC even via the API there were a lot of limitations with what state you could put a subscription in, limiting our ability to seamlessly transition from Recurly to Stripe; we ended up duplicating a lot of the subscription logic in the end.
I know subscriptions have been significantly rehauled since then, but this was my only gripe. Stripe was absolutely excellent back when I used it.
I think subscriptions are complicated because the surface area of the problem is so large. The Stripe Billing APIs (the recurring revenue/subscriptions part of Stripe) have gotten very good. But the challenges involved in the average subscription implementation are a lot bigger than the challenges involved in implementing simple checkout workflows for non-recurring charges.
One thing I loved recently was finding a small error in your nodejs docs. I tweeted you and had a response within an hour or two that it would be fixed. Please keep listening like this, it’s greatly appreciated!
I'm surprised Quickbooks Online is not listed here [0]. I'm guessing they are the blocker here? I have fallen back on using Zapier but the sync often breaks. Native integration would be preferred.
Thanks for flagging! We've got a massive search overhaul in the works that will start rolling out in the next week or so. Feel free to get in touch at dylan@stripe.com if you'd like to give it an early spin when it's ready. (Our new search presents this as a result for your query, in case it's what you were looking for: https://support.stripe.com/questions/stripe-feature-availabi...)
Hey in terms of search, one issue I've had a few times now is the inability to find things in certain sections of the docs because of the way everything is presented on a single page.
e.g. just now I'm implementing webhook handling for subscriptions. So I drill down to the section that lists all the events - https://stripe.com/docs/api/events/types this is massive and I don't want to read everything, so I cmd+f to find "subscription"... oh stripes taken over my default search but no worries I can hit cmd+f again and use the browsers search... I type "sub"... now the page has jumped way up to https://stripe.com/docs/api/expanding_objects... ffuuuuu...
I felt that way until I needed to prepare for the new EU credit card regulation that came into effect a few months back and implement Stripe's update for it. There's a bunch of gotchas in the transition - e.g. you can't apply coupons when creating subscriptions with the new checkout flow (needed to handle 2FA), "sources" and "payment methods" show up in the same list in Stripe's UI, but are not fetched by the same API call. I hope they eventually manage to deprecate and migrate to a single way of doing things because right now it feels messy.
Same here. We have a platform with multiple sellers and we use Connected Accounts. Our first integration years ago was so easy and I loved how easy it was to work with the Stripe API. When we needed to update our integration for SCA support we had the exact opposite experience. The migration guides didn't fit our previous integration, maybe because we use Connected Accounts. Also the documentation had multiple bugs and was missing information, we had to make guesses to finish our migration. On top of that we had to upgrade our Stripe.NET-package which also caused a lot of issues for us because of a lot of broken functionality (we still have issues that we need to fix).
I can confirm this experience. Integrating all this new stuff meant keeping open multiple pages from the docs in parallel, each of which had a warning at the top that certain aspects are different and sends you yet to another page, depending on the integration, it felt like a giant spaghetti mess. I also found some bugs, for example, it was not possible to input sub-cent amounts on their dashboard for tiered plans.
On the other hand, a couple mails and a quick chat on their IRC resolved most of it. But I really wish there would be a clear map/diagram of what route to take depending on what you want to achieve.
Same experience here. Initial integration for 1-off purchases was easy peasy. Updating to PaymentIntents to support SCA was non-obvious. Trawled back and forth through many pages of documents many times before we got there. In the end, the code changes are few but I feel we could have got there via some easier route.
Until you get your head around their way of doing things with Payment Intents etc it can be a bit confusing. But its not too bad, ask questions in their IRC or online help, the team they have on those are fantastic.
It's fantastic. Over the last couple of years I think I've integrated our system with at least 10 different payment providers and Stripe's just works. The most useful thing for us though is that their test system works flawlessly. The amount of payment providers I've integrated with now where the test system is totally different / unusable compared to their production system... ugh.
100%. They're an excellent example of how impactful attention to detail and simplicity can be.
Thinking back to implementing Stripe for the first time, I remember being surprised by how painless it was. Prior to that integrating payments was something that filled me with the same kind of dread I get from dealing with legal paperwork.
Thanks! This is also an area we're working hard to improve. The scale is pretty substantial (we recently handled our millionth support case of 2019), but there are plenty of ways in which we want to improve, and we have a lot of in-flight work to make it better.
Interestingly, I randomly stumbled upon https://github.com/stripe/react-stripe-elements/issues/451, which is the opposite of what you describe. I'm not intentionally cherry-picking and I have limited experience working with Stripe, but there seem to be struggles on their part in some areas too. I suppose it's only natural to have some less shiny areas at any company.
It's the main reason why Stripe has taken a chunk of PayPal's business. We still have to use PayPal's API since most people, especially overseas are aware of PayPal.
We had dedicated PayPal liaisons and they recommended we use a product API that wasn't fit for our task. Just goes to show even their employees can't make sense of their products and documentation.
For me it’s about consistency, in order of importance:
1. self-consistency: Every entity and operation has exactly one name, a given verb always implies the same operation, paths are always constructed the same manner
