The Stripe CLI doesn’t have a command for listing account tax IDs, but it’s still possible to list them using the get subcommand. For anyone else that needs it, here’s how you can list them:
stripe get /v1/tax_ids\nAnd to get a single tax ID:
\nstripe get /v1/tax_ids/txi_abc123\nI’ve been struggling with Stripe’s documentation for a while, and it just occurred to me what the issue is: it’s not clear enough on the basic concepts of its working.
\nFor example, there’s plenty of documentation about how to use Stripe to create invoices: using the API, using the Dashboard, all good. But I need to know how Stripe arrives at the calculation of the amount_due field, and I don’t know where I can get that. The API docs is not useful. It states the starting_balance is involved, but it doesn’t go into details how, or what happens if the balance is negative. Nor does it go into details as to how the ending_balance will change based on the starting_balance or the amount_due. There’s nothing at all on what the value amount_paid is, simply saying that it’s “the amount, in the smallest currency unit, that was paid.” Would that be the total of all the successful payment intents?
What I really want are some maths or logical expressions in how the amounts relate to each other. Something like\nending_balance = amount_due + starting_balance, or amount_due = grand_total + starting_balance, or amount_paid == sum(payment_intent.amount, where payment_intent.status == 'paid'). Something concrete I can tease out and go to anyone who asks, “yes, the ending balance will be adjusted based on the amount due in this manner.”
Maybe it’s assumed that everyone using Stripe at least know basic of accounting, like “due” meaning the amount of money we want the customer to give us. I mean, I think I know what that means, but I can’t really go to someone with this reasoning without linking back to Stripe and proving my work. I’m not an accountant, just some poor dev that knows how the Stripe integration works from a technical standpoint. Maybe the complexities involving in keeping balanced accounts on Stripe side precludes make this information available. That’s a fair call, but it would be nice if the documentation says that. At least that’s better than making assumptions.
\n", "date_published": "2026-07-10T11:27:03+10:00", "url": "https://lmika.org/2026/07/10/more-kvetching-about-stripes-documentation.html", "tags": ["Long Form Posts","Stripe"] }, { "id": "http://lmika.micro.blog/2026/06/19/til-that-if-a-stripe.html", "content_html": "TIL that if a Stripe subscription is associated with a test clock, it won’t be returned in a List Subscription call. Not sure if it’s because the clock is set in the future, or it’s just the presence of the clock itself. Retrieving the subscription by ID seems to work, though.
\n", "date_published": "2026-06-19T13:30:44+10:00", "url": "https://lmika.org/2026/06/19/til-that-if-a-stripe.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2026/05/05/while-were-adding-features-to.html", "content_html": "While we’re adding features to public web services, here’s another one: request durations in Stripe’s Workbench. I’m seeing some pretty slow subscription update calls and it would be nice to see if it’s impacting the timeout of our integration.
\n", "date_published": "2026-05-05T09:15:22+10:00", "url": "https://lmika.org/2026/05/05/while-were-adding-features-to.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2026/02/09/til-about-stripe-pending-update.html", "content_html": "TIL about Stripe pending update feature, where you can update a subscription on condition that the payment was successful. Wish I knew about this before I coded up all this logic manually. I wonder if this is a new feature (I wish Stripe added dates to their documentation).
\n", "date_published": "2026-02-09T08:10:42+10:00", "url": "https://lmika.org/2026/02/09/til-about-stripe-pending-update.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/11/30/laughed-out-loud-when-i.html", "content_html": "Laughed out loud when I heard this as my experience with Stripe's API has been quite different. Stripe does quite well with keeping support for old versions of their API, but they're not afraid of making backwards-incompatible changes between versions. We encountered quite a few of these last time we were updating the SDK, and while I was going through their API docs a few weeks ago, I saw quite a few more that we'll need to make next go-around. I wouldn't call that "low needs" myself.
\n\n", "date_published": "2025-11-30T14:24:28+10:00", "url": "https://lmika.org/2025/11/30/laughed-out-loud-when-i.html", "tags": ["Videos","Podcast Clips","Stripe"] }, { "id": "http://lmika.micro.blog/2025/11/17/protip-for-anyone-using-stripe.html", "content_html": "Pro-tip for anyone using Stripe: don’t use colons in your metadata keys. It’s not that they’re not allowed, but there’s no way to escape that colon in a Radar expression. Best to stick with alphanumerics and the underscore, as if those keys were C idents.
\n", "date_published": "2025-11-17T15:29:51+10:00", "url": "https://lmika.org/2025/11/17/protip-for-anyone-using-stripe.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/11/12/i-will-admit-i-was.html", "content_html": "I will admit, I was a hater of Stripe’s new developer tools that slid up from the bottom when I first used them. But I’ve grown to really like them. They have the one thing I’ve been wishing from Stripe from the beginning, which is showing how the entity you’re looking at looks from the API.
\n", "date_published": "2025-11-12T16:57:21+10:00", "url": "https://lmika.org/2025/11/12/i-will-admit-i-was.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/11/07/the-ultimate-irony-of-fully.html", "content_html": "The ultimate irony of fully understanding Stripe and its API is that you really need to use it to sell something. You can understand a lot just by working on the customer facing side, but when it comes to understanding how payouts work end-to-end; well, owning a business would come in handy here.
\n", "date_published": "2025-11-07T13:08:00+10:00", "url": "https://lmika.org/2025/11/07/the-ultimate-irony-of-fully.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/09/04/saw-a-stack-overflow-answer.html", "content_html": "Saw a Stack Overflow answer for a Stripe question linking to a Discord message as a source. I’m sorry, but for SO questions about Stripe, citing some random message on Discord is not good enough, even if the poster is Stripe support. You may as well cite “some Stripe dev I overheard at a conference.”
\n", "date_published": "2025-09-04T16:07:21+10:00", "url": "https://lmika.org/2025/09/04/saw-a-stack-overflow-answer.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/08/21/why-does-stripe-delete-test.html", "content_html": "Why does Stripe delete test subscriptions after 90 days? What resources do these test subscriptions actually take up? I can understand deleting them after, say, 2 years, but 90 days seem a bit short.
\n", "date_published": "2025-08-21T11:38:40+10:00", "url": "https://lmika.org/2025/08/21/why-does-stripe-delete-test.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/07/07/how-fast-does-stripe-post.html", "content_html": "“How fast does Stripe post web-hook events?”, you ask. Well at the moment I’m facing a small race condition where a thread makes a call to Stripe, and another thread receives the event before the first one has finished its routine. So yeah, pretty fast.
\n", "date_published": "2025-07-07T08:00:44+10:00", "url": "https://lmika.org/2025/07/07/how-fast-does-stripe-post.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/04/24/stripe-support-is-a-lot.html", "content_html": "Stripe support is a lot like democracy: it was better in the past, and on the whole it’s the worst one out there, aside from all the other payment gateways.
\n", "date_published": "2025-04-24T16:34:45+10:00", "url": "https://lmika.org/2025/04/24/stripe-support-is-a-lot.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2025/03/03/so-uh-stripe-which-is.html", "content_html": "So, uh, Stripe; which is it? You can’t change the currency of a customer, or you can? Because I was under the impression that you were unable to change the currency once it was set. So you could imagine my surprise when I was able change the currency of a customer this morning.
\n![\"Auto-generated](\"https://cdn.uploads.micro.blog/25293/2025/out-20250303-104052.png\")
\r\n![\"Auto-generated](\"https://cdn.uploads.micro.blog/25293/2025/out-20250303-104114.png\")
\n",
"date_published": "2025-03-03T09:48:07+10:00",
"url": "https://lmika.org/2025/03/03/so-uh-stripe-which-is.html",
"tags": ["Photos","Stripe"]
},
{
"id": "http://lmika.micro.blog/2024/05/01/for-the-past.html",
"content_html": "For the last few years, I’ve been using 4/24 as the expiry date of test credit cards within Stripe. Well those days are literally in the past now.
\n![\"Screenshot](\"https://cdn.uploads.micro.blog/25293/2024/screenshot-2024-05-01-at-11.25.26am.png\")
\n",
"date_published": "2024-05-01T11:28:45+10:00",
"url": "https://lmika.org/2024/05/01/for-the-past.html",
"tags": ["Screenshots","Stripe"]
},
{
"id": "http://lmika.micro.blog/2024/04/12/moanroutine-stripe-prices.html",
"title": "Moan-routine: Stripe Prices",
"content_html": "I love coding and anything computers. I’ve spent, and continue to spend, a significant amount of my life writing code. And on the whole, it’s been a magical experience.
\nBut not always.
\nSometimes I encounter something that makes me wonder why? Why was that designed that way? Why doesn’t it work? Why couldn’t this be easier? You encounter something that blocks you or puzzles you, maybe even questions how anything in computers can work at all. You’ve got things to do, and you try your best to work around the problem. Sometimes you succeed. Most times you get blocked and need to find some other way to fix it. And so the frustration builds, with no easy way to dissipate it.
\nWell, this is my attempt to do just that. I need a place to write these somethings down, not least to make me feel better. To air thy grievance is to start the healing process. They say that “a moan begun is half done” after all. Well, okay, no-one has ever said that. But maybe we should. We may not have the power or energy to change things, or even to find out why things the way they are, but by God, we can make sure others hear about it.
\nSo enjoy these “moan-routines”. Or don’t. Honestly, it’s totally up to you. ð P.S. The name moan-routine is a play on go-routine, a concept in Go.
\nSo, onto today’s moan. We’ll start the moans with something that saved my bacon today: which is Stripe prices. Actually, what saved me was something that we didn’t do with Stripe prices, which was archive them. For you see, archiving a price in Stripe makes it effectively unusable.
\nThis is arguably a good thing: you change a price, you don’t want anyone using the old one. Well, I say “change”; what I actually mean is replace. You can’t “change” a price directly in Stripe, say from $10 to $12. Instead, you create a new $12 price which will replace the old $10 one. Any new subscriptions you create will use the $12 one from now on, and ideally you’d never use that $10 price ever again.
\nSo you want to archive the $10 price. But there’s a problem: you’ve got all these customers with subscriptions still paying the old $10 price. Stripe doesn’t provide an easy way to move customers over to the new $12 one: this is something you have to do yourself. And you may not want to do that anyway. You may want to send your customers an email informing them about the price change; letting them know they have 30 days or whatever to be ready for it.
\nAnd until you actually go in and change their subscriptions, they’ll be paying this old $10 price. And the minute you archive that $10 price, it becomes radioactive. Any attempt to do anything with it, or any subscription using it, will resolve in an error.
\nWhich gets to the moan: why do this for archive prices? I would’ve thought that Stripe was aware that subscriptions with old price was a thing. Am I to keep this old price active for as long as those accounts are still using it? Even if no-one else will ever get that price again? I wouldn’t be able to archive anything at all until them. And it may be a while before accounts do get changed. Think beta users grandfathered in-to a lower rate.
\nSo I’d like Stripe to change this. Either get rid of the pitfalls around archive prices, or make it easy to port subscriptions over to the new price in some way (subscription schedules are a whole other moan). Instead, I stuck keeping old prices active because I’m afraid that archiving them will things. This clutters up the dashboard and introduce traps like creating a subscription with an old price.
\nLook, prices change. It’s just the way of the world. And if Stripe is going to make prices effectively immutable, it would be helpful for us to make it easy to mark a price as “don’t use this for new stuff but keep the old staff effectively unchanged.” I expected this what archiving a price would be. Turns out I was wrong.
\n", "date_published": "2024-04-12T07:50:00+10:00", "url": "https://lmika.org/2024/04/12/moanroutine-stripe-prices.html", "tags": ["Long Form Posts","Stripe"] }, { "id": "http://lmika.micro.blog/2024/02/26/just-discovered-that.html", "content_html": "Just discovered that Stripe has a changelog, which is great. But they don’t offer it as an RSS feed, which is crazy. Seems like this would naturally translate into an RSS feed. They have one for their engineering blog so it’s not like they unfamiliar with the concept.
\n", "date_published": "2024-02-26T08:41:55+10:00", "url": "https://lmika.org/2024/02/26/just-discovered-that.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2023/05/17/it-kills-me.html", "content_html": "It kills me that Stripe offers six test cards that simulate errors when attaching to a customer, yet only one test card that simulates payment failures once it’s attached.
\n", "date_published": "2023-05-17T11:24:39+10:00", "url": "https://lmika.org/2023/05/17/it-kills-me.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2023/04/03/used-chatgpt-a.html", "content_html": "Used ChatGPT a record number of times today (5). Asked a lot of questions about Stripe, like what happens to invoices when a subscription is cancelled. Proved more useful in giving me a direction to explore, rather than providing me a definitive answer, although that might come with time and trust.
\n", "date_published": "2023-04-03T16:31:39+10:00", "url": "https://lmika.org/2023/04/03/used-chatgpt-a.html", "tags": ["Stripe"] }, { "id": "http://lmika.micro.blog/2023/02/15/so-this-happened.html", "title": "Ignoring Bard to Speak to Paulie", "content_html": "So this happened today.
\nOur team was testing the integration between two systems. The first system â let’s call it Bard â can be configured to make API calls directly to Stripe, or be configured to use the second system â let’s call it Paulie â to call Stripe on it’s behalf. Bard has a REST API that is used by the HTML front-end to handle user requests. Paulie is designed to be completely isolated from the front-end and has a simple gRPC API that Bard calls. Whether or not it Bard calls Paulie at all is determined by the value of an SSM parameter.
\nThe test was setup with Bard configured to bypass Paulie and make calls directly to Stripe. The way we were to verify this was to tail the logs of both Bard and Paulie, make a REST-API call, and confirm that logs showed up in Bard but not Paulie.
\nI got called by those running the test to help, as they were seeing something unusual: when the test was performed, logs were showing up in Paulie. The system was configured for Bard to ignore Paulie and go directly to Stripe, and yet Paulie was being spoken to.
\nSo we started going through the motions. We checked to make sure we had the correct version of Bard deployed, checked the SSM parameter, traced through the code, restarted Bard a couple of times to make sure it was configured correctly. And after every check we tried the test again, to nothing changing: logs will still coming through from Paulie.
\nWe were at it for about 15 minutes. I was staring to go through the more esoteric explanations for why this was happening, like whether we were using SSM parameters incorrectly and we may have been using an old configuration or something. Then as I was going through the traces one last time before giving up, I noticed something: there were no traces from Bard. This REST-API it had did all sorts of things like contact the database before going to Paulie or Stripe so I was expecting something like that to show up. Yet there was no evidence of any of that happening.
\nI then asked how this was actually being tested. And you can probably guess what the response was. Turns out the person running the test wasn’t using Bard’s REST-API at all, and was making gRPC calls directly to Paulie.
\nWell, naturally, if you called Paulie directly without calling Bard, it doesn’t matter what Bard is configured to do. ðĪŠ
\nNow, I don’t write this because I’m angry or annoyed. In fact, I came away from this feeling very zen about the whole thing. Mistakes like this happen all the time, it’s fine.
\nBut it’s a perfect opportunity remind myself that working on tech can sometimes give you tunnel vision, and that sometimes the explanation isn’t technical at all. Sometimes the answer is much simpler than you think.
\n", "date_published": "2023-02-15T15:15:59+10:00", "url": "https://lmika.org/2023/02/15/so-this-happened.html", "tags": ["Long Form Posts","Stripe"] }, { "id": "http://lmika.micro.blog/2022/03/02/time-and-money.html", "title": "Time and Money", "content_html": "Spending a lot of time in Stripe recently. It’s a fantastic payment gateway and a pleasure to use, compared to something like PayPal which really does show its age.
\nBut it’s so stressful and confusing dealing with money and subscriptions. The biggest uncertainty is dealing with anything that takes time. The problem I’m facing now is if the customer chooses to buy something like a database, which is billed a flat fee every month, and then they choose to buy another database during the billing period, can I track that with a single subscription and simply adjust the quantity amount? My current research suggests that I can, and that Stripe will handle the prorating of partial payments and credits. They even have a nice API to preview the next invoice which can be used to show the customer how much they will be paying for.
\nBut despite all the documentation, test environments, and simulations, I still can’t be sure that it will happen in real life, when real money is exchanged in real time. I guess some real life testing would be required. ðļ
\n", "date_published": "2022-03-02T09:36:00+10:00", "url": "https://lmika.org/2022/03/02/time-and-money.html", "tags": ["Long Form Posts","TILs","Stripe"] } ] }