Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe CLI

stripe.com

Post reply on HN
Print view View original

21–30 of 149 posts

Re: Stripe CLI

#21

Post by ceejayoz »

MuffinFlavored wrote: post #12
chadlavi wrote: post #10

This is a great improvement! Last time I did a stripe integration it was definitely kind of a painful, disjointed experience.

Really? It's like... 3 API calls. Create a customer, store a card, create a charge.

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.

Re: Stripe CLI

#22

Post by MuffinFlavored »

benologist wrote: post #14
MuffinFlavored wrote: post #13

Earlier quoted context omitted.

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: https://devcenter.heroku.com/categories/deploying-with-docke...

I 100% agree which is why I decided not to pursue the idea. Thank you very much for taking the time to provide feedback!

Re: Stripe CLI

#24

Post by MuffinFlavored »

ceejayoz wrote: post #21
MuffinFlavored wrote: post #12

Earlier quoted context omitted.

Really? It's like... 3 API calls. Create a customer, store a card, create a charge.

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.

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

Re: Stripe CLI

#25

Post by pc »

knubie wrote: post #15

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.

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

Re: Stripe CLI

#26

Post by ceejayoz »

MuffinFlavored wrote: post #24
ceejayoz wrote: post #21

Earlier quoted context omitted.

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.

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

Re: Stripe CLI

#27

Post by moonbas3 »

knubie wrote: post #15

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.

I agree, it's awesome. Their customer support is also good.

Re: Stripe CLI

#28

Post by pc »

moonbas3 wrote: post #27
knubie wrote: post #15

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.

I agree, it's awesome. Their customer support is also good.

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.

Re: Stripe CLI

#29

Post by SalesDevRep »

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)!

Re: Stripe CLI

#30

Post by yingw787 »

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!
Post reply on HN