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
In the Twilio world, I can do something like this, via the command line and their API:
- activate new phone number
- send SMS from that number
- deactivate number
I have not ever done that particular workflow, but I could.
Who is the Twilio of payments/fintech wherein I could perform a workflow like this:
- generate new CC number in my name
- set transaction limit(s) and expiry 10 days from now
- (go use that CC in real life)
- deactivate the CC
or maybe:
- disable existing card
- reenable existing card
I know I could do this if I wrote the API myself and had a big, complicated, sticky relationship with a bank ... but does someone let me do things like this if I am just an end-user (like Twilio does) ?
Privacy.com gets pretty close. They can generate burner cards or "per service" (such as a card just for your netflix account) that have spending limits per some period of time or in total. Their autofill plugin for firefox works pretty well. That's the extend of my usage of the service, it might do more but I'm not sure.
Personally, I use them for anything that doesn't accept paypal or similar payment systems. Hopefully that's helpful.
I also use privacy.com and it’s great. The only problem is that sometimes merchants don’t accept prepaid debit cards (that’s what privacy.com cards are under the hood).
So far I’ve had cards rejected by Patreon and AT&T.
That reminds me, paypal used to have a one time/subscription CC generator browser plugin way back in the day. It was great. I used it all the time and one day it just disappeared.
I had to implement a corporate version of this; they had a backing account and credit line, so this was an integration that involved four parties: the vendor, the owner of the credit account, the bank backing the credit account, and the card distributor. It was a messy process, involving key exchange and SOAP requests - very much a back-channel API more than a public-facing one.
I think a more publicly-friendly API might be created if it's merely the same credit card company providing temporary virtual credit cards that are backed by your main credit line. VCCs like that are already in use, the question is merely one of how freely accessible they are through programmatic means.
Now that Stripe offers a corporate credit card, it's likely only a matter of time until they enable people to build their own credit card on top of Stripe. I assume they've built the API's internally already for themselves.
I'm not a customer, but I believe that Revolut offers something like this, though with some restrictions and I'm not sure if they extend this to USA - they have the concept of 'disposable virtual cards' https://www.revolut.com/help/getting-started/getting-a-card/... and an API for controlling stuff.
Neteller has both physical and VCCs available for generation via their web portal. You can set a balance for each VCC, but I do not think they automatically expire. They do not offer an API to do it, but it should be possible to curl each endpoint leading to the generation.
How could you programmatically create a credit card without some pre-existing financial relationship with a a credit card issuer?
There's a good reason you cannot simply create and destroy payment cards without any trusted third party keeping track. Money laundering is the obvious issue.
Well, you'd presumable have some pre-existing financial relationship, all the legal agreements and stuff; it's just that instead of (or inaddition to) having a "long-term" credit card number you'd cycle through a bunch of disposable short-term credit card numbers. I.e. your relationship with the card issuer is long-term but the instrument you use to interact with merchants is intentionally limited to a short term.
Hi all! I'm one of the folks who's been working on this for the past few months. I'm happy to answer some questions about the CLI or how it was built (using Go and websockets for pushing data). If you have any ideas or feedback feel free to email me directly too! tomer@stripe.com -- We'd love to hear how you're using the CLI and what you'd like to see in the future.
You could certainly pay less than ~$20,000 in Stripe/CC fees to move $1M if your motives were on the up and up. Especially if you were doing it regularly.
Excellent product, fast improvements, best in class API/SDK, and documentation; this was pretty much my summary after extensive research on payment processors. After 2 years of using Stripe, my conclusion is unchanged.
I filled a bug task on your github page, but you've got a deadlink for the linux install in your readme.
Really excited to get to use these tools. Already integrated with stripe for my projects, but this will allow for more cool testing. Thank you stripe team!
It sounds like you won't have to configure tools like ngrok anymore to accept webhooks on a local connection. That's a huge win because with the free version of ngrok your subdomain would change a lot which means having to goto the Stripe dashboard to update it there. It was pretty tedious.
This is a free equivalent to ngrok and it only uses SSH - https://serveo.net/ - and it accepts custom subdomains. I spin it up for each project like this with $DOMAIN and $PORT being defined/fixed for each project and the connection kept open permanently using autossh:
ssh -R $DOMAIN:80:localhost:$PORT serveo.net
There are API endpoints for creating, listing and deleting webhooks in Stripe now too - my test suites and dev instances purge any existing webhooks and create a new one each run.
Do you think there would be demand for `serveo` but instead of running your project locally, you point to a Dockerfile and the entire container + all of its dependencies are ran remotely (with wildcard subdomain SSL included)?
I was going to test the waters with https://www.dollardeploys.com/ (not functional yet), wasn't sure how to differentiate it between ngrok/serveo.
I think at that point you're really into Heroku's territory rather than ngrok/serveo. Their free dynos might be hard to compete with, you can push a git commit or docker image or automatically deploy upon repo changes:
I've started using `serveo.net` to monitor my internet uptime (Raspberry Pi with a simple webserver, [updown.io](https://updown.io) to request it via [serveo.net](https://serveo.net)) but they were unavailable/offline for ~4 days within the last 10 days.
Serveo is temporarily disabled due to phishing.
Serveo will return in a few days with a few new
restrictions to help dissuade abuse. Thanks for your patience!
I still prefer to setup ngrok because it allows me to view and replay requests. If the stripe cli supported that, then I'd move to use the cli entirely
Yeah that's true, another upside to ngrok is it works for not just Stripe. Sometimes you need to link up with multiple payment gateways and listen for webhooks from 1 of them at a time.
Love this! We Strive everyday at Routefusion.co to model our developer experience and attention to detail off of what Stripe has done. They turned credit card payments sexy, not an easy thing to do, but when you have great experiences like this and focus on a the builders of tomorrow I guess it works!
I like the attention to detail this feature reveals - in particular, how if you're in Stripe test mode in browser tab X and type `stripe login`, the cli will open a page in browser tab Y that gives you a test mode webhook secret, without prompting you to select a mode again. Very intuitive.
Wow, this is amazing! I was learning more about ncurses and the various UI libraries built on top of them (e.g. Urwid). From going without Internet for a third of this year and using 1GB of mobile data per month, I've learned there aren't actually that many companies these days trying to serve customers with slow/intermittent Internet or optimize for data load. And that's an opportunity, because those customers are most likely sticky! I read that 3% of Americans still use dial-up internet, which amounted to 9.4 million people in 2016 (https://www.allconnect.com/blog/people-really-still-use-dial...). IIRC this is still better than the Internet connectivity in developing countries. If you got $1 from each of those people every year (less than 10 cents a month), you'd have $9.4m ARR, and it'd be sticky. Sticking to curses enables issuing API requests out to the world without having to build/download/install a GUI/XWindow server, and an entire browser on that GUI, and an entire webpage on that browser, which may drastically improve reach. Optimizing for legacy machines and empathizing with such a customer base is probably a big reason why WhatsApp looked so attractive to Facebook and why Facebook paid such a high premium to have the platform under its product ecosystem. I'm looking forward to seeing how this expands!
There's quite a bit more complexity in some use cases. Some payments are now asynchronous due to https://en.wikipedia.org/wiki/Strong_customer_authentication ; handling failed payments for things like subscriptions takes some effort (and managing webhooks).
My experience with Stripe has been great, but payments can still get into the weeds through no fault of Stripe's.
Some other examples of complex use cases: connected accounts, reconciliation reports, dunning reports, non-traditional ecommerce workflows. From a security perspective, I'd love the ability to enforce 2FA instead of having to audit the users table every month. To be fair I think the number of clients with 50+ connected accounts is fairly low
I might sound a bit dumb here, but would a cron job that runs daily, finds customers who haven't been billed in 30 days, then tries to bill them and disables their account on failure easier than dealing with webhooks/etc.?
Potentially, but Stripe has a lot of features you might have to duplicate in that case. They automatically re-attempt (including machine learning that tries to do it when the card's least likely to be maxed out). They send email receipts, handle SCA notifications if additional authentication is required...
We would love to understand what went wrong so that we can keep improving the integration experience. If you are interested in talking to us, please email me at sebas@stripe.com
Is Stripe's "documentation stack" open-source? I've seen Slate and its derivatives, but honestly nothing really comes close to the full (amazing) dev experience their docs provide.
Great stuff, wonder if they used any frameworks like oclif or something as a base. Looks extremely detailed, and wow, how do they always launch with such great docs?! Baffling (in a good way)!
that's nice! :) I have found that quite often Stripe's UI would just through errors when trying to open some customers, failed payments or subscriptions. Couldn't really pinpoint why it happens, tried different browsers, disabling extensions and so on.
Wow, so I have implemented Stripe integration in my project recently and I was using at least one feature mentioned in this blog. It was breeze to add payments to my project (and I have experience with some other systems that requires days to implement and test properly).
I’ve build something similar for our company about 4 years ago (also payment gateway) but made it as general free tool to test webhooks via ws https://waithook.com
alternately, you can use tmux which lets you detach sessions, rotate panes, and configure them in whatever arrangement you'd like! Would highly recommend it :)
Alternatively iTerm2 also comes with a native tmux integration. I personally prefer using tmux on my own but have several friends who prefer the iTerm tmux integration (copy-pasting text is definitely easier).
