My Stripe Tax Story
gist.github.com
gist.github.com
My point: if you let this kind of fuck-up go undetected for over three months, you have to at least assume some of the blame and acknowledge that you probably could have caught it if you scrutinized transactions. Every good business owner does it.
For your SaaS, it might be noticing patterns across your customer base and using these patterns to refine your product to cater to a certain facet of customer that seems to like your product, or spotting potential transactional issues before they cause a churn.
It seems like it wasn’t made clear in the docs that invoices aren’t finalized in these circumstances until later.
(I don't know whether the software used makes this easy?)
Btw, you could also fit this into the conceptual framework of accrual accounting, if you modelled counterparty risk.
From what I remember, in general you have to recognize outlays with certainty, but you have more leeway in how you treat inflows.
In general, you can also keep whatever you want in your books and run them however you like; you just have a legal obligation to also keep accounts that are in line with established standards.
You see this distinction in GAAP vs non-GAAP numbers in the US, where GAAP stands for Generally Accepted Accounting Principles.
In banking there's an obligation to model counterparty risk; but I have to assume that banks keep multiple copies of their balance sheets and accounts around:
One version for eg tax purposes, and another version for things like determining capital requirements and risk exposure; if different rules apply in the different domains.
Heck, in many ways, double entry bookkeeping on the accrual basis would be less likely to notice it.
It’d take both an open invoice and running an A/R aging to catch this one, which isn’t implicit in double-entry accounting.
Is it just me thinking this is actually crazy that they didn't notice even through a quarter closing? One could argue they're a small business but then how does the business not notice multiple months of AR being delayed.
I'd much rather bet on a business owner like your dad, who's deeply involved. Sounds like your dad's receipt reading was a great habit to have, and paid dividends far outside of just "making sure things were running OK on a daily basis".
Someday it'll be my own personal Double Double Animal Style.
That's why we don't have self-driving cars yet.
> You get used to it, though. Your brain does the translating. I don't even see the code.
> All I see is up and coming salespeople, valuable customers, strategic products.
> You want a drink?
I work in eCommerce and occasionally there will be something like a script or config gets messed up and an issue with billing will happen. And being the "expert" I'm usually the one called to fix it.
I wish I could count the number of tense discussions I have had that are along the lines of:
Them: We haven't been charging tax in Canada for three months because the config was wrong. Fix it!
Me: (some more polite variant of) So just to confirm, this has been wrong in your ERP... hundreds of thousands of CAD of uncollected VAT... for 3 months and you're just now noticing?
Not sure a ton realize that data is now a core piece of their operations.
That doesn’t mean every transaction needs to be manually revived, but major outliers and a random sampling is a good idea.
I’m far from perfect, and that’s why the CPA comes in after me to check. But if i wait for those quarterly checks to “check in” on quickbooks, that’s on me.
> As a human I can only mess up one or two orders a minute. Computers are uniquely qualified to mess up thousands of orders in seconds.
It relies 100% on the settings of the application in question, because tax codes and procedures vary greatly around the world, and it's internationally used software. There are even some stores using this software that sell items to and from different countries using the same website, so it can be set up to handle tax differently per product.
Not everything is taxed everywhere, so it will accept it without question if someone sets up a product with the tax class "none", and happily log, process and store an order with 0% tax.
Yes, it's a footgun for the inexperienced to be able to accidentally commit tax fraud, but no, the software can't just override the user input and insist that a 25% VAT should be applied to random things based on ... what? The name? A hunch? MaChInE LeArNiNg?
Manual audits are used to discover human error, be it my error in creating the software, or your error in the data supplied to the software. I can create the logs and make them as easy to read as possible, but if you don't read them for three months, that's on you.
Yeah it sucks, but the more we try to take the accountability out of the humans and put it into the software, the worse both the accountability and the software gets.
Just like everything out of silicon valley, creaky bare bones bullshit with meager support and a total hands in the air philosophy when it comes to responsibility.
As a US customer Eventbrite sends me an invoice/receipt in GBP yesterday. I scramble around looking for an invoice in USD and find nothing despite putting all of my information in pointing to the US. It's like doing business with toddlers.
They payment was processed in USD but there is zero mention of exchange rates or anything. My support option? Contact the poor guy trying to make his life easier by using their service. I have come to expect this vapid garbage unfortunately.
Software exists so users don't have to do stuff manually. But people should absolutely check on things periodically. That doesn't mean it's always necessary to check every single transaction, but spot and sanity checking is mandatory diligence, IMO. I pay my CPA to do my taxes so I don't have to do them myself, but of course I sanity-check the end result before signing off on it.
And OP made a huge change to how he was invoicing/taxing his customers, and then didn't verify that things were working properly after making the change? That's just irresponsible.
Stripe's documentation and API could probably stand to improve here, but that's the nature of products and API UX: never perfect. I do think it's pretty lame that Stripe's support and product people were evasive and did a bad job of admitting that the product had some rough edges that need to be improved.
But... c'mon. Not checking something as basic as "are my customer's payments being processed properly" after making a large change to the payment processing pipeline, and only finding out something was wrong, three months later, after an honest customer asked why they weren't being billed? That's pretty bad.
Is it more than 0?
Is it more than yesterday?
Seems like 2 or 3 dead simple controls on his part could have avoided this.
As for why they're inevitable, the context is that most enterprise software is off-the-shelf and serves many markets, so configuration becomes the point of weakness. Only bespoke software written for a very narrow sector, or tailored to serve a single business, can really hope to do better.
We might hope things were different, but they're not, and as long as software continues to be developed by the humans, it's likely to remain that way.
None of this is meant to absolve Stripe, however, since in this particular instance they rather appear to have contributed to the fuckup by omitting a key element of auditability, viz. the clear reporting of exceptions.
I'm all for blaming the software (which by the way in this case is made by a huge company I am 100% sure you know and costs hundreds of thousands of dollars to operate)... but the real problem here is the complexities of tax (I used Canada as an example but the US is the absolute worst because each state makes their own lows) is not a software quality problem, it is a data and open standards (or lack their of) problem.
But since the lack of standards is not being fixed any time soon, sometimes it "is" the user's fault.
I'd argue most ERP's are fine, it's the implementations that are garbage.
Because there is a strong lobby that prevents it.
https://www.propublica.org/article/inside-turbotax-20-year-f...
Money has too strong a foothold in American politics. (In other countries too, but especially in the land of the free.)
Tax credits for education, clean energy, penalties, small businesses, mortage interest, each one of those one-off changes adds complexity, and in total ultimately can make the process dramatically more difficult.
The citizen can either pay that number, or offer amendments to the details which imply a lower rate (or higher if you're a masochist, I suppose).
That's independent of the complexity of how that number is derived, and in balance I would rather the US (as a citizen thereof) use this sort of system than the one we happen to have.
There is nothing inherently wrong with that. Whether you do or do not agree is a different question.
It's interesting to look at different cultures:
The Swedish word for "tax" is "skatt", which literally means "treasure". Historically it was part of the treasure to be collected by the monarch and other people in power. So, not really a way to cover government expenses, but for somebody in power to enrich themselves further. Luckily, the country has moved on from that, just kept the word (and the king).
The German word for "tax" is "steuer", which literally means "to steer". That makes it clear that those fees are not just collected to finance government expenses but to even steer society in a certain direction, i.e., what you mean with policy.
You can streamline the process and at the same time turn it into a single bill that would be much more shocking to tax payers than the current situation where they often get either a refund or a small bill.
Let's say somebody makes 100,000 USD a year and pays 40,000 USD in tax on it. Today, they see 5000 USD on their account every month. Sometimes it gets adjusted a little up or down, depending on what they did on the side, had some stocks, mowed the neighbors lawn, whatnot. But their lifestyle is generally adjusted to 5000 USD a month. Housing, utilities, entertainment, restaurants, hobbies. Now tomorrow we switch to a scheme where they instead get 8333 USD on their account every month, and a 40,000 USD bill every spring. You'd be surprised how many people would adjust their lifestyle, with direct consequences even for tax revenue. You can even imagine a new loan sector that offers you those 40,000 USD in spring that you then can pay off over time. Great, now the monthly payments essentially go through a bank before ending up as tax, but the bank takes their cut. Everybody loses. (Well, except the bank.)
Now you could argue that's the individuals' problem. Get better with money. Educate people, teach it to kids in school. (Really? The education sector is already overwhelmed as-is.) That's not how society works though. Even if the well-off educated elites would like (which is what the HN crowd is part of, no offense..). Humans are not rational agents. If they were, the world would look very different.
If I was optimizing my actions based on what would create the most anti-tax sentiment, this would be a positive outcome, not a negative one. What's worse than a bill from the government? One you can't afford to pay and that causes you to take on debt.
To be clear I'm not optimizing my behavior on such a metric nor advocating for others to do so. I was talking about the purposed hypothetical of lawmakers who were making such an optimization and what sort of laws they would, in theory, be supporting.
I'm not sure where you get this from. People on the right have been yelling about simplifying the tax code for a long time. Flat tax, "postcard-sized tax form," national sales tax, all kinds of ideas have been floated. Even eliminating the income tax altogether and going back to funding the government through tariffs, those the people who suggest that wear a lot of tri-corn hats or subscribe to "Reason" magazine.
The fact of the matter is the tax code is the biggest trough from which politicians can reward donors, lobbyists, and other allies. A nice tax carve-out for left-handed buggy whip manufacturers is easy and cheap, and nobody reads all 1100 pages of some omnibus bill, so whoever slid it in can claim to be "for small business!" (the right), or "making the rich pay their fair share!" (the left).
As for the general population, all of their taxes are taken out of their paycheck. Taxes aren't hard for them. They pay a few thousand in income and payroll taxes over the year, they get a thousand or so back in a refund, and they think everything is great.
If there was a bill that eliminated all the tax code and replaced it with a brochure-sized alternative, there might be some on the right who would object, but EVERYBODY on the left would lose their minds. I can't think of a single progressive who has supported a simplification of the tax code.
https://www.huffpost.com/entry/grover-norquist-taxes_b_30056...
Very odd argument.
Nordquist can be both against improved tax prep software/procedures and for simplified tax laws. We know he's against the former; he's explicitly stated he doesn't want the US government producing tax prep software or doing any sort of additional legwork on the behalf of tax filers.
I read Norquist's article as more along the lines of "don't let the IRS determine what is and is not taxable," not so much about having them produce tax prep software. I suppose you can squint and read that, fair enough, but that does not address the issue of whether Norquist supports or doesn't support simplifying the tax code.
You know, the one where a single mom with children to feed pays the same percentage of her income as the single billionaire that wants to buy a 3rd yacht.
Look up Grover Nordquist. He has devoted his life to making sure paying taxes doesn't become too easy. And he ain't no lefty.
And the proponents of a flat tax would say "so?"
There's a fundamental ideological incompatibility here and unless one side stops caring or puts the other in the ground the bickering will continue.
I guess you have never read anything about the various flat-tax proposals. There have been several, and they have all accounted for those with lower income levels.
One of the fundamental tenets of the flat tax is 14th Amendment "equal protection." Is it constitutionally acceptable to treat a rich person differently from a poor person? The flat-tax people say no. Progressives say yes. I do agree that a progressive tax system has merits with which I agree, but I also think it's perfectly reasonable to assert that falls afoul of equal protection, and therefore should either be rejected or an Amendment should be presented and passed to account for it.
Progressives tend to turn this distinction into a moral argument about fairness, which is not how a government that is bound by law is supposed to work. If you want the government to work on a moral basis, don't be too surprised if a later government with different moral frameworks do things you don't care for.
>Look up Grover Nordquist
Somebody else brought him up in a comment. Taking your assertion at face value, you have one data point suggesting the right doesn't want to simplify the tax code. Good job, but I've got a competing data point of Paul Ryan, who was an actual Congressional leader in the Ways and Means Committee talking about the flat tax, and not an activist gadfly. I think my singular data point carries more weight than your data point.
As for Paul Ryan, he proves my point. His proposal included a huge break in corporate rates in exchange for a modest break in middle income taxes.
I don't care how good AI in finding tumors in x-rays is, I still want a set of skilled eyes to confirm findings.
It's the same reason I double check all my paychecks to make sure I'm paid the right amount and the deductions are correct. All of it's automated on the backend, but it's still my money and worth double-checking.
They do. We can leave aside the practice in many European countries to compute your income taxes for you, based on reporting by your employer and financial services. Even in the US, high quality software is provided for sales tax compliance. In fact, according to the Supreme Court, the presence of that software is one of the main reason they overturned their "no interstate online sales tax" decision in 2018. One reason was
> Streamlined Sales and Use Tax Agreement. This system standardizes taxes to reduce administrative and compliance costs: It requires a single, state-level tax administration, uniform definitions of products and services, simplified tax rate structures, and other uniform rules. It also provides sellers access to sales tax administration software paid for by the State. Sellers who choose to use such software are immune from audit liability.
Which, I guess to return to the point we set aside, is because companies can lobby for public software for their benefit, but tax prep companies can lobby against public software for their benefit.
It might work in the EU but in the US there’s state/county/municipality taxes that can get quite complicate. My zip code has a small area in my county and my county is at a 6% tax rate. Most of the zip code is another county that has a %7.5 tax rate. I have to double check large online purchases just to make sure it’s correct. Almost every place shows the wrong tax at checkout due to using my zip but’s it’s always fixed when my card is actually charged.
Most people are using SAP or Oracle to do this kind of thing because they already know the ins and outs of tax locales.
My state doesn’t have to give a rip that NYC has a city surtax on this but not that, or that some other jurisdiction treats clothing items up to $100 as non-taxable while we put the limit at $175.
I suppose that would be like asking the EU commission to provide tax software for all its member states.
In the US, jurisdictional/funding issues are the biggest blocker. There is no federal sales tax, so the IRS can't use its budget to pay for this. State agencies are not going to be able to use their funds to pay developers to add functionality for a different jurisdiction, and ditto for counties/cities/special districts, which tend to have much smaller budgets anyways.
The best avenue would probably be something like ITOR (the funds that give USDS its wide remit to help any gov agency with their tech needs), but states and localities aren't always open to receiving this kind of help. (It did happen with unemployment programs during the pandemic, but the lawyers had to lawyer pretty hard to make that possible.)
“The only thing government is good at is creating more government.” - P.J. O’Rourke
This all comes back to how poorly we integrate the solutions we build. The position of engineers is such that a free pass is often given for failures like these that are fairly well obscured from view. Similar failures for different roles within the same companies get treated differently. While engineers hold outsized power, it is very difficult to completely address these issues.
Sorry, what?
How is this OK or even normalized - he should not have to check every single receipt every night. You hire people to do that, and if they cannot do it right, you hire someone else.
As OP mentioned, it wasn't a gradual thing, and when you have a lot of customers, it can easily slip through. Even your father would be the same here - if a few people who should have been charged a recurring bill did not, how would he remember that?
> Every good business owner does it.
Absolutely not. Every good business owner gets someone to take care of it, and then double checks their work at times.
It sounds like a lot of work but over the course of many years running the same business, you develop a sixth sense for problems and can quickly scan a spreadsheet of receipts and spot issues. There are dozens of other “versions” of the late-night ERP scan. He can do the same thing walking across a showroom floor or taking one of the company’s Sprinter vans out for a drive.
It’s a way of life for him. He lives for his business and still works seven days a week at age 74. His business is exceptionally well-run and has been recognized nationally for it.
https://www.mysanantonio.com/sa-inc/article/SAInc-Flux-Bike-...
Q: How’d COVID impact your business?
A: Terrible. We haven’t lost any employees, but we’ve had staff who’ve lost family members to COVID.
> you absolutely have to be involved in all levels of your business if you want to be successful
But it does sound like your dad is a very effective delegator and has given a lot of autonomy to people in the business - a skill you definitely need to be highly sucessfull in business.
So, maybe... stay involved at all levels, then find people who are good at a role (that you trust) and give them autonomy... and the you don't have to stay in the weeds for all roles any more?
To the parent comment's point, maybe the receipt checking part could have gone that route, but there was never any one who was right for a role like that in the business?
It would be interesting to learn what his red flags are (for errors and fraud), what his markers for attention are (good customers and staff).
I wonder if some of this could be scripted or otherwise encoded. At a minimum it might help him out.
I am a highly anxious person, and it can be debilitating.
But when you're talking about taking payments and arranging the collection of tax, I reckon it's wise to treat your anxiety like a colleague. Give it the best chair; make sure it has lunch, and not too much coffee. And listen.
If your dad loves the work, okay cool. But your effective implication is you cannot have anyone else do this, which is obviously absurd because there are companies much much larger than either of ours that pull it off.
The key point is not "the owner has to do it", it's someone has to be held responsible for this.
For smaller businesses, it's likely the owner. For someone like your dad's, it's usually someone else. Even a solid bookkeeping system would have picked up what OP missed.
> you develop a sixth sense for problems
100% agreed, but for the owner/operator it's usually all things, but for the person who is responsible, it's usually a lot more of the minutiae.
It's literally impossible to be the master of all things.
Bookkeeping is different, though. He's actually been defrauded by a bookkeeper in the early 1980s. I don't know the details but she was siphoning money from the business in some scheme, probably a 1981 version of OP's Stripe API issue. If you simply trust a person like this and don't verify regularly, the mistakes and frauds happen. Receipts is where the rubber meets the road for a retail biz and I just don't see a substitute for an owner who cares and checks.
I think that's it really - you need to have checks and balances on all things (including yourself imo as the boss).
Personally I would not want to be double-checking receipts every day (and with 100 employees, the volume is likely significant), but if he enjoys it, that's all that matters eh!
> Every good business owner does it
and
> Every good business owner gets someone to take care of it
is…maybe not really that large? Both amount to "every good business owner ensures that receipts are checked daily," and that clearly wasn't happening here.
While I'm sure there is a better way to do this (e.g. invest in BI, hire and train a person to do this etc.), the fact of the matter is no one else is as invested in your business as you. So you are wired to find issues (even if none exist). It might just be an old-school small business mentality, but it works.
At the same time, it's tied him to the business in a way that he doesn't know how to get out.
However, to push back a bit, I think sometimes it’s easy to believe that we’re the only ones who can do something because we’re the only ones who have lived and breathe it for 5+ (Pick your number) years. And one might be surprised if they actually tried outsourcing how competent some folks can be.
Next step up is stuff outside of your core-competency. So that's where the CPA comes in to take some financial stuff off your plate. This can be hybrid with an admin assistance.
Then you get into the "core" functions. For a media creator, that might mean editing. Again, it's easy to fall into a trap of thinking some other editor won't be able to match your style or voice. But when you hire someone who sees themself as primarily an editor, and they're good at their job, they're really good at adapting and adopting voice.
With all of these things, often the person you're offloading to can't match your output 1:1. But if they can get you 90% completed rough drafts of the final deliverable, there's immense value there all the same.
Coming from the tech world, a lot of my focus has been setting up processes, piece-meal outsourcing and letting employees have more autonomy. Recently we even set up a small team in the Philippines to handle data entry.
However, I've grown to appreciate his view as well over the years.
This is so important, and I think it's what differentiates small owner operated businesses from multinationals and chains.
Your employees are not going to idly look through logs to see if everything is running smoothly when they are done with their tasks, they'll just go home and call it a day.
Because that's a job!
When I step on your toe, you should apologize to me, because you could've been more mindful of your surroundings and prevented it.
(I worked for 6 years in that side of the industry. Particularly when it might apply to point of sale software.)
Assuming normal closing hours of 18:00-20:00 o'clock of course.
In the example above, you have someone coming in making a large purchase, which is probably odd if you've never seen this person before (eg: you would have expected them to come in and "kick the tires" and talk to employees a few times before making the actual purchase, even if they did a lot of online research). Plus the non-working card, and being late in the day. Of course, it's also possible that the whole transaction could be legit. If you suspect fraud though you can often do or say things to gauge the persons response. Tell them that for such an expensive purchase you'd really like to tune the bike up and make sure it's perfect, can they come back and pick it up first thing in the morning? Stuff like that, if the person accepts that, or seems to genuinely consider it, it's probably not a fraud sale. If their immediate reaction is "no way", or they get defensive, it could be a red flag.
ed: sibling comment nailed it also. Didn’t even consider that, good stuff
The MINIMUM most people would expect would be a notification either by email or on the dashboard to say that an invoice cannot be processed and at least that would highlight the problem. Even better, when you enable Stripe Tax, it should highlight the people who cannot be charged tax and likewise when you add a new customer who doesn't have the right info, it should notify you.
I find it really frustrating when a multi-billion dollar company cannot think of UX 101 and the customer has to do the heavy lifting.
This guy is working alone and likely has less time to go into detail like that.
This is just another variant of "cloud first" mentality, assuming that cloud service providers are actually going to be better than you (as opposed to just cheaper) in carrying out these tasks.
The companies I've worked for put enhanced auditing and reporting in place before this sort of thing went live to make sure it was working right.
I think it is a variant of "assumed correct" which gets me into all kinds of trouble when I make that assumption.
Yes. 51 years in business. I'm positive that the "hard way" that Dad learnt his lesson was by losing money.
Please do not be judgmental of OP.
Things they did right: 1. Immediately acknowledge the issue and raise it to a Specialist. 2. Give you a work-around, so that you don't need to be blocked. 3. Engage the lead PM, to speak to you, to address your concerns. 4. Fix the documentation first, so others know how to fix this and understand the cases. 5. Take feedback that they need to improve the API. 6. Find which customers had an issue and pro-actively reach out to them. (Isn't this what you wanted in the 1st place?)
Things that didn't go well: 1. Long periods of silence between mails. 2. Lack of a bug bounty, sounds like a pretty big miss on their part and a bug bounty would be nice.
So, yeah, it's absolutely nor clear why the heck the OP is so upset?
This works for any honest business. If you want a custom offering with hand holding, go with 1. If you want a scalable and streamlined unisize business which allows itself to make mistakes in order to build huge things for the masses, go with 2 and accept the losses.
I really dislike the middle ground compromise of having useless conversations with L1 reps who are either incompetent or whose hands are tied. "We've escalated this issue to super-serious, an expert will reach out to you within the next decade".
What do you mean by "reasonable"?
Because, while I wish it were so, I have never ever experienced support as responsive as sales.
> In the mean time, I had also been reaching out to, who best I can tell, was the product manager or product lead for Stripe Tax because I had her email address and contact information from previously discussing Stripe Tax with her.
Ironically the PM was a fair bit more responsive than Support.
Overall my experience with stripe has been pretty negative and the large gap between my perception of the quality of their products, and the reality I discovered in actually using them has made me realize how much effort they put in to marketing to developers.
However, after the trial and when your customer starts paying, you'll have an invoice that's >$0—that's when the Stripe Tax fee would be charged.
We talk about a bit about this in https://stripe.com/docs/tax/faq#when-do-you-charge-a-fee-for..., but we'll try to update this with a clearer explanation.
I appreciate your help in the past getting our business unblacklisted from Stripe in the past.
Stripe seems to be trying to move up the value chain, but problems like this tax calculation issue and the fear of Stripe deciding to brick the accounts of businesses keeps other businesses and worker owned co-ops in the industry I work in from considering Stripe.
Does Stripe plan to review and unban accounts of businesses that were solely banned for being in formerly undesirable or blacklisted categories?
Additionally, emails like the one below do spook me: Our data shows that 72% of your transactions in the past six months were recurring and you are not currently automating recurring payments. Stripe Billing can make it easier and faster for your customers to pay you on a recurring basis.
We use an off the shelf open source invoicing system to connect to Stripe, First Data, our local tax authority and the rest of our infrastructure, which is already automating the recurring billings for our clients without Stripe Billing.
I'm unclear what value Stripe has to add here besides putting all our eggs in one basket (risking potential lockout again), and these types of emails make it clear that Stripe is mining the subset of data you get from us and our clients, though the fact that we're reusing payment tokens via API was missed entirely in this marketing email...
I think the problem is. When I used them like 5-6 years ago, their offering was absolutely legendary. So much so that I happily moved over from 1.5% fees on Authorize to 3% on Stripe.
Right now? It’s basically become everything it seemed to be fighting against in the past.
The business I’m working at now splits traffic between adyen, stripe, and others. Anecdotally, stripe has the best payment success rate of any of our providers.
I know of Chargebee, Recurly, etc but I'm not sure those companies will let you actually spread payments between or if you pick one provider and use that. I've had people ask me if I knew of a company/product that could let them be less reliant on Stripe alone.
"adyen-checkout": "prod_assets_web_modules/adyen-checkout"
I don't think I have ever had an actual good experience with Stripe
Here is a couple of examples
- The account manager assigned to us was absolutely horrible. Would not answer emails. Getting information out of him was like pulling water from stone. And our business is a global company with annual revenues in the hundreds of millions of dollars. He couldn't care less.
- Stripe support... I have an email thread with these guys that reads like a "who's on first base" script. I still read it sometimes for a laugh and make sure I wasn't dreaming the whole thing.
Boggles the mind that Stripe is worth many tens of billions of dollars. I want to invest in their marketing partners. Those guys are doing a fantastic job.
EDIT: If anyone senior from Stripe is reading this; reply back and I might be able to provide you more details. I really want someone at Stripe to read that support email thread and tell me what they honestly think.
They will relay some unrelated bit of documentation and then immediately try to close the issue as solved.
It is like “Step 1: Understand the problem” and “Step X: Validate it solved the customers problem” isn’t even on the checklist.
Just “reply something technical, close ticket, repeat”.
You charge an extra fee for Stripe Tax; your paying product had an issue.
When companies behave this way it feels like you're being gaslit, which is extremely frustrating. The author may have gotten the result they initially wanted, but it would have felt like a huge, disrespectful, slap in the face.
Here you are: http://www.paulgraham.com/lwba.html
As he points out in the article, they alerted him to the documentation updates in the course of their emails back and forth.
Fair point about being frustrated with the initial customer support experience, though. Definitely crappy.
Technically, this is true. From the story though, it sounds like the PM included this information after the author reached out to the PM directly. Only after that did support say "I see we reached out to you about documentation updated!".
So while yes, they did technically tell the author about the documentation update, I'm not sure I would classify it as them "alerting" the author.
Exactly the case, and it's because he happened to have the PMs email. Not because Stripe gave it to him or offered to send the PM his way.
If they have a pattern of customer service problems then it's best that people know it.
I don’t mind them publishing this. It doesn’t feel unfair or dramatizing or in bad faith (etc.)
At the end of the day we build things to try and make other humans’ lives easier; to wrap the complexities of “global financial internet infrastructure” so business owners like the OP can focus on things that are not “collecting Canadian taxes”.
Whether Stripe ended up making the “right” changes in this case or not, we didn’t hit that bar.
And as “someone who works for Stripe but absolutely in no way speaks for Stripe”, it’s a productive reminder of the downstream effects of what we build. What we build has real world implications, ones people at Stripe take very seriously.
It hurts to read about the misses, but I would 10000% rather read about it on the front page of HN than us not know about it. And in this case, again, what they wrote doesn’t feel like it’s in bad faith, so it’s useful feedback.
Not a stripe employee, but this is why I’m glad this was written and published, too.
Obviously the author is upset — I would be, too! — but even if I don’t totally agree with them, they presented their story in a very reasonable, non-inflammatory way, and suggested improvements.
That’s going above and beyond, as far “customer complaint” goes.
Eighty times out of a hundred, it's solid signal of something.
Nineteen times out of a hundred, it's hilariously off base in a way that's good for a laugh.
It's only maybe that one percent that I wish someone had kept their rude/bad/ignorant/whatever opinion to themselves -- but the eighty percent are worth being 'put on blast' however many times, because that's how you stay focused on making things better. (And the nineteen remind you not to take it too seriously)
One of the best things you can do is catch all their webhooks, handle the ones you expect to receive, and raise a serious alarm for ANY others. Then prioritize properly handling those unknown alarms and setup your own notification/escalation system as needed for the important ones.
If you are short on dev hours, then use something like Zapier to catch the webhooks for you and forward critical ones to you in a way you will acknowledge. This strategy doesn't work as well with NEW webhooks so you'll still need to do the first option at some point.
> No failed API calls (as far as I could tell).
I can't help but wonder whether that "as far as I could tell" is carrying a lot more weight than it might first appear.
Stripe's documentation under "Collect taxes for recurring payments" explains,
Creating or updating a subscription that causes an immediate invoice and payment attempt errors with an HTTP status 400 response. Updating a subscription that does not cause an immediate invoice or payment attempt returns an HTTP status 200 response. However, the customer location validation happens later asynchronously when the invoice is finalized. If the customer location is invalid during invoice finalization, Stripe sends a invoice.finalization_failed webhook. If you don’t take any action, the invoice remains in a draft state.
Which at least suggests that Stripe's API will, in fact, inform you of invoices that fail for precisely this condition.
So is it at least possible that the author "built out [their] Stripe Tax integration" either without implementing what would seem offhand to be an extremely important webhook, or implementing it but not surfacing its results in a timely, actionable way?
Stripe needs to offer solutions 100x better than what we build, 10x as fast. That was the premise of the original product, now the “easy stuff” is glossed.
It's always a risk to make assumptions, but I don't think this specific assumption was unreasonable.
Like, why do we even need Payment Intent? I just want to make a Checkout session, set a few variables, and have it return whether the same Checkout session was successful or not, how much was charged, and the line items for it in one request, not four, five if unoptimized.
Could be to support payment methods in Europe and countries other than the US?
https://stripe.com/payments/checkout
It's supposed to make payments easier with a Stripe-hosted payments page. However, creating a server-side Checkout session, and then getting line items from an order, is an unnecessarily convoluted series of requests.
Stripe::Checkout::Session.retrieve({ id: session_id, expand: ['line_items', 'customer'] })
But what is your definition of "check to make sure the integration was working correctly"? Once you know what was going wrong, it's easy but unhelpful to say "you should have checked to see if that thing was going wrong".
He had dashboards indicating "situation normal", and there was no specific advice that he check that an avalanche of draft invoices was silently piling up.
Given that Stripe advertises itself as making payments easy, it seems like it should take responsibility for making them easy, instead of having hidden pitfalls that silently tank your revenue.
>I had noticed that my cashflow for the previous 2-3 months seemed to be tanking a bit
A bit? Revenue from all US customers went to zero for three months! That should have been a giant hole. This is like driving your car into a lake, hearing a "bang" as the engine explodes, then complaining that there's no "you have driven into a lake" warning light on the dashboard.
I don't know what else is going on in this guy's life, except he's got kids so that's already a lot.
> I deployed it on November 6, 2021, the same day that Stripe stopped billing a significant number of my customers, left all their invoices in a Draft state, and didn’t tell me about it.
So at least a significantly large portion are outside of Canada.
> I have functionally 1/3 of my customers that I am going to have to back-bill for months of subscription fees
Since they also mention that they would like to hear what people think about this situation, here's my take:
They deployed a major change/migration to their billing system, implementing a brand new product, and seemingly didn't bother to investigate how it was going beyond cursory looks at a dashboard. Even though they did notice a strange dip in revenue. That seems fairly negligent for one of the most critical aspects of your product. Doesn't take that much time to take a glance at a more detailed view than a dashboard.
Stripe definitely could have been sending more notifications of failed invoices, made the documentation more clear, or been smarter about disabling automatic_tax for customers outside the user's tax jurisdiction. I don't know if the webhooks solution they mention is their standard for these kind of things or how much responsibility is reasonable for the user to monitor those. It does sound like they have/had at least some deficiencies with the new product that would have warranted a more generous response.
The author did seem to realize what was up and how they could have fixed it but chose not to because they were mad at Stripe. I feel like the wrath is somewhat overblown, sometimes you take a risk on a brand new product and have to babysit it a bit more than something mature.
> But what is your definition of "check to make sure the integration was working correctly"? Once you know what was going wrong, it's easy but unhelpful to say "you should have checked to see if that thing was going wrong".
I'm sure he checked that Canadian tax was working, because that's what he bought Stripe Tax for. He didn't expect it to silently screw up his US customer payments, because he did not need to pay tax for them. He reasonably expected that Stripe Tax should have no impact on the payment of invoices for which no tax is owed.
If you only sell locally then it's not exactly hard to implement and stay up to date with the requirements where you live.
It's an incredibly thorough treatment of the incentives and psychology that lead to people labeling process failures as 'human error'.
Most of the book deals with manufacturing, aviation, and air control failures, but the principles generalize so easily to software development that it's a treat to read. One thing that makes it so good is that I was vaguely aware of most of what he covers before having read it, but reading him stitch it all together brought me to the point of intuitively understanding the concepts that had been floating in the back of my mind, and being able to see them all around me at work. He puts it together so smoothly that after having read it, it felt like I always knew what I had just learned.
It's super expensive on amazon https://www.amazon.com/Field-Guide-Understanding-Human-Error... but available on all the online library sites that aren't for linking in polite company. It's also on audible.
Enabling tax support in Canada breaks US subscriptions... who knew.
> I built out my Stripe Tax integration, made sure I had all the addresses I needed for my Canadian customers (Canada is the only jurisdiction I run my business, and therefore only need to charge tax to Canadian customers), and updated all my customer subscriptions, awaiting the glory of automatic GST, HST and PST to be charged, and Stripe Tax taking all my headaches away.
> I deployed it on November 6, 2021, the same day that Stripe stopped billing a significant number of my customers, left all their invoices in a Draft state, and didn’t tell me about it.
The whole selling point of Stripe Tax is that it calculates tax for customers in every supported location. It needs customer location to function. He's supposed to charge tax in other locations where it's required too.
Using Stripe Tax to only handle tax for customers in the home region of the company when the company also sells outside the home region seems like a strange goal.
Missing the forest for the trees.
It's a common goal. When becoming compliant with sales tax laws, it makes sense to prioritize the states/countries where the business has a physical presence.
https://en.wikipedia.org/wiki/Sales_tax#Enforcement_of_tax_o...
It's your responsibility but only over a threshold (and the rules / amount are different in every US state)
Still, the Stripe folks could have at least offered to help him collect the back payments, and (better yet) send an email to his customers taking the blame for this (which would cost them nothing and would reduce the harm to his business).
So sure, just do your absolute best to shirk your legal obligations. Most companies do. But most companies didn’t have Stripes’s reputation.
That said, I personally don’t think this is what Stripe is doing. I think they STILL aren’t 100% sure what the whole situation is and they don’t have anyone close to this who is willing and knowledgeable enough to call the shots any more quickly.
So it looks like a long investigation in parallel with the fix, and maybe some external feedback (this letter, some minor legal discussions with affected parties), will help provide the learnings and context necessary to actually understand what the effects were and what their responsibilities are.
They may not be able to make it right immediately even if they want to because they’re not quite sure what (precisely) they legally screwed up and how that affects each customer.
So, there’s a fine line between malice and local incompetency (which doesn’t even have to be massive incompetency! Someone who has 95% of all the experience they need for the role could get caught off guard in this situation). I’m sure stripe has the expertise it needs for this, it just might not have been in this group at the time.
Of course Stripe isn’t blameless as a company, they’re a huge financial company with more than enough resources to prevent, mitigate, and recompensate these kinds of accidents.
It’s understandable that things can fall through the cracks in such an ambitious tax engine.
But enabling an auto-magic feature for a business-critical operation (invoicing and taxes) and not even checking if it worked? Sorry to say that but it is utterly irresponsible. Heck, even the invoice numbers must not have matched. And the draft invoices piling up for months must have been visible too.
I was wondering about this as well. Author seems to have checked several dashboards and metrics, yet still missed it. Feels like a clear UX bug if they didn't at least have a way to alert or monitor for drafts that are never sent, especially if they are recurring on the same accounts.
When I reached out to support, I also felt insulted and like I was begging my cable company to refund the $5 they owed me. They refused to acknowledge that their product is broken or take any blame.
I'm honestly just waiting for a good Stripe alternative to pop up so they can't get away with these product issues and bad customer support policies so easily.
Anything to do with money and tax internationally is complex, and it should be monitored at least until you know it works, e.g. put dates in your diary to check your first international customers paid the right tax?
I must say, the Stripe chat session support people are heroes when you consider the breadth of the topic area they are covering, and some of the random chat abuse they must get from confused end user customers, and I don't think they deserved the fake-swear or some of that tone.
Especially when the writer concedes he could have been productive in the meantime. Some of this stuff just goes with the territory, and they are a business, not magicians.
There's also a sandbox -- is the writer saying there was no way to find this out through testing in the sandbox?
I have had one experience like this where I got a result I did not expect on live compared with the sandbox, which came down to quirks of my sandbox testing.
Specifically to do with trying to speed up testing [0]. I was getting payment collection tested within the day, but that meant a setting that affected something that happened at the end of the billing day never showed an impact in testing; on live it always would. That outcome, I think, could have been covered in a footnote like the one that was added after the writer's experience.
The reality is that Stripe's documentation is heroically excellent (a counterpoint to the Hugo story yesterday) but their system is vast and has all sorts of complex real-world interactions. They have shown they are responsive by correcting the documentation going forward.
[0] About the only thing I wish you could do that you cannot, is accelerate time in the sandbox, to make stuff like this easier to test. I understand why you can't but this is my fantasy. A stateful Stripe Connect mock would be useful though; I had to add one to my app.
For the most part you test your app in development the way you test any app that uses a third-party API service: by carefully reading the documentation, faking/stubbing responses and triggering your own webhooks with example data (which you can do from their devtools).
So beyond that, a sandbox that does everything the same way the live environment does except actually move money is actually the right kind of sandbox.
There are some narrow situations in Stripe Connect testing where it would be really nice to be able to tell Stripe to count days as minutes, though it does seem to ignore initial delay_days delays which is the most important one.
An official stateful Stripe mock with Connect support and webhook triggering would be useful (localstripe is excellent but lacks this).
But you shouldn't dive into Stripe Connect without knowing that it gets complex if you're deploying it globally, and I dare say the same applies to automatic taxation across different jurisdictions. You're going to need to know how to test this.
Thanks so much for pointing this out.
Looks like is is only for Billing/Subscriptions, rather than for the inter-account events in Stripe Connect that I am referring to in my case. At least so far. Oh I would _love_ time acceleration for Connect.
But it could have helped the writer of the original post test stuff out.
All I can say is they probably built this in a hurry and the workflows weren't really tested or checked by humans. I call it "But CI is green" syndrome.
[edit] I’m willing to be educated, please tell me how this isn’t Invoices with stored payments (which I’ve now seen has an additional fee too)
I say this, still about to use it in production. It upsets me that the amount of work I have to put in to getting Billing working doesn't seem to justify a percentage price. A set fee, sure. Riding along with my services' value? No.
Whether Stripe's price is worth it is subjective, but something that is absolute fact is that whatever you've built doesn't compare. I can tell you that with absolute certainty, even without having seen any of what you've built.
Consider this. Consider that you don't understand why what you perceive as the added value from Stripe Billing "isn't justified" (despite a LOT of businesses paying for it). Consider that you might be missing something. And you say you haven't even used your service in production yet?
This is a case of "could build the service in a weekend". Hey, have at it, but when customers come to you asking for a billing-related feature and you don't have it because you'd have to build it (instead of toggling a switch in a dashboard), or when your cron fails which causes incorrect billing and costs your business a lot of irrecoverable money (instead of just asking support for a correction), then think back about your choices.
Again, have at it, plenty of businesses do this themselves. But most of them regret it in hindsight, because it's not their core competency and shouldn't be.
However, I still don’t see the specifications difference in the checkouts (self hosted pages, pdfs, fraud protection) and Invoicing (reminder emails, retry payments, and end of service notifications, etc) - save the repeated nature of the subscription and if a stretch for you the subscription management / trials.
I’m saying 9/10ths of billing is covered in their 2.9 + .30 offering…
Again please tell me where my perception is off - I’d much rather learn - I just don’t see it
Also note that IAP is the infamous in app purchase from Apple — that I truly adore for the 30% because it actually does the things that are hard to do.
It's been a long time for Stripe to introduce a solution for taxes after it was requested by lots of customers (and recently acquired TaxJar because of it)
The US just has a convoluted tax system.
I wouldn't go as far as to say they've fallen to the "bean counters" but they definitely aren't as customer obsessed as they have been in the past and quite a few gaps in their armor are becoming obvious.
But it does sound like we did drop the ball with you, and I'd like to figure out what happened if you could forward me an example at edwin@stripe.com.
They are arguably best in the industry doesn't mean they are as good as they once were. Apple Retail experience, App Store curation. Butterfly Keyboard? If if it trend we are talking about then Apple is no different to other company you mentioned.
The merchant of Record will then act as a middleman/reseller between your SaaS and a consumer, and will take full responsibility not only for calculating, but also collecting and filing taxes in any of the jurisdictions.
As a SaaS, all you get from MoR is one payment at a defined schedule. Any errors in tax calculation, reporting, filing are not your problem, it's their problem.
Stripe Tax costs the same as Merchant of Record, but it doesn't do anything they do. Yes, they help you calculate the tax amount, give you the summary, but it's you that still need to file taxes correctly everywhere in the world, and it's still you that is responsible for Stripe Tax mistakes.
Until Stripe can act as a full Merchant of Record, I don't see a reason to use them unless one sells only in one (home) country.
Gumroad is nicer from the indie developer perspective, less restrictive than Paddle regarding product types sold, but shopping card and pricing are more limited (USD prices w/o VAT only).
Stripe is still better from the developer's standpoint, more mature and nicer integration / API, but doesn't handle tax filing. Would use it if developing a product for a single market.
IMHO stripe has become far too complex and people are relying on them for a critical part of their products without a fallback. I've seen a few occurrences lately where bugs, random account blocks etc have taken Stripe payments offline and suddenly the revenue stream tanks.
Always have a backup payment provider!
Have you been able to get Stripe to export your clients card data and ACH details to your backup processor?
Curious as I'd love to have automated payment provider redundancy and replication for recurring invoices.
1. Generic answer that "yep, it's not working, here's how to fix it" 2. Updating documentation to make it better. 3. Somebody saying "what should we do about all the other customers in the same situation? can we just shut up about it?" leading to the last email.
And then... yeah, you can't directly apologize and take responsibility because that would cost you a fortune (and really, back billing is the right answer, though maybe he could in turn offer his customers a month's discount or something). Maybe Stripe could waive some fees for a while or something, but you have to have some limits on hard to use but technically correct situations.
The system is truly working when you can just play dumb and rest easy knowing everyone you screwed is too poor to do anything about the situation in court
I get emails coming in to random (but valid) email addresses for purchases I make with vendors using Stripe. For example, I've seen Internet domain renewal charge confirmation notices going to my auto repair email address, and I've seen telecom hardware purchase confirmations going to my Jersey Mikes (sub shop) account email.
I suspect that this is another example of "you are the product."
I began to draft an email with many attached receipts demonstrating the email confusion, but then I realized they were all from Square and not from Stripe.
Please accept my apologies for the above post. I would remove it if I could.
Sorry.
There are so many ways that billing can fail and they all result in cash flow problems which is incredibly stressful.
Where your business is located doesn't necessarily mean anything. The location of the customer is what usually matters. You'll most likely have to register in quite a few places and keep up with tax reporting, payments, and rules everywhere you're registered.
Stripe sent me an email saying the payment had been “processed”, so I gave them the $3000 item. I later logged in and noticed “processed” meant “processing”, and the stolen card bounced at the bank a week later. They refused to take responsibility for sending me an email that clearly said the payment had been fully processed when it in fact had not been, allowing the item to be stolen.
Stripe support mocked me. They refused to cover the money and I never used them again. The only redeeming factor was it logged their IP address in the card logs, so I gave it to the police and they caught someone who had stolen hundreds of other items (but still no recuperation of lost funds for me).
I only use PayPal now. Never had an issue with PayPal, and they have always fully insured all transfers. No confusing transaction states that offload responsibility as a payment processor. None of this “we take a huge cut, but actually grant you no protection” garbage.
PayPal does not protect you from stolen cards, at least they'd didn't back then (5 years ago maybe?)
Still, the post is equally a massive self-own. In what business can you be so lax about cash flow, the most important business metric ever, as to concluding that it "feels" off after some 3 months and then think it will somehow even out over time? And only because you were alerted by a customer?
What would happen without that customer? A few more months of tanking financials before you wake up?
I must be a dinosaur to believe that order intake/management, invoices, tax and payments is something you're absolutely on top of, on a daily basis. It's the very core of every business. Either you do it or your accountant does it.
It doesn't matter if you use Stripe or a piece of paper, this is a thing to be on top of. Did I get paid is the #1 business question, nothing else matter in comparison.
Further, OP implemented a tax module, didn't bother to read the migration guide, and tested nothing. Same problem: an unmanaged business. You should not miss 3 months worth of draft invoices.
Still, we all make mistakes, Stripe could definitely have done better as well, so some irrational anger is understandable. Yet I find it very sour how some poor support team is hung out to dry.
Disclosing all of this in this amount of needless detail is close to doxing. Next, it is shared far and wide after which many people can pile on to the team. I find that disproportional and in poor taste. You can tell how even when the problem is clear and some acknowledgement is given, it's not enough. It's as if OP want theirs heads. Revenge.
Don't humiliate support teams. If you want compensation, be clear about what you want exactly. They aren't going to rectify you with a full page ad in the NY Times.
This is not a field where you want complexity or cognitive overhead.
I've encountered some ugly code while consulting in the payments space and had to educate and advocate (sometimes less gently than that word conveys) with developers concepts like atomicity, rollback, instrumentation, reconciliation, monitoring, diagnosability, etc. even after their creations had misplaced literally hundreds of thousands of dollars. It's always easy to blame the user; a good developer/architect understands how their code/systems can fail and stays on the lookout for edge cases and potential gaps.
I suspect (hope) that in a few years most billing/payment systems will take care of this for you (either natively or through a seamless partnership) so you just fill out a few forms and forget about it.
Not sure how you can even start a business, sell stuff and not collect VAT right from the start. Here in Europe this is unthinkable.
That being said, my sites have thousands of subscribers. If subscriptions were off by a cent at any point in time, things would have been red flagged, and I would have contacted them (Strip, that is). I do have a backup payment processor, and assuming both are unavailable due to negligence on the providers' end or my own, I give the users the month for free. I had to do this exactly once in 15 years.
Stripe, without a doubt, screwed up, and the writer was correct in taking them to task, however, end users should have been let off the hook. It sounds like the write wanted to back bill them for it.
You should absolutely not be tossing this at customers, I would have thanked the customer, then I would have given them several months free while I resolved the issue.
Customers should be first. I actually had to archive a site recently due to declines in my ability to update it. The customers involved weren't unhappy about my ability to keep it updated, they were unhappy that I was shutting out their ability to support the site.
Treat your customers like gold. I promise you won't regret. I had someone try to donate thousands to me to keep a site online. I declined and kept the site online and archived for free.
Is this true? Don't you always have to collect/pay local taxes if you are selling stuff in a country? For example, you sell to a customer in Germany, your price must include German VAT.
The details vary for the EU depending on whether the product is business-to-consumer or B2B and what kind of volume we're talking about. Some countries, such as the US, have a double taxation treaty with the EU that allows you to use a self-charge VAT structure when you do small amount of sales which has the effect of not needing the US seller to register for VAT, provided your tax authority (ie the IRS) authorizes you to participate under that treaty.
Correct handling of sales tax/VAT globally is complicated and I definitely had a "oh honey" moment when reading that sentence as well.
Stripe has expanded by offering to take care of that for customers. That has two consequences: (1) obviously that means Stripe has to take care of the complexity with the added problem that each customer has a specific use-case and (2) customers must still make the effort to understand exactly how Stripe's system works and implement extensive checks and reports (That's always the case with payments but even more as you entrust more business logic to a third party).
Not taking (2) seriously will hit you. If you notice an issue because a customer actually took the time to contact you because they have not been charged in several months, it definitely means that you have not followed through on (2) at all.
For small businesses, you probably know better than Stripe what taxes you need to pay (no wonder how complicate they may be).
Besides, your reasoning that you need to charge only canadian VAT is incorrect. If you sell to EU non business customers you need to charge EU VAT. If you sell over a certain threshold in most US states, you need to charge their sales tax. Australia is also threshold based.
Now, my business is small enough I can ignore safely all the threshold for the foreseeable future (sigh) but I do need to track every damn European penny (and I don't sell to EU customers some services just because of this).
What a way to avoid saying "problem", "bug", "issue" or any other term that might be perceived negatively in a lawsuit.
This potential issue was flagged in the documentation.
I don’t want to “blame the victim,” but I don’t see Stripe As particularly culpable here.
I think general etiquette with discussion forums is to post links to a variety of sources, not just your own content.