My dad owns a successful chain of bicycle stores in Texas. He’s been in business for almost 51 years and he’s one of the largest bike dealers by volume in the country. He has nearly a hundred employees and a bookkeeper. Despite having a proverbial dozen balls in the air at any time and despite having people on the payroll to do bookkeeping, he sits down at his computer every night at home, logs into the ERP system, and reviews sales and receipts. He catches all kinds of crazy things. Credit card fraud (before the chargeback even comes), internal theft, mis-priced items, mistakes, you name it. He has great employees but even the best make mistakes and he’s learned this habit over the decades the hard way. I remember sitting next to him as a kid, watching him pour over cash register journal tapes that were yards long, looking for problems.
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.
> 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.
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?
It is, unfortunately, an extremely common discussion. That or some close variant of.
It's funny that, with the importance of tax to government revenue, why do governments not make a habit of funding/creating really high quality tax software for businesses/individuals to use? Increases in collection efficiency have historically been associated with growth of the state coffers (and state's whose bureacracies failed to adequately capture tax had to resort to funding themselves in other ways, frequently in the past through "expansionist tendencies", ie, war--for territory, resources etc...which then only works if you can pay for soldiers and equipment). Not that governments seem great at making software (in general), but with something so critical, a focus on this seems like a "sort of" low-hanging fruit...
> It's funny that, with the importance of tax to government revenue, why do governments not make a habit of funding/creating really high quality tax software for businesses/individuals to use?
Not just the “TurboTax” lobby, but also a strong contingent of anti-tax conservatives. One of their approaches to gain sympathy to their cause is to keep making taxes hard. If taxes are hard, the general population will want less of them.
>One of their approaches to gain sympathy to their cause is to keep making taxes hard
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.
Straight from the horses mouth. Grover Nordquist and other anti-tax conservatives have been staunchly against allowing the IRS to do any sort of tax prep for the public for fear that will somehow lead to more taxes (ignoring the fact the IRS doesn’t create tax policy out of thin air).
You seem to recognize that "tax prep" and "tax code" are completely different things, so I don't understand how or why you are making this your argument. Simplifying the tax code is much more a right-wing thing, maybe even an entirely right-wing thing.
Because I was responding to a question specifically about government-provided tax prep solutions...
why do governments not make a habit of funding/creating really high quality tax software
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.
Your comment was showing up as a reply to mine, so I assumed you were responding to me.
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.
The only right wing proposals to "simplify" the tax code have been ridiculous proposals like the flat tax.
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.
>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.
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.
A progressive tax treats everyone equally. It taxes Jeff Bezos the same rate for the first $25k as it does me. Just like it would charge me the same rate for the last billion I earned. Everyone lives by the same set of rules. Anyway, progressive vs flat tax is orthogonal to simplifying the tax code because a graduated tax rate is not complex and is the very least of our current worries when it comes to tax code complexity.
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.
>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.
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.
That's not fully true. There is also a contingent of people who like to use the the tax code as a mechanism of policy apart from efficient collection of revenue.
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.
While all of this is true, other countries have a system where the government tells you what tax they believe you owe, and provide the details of how they reached this number.
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.
One thing to add: You're typically still obligated to file a return if the prepared taxes are not correct. You're not "off the hook" in any way by accepting what the prepared statement says. This mostly bites e.g. entrepreneurs with more complicated taxes, especially if you filed for an extension on the business side.
> There is also a contingent of people who like to use the the tax code as a mechanism of policy apart from efficient collection of revenue.
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.
In the US that's mostly because that's the biggest lever the Federal government has to pull. The power to legislate things within states directly is mostly devolved to the states so Congress mostly has the tax code to point a firehose of money to incentivize things. It's why the Affordable Care Act hinged on the individual mandate initially, all the regulation of healthcare legally depended on the existence of a tax to put it in Congress's legal authority.
One could make taxes very easy in a way that would definitely boost the popularity of the anti-tax crowd. Makes taxes a single bill sent out at tax time. No tax collections, not withholdings, etc. You get a bill, you log into an IRS website, enter in the information for donations, dependents, etc., and you get your final bill you have to pay. IRS can even prepopulate that data for you and just have you sign off or make any needed modifications.
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.
Given how bad people are with money, the number of people who can't pay their taxes would skyrocket if withholding is replaced with the scheme you are proposing.
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.
>Given how bad people are with money, the number of people who can't pay their taxes would skyrocket if withholding is replaced with the scheme you are proposing.
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.
> why do governments not make a habit of funding/creating really high quality tax software for businesses/individuals to use?
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.
I have enough experience with local and federal government that there is no way I want them to build any kind of software. Much less a complicated tax software.
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.
The software would have to work everywhere. The tax collections (review/enforcement, really) process only has to work in one place. Tax law in one place is usually clear enough; the complexity is in the aggregate.
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.
The federal government is only one part of it. States, counties, and cities can also impose their own income taxes or sales tax. Or like Florida they can choose not to have an income tax.
I suppose that would be like asking the EU commission to provide tax software for all its member states.
Not sure how software is going to always find "...credit card fraud, internal theft, mis-priced items, mistakes....".
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.
> why do governments not make a habit of funding/creating really high quality tax software for businesses/individuals to use?
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.)
That said, congress could fund this tomorrow if they wanted. Budgetary concerns apply to executive actions in this arena, but the whole idea sounds like it's necessary and proper for smooth interstate commerce.
That’s honestly only a small part of why I would never want this. More significant, for me, is that this TaxSoftware.gov idea would mean literally thousands more employees on the government payroll, being ineffectual, slow, and bureaucratic. And when their government career is finally over, those people will all take home government pensions, as will their future replacements. Once you create more government, it will never end and will never go away.
“The only thing government is good at is creating more government.”
- P.J. O’Rourke
Well, I am sorry but in my eyes this just shows bad product quality, bad transparance and missing understanding of basic business stuff on the side of the product. The only reason for software to be existing is to NOT mandate users to check stuff manually.
> The only reason for software to be existing is to NOT mandate users to check stuff manually.
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.
As it happens, I'm reading this thread while taking a break from writing tax handling in a piece of e-commerce software.
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.
Everything you wrote is correct. But still, if your product does not transparently show and alert such events, overall product quality is in my opinion bad. Dev or lead or product manager should not be ok with this. But this pretty mich reflects current state of software development. Errors and stuff are in way too many cases "ok" to occure.
I think what the poster is saying is that, as far as the software is concerned there IS no event to alert. You live in the US, but setup the taxes as if you live in the Caribbean? You're responsible for the setup, and as a business owner responsible for either setting it up correctly, verifying that someone set it up correctly or paying the auditors to do that for 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.
Not AI, just statistics and double checks. In the old days that was done by people that knew what they were doing now it's a job for programmers. Having alerts about too many strange entries in the transaction log/inventory is something I've implemented.
I agree 110%!! This is just a miss by developers who do not understand the use case and business impact. I have rarely seen systems that implemented business logic alerting until after the company has been screwed. Perhaps not even then. It is a disconnect between the developers and the business. Stripe should be sending emails/notifications as invoices pile up in the "draft" state. That edge case was never examined. Total miss and prime example of the move fast and break things world we live in now. I view these services like Stripe as cutesy little services because of this and I would never trust my business to them. Diligence is on you but the marketing department sells the opposite to unsophisticated customers.
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.
No disagreement at all that ERPs are generally garbage, especially for how much they cost. But this comments makes me think you have never dealt with international taxes. The rules are insanely complex, there is no global standard for communicating the tax, multiple systems have to be in sync with each other, and some systems even use different rounding algorithms...
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.
Users should be doing sanity checks of financial transactions on a regular basis. You even want an external party doing audits as frequently as is reasonable.
That doesn’t mean every transaction needs to be manually revived, but major outliers and a random sampling is a good idea.
I tell my clients all the time why I can't just make a "quick change" and I have to manually review the data sometimes and go through a ton of code review. I tell them...
> 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.
The existence of audit & compliance responsibilities does not abolish the responsibility of the software to reduce foot-guns. The number of people here arguing the opposite is completely insane.
A re-reading of the remarks suggests to me that they aren't arguing exactly the opposite. I'd put forward, after all, that no-one wants to create footguns, but folks are recognising that footguns are inevitable anyway, so plan accordingly.
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.
Quickbooks takes a stab to categorize my books for me. But you better believe, while I’m no CPA, I’m in the books at least once a week making a modicum of effort to understand and work on these things.
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.
So software is a "guarantee" thing already that people can trust in? I wonder how many software engineers will be out of their jobs if that actually happens, we will see
This applies to every industry and consequential process unfortunately. Take something like GDPR deletion requests. Many mid-to-large organizations have automated flows setup to purge accounts after users make requests after very detailed planning with legal and compliance teams. Companies assume this is the end of it and that they don't have to audit and perform maintenance at the engineering team level because it's something that someone in support or another team shoved off the side will own. What you find is one time it's not purging file uploads, other times it's not purging user PII, etc.
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.
One more thing to add to this: scrutinizing transactions isn’t just for catching bad stuff. It’s also a way to spot the good. For my dad, it’s a way to spot up-and-coming salespeople who are punching above their weight, for noticing high-dollar sales to repeat customers and making sure that those folks are well cared-for. It also tells him what bikes are selling well and helps him make strategic decisions for buying.
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.
To be fair, in this case, the author was tracking his KPIs, and those suggested that all was hunky dory, but what he wasn’t tracking were the actual payments being received against invoices that never converted to an open state. In this case, the invoices were left in a draft state on Stripe’s side. And who could’ve expected that they’d need to occasionally check for draft invoices?
It seems like it wasn’t made clear in the docs that invoices aren’t finalized in these circumstances until later.
This sounds like something good old fashioned double-entry bookkeeping would have caught immediately (hunky dory income from Stripe seemingly falling into a black hole). No need to scrutinize every transaction until you notice the ledger isn't adding up.
Double entry booking would have shown a growing accounting accounts receivable and an undersized cash account. Sure, you might dig into why that is, but it wouldn't leap out.
Heck, in many ways, double entry bookkeeping on the accrual basis would be less likely to notice it.
It sounds like a classic example of how accrual bookkeeping can be misleading due to timing issues (the sale has already been booked even though the cash hasn’t been collected). I know it has other advantages vs. cash bookkeeping, but cash is so much easier to understand that I have always chosen it whenever possible (i.e., for a service business).
Could you? I thought accrual methods weren't allowed to think about future probabilities and had to decide on whether to recognize an event or not. I mean, if you had counterparty risk insurance, that would make sense. So I guess if you treated yourself as self insured, you would could create the same accounting treatment?
I don't know about what's legally allowed or not. (Might also depend on jurisdiction.)
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.
Depending on the process, maybe. I don’t know the landscape of accounting integrations with Stripe, but I probably wouldn’t want to sync a Stripe draft invoice as an open invoice to my accounting app. If there’s no open invoice, there’s no reference in the GL, and there’s nothing to be caught apart from an informal ‘cash flow seems to have taken a hit’.
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.
I don’t think it would. All the invoices were left in a Draft state, so I don’t think that appears on your ledger. You’d have to look at your list of Draft invoices to see it going up and up.
That feels weird to me. If some dashboard is telling me "nice, your revenue is growing!", but the money actually flowing into the bank account doesn't look right, I'm going to investigate. Immediately. I'm not going to just trust those metrics when the actual real-world measure doesn't match.
What is weird is how their accounting software didn't raise 5 different alerts when they have AR outside of their due dates. I have a small business and mine raises alerts all over the place when something slips the due date for AR.
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.
You’re absolutely right and to be clear, my dad also pours over data roll-ups, charts, etc., but he’s never stopped looking at receipts. It’s a habit he’s had since the 70s. Back in the day, he used these electro-mechanical cash registers that had very loud typewriter-like receipt printers. At the end of the day, the manager would run the journal and my dad—-in his office across the store—tell you what kind of a sales day it was simply by listening to the sound of the register doing the end-of-day sequence.
There's a persistent meme on HN that it's straightforward to make a business that "runs on autopilot", with no human intervention. I'll admit that such a business is possible, but I'm deeply skeptical of the durability of such a business.
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".
LOL, it's true. The idea of the quick exit is also part of the HN culture and I think that would be very foreign to people like my dad. People who build small but profitable, businesses and run them for the long-term are underappreciated in the tech world. I don't know about you but if I was building a SaaS, I'd be looking for the tech equivalent of In-n-Out Burger: something you build and spend most of your time making sure that it does the same thing consistently for years on end, and just enjoy the profits and dependability.
I'm right there with you. I've been building and running a job board for the last few months, and I'm hoping it becomes my own little SW equivalent of an In-N-Out. It's profitable, and slowly growing, so it's moving in the right direction.
Someday it'll be my own personal Double Double Animal Style.
> he sits down at his computer every night at home, logs into the ERP system, and reviews sales and receipts
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.
My dad is not next to me to reply, but your rebuttal patterns a conversation that he and I had many times over the years, when I was first getting my start in business and tried to tell him he was too old fashioned in his business methods. The bottom line is that you absolutely have to be involved in all levels of your business if you want to be successful and don’t want to be taken advantage of by the unscrupulous. This doesn’t mean that you shouldn’t trust your folks. In fact, he’ll be the first to tell you that you have to trust your people. But, bottom line, you can’t outsource this level of care and attention to detail; you must be involved and you must be constantly on the lookout.
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.
> 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?
> The bottom line is that you absolutely have to be involved in all levels of your business if you want to be successful and don’t want to be taken advantage of by the unscrupulous.
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.
To a point, yes. I mean, bikes have changed a ton in 51 years and I guarantee you my dad would struggle to work on the newfangled high end high tech stuff, nor would he be the guy that you'd want to professionally fit you to your new road bike. He's got people on the payroll who do that, for sure.
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!
I concur. I also happen to run a business and although I employ almost a hundred people I have never let my eyes of the "tape". I trust my team and owe a great amount to them for helping run the business. But if they make a mistake that directly affects my bottom line, it's ultimately my fault.
Similar situation as OP. My dad started the business (his 3rd overall) 22 years ago and it's been growing steadily since. My dad still does daily scans of our ERP. I run the business with him and we have 40 employees, and I too have had similar conversations with him.
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.
> no one else is as invested in your business as you
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.
I think your mentality is right (as a small business owner myself).
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.
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.
Can you share what kind of tasks you've successfully outsourced? In my experience it was very hard to outsource task with a vague definition like "look for things that aren't running smoothly".
The low hanging fruit answer is "admin." It's easy to fall into this trap of "only I know how the whole business runs; so I should just keep doing admin stuff." But you'd be shocked at how quickly a competent administrative assistance can handle some of this stuff (including pre-drafting email responses in your "voice").
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.
While I'm pretty sensitive to "victim-blaming" and feel for the fellow involved here, and there's certainly some evidence that Stripe may have shipped an under-tested product, I would argue that the distance between
> 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.
LOL did you miss the part where he said his dad has 100 employees and is one of the biggest bike dealers in the country? How successful is your company?
You are a business owner?
I have similar experiences as the OP. You cannot simply hire someone to oversee such large extend of information and business. Yeah that would be a CEO. But no ceo is willing to do that shitty administration work. Automation could help maybe. But generally it's just you yourself who needs to do it.
Yeah, this is nuts. Sounds like he has no internal controls, except for going over everything each night. But that’s not a very smart nor efficient way to go about it.
I think this is an unfair comparison. There is a big difference between checking the work of multiple employees who might type stuff in wrong or credit card fraud compared to OP who has a fully integrated billing system provided by a very large and well-funded company who have failed to get some real basics right.
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.
Agreed that Stripe has some product & UX issues here, but if I'm going to make big changes to how my customers are billed and taxed, I'm going to very carefully watch the result of those changes for a while to make sure it's working properly. Seems like OP didn't do that, and that's pretty irresponsible, IMO.
Agree. Such behavior is unacceptable for a paid service. I can understand there would be bugs etc., but leaving draft invoice dangling there without any alarms raised is beyond reasonable. Let invoices go out and help the client collect the money on time is vital for such products. It's eye-opening to see someone blaming the business owner instead of the software vendor.
OP assumed that Stripe would get it right exactly as they wished it would work, and wasn't verifying it. The problem literally started as soon as they enabled it: "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."
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.
> 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.
I think it is a variant of "assumed correct" which gets me into all kinds of trouble when I make that assumption.
It doesn't sound like he reconciles the ERP system to the bank statements every night. That seems to be the appropriate analog. Meanwhile, the author was monitoring all the KPIs, so they were looking at what they should look at.
I would think that "money flowing into my bank account" would be a KPI. OP did seem to notice something was off there, but ignored it! Instead he decided to trust a dashboard that just told him "you revenue is growing, yay!" That seems foolish.
From what I understand from the article, the Stripe dashboard shows nothing wrong, and indeed, apparently shows draft invoices as income, or it’d have been fairly certain the revenue stream had cratered.
I agree that a business owner should be tallying things at minimum every month to make sure numbers add up, but Stripe handled the screw-up poorly, and needs some serious retribution.
Here’s a real example that happened to him a few years ago. He was out of town on business and there was a big sale, around $15K if I recall, to a customer from Mexico. The sale was done just before closing (something he saw in the review) and the card was manually keyed in. The story was that the guy’s card “wasn’t reading” so the employee keyed it in manually, a huge red flag. The charge went through but of course ended up in a charge-back a bit later. If you weren’t scrutinizing your receipts and doing double-checking of the big sales, you might miss this until the chargeback hits. For him, there was nothing to do except educate employees and double-down on policies regarding manually-entered cards, big sales made just before closing, etc.
In a brick-and-mortar business, closing time is when employees (i.e, non-owners) are in a hurry to get the store cleaned up and shut down so that they can go home. They’re tired and they might feel pressured to just get the sale done. Scammers know this and so closing time is a good time to come in and try to pass off a fake credit card with a stolen number. Weekends, when many less-seasoned employees work, is another popular time.
Yes, absolutely, and this is why fraud detection is often as much art as science.
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.
The fraud indicator in this case is that the card is a dupe, hence why the machine couldn’t read it and the number needed to be manually entered. So when the charge went through, some poor soul elsewhere in the world had to issue a chargeback.
ed: sibling comment nailed it also. Didn’t even consider that, good stuff
I actually thought Stripe did decently here, there were periods of silence which sucks. It's odd that you feel they are obligated to explain their internal processes with you?
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.
I think it's reasonable to expect either (1) support to be at least as responsive and competent as sales or (2) compensation or refunds for poor service.
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".
Stripe Support did not engage the lead PM, OP happened to have the PM’s email:
> 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.
I also had issues with stripe's automatic tax. We use stripe's subscriptions with free trials but don't collect credit card details up front, preferring to make sign up simple and low friction. Automatic tax is charged at 0.5% of each transaction, and apparently a trial ending is considered a transaction even if the user has no payment method, so we were hit with automatic tax fees for every trial end even if we received no money for them.
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.
> I discovered in actually using them has made me realize how much effort they put in to marketing to developers
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.
If you want something barebones with the smallest possible transaction fees and a good API, Helcim was quite good at least a few years ago when I used it. This was for a project that did a lot of micro-charges and they were the only payment processor I could find where that would still be profitable because of their (then) low fees. Not sure what their fee structure is now, though.
I worked briefly in sales at stripe, and most large enterprises are on or have considered Adyen. Keep in mind that many of these businesses will use more than one payment solution.
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.
Would love to learn more about that business -- I've pondered trying to build a payments API that could offer a way to transparently switch between payment providers, hadn't seen too many companies that were doing it
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.
Interesting that Dropbox don't use Stripe? Seems a bit surprising as I thought YC companies generally use each others wares... I think the club aspect of YC is one of the most powerful to be honest.
Hi Edwin, I appreciate you offering. I did message support about this but it pretty quickly hit the limit of the time I was willing to put in to try and retrieve the money we lost (which wasn't all that much). It is one of those things where the way Stripe charges is technically correct as you need to calculate tax for all transactions even if they aren't fulfilled. But the odd behavior of trying to charge at end of trial even if a user doesn't have a payment method combined with charging 0.5% of all transactions whether fulfilled or not results in a pretty unexpected outcome. Changing any one of these behaviors, or even making the documentation clearer would stop this happening to anyone else probably.
It'd be useful to take a closer look at your invoices, so let me know. The Stripe Tax fee is charged for the volume of the invoice—a trial invoice should have a volume of $0, so the Stripe Tax fee would not be charged.
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.
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...
There is a massive chasm between Stripe's perceived (for a lack of a better term) awesomeness vs the actual reality.
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.
Support has been dreadful for me as well. Had a few false fraud charges claimed on my Substack. Lost every single one. No explanation from Stripe and no opportunity for appeal.
(I work at Stripe.) This was a painful read. I'm sorry. We could have done a lot better. We're working on remediations now, and we're sending another, corrected email tonight with the updated CSV file of failed invoices as of March 1st.
And working in good faith to resolve the merchant's problem and rectify the issue can often prevent a lawsuit in the first place. You're overthinking it.
I respect Stripe for responding in some way. When I had an issue with Square they just terminated my account and left me stranded, rather than fix their product.
I'm not quite understanding the need to put them on blast here. Yes, they should have been more apologetic and they should certainly have escalated your ticket more quickly. But they made the changes you wanted seen: better documentation & better process, and reaching out to customers proactively when they see this problem.
I suspect, because I have been in a similar situation before, that the author is frustrated because the company first ignored/downplayed the significance of his concern, then blamed his issue on user error (without accepting responsibility), and then quietly modified their documentation and addressed the issue as if they had "just discovered it".
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.
Interestingly enough, I vaguely remember a pg article about how Lisp was so effective he could deploy fixes during a customer support call about the issue, to the point the customer thought they had messed up instead of the application. I can’t seem to find that now, but this one is close (in praising Lisp’s speed advantage for startups):
> As he points out in the article, they alerted him to the documentation updates in the course of their emails back and forth.
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.
(I work at Stripe but don’t in any way speak for the company. This purely personal.)
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.
> what they wrote doesn’t feel like it’s in bad faith
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.
I work for a company about which people talk a lot publicly (and which I do not represent officially or speak for in any sense), and I tend to feel the same way.
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)
Having shipped a non-zero # of billing bugs with the Stripe API...
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.
I don't know how Stripe's dashboard looks/works, and whether it easily displays the number of invoices left in "draft" state. But when the author writes about the silent failure here,
> 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?
The goal of Stripe is to make things simple. I shouldn’t have to implement a webhook to discover that none of my invoices are actually being paid. I’d expect a notification email to be sent to the account until that is explicitly turned off.
If you're writing software, and you develop a new feature without testing the failure path, then I don't think it's possible to make any safe assumptions about what failure should or shouldn't do.
I agree with you on general basis, but in this case it seems that Stripe provides a dashboard containing key data. It's not unreasonable to expect that critical payment failures would be displayed as well.
It's always a risk to make assumptions, but I don't think this specific assumption was unreasonable.
Yeah, I saw your other comment and feel you nailed it.
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.
One thing that's confusing/annoying from the Stripe developer experience is that subscriptions generate an absolutely huge number of webhooks. There's probably 10 or 15 webhooks per recurring payment, and many of those contain the same data. Different pieces of documentation talk about the importance of different webhooks. Additionally, I've never found a good way to easily test webhooks related to recurring payments without resorting to manual testing. I could easily imagine the OP being confused by Stripe webhooks.
I've noticed Stripe products tend to be buggy and/or half-finished. What's the deal with that? Anyone know why a company with so much talent and great product that seem polished seem to have critical issues?
I thought I was crazy looking at their API and thinking it was crap because everyone seems to praise the Stripe API. I ran into undocumented sections around line items for Checkout objects, and the whole loop-around to go from Checkout Session -> Payment Intent -> Charge Information -> Order Information -> Line Items (or whatever order the 4 separate, synchronous requests our app has to do to get cart line items) is overly complicated.
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.
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.
You can use "expand" to get multiple queries into a single request, kind of like a SQL join. I don't know if this is exactly your use case, but when we get a Checkout session, and want the customer and purchase line items, it looks like this (using the Stripe Ruby library).
He wasn't collecting address information for US customers, so the invoices hung in a pending state. He didn't check to make sure the integration was working correctly until a customer emailed him to ask why they hadn't been billed three months later, so there were a lot of invoices to clean up, which he apparently found to be very annoying.
You don't normally have to give Stripe location information for US customers. The problem happened when he enabled tax support for Canadians.
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.
He didn't enable "Stripe Tax for Canada". He enabled Stripe Tax.
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.
> 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.
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.
It is your responsibility, but the specifics of impact and enforcement are complicated. This looks like a nice summary:
https://baranovcpa.ca/us-sales-tax/
Who wants to be a global hallway monitor for taxes? It makes more sense to pay for a tool that makes you compliant with the applicable tax laws, and forget about the rest.
I think he's correct that the failure mode was pretty awful. Silence isn't a great approach for failures in your cash flow. But, I agree with you that at least some of this can be chalked up to a botched integration, and that he probably could have reacted to bad signs more proactively (i.e. the drop in income).
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).
If the truth makes them owe damages… then they rightfully owe the damages, which would make that silence willfully unethical. It’s wrong to try to avoid making things right especially if you think you have a legal obligation to make things right.
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.
> He didn't check to make sure the integration was working correctly
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.
If anyone is interested in this topic, I recommend the book "Field Guide to Understanding Human Error" by Sidney Dekker
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.
>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.
You are assuming that a large number of their customers are from the U.S. not knowing what business they are in, their customer pool might be 90% Canadian. The whole world doesn't necessarily target U.S. customers.
The author mentions "functionally 1/3 of my customers" and "I can not stress how much this has f*cked over my business."
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.
I'm going to repeat what I said in a parent comment:
> 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.
In what world does he not have to pay tax because the customer is in the US? You have to comply with tax regulations where the customer is located. And that is the problem that Stripe Tax helps with.
If you only sell locally then it's not exactly hard to implement and stay up to date with the requirements where you live.
> 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.
People are always going to have this feeling of "I can't believe Y was not as conscientious as I assume I would have been in X situation". It's hard to put ourselves in other people's shoes.
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.
Yes, the documentation was lacking, the consequences were unexpected, the API design was not great to prevent this and the dashboard did not show the problem. They are all Stripe's faults.
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.
> 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.
I had a similar horror story with Stripe recently where several customers got billed via payment methods that were explicitly disallowed on the subscription object. This cost us loads in unnecessary fees.
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.
The fact that it took the writer three months (!) to spot this problem sets up a situation (IMO) in which swearing for effect in a chat session is out of the question. It's partly on him.
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.
If they do not have time acceleration I think it's clear that the fault lays with Stripe and their bad testing practices. I thought people paid Stripe to handle the "get money from humans" problem, that is a pretty broad problem though so Ig guess not. Considering it took Stripe, and lets be generous, 7 months to figure this out they obviously have problems with testing.
I don't know how you can say any of this with the certainty you're conveying here. It seems wholly unwarranted.
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.
OK wow, I have never seen that, though I haven't done anything with subscriptions myself yet.
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.
Is there an extra fee for this Stripe Tax integration extra ? If not a separate fee, will they refund partially given that no alerts or alarms were raised for this behaviour ?
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.
Stripe Billing is much more than a cron job. It's an end to end solution for invoicing. It includes emails, trials, hosted billing and subscription management pages, PDFs, and a lot more.
I've implemented IAP -- and it is eons better than the 8 calls it takes to do any of this in Stripe. By the time you get done writing and handling the numerous API calls, errors, checks, etc for this, you've basically built the cron without storing the card information and having to do full PCI of your own gateway, which is exactly what Stripe offers as their service, everything else is window dressing.
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.
I've been working in fintech since 2014, and in tech since 2004.
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.
I appreciate you writing this out in full — and my original post asked to be educated on this…
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.
Sad to see Stripe fall to the bean counters instead of staying focused on customers. They were coming out with some cool innovations a few years ago. Even "don't be evil" Google is moving in this direction. Not sure why companies always evolve this way. Boeing is another prime example. Apple has maintained its focus on the customer and thrived, bucking the trend, which seems like it would be motivation for others to stay focused on the customer. Especially given when Apple hired the Pepsi guy to run things in the bean counter way, the company nearly died.
I would only have to assume you haven't ran a business with over $2M ARR. Taxes, VAT, etc is a HUGE pain in the ass.
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)
As someone who has used Stripe over the past 5 years for large scale e-commerce and marketplace startups Stripe has dropped the ball quite significantly over the past two or so years. Their customer support has gotten worst, their communication to customers has faltered quite a bit and they're starting to nickel and dime their customers for basic features (like support that responds within a day or two).
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.
We send satisfation surveys after support interactions, and consistently over the past year, 8+ out of 10 businesses have rated their interactions highly.
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.
Maybe off topic, but what % of surveys are answered?
We get survey requests from our main vendor. Generally the experience is not great, which I consider is systemic to the company. So replying negatively to a survey seems like it will bring down blame on the engineer who handled the case.
When an engineer does a great job, it feels like I should fill out a positive survey. But then I'd expect the vendor would feel '8+ out of 10 businesses have rated their interactions highly'.
So I never reply to the surveys.
I do try and provide constructive suggestions on our regular calls with our vendor.
> Apple has maintained its focus on the customer and thrived, bucking the trend
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.
I don't understand why would anyone use Stripe Tax? At that price range, suddenly one can also switch to something like Paddle, Gumroad, FastSpring, MyCommerce or some other Merchant of Record.
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.
I currently use Paddle. There have been some issues with the lack of documentation during the development, but as a developer, I'd rather deal with that than filing taxes internationally.
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.
Things like this are why I do this internally and just use stripe and other payment providers for actually charging the customer. Granted it's a pain in the arse but you only need to set it up once and occasionally adjust the tax rates as they change.
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.
It doesn't particularly matter. PayPal is a simple alternative (granted they have their own issues but it's unlikely both Stripe and PayPal will crap out at the same time). For recurring subscriptions it is a challenge since you'd need people to pay manually if you switched payment provider but for e-commerce that runs off one off payments it's no problem.
That sequence of events is exactly what I'd expect for a "we screwed up, but not in a way to incur any legal liability"
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.
> And then... yeah, you can't directly apologize and take responsibility because that would cost you a fortune
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
Stripe is just awful. I have no experience from the vendor side, but as a customer, I've noticed that they seem to associate a credit card number with an email address. My business credit card is associated with dozens of different email addresses, but Stripe wants to use the one associated with my most recent purchase regardless of what email I provide to them.
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 cannot edit or delete the above post, but I made a mistake and I must apologize to Stripe. I had confused it with Square. The above post should apply to Square and not Stripe, which means it is now off-topic.
Customer email addresses are only stored within a business’s Stripe account and aren’t shared across businesses when the same credit card is used—so I’m curious to see what’s going on here. Could you forward an example purchase confirmation to me at edwin@stripe.com?
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.
Upcoming problem:
> Canada is the only jurisdiction I run my business, and therefore only need to charge tax to Canadian customers
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.
I used to use Stripe to process payments. One day someone bought a huge item with a stolen card.
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.
I worked for a company that went bankrupt due to sudden massive fraud using stolen credit cards on PayPal, that all went to chargeback which also inflicted a $20/chargeback fee from PayPal. They were something like $6000 in debt to PayPal in chargebacks and fees when they just folded.
PayPal does not protect you from stolen cards, at least they'd didn't back then (5 years ago maybe?)
I don't disagree with the point that Stripe should have implemented failure handling in a much better way for something as important as this. Valid point.
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.
I consider this a great example of why systems dealing with money should be carefully engineered with sufficient safeguards in place that even reckless kindergarteners could operate with reasonable confidence they can't shoot themselves in the foot.
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.
An aside: It’s so absurd that someone should have to collect tax on behalf of a jurisdiction they aren’t even in. One the worst outcomes of Amazon reaching critical mass was their making agreements with various states and countries, making the tax collection moat wider and wider.
Yeah, it's a huge distraction from your core business. I work at a company that tries to take care of it for you: https://anrok.com
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.
So user didn't read guide properly, then after turning on a new tax invoicing system didn't check that all customers were actually being invoiced for three months... Obviously Stripes fault. /s
Well, the user only wanted to be half tax compliant (in his home country only), and not collect any taxes in the other countries where he is legally obliged to collect them to.
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.
So, this kind of sent me on an emotional rollercoaster. I empathized with both parties.
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.
> the tax engine knows that I do not need any additional information for subscriptions that are US-based or based in other countries as I have no obligations to collect tax there
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.
You are right. It doesn't excuse Stripe Tax, but a business can have both presence nexuses (ie we sell from there) and sales nexuses (ie we sell enough to there that the local laws say we need to register and collect taxes).
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.
Payments, invoicing, tax, etc are hard because the logic is complex and many things can fail in many places.
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.
Thanks for sharing, I was considering using them (and I was even in the beta) but the product seemed way lacking and I didn't want to pay the extra fees - so I stayed on my custom implementation.
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).
Tangental side note, I googled profitwell (mentioned in the gist) and the first result is an ad for another competing company (that I won't mention) which includes "profitwell" in the title tag. Super shady!
This is a common phenomenon sometimes referred to as the Google tax. Which is why when you search for "company name" you still get ads for that company when the first actual result is their website, they bid on their own name so that competitors don't appear ahead of them.
This is a massive screw-up by Stripe, and the fact that you had such a difficult time communicating with them makes it ever more difficult to fix. We need intelligent humans overseeing this software, not a bunch of triggered bots and human script readers. I don't know how to get Stripe to fix this other than media embarrassment, which is an incredibly inefficient way to run customer support and QA.
Does anyone know if this is just the implementation that came with Stripe's purchase of TaxJar? Because perhaps they just bought something that was working and when they merged it with the rest of their operations and expanded into Canada certain bugs became more apparent??
Aside from a Stripe rep estimating a response in 12-24 hours, and then taking 3 days to give out a canned response, it seems like Stripe hasn’t don’t anything wrong.
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.
Before anyone gets too excited to talk about their problems with Stripe on HN, please know that my account is semi-banned and anything I post is flagged as “self promotion” after I wrote a negative piece on Stripe that reached the HN front page.
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.