Stripe CLI(stripe.com)
stripe.com
Stripe CLI
https://stripe.com/blog/stripe-cli
148 comments
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.
Top APIs I've enjoyed working with:
1. Stripe (Best)
2. Twilio
3. Twitter (Does what it needs to do quickly)
4. Puppeteer (Amazing. Was super helpful.)
5. Google (mostly ok but could be better)
APIs I've hated working with:
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)
1. Stripe (Best)
2. Twilio
3. Twitter (Does what it needs to do quickly)
4. Puppeteer (Amazing. Was super helpful.)
5. Google (mostly ok but could be better)
APIs I've hated working with:
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.
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.
[deleted]
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.
Have you tried using containers? There are extensions for Firefox[1] and Chrome[2].
[1] https://addons.mozilla.org/en-US/firefox/addon/multi-account...
[2] https://chrome.google.com/webstore/detail/sessionbox-free-mu...
[1] https://addons.mozilla.org/en-US/firefox/addon/multi-account...
[2] https://chrome.google.com/webstore/detail/sessionbox-free-mu...
For some reason every page load also needs to download a 8MB blob. I discovered this when I was trying to access it over a tethered connection.
Add eBay to the second list. We are still uploading XML documents.
Ebay does have a "RESTful" API:
https://developer.ebay.com/api-docs/static/ebay-rest-landing...
Definitely agree that the old SOAP API was/is horrific. But the XML is about as easy to work with as JSON/REST.
Definitely agree that the old SOAP API was/is horrific. But the XML is about as easy to work with as JSON/REST.
I second that, eBay API is hot garbage and their staging is years out of date.
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.
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).
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.
This actually explains a lot of other things. Like the DMV.
eBay is an absolute nightmare. They have a demo instance to test on and it's about 4 years out of date and half of it doesn't work anymore.
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.
Wow, this is awesome.
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?
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 working with it 3 years ago and it sounds like it hasn't gotten any better in that time.
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.
They have no incentive to improve their docs. They're Facebook, there's no competition at all.
Add Mailchimp to that first list. When I do APIs I set Mailchimp quality as my documentation goal.
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”.
Foursquare API [1] is pretty good too (if you're still doing the location thing)
[1] https://developer.foursquare.com/
[1] https://developer.foursquare.com/
Twilio indeed! I also have Digital Ocean and SendGrid on my own list, which are written by developers for developers.
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 [email protected].)
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.
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.
[1] Stripe provides a very detailed and customized API upgrade guide based on your current API usage https://stripe.com/docs/upgrades?since=2016-03-07#how-can-i-...
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.
[1] Stripe provides a very detailed and customized API upgrade guide based on your current API usage https://stripe.com/docs/upgrades?since=2016-03-07#how-can-i-...
They had a great blog post on how they manage API versioning a couple years ago: https://stripe.com/blog/api-versioning
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.
If you guys could make your docs available for offline/downloadable reading in apps like Dash, it'd be amazing. There's a fundraiser to do it:
https://github.com/Kapeli/Dash-User-Contributions/issues/201...
but this project would be much easier to do by someone inside of Stripe.
https://github.com/Kapeli/Dash-User-Contributions/issues/201...
but this project would be much easier to do by someone inside of Stripe.
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 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.
We wrote a blog post detailing our Stripe Billing implementation: https://www.daily.co/blog/implementing-api-billing-with-stri...
We wrote a blog post detailing our Stripe Billing implementation: https://www.daily.co/blog/implementing-api-billing-with-stri...
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.
[0] https://stripe.com/partners/apps-and-extensions/accounting
[0] https://stripe.com/partners/apps-and-extensions/accounting
FYI while you're here: Your search is broken: https://support.stripe.com/search?q=Countries
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 [email protected] 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...
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.
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.
As someone who just started using Stripe with no prior experience with their api, the current state is very confusing.
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.
I heard developers saying this in real-life as well about SCA (Strong Customer Authentication).
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.
I love that they've been so successful.
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.
I love that they've been so successful.
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.
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.
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.
Aside from documentation, how do you judge if an API is good?
= Design characteristics =
1. Simple, distinct concepts with unambiguous names.
2. Semantics are clear, following conventions as appropriate.
3. Minimize surface area without reducing functionality.
4. Clarity and specificity of ErrorCodes and messages.
= Operational characteristics =
1. Extremely low level of 500s.
2. Low call latencies.
3. The API does what it says it does.
4. Consistency is (nearly) always within its documented SLA.
5. Do not make backwards incompatible changes.
= Social characteristics =
1. Docs are correct, up-to-date, complete, specific, and unambiguous.
2. Clearly communicate service outages and resolution timelines.
3. Seek feedback on evolving the APIs.
1. Simple, distinct concepts with unambiguous names.
2. Semantics are clear, following conventions as appropriate.
3. Minimize surface area without reducing functionality.
4. Clarity and specificity of ErrorCodes and messages.
= Operational characteristics =
1. Extremely low level of 500s.
2. Low call latencies.
3. The API does what it says it does.
4. Consistency is (nearly) always within its documented SLA.
5. Do not make backwards incompatible changes.
= Social characteristics =
1. Docs are correct, up-to-date, complete, specific, and unambiguous.
2. Clearly communicate service outages and resolution timelines.
3. Seek feedback on evolving the APIs.
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
2. consistency with industry norms (eg REST)
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
2. consistency with industry norms (eg REST)
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) ?
- 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.
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.
I still recommend privacy.com though.
So far I’ve had cards rejected by Patreon and AT&T.
I still recommend privacy.com though.
Also, DigitalOcean. I'd used a prepaid debit card with them in the past, but they don't accept them anymore.
Adding that prepaid debit card to your PayPal account, then paying DO with PayPal works seamlessly.
DO has some decent tech support. I would try to contact them and see if they could accept the card.
Is there anything like Privacy.com, but for Canadians? I really like the idea of being able to have per-service burner cards
Not an ideal solution but you may want to look at prepaid credit cards. In my case, I use USD prepaid cards via CIBC for SaaS subs. https://www.cibc.com/en/personal-banking/prepaid/cibc-smart-...
I'd use privacy.com but I really like the points my CC gets me...
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.
You can do this today with Stripe Issuing! https://stripe.com/issuing
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.
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.
https://stripe.com/issuing. Just needs a virtual-only option.
Stripe Issuing supports virtual card issuance.
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.
Sounds like something Privacy.com could do without much trouble, though I don't think they actually have a CLI (yet).
Interesting ... although they do not have a CLI, can you call functions with 'curl', like:
curl api.privacy.com CID:blahblah token:blahblah ... action-action-blah-blah ?
I don't actually use a Twilio CLI - I call functions with curl from my own scripts ...
curl api.privacy.com CID:blahblah token:blahblah ... action-action-blah-blah ?
I don't actually use a Twilio CLI - I call functions with curl from my own scripts ...
I don't know this specific site, but it's fairly common to put basic (or less basic) measures against such curl-ing.
I don't think there's a public API.
There seems to be some sort of API, some of which is non-free.
https://developer.privacy.com/docs#introduction
EDIT: It appears I was able to activate the API with my personal account.
https://developer.privacy.com/docs#introduction
EDIT: It appears I was able to activate the API with my personal account.
[deleted]
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.
I haven't used it, but https://developer.privacy.com could probably accomplish things like that.
Pretty sure you can do this via https://www.marqeta.com/api (disclaimer: I haven’t personally used; assume you need some $ to get an account).
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.
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! [email protected] -- We'd love to hear how you're using the CLI and what you'd like to see in the future.
Does stripe PGP encrypt everything on top of TLS? Question for cli and browser
Enable charges of more than $1mil please.
Curious what your use case is.
My guess: Money Laundering.
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.
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.
Also, an interesting coincidence that I've just released a case study of Stripe's success and recent $35B valuation [YouTube]: https://www.youtube.com/watch?v=nlFAbBvu7hA
Also, an interesting coincidence that I've just released a case study of Stripe's success and recent $35B valuation [YouTube]: https://www.youtube.com/watch?v=nlFAbBvu7hA
Fwiw, we kinda had the opposite experience when trying to get them to fix the a11y of their product.
It has been a constant struggle on all platforms to get the stripe widgets to behave correctly.
Since payment is not exactly an optional step in a product, this has been very painful.
It has been a constant struggle on all platforms to get the stripe widgets to behave correctly.
Since payment is not exactly an optional step in a product, this has been very painful.
Curious which widgets you're talking about?
the credit card data input widgets that stripe provides
Always interesting to see what CLI library is used. Looks like another feather in the cap of https://github.com/spf13/cobra.
I would love to hear why they chose cobra over something like https://github.com/urfave/cli
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!
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!
Kenneth from Stripe here. We just committed a fix. Thanks for the heads up! https://github.com/stripe/stripe-cli/commit/edaa05a505e935a5...
Very impressive. From an engineering standpoint, Stripe knocks it out of the park.
This looks really good.
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.
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:
https://stripe.com/docs/api/webhook_endpoints/create
ssh -R $DOMAIN:80:localhost:$PORT serveo.net
https://stripe.com/docs/api/webhook_endpoints/create
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 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...
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!
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.
Currently offline due to phishing.
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!The message is new, usually the website was also down, but this probably explains why.
That's why i switched from ngrok to localtunnel (global npm package) https://www.npmjs.com/package/localtunnel
You can just run lt -p 8080 --subdomain whateveryouwant ;)
You can just run lt -p 8080 --subdomain whateveryouwant ;)
Yes setting up all that stuff was one of the most painful things about local development working with Stripe webhooks. This is a good solution.
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
On the listen side, you can run `stripe listen --print-json` which will output the entire object.
You can also resend events by doing `stripe events resend <event_id>`.
We'll see about documenting both better!
You can also resend events by doing `stripe events resend <event_id>`.
We'll see about documenting both better!
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!
I too salute our stripe overlords. The payments api is so easy to use - I was done in a few hours, literally... in php (boo). :-)
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.
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...
Hi! I'm Sebastian and I work at Stripe.
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 [email protected]
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 [email protected]
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)!
Looking through the repo's dependencies (https://github.com/stripe/stripe-cli), it seems they are using the GO CLI framework Cobra (https://github.com/spf13/cobra).
A lot of people say "mobile first," but I think that's because they're overlooking CLI's.
They're by far the fastest way to prototype functionality, and a dream for the QA team.
They're by far the fastest way to prototype functionality, and a dream for the QA team.
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.
Hopefully CLI wil work :)
Hopefully CLI wil work :)
Hmm, that shouldn't happen – mind shooting me an email with an ID or two that failed? rattrayalex at stripe.
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
How can I get the multiple terminals view in the blog header image?
Kenneth from Stripe here The demo is using https://hyper.is/ with it's standard dark theme and terminal splitting which is built in.
looks like just your regular iterm2 split panes?
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).
you don't say!
Nice ad.
Still waiting for my country to be supported for years now.