Note that if you are just interested in US sales taxes, and only need to collect tax in the ~1/2 of the states that are part of the Streamlines Sales Tax (SST) project, you can have your tax rate calculation, registration, reporting, and filing all done for free.
The member states of SST have agreed to pay for those services from several tax SaaS companies. (There is one catch: to avail yourself of this, you must collect tax for all SST states, even though you might be below the threshold in some of them).
The companies participating are Avalara, TaxCloud, Sovos, and Accurate Tax.
For small online businesses I suspect that a lot more can take advantage of this than you might expect. Here's a map showing the SST member states [1]. Although it is missing some big states that you probably do a lot of business in (California for instance), a lot of those big states have quite high thresholds for sales or number of transactions before tax kicks in.
Some of the companies that provide the fee SST service will also add non-SST states for a fee. If you only need one or two non-SST states, it will still probably come out cheaper than using Stripe (and will include reporting and filing).
Based on my personal experience I would recommend staying away from TaxCloud. When they make mistakes filing for you (and they have) the states will come to you directly with scary letters, TaxCloud won't answer your calls or messages. The only way I was able to sort things out was by getting another states small business advocate to help.
TaxCloud also has a habit of changing their fees without notice. Currently they charge an API access fee even for their "free" accounts.
Finally, they lock you in by not giving you enough information to cancel all the accounts they started for you in other states but not providing a clear way to cleanly close your account.
How quickly my excitement disappeared when I saw that California was not a member. Thanks for the information; I'm sure there are others, like myself, that have no idea such a thing exists.
I'm somewhat baffled by California not being a member.
California's threshold below which out of state remote sellers do not have to register, collect, report, or remit sales tax is $500 000/year of sales into California.
If I'm a remote seller using the free SST option to handle my taxes in the SST states, and am selling say $300 000/year in California, I will not be collecting any California tax.
If they joined SST, I would have to collect California tax even though I'm below the threshold because the deal to get free full service tax handling under SST is that I collect for all SST states.
I don't see any downside for California. At the stroke of a pen, they would suddenly be getting tax collected from a ton of remote sellers that fall below the $500 000/year threshold.
Same with Texas, which also has a $500 000/year threshold, or New York which is $500 000/year and 100 transactions, or Florida which is $100 000/year, or Illinois which is $100 000/year or 200 transactions.
California is not a member of the SST because it does not currently tax a number of things that are subject to tax under the SST regime. For example, digital goods are taxable in SST states but not in California.
Similarly, there are a number of other product categories where CA's taxability classifications do not match the SST's classifications.
Generally, the total tax they could collect from remote (non-CA) sellers below the $500k nexus threshold is not worth the effort it would take to change things so that CA could join the SST, and moreover, it would require significant changes by CA sellers.
Generally, those same considerations also apply in NY: the cost burden on local sellers to make the change would dwarf any minuscule tax increase from joining the SST.
The US could really use some national action on sales taxes.
I'd like to see Congress make it so a state can only require remote sellers with no physical presence in the state to collect tax for the state if:
1. Tax rates on remote sales are uniform within a zip code. No more having to deal with "123 Fake Street, Hooterville, 65026" having a different tax rate than "124 Fake Street, Hooterville, 65026". (Worse, I recall finding an example where a tax boundary apparently ran through an office building, so different offices on the same floor had different tax rates!).
2. They adopt a standard for tax classification that will be specified by the Federal government. They don't have to change the classifications used for taxing sellers with a presences in the state, but for remote sellers they have to use the Federal classifications.
3. Rates for remote sales can only change once per quarter, and the data for the quarter must be published one month before the start of the quarter. It must be published on the web, at a URL that requires no registration or fees, in a format specified by the Federal government. The Federal government would maintain a web page that contains links to the state data pages.
4. Sellers can report taxes using a uniform format defined by the Federal government. The format supports reports that cover the taxes for more than one state. The seller can file such a multi-state report with any state that requires remote sellers to collect tax that they owe tax to, and that state will forward the report to the other states it contains data for. The seller can also pay all the tax to that state, and it will transfer the appropriate amounts to the other states.
If Congress did this it would make dealing with remote sales tax so much easier.
It's too complex to even take a stab at guessing what they'd say based on that though. Also, I'd forgotten what a wild lineup the votes were.
GINSBURG, ALITO, and GORSUCH, JJ., joined. THOMAS, J., and GORSUCH, J., filed concurring opinions. ROBERTS, C. J., filed a dissenting opinion, in which BREYER, SOTOMAYOR, and KAGAN, JJ., joined.
Edit again: Seems Roberts agrees Congress can do something:
Roberts noted that Congress has been considering whether to alter the physical-presence rule, and “nothing in today’s decision precludes Congress from continuing to seek a legislative solution. But by suddenly changing the ground rules, the Court may have waylaid Congress’s consideration of the issue.”
The majority “proceeds with an inexplicable sense of urgency,” the chief justice said, and it “breezily disregards the costs that its decision will impose on retailers.”
There are complex distinctions made in more than 10,000 taxing jurisdictions, he said.
“New Jersey knitters pay sales tax on yarn purchased for art projects, but not on yarn earmarked for sweaters,” Roberts said, while Texas imposes a sales tax on plain deodorant but not on deodorant with antiperspirant, and Illinois treats Twix and Snickers bars differently for sales-tax purposes.
It's kind of hinted at somewhere in Wayfair that this is really kind of about the defaults when Congress declines to speak.
Congress has extremely broad powers to regulate interstate commerce which would let them decide if and how states can make sellers in other states collect for them. So far, Congress has declined to weigh in, and so we get the default.
For some things the default is that states cannot do them unless Congress says they can. For others the default is that they can do them unless Congress says they cannot.
With Congress remaining silent, it is up to the courts to figure out what the default is for a given thing. Wayfair is essentially saying the older decisions picked the wrong default.
Although your belief is a common one even at the highest levels, reality is that Art. 1, §8, cl. 2 is not actually as broad a power as is believed and/or imagined. People are reading something into that clause that did not exist when it was written, nor should it exist today. It is a function of the misunderstanding of what "regulate" means as it is and was meant, rather than what today's manipulators or "designing men" as Andrew Jackson called them, intend to imprint on it.
When written, "regulate" did not mean control by authoritarian and dictatorial means, absent of checks and balances and controls on power as it is implied today, i.e., "we {insert unelected bureaucratic authoritarian agency} decree by regulation that you may not do this thing or that you have to do this thing." What "regulate" meant when written was to order and bring into purpose suited structure, to bring into a regular state, opposed to an irregular state. There was no overt or hidden or implied sense of manipulation and control implied, it was a description of state, not action.
It is something that is to a large extend willingly overlooked by those who are authoritarian minded, but this natural entropy of language/meaning and even often deliberate and intentional manipulation of language and words (see today's public dialogue and clear and intentional manipulation of language, i.e., you can say some things and the meaning and use of other things is imposed or assaulted), causes excessive amounts of problems. A good example of this kind of change, is the word matrix; that means a pattern of lines or marks, usually in a uniform layout, which used to mean nothing more than a female breeding animal since time before records and well into the 18th century, including even today in niche agricultural circles. The connection to the breeding female coming from the sense that a mathematical matrix is a component into which quantities can be set, or bred into.
Congress does not technically have the right to control commerce, let alone trade, but it does have the power to set commerce into and orderly, or regular state; opposed to an irregular state, i.e., into a wanton and unpredictable state. That does not include using its powers to change or manipulate it with objectives or outcomes in mind.
But regardless of what I say or even the founders meant, the great powers of human hive-mindedness and whoever can control it will ultimately determine the outcome and impacts. We are rapidly approaching a state where everything and anything in the Constitution is essentially put through an authoritarianism conversion where everything is interpreted as meaning centralized control and power, while always and relentlessly stripping individuals of power and control over their own lives and freedoms … all by changing language, which is precisely why certain groups are so focused on changing the language, because if you change the meaning of freedom to slavery, then you are halfway to 1984.
>Although your belief is a common one even at the highest levels, reality is that Art. 1, §8, cl. 2 is not actually as broad a power as is believed and/or imagined.
Ultimately, reality is whatever people alive now determine it to be. The intentions of the original authors of the Constitution are interesting, sure, but only "real" in the sense that they guide the actual decision makers of today.
Probably not to enforce standards, but they certainly have the power to create standards and incentivize their use. Much in the same way they can't control speed limits on national highways or the drinking age in various states, yet these laws are largely uniform across the country.
Those rules have to be on a funding source that's plausibly related and it has to be non-coercive. I'm struggling to think of a relevant funding source here.
> Those rules have to be on a funding source that's plausibly related and it has to be non-coercive.
That seems to not be the case in practice. Highway funding is dependent on states setting a legal drinking age no lower than 21. Those two things are not plausibly related. And it's definitely coercive.
The two are completely plausibly related. Drinking age has a direct affect on the amount of drunk driving on roads and therefore the safety of them. The main group behind the push to 21 was Mothers Against Drunk Driving.
In fact, the Supreme Court case about this was where they came up with the rule!
The spending must promote "the general welfare."
The condition must be unambiguous.
The condition should relate "to the federal interest in particular national projects or programs."
The condition imposed on the states must not, in itself, be unconstitutional.
The condition must not be coercive.
Yeah, it sucks. However, not all goods, not all states even have an existence of a nexus. Virginia specifically exempts sales taxes of digital products delivered electronically, such as software, downloaded music, ringtones, and reading materials.
The basic rule for collecting sales tax from online sales is: If your business has a physical presence, or “nexus”, in a state, you must collect applicable sales taxes from online customers in that state. If you do not have a physical presence, you generally do not have to collect sales tax for online sales. In the court ruling that allowed this, it was determined that Wayfair did have a nexus in those states. Not all businesses operate that way and there are a lot of gray areas.
> If you do not have a physical presence, you generally do not have to collect sales tax for online sales.
That was how it stood before the Wayfair ruling. Under Quill Corp. v. North Dakota (1992) and others, the Court had ruled that states did not have the power to force out of state sellers to collect tax for remote sales unless the seller had a physical presence in the state.
Wayfair overruled Quill. The Court created a new kind of nexus, an "economic" nexus, and ruled that an economic nexus was sufficient to allow states to force out of state sellers to collect.
Merely selling a sufficient volume into a state is sufficient to create an economic nexus. They didn't give any hard and fast rule for deciding what is a sufficient volume, but the state involved in the Wayfair case, South Dakota, was trying to charge tax on any out of state seller that had more than $100 000/year in sales or more than 200 sales per year in South Dakota so we know that is on the "sufficient volume" side of things.
The rule for online sales tax in the US is now this:
1. If you sell online to customers in state X, you need to look up that state's economic nexus law to see what their threshold is. Here's a good place for this [1].
2. If your sales volume is not under the threshold, you need to check to see if that state exempts your particular product or service.
If you hit the threshold and there is no exemption, welcome to hell.
1. Congress does not have that power, as it would interfere with the states' control of in-state commerce. They could however make that a requirement for requiring out-of-state sellers to comply with sales tax.
2. Same as #1.
3. Rates for sales tax generally change every few years as it requires an unbelievably large amount of notification to sellers, service providers, etc. Where sales tax rates change faster than that, it is usually part of a pre-planned and pre-published change in rates occurring over several years. A sales tax rate changing annually is actually fairly uncommon; a sales tax rate changing more frequently than annually (absent special circumstances like COVID19 incentive rates) is extremely rare.
4. This is basically the purpose of the Streamlined Sales Tax, which is an initiative of over two dozen states to streamline sales tax compliance: only a single return is required and it covers all of the member states. However, it is voluntary.
Note that your suggestion for payment is unfeasible, since it would require each payment to also include the tax liability data for every other state, and each state would have to set up a separate bureaucracy to handle money transfer. It's faster and more efficient for taxpayers and states to simply have the taxpayer use existing payment mechanisms to pay each state separately. On the taxpayer side, it's literally seconds more work if you're using a unified tax system (like the SST).
1. Oops. I forgot to say that this was only to apply for sales taxes on out-of-state sellers.
2. I did remember to mention that for #2.
3. The rates that apply to a particular location in a state might change infrequently, but there are a lot of locations, so even if each location's rates change infrequently there can still be a lot of rate changes within the state each quarter.
For example, in my state (Washington), there are ~1 million 9 digit zip codes listed in the rate data the state makes available. Here is how many of those areas had rate changes compared to the previous quarter starting from 2020:
(This is only counting cases where the zip exists in the rate tables for two consecutive quarters. There are also zips being added and removed which I'm ignoring).
In those 6 quarters many places actually changed more than once, the most extreme being 98520-6503 which changed every quarter.
Among all the places whose rate changed sometime in 2020 or 2021 (so far):
436523 changed 1 time
4533 changed 2 times
654 changed 3 times
84 changed 4 times
7 changed 5 times
1 changed 6 times
4. SST would be great if every state did it, but as you note it is voluntary, and as you noted in other comments I believe several states apparently have no interest in joining. If the Feds did it, they could make it mandatory, and they could make it simpler (such as making it purely zip code base5 (hopefully 5 digit only) instead of address based).
With it zip based and updated at most once per quarter, almost all the complexity of dealing with finding rates go away. Heck, I would probably remove the address entry fields from our shopping cart because we sell downloadable goods and tech support for those goods. The only reason we have to ask for address is for sales tax lookup.
What I'm basically suggesting is something similar to the EU's VAT MOSS system. Here's how we deal with VAT for our EU sales. (1) It is one rate per country. I had a local DB with the rates. (2) Once a quarter I make a CSV file that lists country, our sales in that country, the VAT rate of that country, and how much tax we collected. (3) Once a quarter someone in ops uploads that CSV to the Irish tax authorities and we pay them the total of all EU VAT we owe for that quarter. (4) The Irish tax authorities forward the data to the other EU countries along with the tax owed (logically...I'd assume that physically they do something like net out things first. Just as we pay our Italian and German VAT through Ireland, there are others paying their Irish VAT through Germany or Italy, and there is no need to have say Ireland pay Germany at the same time Germany pays Ireland).
I don't see why the states could not do something similar, so that I just send a CSV of state, zip, sales, rate, amount collected to one state along with the total tax collected and let them distribute it. Maybe have the Feds set up a clearinghouse for the states to use that actually deals with netting things out and settling between the states. Might as well then go one step further hand have the sellers just upload directly to the clearinghouse.
Addendum: I got curious about that place that changed every quarter, zip code 98520-6503.
That zip covers the odd addresses in the 101-199 address range of E Wishkah ST in Aberdeen WA. The even side of that block is zip code 98520-6508 and only suffered one rate changed in that time.
The 200 block odd side changed twice, the 200 block even side changed once. Going the other way from the 100 block of E Wishkah, the odd side of 100 W changed once, and the even side twice.
In 2020, there were fewer than a 2 dozen rate changes throughout the entire year at the local level, none at the state level, and certainly not any rate changes in a single tax locale occurring multiple times during the year at any level. And this was verified by running tax rate reports for the state of WA in Avalara for each quarter in 2020.
I understand the point you're trying to make, but you're not going to win this argument by making up such blatant falsehoods. (Note that I actually handle the sales tax compliance for my company, including the state of WA, and I am definitely more familiar with sales tax rate changes than you are.)
4. The Feds do not have the power to require states to join the SST as it would violate the states' right to control intrastate commerce.
4a. Zip-coded based taxation is not sufficiently granular. For example, a single zip code in LA can contain multiple municipalities. A number of zip codes cross county and state lines. (9-digit zip codes are more granular, but only areas with sufficient mail volume are assigned the extra 4 digits.)
4b. I don't know what is behind your fascination with updating sales tax rates every quarter. Sales tax rates are generally updated every few years for any given tax location. It only seems like they update more frequently than that because you are conflating local tax jurisdictions with state-level jurisdictions.
4c. I know how VATMOSS works; as I have stated elsewhere I am a tax professional and handle indirect compliance functions for my company.
There is not a single VAT rate per country; there are 3 or more rates, corresponding to the different VAT classifications of goods. Most EU countries have 3 rates; during COVID several of them had as many as 7 rates (as a result of short-term discounted rates on certain types of goods and services).
Furthermore, only a limited number of VAT-subject digital goods and services are handled by the VAT MOSS system; physical goods are not VAT MOSS eligible, and classification/taxation of physical goods is 99% of the complexity of indirect tax regimes.
Additionally, the EU is legally and structurally fundamentally different from the U.S. VAT MOSS is possible in the EU because the member nations are bound to participate in EU economic initiatives as a condition of being a member of the EU (see, for example, the issues leading to Brexit). No similar legal arrangement exists between the American states; moreover, the U.S. Constitution does not grant the central/federal government the power to control commerce within a state.
It is simply not possible to have something like the VATMOSS in the U.S. It would require significant changes to the basic structure of American government. The best we'll get is the SST, and it's very unlikely that states like CA and NY will ever agree to give up control of their own tax systems to a system run by the Midwestern and Southeastern states.
Indeed, the SST exists primarily because most out-of-state sellers to these states would not sell enough to reach the nexus thresholds and so those sales would not be subject to sales tax; the SST is the carrot to get sellers to agree to handle sales tax compliance, and that is why it is mandatory to agree to sales tax for all SST member states as a condition of using the SST. (For example, without getting into specifics, my company's sales to all SST member states combined is less than the sales to CA, or NY, or FL, or CO, or TX, or IL.)
That also shows it changing, but not as frequently (and always has it in location code 1401, whereas the ZipRates files have that zip sometimes in 1400 and sometimes 1401).
There is also the short format files (just change the "E" in the name to "C" to get them), which give yet another story. They put 98520-6503 in location 1400 or omit it completely. When they include it, they match the rate from the long files.
Addendum: I took a look at the boundary file that Washington provides to SST (WAB2021Q3MAY27.zip available here [1]). Here's what that file says about O addresses in the 101-199 range of E. Wishkah ST.
It has the same bouncing around between SER codes 1400 and 1401 that it does in the earlier files. At first it looks like that depends on whether or not it is listed as being in the county or the city, but notice the last 3 entries all have it in the city but it still bounces around.
When it is listed as in 1400 it has state 53 tax and county 027 tax. When it is listed as being in 1401, it has state 53 tax, no county tax, and place 00100 tax.
The statewide component of sales tax in Washington is 6.5%.
Here are the county 027 tax rates, according to the rates file WAR2021Q3MAY27.zip that Washington provides to SST, found here [2].
Matching the rates and the boundaries files by validity ranges, I get for 101-199 E. Wishkah ST odd addresses for 2019q4 through 2021q2 8.98, 8.8, 8.9, 9.08, 8.9, 9.08, and 8.9, which are exactly the same as what I got earlier from the zip+4 long files.
I have no idea why these are not the same as the results using the Washington interactive lookup gives for those address, nor why Avalara apparently gives different results, now why the results using the zip+4 short files differ from the long files.
You might suggest that it was because I was going by zip+4 rather than address, and tax boundaries do not necessarily follow zip boundaries (even when you use zip+4). But with the files Washington gives SST, I'm going strictly by street address so that cannot be it.
Washington also has street address based files in its own format available to download. I've not looked at those. I probably should, to see if perhaps that is where their own interactive page and Avalara are getting data.
I have previously found inconsistencies in Washington's various tax files and interfaces (and reported them). Perhaps this is another case of that. Perhaps I'll report this one, after doing a little more checking around.
Edit: I grabbed the street-based rates from Washington's site. Same result as I got from the zip+4 long and from the boundaries and rates files that Washington provides to SST.
Honestly, I wonder if the level of autonomy we provide to states and lower subdivisions makes sense anymore in an era of one-day delivery and non-in-person sales.
They're buying the same goods, with the same currency, backed with the same warranties, and shipped with the same couriers, but because some of your customers are on the other side of an arbitrary line drawn for a political gambit in the mid-1800s, here's an entire second set of rules and documentation to deal with.
Even if you can somehow convince all the states to play ball, and not tie any sort of standardization process in the courts until six months after the heat death of the Universe, you've got the same problems on different scales with patchworks of local authorities.
If anything, though, what we should be looking for is a uniform national VAT or sales tax, distributed proportionally back to the states/local authorities. It would discourage the "race to the bottom" gaming of special tax regions and exemptions to attract business, and take funding for essential aervices out of the hands of state legislatures. In at least some states, we have real problems because such legislatures will do things like "taxes can only be raised as a ballot initiative with supermajority" as political posturing, then hatch up harebrained schemes like "the courts said we actually have to fund public schools, let's sell off state-owned land as a one-time earner" to kick the can down the road.
Added plus: we could reasonably price goods as tax-inclusive, like in the UK, because the marketing copy can be consistent and accurate everywhere.
Interesting. People bemoan that the market in Europe is too splintered and that the whole of the us can be seen as one market. But all these state differences seem to at least indicate that it isn’t that simple.
Interestingly, VAT law is mostly harmonized in the EU and remittance will get even easier starting July where you can declare and pay VAT on cross-border sales to just one entity ("One-Stop-Shop").
The $500,000 threshold is, IIRC, for companies that don't have a 'nexus' in California. As of a few years ago, having a single remote employee in California was enough to create a nexus, causing you to be treated as a California-local company.
This is spot on. It's an interesting program perhaps, but unfortunately a lot of states are missing including California, Texas, Colorado, Florida, Illinois, New York, Massachusetts, South Carolina, and we're not seen any uptake from other states toward adoption either.
CO has a very unique sales tax system: every county, city, and special district can set its own rates, and define taxable (or nontaxable) product categories, and determine the taxability of of those product categories, and even apply special (formulaic) discounts for complying with the tax regime. Plus, a number of tax jurisdictions overlap. And this is the simplified system that the state implemented in 2019 to make things easier for remote sellers in a post-Wayfair world.
And that doesn't even include the roughly 70 home-rule cities which administer their sales tax separately from the state's "simplified" tax system.
For filing purposes, each CO "tax location" is treated as a separate return by Avalara and other sales tax services providers, so the costs can add up very quickly for remote sellers using these services for sales tax reporting compliance: Denver alone has more than two dozen separate "tax locations." Consequently, at my company we use Avalara to compute sales tax for remote sales to CO but file the CO returns ourselves and save several thousand $$$ each month.
Luckily, due to Wayfair nexus requirements, CO sales tax compliance only kicks in at 100k or more in gross sales to CO (not including sales to home-rule cities). Because each home-rule city has its own sale tax system, the nexus threshold is independent for each home rule city; the state has advised these cities to set a threshold of $100k to avoid nexus-related litigation that could result in a bright-line rule setting an undesirably high threshold for nexus.
I was lucky to be part of the beta for my SaaS (https://turnshift.app) and I must say this new feature simplifies things A LOT.
Especially as a EU business owner, I previously had to sync every VAT tax rate possible, use a complex workflow to know if a customer needed to pay taxes or not, link tax rates to customers, and create taxes reports for my accountant. Stripe tax does all of that automatically, based on the customer full address and VAT numbers.
PS: Yes there were other services (Paddle) providing this (and much more to be honest), but the Stripe API and customization options makes it my go-to solution for integrating payments.
It doesn't say they file the taxes for you. "Speed up filing and remittance with comprehensive reports" means they will help you with it, but not do it for you. Later on the website : "Stripe reports surface all the information you need for each filing location, so you can easily file and remit taxes on your own, with your accountant, or with a preferred partner.
US filing partner
TaxJar
EU filing partners
Taxually
Marosa"
Literally all companies pay other people (accountants, lawyers) to do their taxes and in many cases they are third parties so no, that is not the case.
They're just using the word "literally" in its ever more popular sense in which it does not mean that it really does apply to all companies.
For example, according to Oxford dictionary https://www.oxfordlearnersdictionaries.com/definition/englis... "used to emphasize a word or phrase, even if it is not actually true in a literal sense" or Merriam Webster https://www.merriam-webster.com/dictionary/literally "used in an exaggerated way to emphasize a statement or description that is not literally true or possible" ; in modern usage, "literally" can be it's own antonym and mean "not literally". Language is fun! :)
I suspect that the majority of businesses are small enough that their taxes are trivial and pretty harmless -- at least if you weight by count. If you weight by size -- sure, most business is big business and has complex taxes.
The downside is of course that Stripe takes over more and more of your important infrastructure. A question should always be how to include several suppliers and/or how to change supplier in order not to put all in your eggs in a single basket.
This sounds a little like the big sites I've worked on that spent immense amounts of money on being database-agnostic, "so we can switch from Mysql/Postgres/Oracle to $other if we want".
Nobody ever wanted to switch; the expertise in using one provider created immense inertia. And even when a few folks (fans of $other working side-of-desk) tried to make a proof-of-concept swap, it turned out that the code was anything but agnostic and dependent on the first provider it was built for in pervasive and fundamental ways.
So, too, with service providers and partner businesses. Spending time/money on being able to switch suppliers and keeping all your eggs from being in one basket is a waste of time: you won't switch voluntarily, and if you ever have to switch involuntarily it'll still be about as difficult as it would have been if you hadn't prioritized redundancy/diversity.
At a minimum, implementing an abstraction layer around all external services really is software development 101.
For some services it's also not just being able to switch, it's having more than one used in production. If you manage that then switching is no longer a problem since it's already implemented! That's important for key services.
> The cost of letting Stripe do all the work than moving over to another provider is extremely costly and can damage sales.
Yes, that's exactly my point: At some point you are completely locked in with a single supplier that holds your entire income stream and perhaps even more than that.
Ideally (easier said that done, I know) you want to have at least 2 suppliers for any key piece of infrastructure as early as possible and to avoid letting a supplier 'expand' the number of tasks they do for you too much.
The latter seems to be Stripe's strategy: They start with payments then expand step by step in everything related et even in things like company incorporation.
YES, considering the only best competitor in this space Paddle takes 5%.
Taxes is the reason why in the past most EU/UK businesses go to Paddle. Stripe's Tax feature now saves people who were considering Paddle a lot of time now.
Here's some current Stripe UK pricing, confirmed on their site today.
Baseline of 2.9% + £0.20 for international card payments. (It's reduced to 1.4% + 20p for European cards.)
Add 2% for currency conversion. The exchange rate used is stated as "the daily mid-market rate provided by our service providers".
Add 0.5% for Billing if you're using subscriptions.
Add 0.5% more if you're using this new Stripe Tax functionality.
That is significantly over 5% for a typical SaaS or merchant selling digital content online, making international sales in multiple currencies.
Given that merchant of record services like Paddle are providing functionality far more comprehensive than Stripe Tax appears to be, they're still going to be attractive for smaller merchants compared to the more traditional PSPs like Stripe.
It's probably worth pointing out that while the EU has a long track record of making VAT difficult for everyone, plenty of other countries around the world and even some smaller regions seem to be jumping on the bandwagon lately. If all of these governments start attempting to enforce their local laws extra-territorially (leaving aside any questions about the legality and/or morality of doing so for this discussion) without also introducing reasonable de minimis thresholds to avoid grossly disproportionate compliance costs for negligible extra tax revenues in low volume situations, the situation could get very messy.
If that does happen and businesses are forced to comply with all rules globally regardless of actual sales volumes, I don't see how the model uses by traditional PSPs like Stripe has any chance of surviving. Every small business will have to sell via intermediaries like Paddle to shift the tax responsibilities to a larger business with the resources to deal with it, and pay whatever premium the market decides that justifies on all affected international sales.
The tipping point is the 2% for currency conversion, but keep in mind that this is happening either way on Paddle as well, just not going to Paddle. Paddle takes 5%, then the entity that converts from USD to your currency (Payoneer / wire transfer bank) takes the 2% or more. Stripe calls it out clearly and gives you your money in your own currency.
If you're selling a B2C service (so the really horrible tax rules apply) for say £10/month, that extra £0.20 is another 2%. Stripe's total cut for an international sale with currency conversion is then nearly 8%, even if you don't use any of their other services with their own extra costs and you never have any refund or chargeback costs to amortize.
Stripe is crazy expensive these days.
(There are other parts in the fees charged by other services as well, but those also aren't like for like comparisons. I'm just saying that 5% as a baseline wouldn't necessarily be that high compared to services like Stripe.)
Paddle uses Currency Cloud for that, which charges a true mid-market rate and a very low transaction fee. It's what Transferwise uses behind the scenes.
They use whatever to convert all the currencies of the world into your base currency, usually USD/EUR. Then they transfer that to you, and you pay more conversion fees if that’s not your actual base.
I sell in USD, and then once a month they transfer my sales to me using Currency Cloud. At that point it gets converted at the mid-market rate + 0.25% IIRC. Since they don't actually make international transfers using banks, that amount is what actually arrives in my bank.
I believe the currency conversion charge can be avoided by only charging your customers in your own currency or another currency you have a bank account for. I rarely see a small merchant that takes more than one or at best two currencies.
That'd leave you with 20p + 3.9% (international) / 2.4% (European). Compared to Paddle's 5% + $0.50 that could be a good deal depending on how much of your volume happens in Europe.
I believe the currency conversion charge can be avoided by only charging your customers in your own currency or another currency you have a bank account for.
It can, but then your customers get hit with varying exchange rates and potentially high conversion fees on their side. This will not make you popular with your international customers, at least the ones who didn't already back out when they saw a foreign currency anyway. Depending on which research you read, the rate of lost conversions due to lack of local pricing could be as high as 50%.
Within the overall landscape of payment processing options, Stripe looks trapped in an awkward middle ground now.
Above them are the merchants of record. Including currency conversion, international sales using Paddle seem to cost 7% + 35p at current USD/GBP exchange rate and their standard published pricing. But for that, you get real tax compliance.
Then we have Stripe, coming in at 5.9% + 20p (4.4% + 20p for European cards). Even with Stripe Tax, you're missing much of the essential functionality for global tax compliance and the reassuring liability shift, so that extra 1.1% + 15p or even 2.6% + 15p would be the easiest sale since bottled water in a desert to a lot of merchants.
Further down the price spectrum, we have services like GoCardless that are offering direct payment schemes rather than cards (duh) but for a fee of only 2% + 20p including currency conversion. You don't get any built-in tax support here, so it would be fairest to compare with Stripe at 5.4% + 20p or possibly 3.9% + 20p, but that's still quite a difference. And while you have to do your own tax compliance as with all payment processors using this model, you do get other benefits, notably in much improved reliability of collecting payments via direct payment schemes compared to card payments.
I wonder whether Stripe's medium-term goal might be to establish its own merchant of record service, and Stripe Tax in its current form is just the opening move. Otherwise, it doesn't really make sense to me as a strategy. But I have no inside knowledge on this and there are several Stripe people around who probably do, so no doubt if they want to elaborate at this time they will.
I agree that the convinces of Paddle is hard to beat, especially for sole developer and small companies. Liability shift being indeed very powerful. But I also think the percentages thrown around are too sinistic. If you make ~5 figures a month in revenue it becomes very doable to hold a Euro and USD bank account in addition to your local currency, likely covering a fair amount of your customer base. Suddenly your cost are significantly lower (at the expense of now having to manage multiple accounts)
Sure, you can hold accounts in multiple currencies. However, if you're a sole developer or small business bringing in low-six-figure revenues, you're probably going to want to take much of that revenue out of the company to pay its people on a regular basis. That in turn probably means transferring it to your primary bank account and converting the currency to your primary currency in the process, which will incur a conversion cost again. So holding accounts in several different currencies mostly helps if you expect to both bring in and pay out significant amounts in those same currencies, avoiding a round trip of conversion to and back from your native currency.
Indeed. That seems to be what GoCardless are using now, and as mentioned above, they work out much cheaper than Stripe for international payments with currency conversion.
Stripe also offers interchange plus pricing, but you’ll have to badger them for it… if you’re selling in Europe it can work out much cheaper, but it depends (eg amex would cost you much more).
Also the exchange rates can be avoided by setting up bank accounts with different currencies (eg transferwise —- now wise). This alone saved us a bundle.
With this new Stripe solution, do you still have to register for licenses to collect tax everywhere and remit the sales tax to various US states and foreign governments? Unless I misunderstand, that still sounds prohibitively onerous for anyone working as a solo dev or very small team..
This is a really useful toolkit. Going much further might make you into the actual legal entity, which could have consequences I don't fully understand (but is perhaps Stripe's plan?)
Not sure how it works in the US but in the EU you don't have to register anything. Just keep tabs of what VAT you collected for what country, and then pay accordingly afterwards. No licenses needed.
Last time I looked into this, it seemed to me like in the US you would need a separate license for each state you collect sales tax in (before collecting any tax)... and naturally, each state has a different licensing process, and some charge fees to register. For small independent projects, it seemed like kind of a nightmare.
A bad ruling. To let it stand, the more reasonable interpretation is that the purchaser has to remit sales tax to their own state. But it may not stand on further challenge. For example, why should the state the items are leaving not be entitled to sales tax?
The law already was that the purchaser should remit use tax to the state for purchasers from out-of-state vendors.
But compliance was basically non-existent; most people didn't even know that they owed use tax on such sales, much less what rate would apply. Sales tax is basically use tax, but with the burden of compliance placed on the seller.
As for why the sellers' state is not entitled to sales tax: in the old-time days, pre-Amazon, this was how many (but not all) tax jurisdictions determined sales tax. (For example, CO's sales tax regime pre-Wayfair used to use the seller's address to determine tax rates.) But the rise of Amazon and online sales meant that sales tax would go to a few jurisdictions where the sellers were located, rather than be spread out where the buyers were located. As sales tax pays for things like roads, etc., that these remote sellers used, many jurisdictions thought this was unfair, and moved to change sales tax sourcing to destination-based sourcing (i.e., to taxing based on the customer's location). And in the Wayfair decision, SCOTUS said this was acceptable. (At the national and international level, destination-based sourcing has been the law for decades, and has been part of America's tax treaties dating back to at least the 1970s.)
I was just wondering about this. I recently purchased something online, and when I got the email receipt it had all the state and county and city level tax breakdown. I thought to myself, was this tax being charged due to the billing or shipping address? Apparently it was the shipping address when I asked.
> But compliance was basically non-existent; most people didn't even know that they owed use tax on such sales
As a business owner, I would ask myself “how is this my problem?” If a stare has a problem with residents not complying with a tax, I am not sure why a business in another state should care. If I buy a product from China, are they required to collect sales taxes for Montana? Of course not. So not sure why a business located in a sovereign US state has any obligation to follow laws of some other state in which they don’t operate. It’s the purchaser that has the relationship with their local state, not the seller.
The Wayfair decision was ridiculous. The Quill decision it overturned was the correct answer in terms of interpreting the Interstate Commerce Clause. Interestingly, Amazon and other large e-commerce companies don’t have a problem with collecting sales taxes everywhere because their compliance costs are trivial as a proportion of revenue.
It happens with brick and mortar stores, too. The MO/KS border has a large population buildup. It's totally normal to shop in the state that has the best tax rate for your goods. If you apply the ecommerce logic to this, you need to have people show ID at stores so the store can apply the right tax rate.
It seems to me the seller's state has just as much claim to sales tax as the buyer's. The seller is potentially making use of business development credits etc, etc, originating in their state.
This is an issue that falls under the federal government.
No, you guys are both misunderstanding how the sales sourcing works: it's the address where the sale is deemed to have taken place.
For brick-and-mortar sales, that is the physical location of the store: you will be taxed the appropriate rate for the address of the store. Note that this includes includes online orders picked up from a store location, and in-person orders even if the goods are not actually physically located at the store, such as if they are shipped from a separate warehouse to the store. However, delivery orders might be subject to different rules, depending on the state; some states use the address provided by the customer as the location of the sale, so that in-person sales delivered to out-of-state addresses might not be subject to sales tax.
For online sales, the sale is (now) treated to have occurred at the address provided by the buyer for delivery, because that is the most expedient way to determine address. The EU has made waves about using IP addresses or geolocation to determine the actual location of the buyer at the time the order is submitted, but AFAIK both proposals are DOA due to infeasibility.
It seems to me the seller's state has just as much claim to sales tax as the buyer's. The seller is potentially making use of business development credits etc, etc, originating in their state.
No, the seller's state doesn't have a claim to the sales tax, because sales tax is a tax on the customer not the seller. It is simply collected by the seller because the compliance is easier to enforce. (Caveat: in Hawaii, the GET is a tax on the seller that can be passed on to the customer.)
You are fundamentally misunderstanding that a sales tax is a tax on the customer not on the seller. This is because sales taxes are fundamentally use taxes with the compliance burden shifted from the customer to the seller.
You can argue against reality all you want, but it won't change decades of history, nor will it change how the world actually works.
> If I buy a product from China, are they required to collect sales taxes for Montana? Of course not. So not sure why a business located in a sovereign US state has any obligation to follow laws of some other state in which they don’t operate.
Luckily, my home state of Virginia has exclusions. From what I understand, until congress acts, more lawsuits need to happen from companies challenging states to pay these bullshit taxes. VAT is also a terrible burden.
The trend in courts and legislatures, both in the US and in Europe and the ROW, is toward customer-based tax sourcing and away from seller-based sourcing.
You can thank Amazon for abusing seller-based sourcing for this shift, though it has actually been a decades-long process that began before most people on this forum were born. Amazon simply accelerated the transition.
I think due to South Dakota v. Wayfair, states now have more power to define what constitutes "nexus"... so there are all these special rules and thresholds now to keep track of (different for every state) that define whether you have economic nexus and need to collect sales tax there. If you hit the threshold and/or other rules apply, you're obligated to collect sales tax... but of course you can't do this until you have secured a license in that state. This was my read on the situation, but if I'm missing something definitely let me know.
How do they keep track of who you are? I presume you need a VAT ID of some form? (From https://en.wikipedia.org/wiki/VAT_identification_number#VAT_..., it looks like they’ve crafted it so that many countries’ business numbers can be turned into VAT IDs painlessly, e.g. Canada’s work direct, Australia’s you prefix with a two-digit checksum. I note the conspicuous absence of the USA from the list. I have no idea about US tax.)
Also wondering about this. Having a one man band b2b only saas, in EU. Have few customers in US to whom I just send an invoice with no tax added. This is what I heard from long ago was how you do.
Have never registered any taxes abroad in any country. For EU customers I collect VAT no and do the quarterly report but for all other countries I’ve done nothing. I have basically been doing this wrong then?
I use Paddle, they do file 99% of your taxes for you.
In effect, they sell the product to customers, and handle all the tax on that side, for every tax regime in the world.
Meanwhile you act as a company with a single B2B client and one invoice a month (covering Paddle's net sales minus 5%) instead of N invoices. They send you an email every month with your 'reverse invoice'. As accountancy goes it's extremely easy, but you do need to do the basic tax filing in your local jurisdiction.
That 5% includes all the processing fees, they also have a bunch of useful subscription infrastructure, and they handle customer support for billing issues, which tends to be a substantial percentage of issues as you get larger.
So far they've been great, and doing nearly zero accountancy is worth a lot of money to me as an indie dev with a digital product (where you need to know a lot about local digital taxes nowadays). That said, would I do the same at the beginning if this existed a few years ago? Hard to know, but this doesn't look so compelling that I'm likely to switch now.
> Meanwhile you act as a company with a single B2B client and one invoice a month
There were some changes in this area recently. Paddle is now providing you two reverse invoices each month, one for sales in the USA done by Paddle.com Inc. and one for sales in the rest of the world done by Paddle.com Market Ltd.
For the accounting purposes you have two B2B clients (belonging to the same group). You still receive a single wire transfer though.
How do you find working with Paddle? They've been on our shortlist for a new project and we've heard only positive things from people who actually use them. However, their terms could make any lawyer or company officer who actually read them visibly wince, and so far that has prevented us from engaging with them despite their clear advantages over the traditional payment services.
I've been using Paddle (and thus not worrying about VAT) for years now. They're mostly pretty good, although I use a very limited subset of their functionality, I basically just use them as a payment gateway. Their support is responsive and helpful, especially in the last year or so, and I haven't had any downtime to speak of. They don't accept all the payment methods that Stripe does, but enough for me.
There are a couple of pain points. Their invoicing is just a hot mess, if invoicing is a requirement for you I'd evaluate that very carefully. And they don't really have any sort of proper test system, which is pretty unbelievable. I do most of my testing in production using discount coupons, but 100% discount coupons can only be used with orders for a single item, so I can't test orders for 10 licences in any very useful way.
I dealt with their contract conditions by just ignoring them and crossing my fingers :-)
Still, all that said, there's nothing in this offering from Stripe that would tempt me to change. I'm also lucky in that I managed to negotiate a good rate from them when their model was switching to B2B (from Mac app sales, which the App Store killed). If you have any further questions, feel free to email me.
Edit: one other thing I like is that they use Currency Cloud to transfer funds to me, which give a much better exchange rate than a simple bank transfer and means that my local banks don't stiff me to receive a foreign transaction.
Are there some specific terms in their legal bits that you're concerned about?
Personally, they've mostly been very good. The product works, it was very easy to set up and it does everything out of the box, and it's made sales tax & accountancy almost completely disappear.
I have occasionally run into issues or bugs, and their API is a bit of a mess, but nothing show stopping and their team has been reasonably responsive and sorted everything out very reliably. That's noticeably got better & faster recently, I think they're beefed out their support team a lot in the last year or so.
If you're selling a new product as a substantial business, I think they're good but there are other options to look at too and there are tradeoffs (5% is high, you could probably do your own customer accountancy etc in house).
If you're a solo dev/small indie, or just getting started though I think it's a no-brainer. It's just so much quicker & easier than doing everything yourself.
Are there some specific terms in their legal bits that you're concerned about?
Quite a few, but to give an example from high on the list, it appears that a SaaS company would warrant that software sold through Paddle is always bug-free, accept unlimited liability via the related indemnification requirements if it isn't, and yet have no right participate in or even know about any relevant process if something goes wrong. That's a toxic combination and hardly looks like a healthy basis for a mutually beneficial business relationship.
Other concerns related to the considerable flexibility Paddle appear to give themselves in terms of how they represent, price and provide access to whatever is being sold, again apparently without necessarily requiring the consent or possibly even the knowledge of the underlying provider. We're unclear about how much this might be necessary because of merchant of record legal model, but it has little to do with what we'd actually want to use Paddle for or why we'd choose them over other services for collecting payments.
For context, this is a new business but run by a team who have collectively founded multiple others before. Several of us are very much over wasting time and effort on the mechanics of taking money from our customers and complying with whatever rules accompany that. Obviously fees charged by a payment service do matter, but a moderate difference there is still insignificant to us if the service we use can offer enough flexibility for our needs and easy integration, and otherwise takes on as much of the mechanical implementation and regulatory burden as we can shift.
Paddle is fundamentally different to Stripe. As you said they a merchant of record. Your customers purchase via Paddle, manage the subscription etc via them. Disputes would be via them too. Something to bear in mind.
Sure, the model is different, but that still doesn't make signing up to an impossible promise with unbounded liability when you inevitably break it a good idea.
What happens if Paddle are faced with a customer who is getting snotty about a bug and threatening litigation in an expensive jurisdiction? Paddle apparently have the right under their terms to settle that dispute on whatever terms they wish and then pass the entire cost on to the developers. There doesn't appear to be anything requiring those terms to be reasonable nor anything close to what the developer themselves would have had to offer in their own home jurisdiction or if they'd been selling directly to the customer on reasonable terms. As far as we could see, Paddle don't even have to notify the developer that any of this is happening, they can just send the bill at the end.
If anyone from Paddle is reading this and would like to explain publicly why that isn't an existential threat to every SaaS business using their service and what their terms actually mean, that would be very interesting to read. Maybe something like the above scenario would never actually happen. As I mentioned before, I've heard nothing but positive comments about Paddle from various people I know who actually use it. But in that case, there's no need for such one-sided terms, and it's better for everyone if the legal documents say what you really mean instead.
I've been happy with them so far, although I only have a few customers. The backend dashboard feels a little MVP but everything works well. The checkout flow is also hosted so you just embed that into your app which is nice.
Yes we have, though the terms for vendors that are linked from the main terms page on the FastSpring website don't seem to be the correct ones for vendors in the UK so our current assessment is only provisional.
The FastSpring terms don't appear to create the same risks for us that we identified in connection with Paddle's terms as I mentioned above.
Paddle and FastSpring (I found their support to be more helpful than Paddle's but they charge even higher fees), the two solutions commonly used in that space, act as Merchants of Record. Since you are not selling directly to your users you don't have to file the corresponding taxes, just the ones that correspond to the transactions between Paddle/FastSpring and you. But I'm not an accountant and they may change their operations in the future so don't rely on this comment alone.
Personal experience from using Avalara for six months:
- Returns were processed via a queued batch job. It could take between 1-3 hours after submitting to process a return. Avalara had a countdown clock on their website showing the estimated hours/minutes remaining until the return would get processed. I have seen the countdown clock show 1-3 hours plenty of times (quite frustrating). This was the case 6-12 months ago. Perhaps Avalara has fixed this issue since.
- The 1-3 hour wait made filing quite difficult when the original return had an error. Submitting a second return to cancel the first required another 1-3 hour wait. Then submitting the final (third) return required another 1-3 hour wait. Filing one state easily turned into a whole day ordeal if there was an error.
- Support from level one/two staff for difficult tax questions did not help. Level one/two staff gave a vocal repeat from the online help guide. Level three support was acceptable however.
- Tax returns filed with Avalara are done via a rather cumbersome spreadsheet. Don't expect someone to hold your hand. Rather, it requires many trial and error submissions to figure out how to make the Avalara engine work.
Note: A basic "shipping product" business like Amazon/Walmart would do fairly well with Avalara. However, a company that does complex construction projects will have challenges. We ended up reverting to filing taxes manually.
What is their pricing, I can't find it on the site.
Whatever it is, reading reviews of Avalara suggests it's beyond the level smaller businesses can afford and has also been increasing dramatically from one year to the next for some time.
Avalara have a strong web presence because they've always been good at presenting key information like current tax rates and forthcoming changes. Their content marketing is excellent. But as soon as you look for more details about anything they offer, you seem to be straight into "enterprise contact-us sales process" mode.
Avalara is expensive. It works out to being cheaper if you have sufficient scale, but it's generally pricier for small businesses.
However, that is because you're paying for their customer support, and Avalara customer support is very good. Every issue we've had has been dealt with promptly, including issues where Avalara misfiled a return. (Long story short: they owned up to the mistake and corrected it with the state without any additional cost or penalties to us.)
Paddle does have a solution to this but it is what I would consider to be in eternal alpha - it's functional (barely) but it drives me insane every time I have to use it.
Most importantly, they become the merchant of record. In other words, they're a separate legal entity reselling your product to your end customer, and therefore they are the ones who deal with almost all of the corresponding tax and legal responsibilities. You then deal with them through a B2B relationship, in which they give you you the collected revenues minus their fees every now and then, and you provide your product to the customers they've sold it to in return. Your own accounts and tax responsibilities are dramatically simplified as a result, though typically with a merchant of record arrangement (with Paddle or any other) you trade that off against some loss of control and higher fees.
Honest question: can somebody enlighten me about Stripe's appeal? I am not an user (until recently they weren't even available in my country) but I used ShareIt (now Digital River) 20 years ago and Avangate (now 2checkout soon Verifone) in the past 15 years and they both:
- had a much larger international presence, with localizations and everything
- had sales taxes, VATs etc computed from day one
- had cart (not sure about ShareIt though) & API
- integrated countless payment gateways: from credit cards to purchase orders, wire transfers and even PayPal
How comes Stripe won even if they arrived much later on the market? I believe their pricing structure was not very far from the competition. What did they offer to attract users even though they lacked such important features?
The developer experience and ease and speed of integration are second to none. They managed to take a commodity service performed by many incumbents and make it so effortless that it blows away the competition.
Yes, I heard that (couldn't test it myself). The integration for Avangate for example was a proof-of-concept PHP file and a couple of docs explaining the CGI parameters. Not great but not that horrible either.
But were those so incredible that it made up for the missing features? I mean if it was me I wouldn't implement the sales tax myself in a million years, no matter how nice the experience and integration was...
A couple of years ago, internet sales tax across state lines started being enforced. I think there was also a temporary moratorium to build up ecommerce while in its early stages. This case was related:
Disclaimer: I now work at Stripe but the following was purely when I used them as a user:
Stripe targeted developers from day one and made it extremely simple to get up and running (literally seven lines of code for a working payments system) and they documented their api very well.
Then they added on a lot of stuff that made me (as a user) happy, like paying out to my bank account a lot more quickly than the competition, adding recurring subscriptions with a few more lines of code etc.
Basically, their systems just worked out of the box and were more polished than others that I used.
If I want to know how much Stripe will cost, I can visit Stripe's webpage and see all the fees laid out. It doesn't tell me "Talk to sales", which is common in the payment/tax calculation business.
I believe that. But on the other hand you had to implement sales tax - that seems to me a few orders of magnitude more complicated. Was it worth the tradeoff maybe?
Sales tax is not a "I need this at launch" feature. Many companies start out in a single market where you can just hardcode the tax rates if you want, and worry about that later (and then the engineering hours to add sales tax etc. are probably not a threat to your existence).
Gotcha. My products were addressing the global market from day 1 so the ability to automatically send an invoice with a correctly calculated sales tax to buyers from any country on the planet seemed vital. Let's also not forget about collecting and remitting said tax to correct tax authorities...
Banking in the US is at least a decade behind the rest of the developed world. Bank to bank transfers, credit cards, etc. etc. are all like banking in Australia in the late 90s.
So for those in the US, Stripe is amazing. For those of us outside the US, it's just like all the other options we've had for 10+ years (as you said)
Besides for the extreme ease of documentation (which is getting a little harder now that there's so many different services), Stripe gained a lot of traction at the start.
Stripe was one of the first credit card acceptance companies with $0 monthly fees. I was paying a merchant account monthly, then authorize.net gateway fee, then an extra $20 to authorize.net to store tokens. Then the per-card fees were somewhat opaque with every card (qualified vs non-qualified) having different pricing.
With stripe, it became much lower risk: pay a set fee for each transaction. No monthly minimums.
Many of the credit card companies have moved to this model, but it was rather cutting edge and seemed much more "fair" for a commoditized gateway.
I have to say that when I first evaluated Stripe I was comparing it to things like authorize.net. I haven't meaningfully looked at the other available options since. Stripe is easy and known and I haven't gotten org pushback about it. So maybe just ignorance?
This is so on point. About a year ago I was thinking of opening a company and selling digital products with Stripe in Japan (where I live). They offered a quick free call to answer my questions, and I did so. I am not fluent in Japanese so any help I'm offered I take it, and I wanted to know how many other troubles I could face at this endeavor.
All my questions were answered promptly and greatly by them, and I was getting more and more convinced to do it. Until I asked, "Stripe handles sales taxes, right?" and the answer was "no". They gave me a brief overview of how that works though. Let me tell you I know why you don't see an "Amazon of Japan", apparently in here I'd have to calculate the sales taxes for every country where my products are sold through agreements of Japan-{said country}. Some countries don't even have agreements like Brazil so they are in a gray area.
It seems like Stripe Tax might be a game changer for this specific situation! I'm not ready right now personally/professionally to try to do the company, but let's see in 6 months - 1 year. I am so jubilant!
PS, this is from a quick conversation I had ~1 year ago, so some small details might be fuzzy/outdated/incorrect. Ofc this is no legal or accountant or any kind of advice, just my experience.
> Let me tell you I know why you don't see an "Amazon of Japan", apparently in here I'd have to calculate the sales taxes for every country where my products are sold through agreements of Japan-{said country}. Some countries don't even have agreements like Brazil so they are in a gray area.
AFAIK this is true for any other country, not just Japan. If you're in US, and you want to sell and ship products outside of US, you need to take care of the sales taxes and customs for each of the countries you ship.
Or you leave the burden to your customers, but they might not be happy to have to pay expensive custom to the mailman to get their package.
Apparently it's either not a requirement or not so strongly enforced in the US and EU as it is in Japan, or that was my understanding from the conversation.
Update: searching a bit and reading about the EU sales taxes, there are few rules but overall it's pretty clear you either don't pay or pay local sales taxes even for international sales for low-volume B2C sales (sorry it's Spanish): https://www.carrilloasesores.com/post/iva-de-ventas-por-inte...
In Canada, it is a requirement to self-assess GST on purchases you make online. When you buy something online, you're supposed to fill out a form and mail a cheque to the government for the GST you should have paid on it. That being said, this is completely unenforced as well as unenforceable. Also, if you ask basically anyone in Canada they probably would have no idea this was a rule, but the rules are the rules.
I have a nano sized business to cover some server costs in Finland. Here are the EU rules as I understand them:
* Selling goods
- If selling to private persons in European Union fiscal territory (EUFT), add 24% (Finnish VAT).
- If selling to businesses in EUFT, no VAT.
- If selling to anyone outside EUFT, no VAT, but you may be liable to collect and pay VAT to the customer's country's tax authorities.
- Note that there are separate customs rules!
* Selling electronic services
- If selling to private persons in EUFT, you need to register to the customer's country's tax authorities and add the customer's country's VAT, and then pay it later to the customer's country's tax authorities. EXCEPT if you only have an office in one country and you are selling to another EUFT country, and you only sell <= 10,000 € worth of services, then you can use your own country's VAT like normal.
o Or you can register to so called VAT MOSS (Value Added Tax Mini One Stop Shop) where you use the customer's country's VAT but you don't need to register or pay to their tax authorities, instead you send a quarterly report to your own country's tax authorities about all the sales you have done, then you pay them a calculated sum, and they will divide the paid VAT to all the countries based on the sales. Of course there is now a new VAT OSS that is somehow different from MOSS.
- If selling to businesses in EUFT, use reverse VAT (buyer is liable for VAT).
- If selling to anyone outside EUFT, no VAT, but you may be liable to collect and pay VAT to the customer's country's tax authorities.
Now I'm not a tax lawyer, so this is all just my best understanding based on our tax authority's website. I just wanted to get some money back to pay for my ~20 €/mo server costs, and I had to learn all of this. I will be very interested in what this Stripe Tax can do to remove my headaches. :) Of course, since my revenue is so tiny (and thus the money I bring to Stripe), I can't access all of their services AFAIK. And I'm mostly one chargeback away from losing major revenue due to the 15 € penalty. :D
EDIT: Turns out I have no idea how to format lists on HN.
Unfortunately, almost everything you're talking about there is about selling physical goods. The rules for electronic sales have been completely different for quite a few years now and are a labyrinthine mess that makes even professional accountants frustrated and national tax authorities screw up the most basic processes. In most cases, they also don't have any minimum thresholds at all, and the few concessions that have been made are quite recent.
How long is soon? I'm asking as I'm in the middle of building a saas. I might get to payments functionality in about 2-3 weeks if all goes well. Should I wait or register interest?
I understand that from the 1st of July, the electronic services section will expand to all goods, potentially with some thresholds, so you should charge the VAT rate for that particular item at the customer's home country and submit that to the Finnish tax authority (under the OSS scheme).
There are also a lot of thresholds that might apply to your situation. More rules to look up, but could simplify it to having less administration if your revenue is under a couple K's
Good point! And with Stripe Tax we'll monitor how close you are to those thresholds too, so you'll know when and where you need to register as your business grows or sells into new markets.
We were lucky enough to be able to integrate the Stripe Tax beta with Billflow.
In my opinion this is the coolest thing Stripe is launched (For SaaS) since they came out with subscriptions. It just works™.
Implementing Stripe Tax was dead-easy, to get it working we essentially just had to switch a boolean to true on our subscription creation code.
Also, the new functionality of the upcoming invoice API is something we've been wanting for a while - being able to estimate the first invoice for a subscription _without_ the customer existing beforehand makes life so much easier when checkout is concerned.
The feature is of course very nice, but the pricing is steep at 0.5% of your transactions. So I'm giving away 0.5% of my revenue (provided all of my revenue comes from sales) for the privilege of having my taxes calculated? That's on top of the 2.9%+30c per transaction that I already pay stripe?
Correct. But that's not what you're paying for of course, you're paying for the fact that you don't need to pay an accountant to double check these numbers: if they are wrong and the tax man comes after you, you get to hold Stripe accountable for any and all repercussions. You are paying Stripe--if you so choose--to take on the legal responsibility of getting it right.
> if they are wrong and the tax man comes after you, you get to hold Stripe accountable for any and all repercussions. You are paying Stripe to take on the legal responsibility of getting it right.
Where exactly is this stated? As far as I can tell, all this does is say what taxes you should be collecting, and then collect them. It doesn't even handle (at this point) remitting payment to the appropriate jurisdications.
I see no evidence that if your taxes are collected wrong, Stripe will do anything other than say "Your accountant should have caught that, sorry." I see no evidence that by using this product, Stripe will indemnify you against tax issues (which yes, would go a long way to justifying the cost)
I don't really think you're paying for accountability. That would involve some serious risk taking on Stripe side. I see no mention of this in the marketing material.
Is that legally binding somewhere? If they completely miss out that we were meant to collect X% for a municipality, will they be covering that out of their pocket?
Hey! Kelly from Stripe here: Just to clarify, there's no additional cost for using Checkout, and Radar is per small per transaction fee (or included free with Stripe if you're just starting out!), not a variable 0.5% fee.
Thanks for clarifying! That’s something I was looking at on the landing page and didn’t find that. So Checkout already includes Stripe Tax at no additional cost. That’s great to hear
It seems like the thing that makes it steep is the percentage rather than a charge per transaction, right? Philosophically it's geared to the total value you generate rather than the value they provide to you.
Credit card fees in general are like an extra tax. And credit card companies have so much power they have pushed the cost onto all transactions, even those that use cash (by forcing merchants to eat the cost difference, they push all prices with that merchant up).
This is something people say often, but studies put the cost of accepting cash for retailers at 4.7-15.3%, which is higher than the cost to accept credit cards. If anything, it's the high cost of handling cash built into prices that's increasingly burdening credit card users in stores, not the other way around.
Tbh these are debit cards. The Durbin Amendment limited the interchange that count be charged on debit transactions (I think the average is something like 0.3% now), so everyone was pushed towards "credit" products instead.
That looks great, but that's a ridiculous pricing scheme. If you invoice $100k in a year, you're paying $4000 to Stripe to manage your sales tax.
A lot of the issues with sales tax are not knowing your regulatory requirements and set up. I'd say that's probably worth $4k, but then going forward you still have to pay them that amount. I'd say it would be more worthwhile to pay an accountant to do that for you, and save the ongoing fee. You will have to pay an accountant anyways to do your tax returns. I'm an accountant and my firm often does sales tax returns for our clients. Now, if you're making $1 million a year, that's $40k you need to pay Stripe for the privilege of not worrying about sales tax, compared to a few thousand you'll pay your accounting firm to do it.
The API and integration options are great and I hope Stripe is successful. Really, if they are, it means I can just charge more for my services.
Edit: As others have pointed out, I'm bad at math. I'm going to leave my shame up here but I realize it's $400, not $4000. Just goes to show you that accountants are just like regular people, and that you shouldn't rely on your accountant doing things off the top of their head not using Excel. The order of magnitude difference really shifts my opinion of it.
Nope, if you have $100k transactions in a year, it will be $100,000 * 0.005 = $500 not $4,000 (And 0.4% is when you make more than $50,000 in a month)
I too made the mistake of doing amount*0.05 when they provided me the pricing in beta.
This is why I went with them, if I can't do a simple percentage computation I'd rather not do the taxes myself.
And if you're making $1M a year, it will then be $4,000. And I guess that's still cheaper than having your accountant going through all your Stripe documents, computing taxes while also, on your side, having to make sure you're 100% tax compliant. Maybe at $10,000,000 it will start being a bit pricey, but at that point you'll most probably discuss with Stripe to reduce that fee.
When I saw this announcement, I had fully expected these new features to be included as standard - I was a bit surprised when I saw they were charging for them.
That said, I think the pricing is well worth it if you're selling B2C. EU VAT is complicated, and I presume state-level sales tax in the US is too.
If you're selling B2B in the EU however, then all you really need to do it collect and validate VAT registration numbers. Now, the EU API for this is pretty crappy, and has a ridiculously low rate limit - but still, it's not difficult to do. Indeed, I did it in a few hours when I was setting up Stripe for a B2B micro-ISV one or two years ago. I actually think that VAT ID validation should be included as standard - not chargeable.
Hey there, I believe validating VAT numbers is outside of the Stripe tax pricing and part of the Customer Tax IDs API, without any extra charge. Maybe someone from Stripe can confirm?
And yes, if you sell only to B2B Europe and everyone inputs their VAT number you're fine (because you actually don't have to charge VAT, it's a reverse charge). Stripe tax do know this nowadays.
But that's actually not so common, people signing up for products usually have no idea what the VAT number of their company is. But they are capable of getting a credit card and giving you a business address.
In this case, you have to compute VAT rates based on the country of the customer.
(This is not an accounting advice, just personal experience!)
> Hey there, I believe validating VAT numbers is outside of the Stripe tax pricing and part of the Customer Tax IDs API
Ah, good to know! It was mentioned in the same TFA, so I had thought it was chargeable with the rest of it.
> But that's actually not so common, people signing up for products usually have no idea what the VAT number of their company is.
Hmm, that hasn't been my experience, on either side of the table. As a biz owner, I get plenty orders from companies big and small, and always get a VAT ID through. When purchasing (on occasion) in my previous day job, I just had to ask someone in accounts what it was.
> If you invoice $100k in a year, you're paying $4000 to Stripe to manage your sales tax.
The pricing on the page says 0.4% - that's $400/year not $4,000
> Now, if you're making $1 million a year, that's $40k
It's $4,000 by the above.
> compared to a few thousand you'll pay your accounting firm to do it.
It's not _just_ the money you pay the accountant to do it once, you need to get all of the data about where the customer is purchasing from to your accountant in a format they can use. Also, depending on your accountant, international sales tax is unlikely to be their forté - they might handle different states, but can they handle the varying rules in EU countries?
Yeah, you're right, my coffee hasn't kicked in yet.
For the amount I thought you would pay for Stripe to do that, you could have hired an accountant to figure all of that out for you on an ongoing basis, but for the actual price that's a pretty good deal to not have to think about it.
My opinion on accounting services has always been that it's nothing that a business owner can't do themselves since it's not really that complicated, but it's never worth the time when you can pay someone who already knows what they're doing. Stripe Tax falls into that category for me too, it's cheap enough that it makes it not worth it to do it yourself.
> you could have hired an accountant to figure all of that out for you on an ongoing basis, but for the actual price that's a pretty good deal to not have to think about it.
Even if you have accountants on tap, they may disagree. I did some work on a project where we were needing to deal with tax calculations (was using taxjar). At least one of the questions was about when we should be charging tax on certain 'extras', like... shipping. Their accounting firm said "no, you don't charge tax on shipping". Taxjar was automatically making that charge, and throwing off the expected numbers. After some digging, I found, at least in their primary state, they should have been collecting tax on shipping, but I don't think it was uniform across all the other states.
So... they had an accounting/books person on staff, and this question went up to their 'tax person'. I think it was either a general attorney or a tax specialist or something - this was their 'oracle/decision maker', and they were just flat out wrong.
This probably wasn't the case 20 years ago, when they were putting all their records in to an electronic system the first time, but... rules change. Keeping up with them is not a trivial thing, and when millions of dollars are on the line... you can make expensive mistakes.
2. As of this writing, almost everyone responding to you is using 0.4% as the pricing, when their page shows it's actually 0.5% for the scenario you described ($100k in a year). The lower rate only kicks in if you process over $100k in a _month_.
Unless they've changed their pricing details in the last hour, that's another great reason to let them handle this! Clearly we, collectively, don't have the attention to detail required for this ;)
I'm not sure if I'm missing your comparison, but an accountant doesn't calculate how much/which tax should be paid in real-time based on the business and the user's location and then automatically account for that.
I don't know how much it's worth, but properly supporting tax takes a lot of effort to do correctly in real-time.
> I'm going to leave my shame up here but I realize it's $400, not $4000. Just goes to show you that accountants are just like regular people, and that you shouldn't rely on your accountant doing things off the top of their head not using Excel. The order of magnitude difference really shifts my opinion of it.
Wouldn't most online businesses just need to collect the taxes for the customers that their business operates in?
Posting this on the basis that there should be no stupid questions when it comes to tax.
For example; an Australian business needs to collect GST for Australian customers only. Americans accessing the Australian service would not be obligated to pay GST and as the Australian business doesn't have a US entity wouldn't have to collect US state taxes.
You would hope so, but no.
A good example is that the UK now requires online business to collect UK VAT on sales to UK customers, even when the seller is abroad - there are many similar rules and this will really help people, especially smaller businesses who really face big barriers in dealing with these rules.
That's not how it works within Europe. You need to collect taxes in the country where your customer is located, you need to register with VAT instances in those countries. There are exceptions, for example up to some total revenue you may be allowed to collect local sales tax instead. This is what I've understood, but it probably gets more complicated in real.
That kind of used to be the way it worked, but not for the last several years. Now you are generally expected to know about the tax laws and requirements for the customers region and collect and submit tax accordingly.
This is great! ATM I'm banning all EU end users from purchasing my SaaS unless they're a business because the cost of handling VATMOSS is just not worth it.
It also definitely played a role in choosing to do a B2B service over a B2C one.
So now the choice is:
- File VAT yourself, pay 3.5% + some pennies to Stripe
- Pay 5% to Paddle and they file VAT for you
Definitely glad to see more competition in this area.
I deal with the software end of dealing with VAT for a small company that sells downloadable software and technical support for that software. We've not found it costly at all.
It took one guy a couple days or so to get registered with Ireland for VATMOSS.
To do the quarterly report for filing, I run a fairly simple script I wrote that produces a CSV file with one row per country giving the total sales and the total VAT we collected for that country, and someone uploads that to a form on the Irish tax authority site, which I understand is a simple and straightforward process.
Their API for getting rates is very simple, and their free plan allows 100 API calls per month. It is one call to get the rates for all VATMOSS countries.
The reporting script needs to get exchange rates to calculate the VAT in EUR for those sales where the customer paid in GBP or USD. The EU makes that information available in this handy XML document: https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist-90d...
That contains the exchange rates between various currencies and EUR for the last 90 days. The rate you want for VATMOSS is the rate on the last business day of the quarter you are reporting for, so there is a little bit of calculation to figure out which day's rate to use.
Mainly implementing different VAT rates. My accountant also would charge extra to do the EU VAT filing.
Right now I'm just charging no VAT worldwide (and we keep track of the totals in US states to see if we approach limits) or VAT for my country.
Also, given we're a B2B service, most of our customers are actual businesses, so we would be adding complexity to our payment flow for not much gained.
Thanks a lot for vatlayer, that looks great and I will definitely keep it in mind!
Like, every single time. Their execution is amazing.
Serious question, have any of their products had a poor rollout?
I’m not asking about a feature you’d prefer that’s missing. I’m asking about something being buggy, poorly documented, or having a confusing marketing page.
> Serious question, have any of their products had a poor rollout?
Yes. Payments with SCA2. Very poorly documented when rolled out, and TBH the docs aren't much easier to navigate now once you get off their "do everything immediately client-side" happy path.
I've never known them to be buggy, but in this space there isn't room for bugs.
Yes, their PSD2/SCA roll out was disastrous. The documentation is marginally better now, and to their credit they've also produced a lot of example code repositories showing end-to-end implementations of various scenarios in various programming languages. But then, the epic scale of a full API integration and the moderate scale of even a Checkout integration today, as shown in those docs and sample repos, only highlight how painful the whole process has become. Then you look at the modern services that are going back to what early Stripe did so well, handling most of the pain of charging customers for you with very straightforward integration requirements, and the differences are stark.
The new additional transaction fee for Stripe Billing is awkward. They charge an extra 0.5%, which is fine, but it always comes out as a separate transaction instead of being added on top of their regular transaction fee. Sometimes it gets withdrawn from your balance after they've already deposited your earnings, leading them to make a withdrawal from the bank.
So. After 10 years in business and THOUSANDS of customer requests (I even made one myself, in-person when I met Patrick Colison at a conference) Stripe has introduced... a calculator. And you still have to do everything yourself - filing the papers and wiring money.
Thanks, but no thanks. I'll stick with my current payment provider that handles _everything_.
I do admire Stripe and wish I could move some day :(
Thanks for the feedback. We’re working toward an end goal of making tax compliance as simple as clicking a button. In talking with users they called out three big pain points: knowing what the obligations are, knowing what rate/rules to apply and how to calculate tax (e.g. SaaS is taxable at 80% of the base rate of the price in Texas), and then how to file and remit the money once collected. Stripe Tax solves the first two out of the box today, and with TaxJar we’ll be able to bring filing and remittance as a native part of our offering.
All Indie developers or 1-3 person team need is a Merchant of Record, or simply a SaaS app store without index page like Apple Store. I don't even want to have a /billings page. Please also provide full feature customer portal (refund / cancel / pause / coupon / etc.)
And I want that store to have only literally "one" page for API documentation. All I want to check on my app is `authorized?(user.subscription)`
So they will charge 0.5% of my business to do my taxes? That makes sense until 350k per year more or less, but after that Quaderno has a 45 to 99 usd per month fixed price to do that.
It sounded outrageous the first time I saw it, but it actually makes a lot of sense for most small businesses.
I'm glad they rolled out this feature, too bad that they never announce what they are working on and it's a big bang overnight.
I was looking into integrating my app with a tax provider, I wouldn't even have started if I knew this was in the pipeline.
But now that it's here, it sounds great and just another reason for choosing Stripe. I haven't integrated with Paypal and I don't think I'm going to.
From the docs (https://stripe.com/docs/tax/checkout) it looks like Apple/Google Pay is disabled when Tax is enabled. I wonder if there is a technical limitation there or if that is something that will be supported soon?
Confirmed this is a technical limitation that we're working on as swiftly as possible. Drop me a note at jackerman@stripe.com and I'll let you know as soon as we've resolved this limitation!
Yes, to the extent they require it (and you want to stay compliant.) There are companies that can handle the remittance for you; Stripe lists several on their page. Reporting requirements would probably be quarterly or monthly.
In practice, almost all US states that have sales tax have a in-state sales threshold amount, usually $100k+ and/or 200 transactions, and at the level of business as per your example, you wouldn't hit it. (Kansas has no threshold, but this is probably illegal per the terrible court decision that allowed this sales-based nexus mess.)
So if there are limits I assume you collect 150 transactions a year from California, you have to keep the tax collected until you reach 200 and send the tax for all 200?
Presumably you can't spend the money on beer and yet you also can't refund the customers either.
I'd say it's more than messy, it's a disaster. There are reasonable solutions to internet+sales tax, but the current situation is not one of them.
If you collect the tax, you need to remit it. The transaction/amount limits are the limit where you should register, collect, and remit. And usually this is a one-way affair; once you're registered, you'll need to keep filing even if you fall below the threshold.
When we implemented Stripe, our team was flatly frustrated that this wasn't already included in Stripe. It spawned a lot of arguments as to why we were even using Stripe over just a normal payment gateway. Having to calculate sales tax was a much harder problem for us than what Stripe was solving.
Although paying .5% on every transaction just to do a lookup on a table of what should be public information is still frankly absurd. For all of the lip service given to ease of doing business, governments still enable a lot of rent seeking in the process.
We started using Stripe recently for a worldwide base of customers and I was a bit flabbergasted that Stripe didn't have a tax solution already built in.
Taxes are a PITA, and in my opinion this product from stripe makes enormous sense. If it's as good as everything else they do, it'll simply our lives enormously. Super happy to see this being released.
I have a very small video game business (emphasis on small) and I already use Stripe to handle non-EU digital purchases. I specifically avoid taking money from EU customers because I briefly looked into the tax requirements and it seemed onerous. The registration process for really small businesses that did online sales was very weird, and unlike Canada or the US, the threshold question seems to be hard to answer (I think you have to pay taxes from day 1 even if you sell 50 euro per year?)
Anyways, I am glad stripe is adding this product, and I've signed up to join, but I am still wondering how complicated and expensive the whole process of registration for vat OSS was. I doubt I'd get more than 50 euro total per year in sales (yes, I mean 50 euro. not kidding).
If your sales is small better stay away. Find "Merchant of Record" or reseller who will cover all that mess for you. There are many: Gumroad, Paddle, FastSpring...
Maybe someone from Stripe is reading the comments and can explain: why do refunds not reduce the reported tax collected? Are we supposed to keep separate records of that?
Good question! You can create a Credit Note, which will indeed shift the liability and will correctly reference and update the prior legal invoice. If you’re refunding a PaymentIntent however, we won’t shift the liability. Basically, we offer you two ways to move money back to your customer: one that might be a higher lift which ensures your accounting is updated and the liability if shifted, or a much easier way to refund, but you may pay some tax out of pocket.
Presumably because it's hard to do correctly, and Stripe chose to focus on the easier part.
For example, I need to report VAT on the 15th of the second following month. If I got a refund after that date, I have already reported that tax, and I need to report a correction. I can't just report a lower tax the next time.
If you don't have a lot of refunds, then just paying taxes that you don't owe may be cheaper than handling it correctly (which is a lot of effort). And it may be the safer option -- nobody is going to fine you for paying too much tax.
I was recently looking for a way to sell my digital product.
I was surprised how complicated all these solutions are. First of all, I want a 'merchant of record' to handle my taxes, which basically gets rid of most payment solutions.
Secondly, I want an easy to use affiliate program where I can add affiliates.
Oh man, they almost all work with some complex external affiliate service.
I used to sell my indie game with Plimus (around 2009), which is now BlueSnap, but even they are now really complex and working with external affiliate network.
Ended up with Gumroad, which has all of these things, in a very simple and clear way. Now I understand why they are so popular.
I'm not seeing anything here about generating VAT-compliant invoices here or in the documentation.
Different countries have different requirements for what must be included on the invoice and specific language to use (e.g. how a reverse-charge is supposed to be worded).
If you're looking to invoice a customer, Stripe Invoicing is VAT-compliant. It allows you to customize your invoices according to your customers' jurisdiction requirements (like sequential numbering): https://stripe.com/docs/invoicing/customize. We're also working on providing VAT invoices after a payment too. Give us a poke if you have any questions. edwin@stripe.com
Very happy to see this, it is such a necessary feature. I was recently looking for an option to enable VAT calculation in Stripe and couldn't believe it wasn't there. Now it is, and it looks very well done as Stripe's features usually are.
Thanks for the feedback! Completely understand your reaction to pricing. For a bit of context, we’ve spent the past year listening to users and trying to understand the best way to price. In finalizing our launch pricing, we made sure there are no fixed upfront costs or contracts, nor are there any per transaction fixed fees either. We tried to find a price point that ultimately was not prohibitive for small businesses but also portrayed the value of the product itself. Please do keep the feedback coming, we’re always open to hearing more from users: kmoriarty@stripe.com
My honest feedback on pricing was "expensive but we would only want to apply it on non-US users." Also, we wouldn't want to have to pay for invoicing, which is honestly much much worse of a value prop. For someone with a 20% margin business, the combination of these and payments products is about 4%, or 20% of all profit.
While this is the first product since payments I have liked (so good work there) it would be nice to see Stripe work on reducing the transaction costs, particularly on the payments side. Right now for me I consider Stripe a part of the "credit card processing tax cabal". Payment processing fees are a huge tax on the world, and if stripe could help solve that and genuinely reduce it to the level it should be (nearly free marginally), I would have the utmost respect for them. I honestly think this should be the main company focus if they actually want to help customers.
It's worth noting that there's the interchange fees that come along with using a credit card in the US aren't just a pure profit rake for the credit card companies.
It obviously pays for computing resources and staffing and such, but beyond that it also, roughly, pays for all the fraud that happens with any credit card. In many cases, when someone does a fraud, it's someone "in the middle" (i.e. not the fraudster, the card holder, or the merchant) who ends up holding the bag.
It's also paying for some aggregate amount of credit risk that card users pose to their banks.
Credit card fees are high because fraud is such a colossal problem, and at various levels it's better for institutions to just eat costs (and thus slightly raise the minimum viable price they can charge for processing) than make it harder for people to buy things.
It punishes smaller transactions unfairly, which doesn't make a lot of sense since the size of the dollar amount probably doesn't have anything to do with the incremental cost to stripe to compute the tax bill.
Yes, the 0.5% adds up. 0.5% for Billing, 2.9% + 30c per transaction, more if you add e.g. fraud for teams etc.
Stripe is great and I use it too, but the way they charge you (a percentage of your revenue) is simply not that fair in the long run while their workload has a fixed cost per transaction.
Welcome to the world of saavy SaaS businesses. Smart/enterprising SaaS founders and businesses these days all know to tie their billing to whatever metric/KPI they are solving for customers -- per-seat billing, per-pageview, etc.
Why make a little money (even if it's 2-10x your cost) when you can make much more by taking a small-seeming percentage of every single <whatever> that comes through your business. When your customer wins (and when they aren't winning you aren't a huge strain on their wallets) you win, and if the 0-5% eaten up by their bundle of SaaS products never matters to them, then you get wildly rich doing it and no one is angry about it, since the incentives are aligned. Then you plow that extra revenue (that you wouldn't have gotten from the simple 2x-10x your cost) into expanding your service offering so you deliver so much value (or perceived value) that moving away from your service just doesn't make sense.
This is HN and just about everyone and their mother knows this at this point, and has been living it for longer than I've been writing computers but I'll say it anyway -- Stripe is the dream SaaS company, essentially a financial middleman that no one hates (yet?). The SaaS promised land is a somewhat close cousin of the dystopian everyone-is-a-renter-and-only-a-few-own-the-capital future. Maybe the hand wringing I'm doing is wrong -- maybe it should have been the case all along that solution providers should have extracted a never ending royalty on the revenue generated by the solutions they provide. Not only service providers but maybe workers should want that (no one remembers pensions, but they kind of were this) too. Who knows.
If you can sell a music single album to 0.3% of America for $1, you get $1MM. If you do that with a Stripe store, Stripe gets ~$30k, for infrastructure that probably cost them less than $300 to host (for a single customer) and an ever-decreasing amortized amount to build (assuming they eventually stop growing their development workforce for growth stake). The artist that just made $1MM probably doesn't care about $30k as a millionaire (maybe they should, maybe they shouldn't).
It's a win-win, and it's why Stripe's goal is to increase the GDP of the internet.
Apparently Buffet calls this a “toll booth” business.
Once the road is built (customer integrates Stripe into their state machine), you can just keep collecting their toll for driving on the Stripe highway.
The thing is, if you didn't integrate Stripe, you'd either be:
1. integrating someone else who does roughly the same thing as Stripe
2. integrating with and maintaining 100's of individual payment methods and countries, and dealing with tons of entities and managing relationships with them.
You might be able to cheat if you just do visa cards and only in the US, or something. But that is dramatically less than what you're getting when you integrate Stripe.
Middlemen all the way down. At this point I think the question is when does the fatigue start? Maybe it never does -- if 10 companies all take 0.5%, you're at 5% but what if you use them to run 90% of the work of running your actual business? For many businesses that would be worth it (and most SaaS-ers and proper business people would heartily agree).
I'm about to go off on a wild tangent here but I think this is the obvious endgame for autonomous vehicles (article from Ars Technical on this hit HN just today[0]). More narrative for that world where no one owns anything and everyone rents forever and if you didn't own capital by 2100 your chance to do so is now infinitesimal. Safety of autonomous cars will surpass human driving, human driving will be outlawed, and the toll booth behavior will kick in with either companies licensing self driving technology, or the cars, or just running the services. Yeah, you never pay the $1-2k to buy a beat up first car (that could have lasted you 5 years with careful care and proper maintenance), but you're stuck on the $8.50/day ($2040/year if you commute to work 240 days/year), forever.
Another wilder tangent (possibly too much of a distraction from the topic at hand) -- this future is one of the reasons I am skeptical of UBI. UBI feels like the fastest way to encourage every kind of company to take this route. If you know every citizen will get $1k/month, the monopoly-dominated markets will fight (initially, at least) to get their share of that guaranteed $1k, almost as a form of governmental graft. Differentiated work pools get rarer and rarer (people specialize up, but automation gets better, ad infinitum), and at some point a large mass of people are getting UBI + gig economy wages. The corporations who have carved their part of the daily budget out never stop winning -- they now don't need to worry about economic conditions for their now-somewhat-more-distant gig worker force, the government will step in to help citizens, and those corporations can continue to influence those proceedings. What breaks this cycle? Is the goal a utopian world where $UBI is actually enough to free people of work completely? That never seems to be the goal, or maybe I just haven't seen enough people play out enough steps in the UBI plan. I just know that when people doing really well in the current capitalism-on-overdrive system start to get behind something that really seems like a utopia for those doing not-so-well in the current system, there's a catch.
Don't forget they also force-convert payout wires to your native currency if you aren't in the US. Even if you operate mostly in USD, have USD accounts, etc.
Yep, Stripe prices its products pretty competitively and talks to many beta testers before we settle on pricing. I think even adding all this up, it's less expensive than merchant of record providers like Paddle.
Why does it have to be a percentage of your revenue? It’s doing exactly the same thing for a $100 invoice and a $10000 invoice, why does the latter cost 100x more?
Value. A service Y makes it easier to collect that $10000 invoice. Inversely, by not using a service Y, you might not see those $10000 or it will be more difficult to do so.
A glass of water has more value to you when you're thirsty.
Why not ? If you have small transactions you end up not paying a lot, and the more you make money the more you pay Stripe. If you make so much money that you can have your own tax system, good for you ! Implement it and don't pay Stripe :)
Fixed price schemes would be less fair for small businesses that want to grow. Stripe helps you to grow, so that your company becomes the one big enough to "subsidize" the small ones after benefiting this pricing in the first stage
Our SAAS has to calculate sales tax on the fly for purchases in the US. We don't charge credit cards but invoice the customer later. However, the tax calc is the same. We use an API [1] from a company called Strikeiron that was purchased by Informatica. We pay about $75 per month for tens of thousands of sales tax lookups by city/state/zip.
If we were taking credit cards, we'd look at Stripe's solution. It would be much less expensive than what we are doing today.
Hey there! I'm the PM for Stripe Tax, I'd love to hear more about your use case around how frequently you'd want us to be revalidating VAT IDs, the information you'd want returned, and of course any other tax-related requests you may have: kmoriarty@stripe.com
I had to look up "merchant of record" [0]. I think the implication of Merchant of Record platform-wide would be that Stripe would own the customer-vendor relationship, and that Stripe would become something like Amazon Marketplace. I agree that as a "feature" MOR has a market, but I would see risk for Stripe as being seen as a competitor to its customrs, vs as a processor for them.
How does that work when the amount of the tax depends on the location? Do your visitors need to enter their billing & shipping information before they can browse your site?
VAT is uniform across all of Germany. Therefore detailed location information isn't necessary. The country can be inferred reasonably accurately from the IP. You can have a drop-down somewhere to correct the country if necessary.
~~And I don't think there's a law that requires you to show the price including tax, but it's definitely expected.~~ I have been corrected: it is indeed required.
> The country can be inferred reasonably accurately from the IP.
That would be a guess at best. A VPN or caching service (or merely inaccurate geo-IP data) could cause the site to infer the wrong location. The law linked by Vespasian doesn't appear to make any allowance for cases where the tax jurisdiction may be uncertain, though it's possible that the automated translation I read glossed over some nuance.
> You can have a drop-down somewhere to correct the country if necessary.
If the visitor neglects to select their country, and the default was incorrect, does that mean the site is not compliant with the law? The requirement was simply to show the final prices—no allowance was made, so far as I could tell, for being given inaccurate information.
As Vespasian said this law was written before consumers had large scale access to the internet and used it to order things online and from foreign countries.
In practice, if you're not a German business you probably don't need to worry about it too much. Most (if not all) countries in the EU have at least the custom of showing final prices including tax. If you're an EU business, you could just do that by default unless the customer explicitly specifies they are from elsewhere.
If you're a non-EU business selling to EU customers, you don't need to handle VAT. The customer is responsible for paying VAT upon import and will generally be notified by customs of the amount due before the item is released. Of course you can choose to handle VAT and make the customer's life easier, but you don't need to.
When I order something from Amazon.co.uk to Germany (post brexit) I see the normal price including British VAT on the product page. As soon as I add the item to the cart and go to checkout, VAT goes to 0% (doesn't apply because the item isn't sold in Britain) and I get an "Import Fee Deposit" added. The latter consists of German VAT and any applicable duties. This is because they handle dealing with customs on my behalf.
This law is an old one and has been in effect forever (offline and online). I'm certain there is a lot of legal practice and precedence on what can be expected of a "reasonable" company. Courts are usually quite pragmatic in their rulings (otherwise no law would ever work)
The Goal is to prevent misleading advertising and tricking of the customer by showing them a different price.
A typical costumer won't use a VPN etc, so if you can demonstrate that you had a sufficient amount of evidence no court will punish you for it.
E.g.: German IP, German browser, a German credit card and a German shipping address are probably sufficient.
Edit: it used to be that you have to go to great lengths to ensure that no consumer can shop in your B2B shop (like verifying their business license, making sure the customer isn't lying etc). In recent years the federal high court ruled on several occasions that this is not necessary and a simple disclaimer and a checkbox is enough in most cases (IANAL).
There are strange cases (e.g. I'm on holiday in Germany using hotel wifi, ordering from a German webshop for delivery to Sweden using a Danish credit card).
In that case, the price will change when the delivery/payment details are entered.
We are currently using ChargeBee that has great connectivity with Stripe and offers a lot of the functionality that Stripe Tax is now offering. Wondering if it is worth the change. I have nothing but good things to say about ChargeBee so I don't think I will be making the move unless pricing becomes an issue. They also have a really good starting package for startups.
It's quite obvious both PayPal and Stripe need to account for these terribly burdensome tax laws going into effect next month. The thresholds for most companies (UK excluded) was previously enough for most international sellers to not have to worry about filing for a VAT in multiple foreign countries. However, now they are making it even more burdensome by removing these thresholds entirely. No USA businesses selling small amounts of good are going to deal with that burden. If PayPal and Stripe can't deliver, that VAT ain't being paid by the majority of online shops. This is a case of them trying to go after the big guys and screwing the small. Good job on Stripe. PayPal needs to do the same. https://www.avalara.com/vatlive/en/vat-news/eu-2021-one-stop...
The only EU threshold change affecting US businesses sending goods directly to EU customers is the removal of the 22 EUR low value consignment relief.
Regardless of sales volume, such businesses were not obliged to file VAT in EU before and will not be after the changes either - they will now be able to file IOSS VAT returns if they wish, though.
The annual thresholds the linked article talks about are all concerning intra-EU cross-border sales, not imports.
Random aside on marketplace tax and using Stripe Connect. It would be especially useful if Stripe had a field that allowed marketplace facilitators to ensure they are collecting the tax. Using connected accounts with destination charges allows platform account to receive the tax by placing it in the application fee field, but if you happen to also collect a commission that means you are combining your tax + commission and storing that value in the application fee field. Since marketplace facilitators are responsible for tax collection in the US having an extra field to put this tax in would be great.
Piggybacking off this... Has anyone built a really good tax exemption system. I know Amazon has a pretty decent system for their B2B that allows you to upload a tax exemption certificate for your state (US). Then they have some sort of auto validation process. I assume it calls out to each state's secretary of state system to determine the validity. I would be interested to know if anyone has seen a SASS service like this that other B2B providers can leverage for fully automatic tax exemption validation.
I was dealing with taxes using Stripe Checkout so far, and to be honest it’s far from perfect. Worth looking around this new feature, but feel like they haven’t done much and are going to take 0.5% of every transaction!
We're always working to improve Stripe Checkout, and very open to your feedback. Feel free to drop me a note at jackerman@stripe.com if you'd like to chat about Checkout!
As much as taxes suck, taxes on online transactions are becoming ever more common (and not only in the EU). If anyone is curious, this is a good write up of how it works https://support.patreon.com/hc/en-us/articles/360043055071-S... (and on Patreon it gets even more complicated because it changes by US state and type of perk)
I've been using Stripe for years for my website, codehawke.com. Once you get over a certain amount of revenue and or sales transactions, they file 1099-K directly with the US IRS, they won't miss your failure to report that. I'm not sure if this is new, or I reached some new threshold? They are definitely in communication with the IRS at this point. PayPal does the same thing.
Do you sell to US only or globally? Each country has its own tax rules.
E.g. if you sell to EU customers, you need to apply a correct VAT % of their country on top. If you reach a certain threshold you then need to file VAT returns.
I do account for that, but honestly I don't make the international sales to worry about it. UK is the one exception for that. The rules are being a bit more simplified starting July 1 of this year. VAT is a disaster for all businesses. This is a case of going after the big guys and screwing the little guys in the process. Luckily, 70% of my revenue is in the USA and on top of that my company is based in business friendly Virginia.
Stripe and Swish solve different problems. Swish is mobile phone based direct bank transfers, Stripe is credit/debit card transactions. The big problem with Swish is that it only works if you have a phone with a Swedish SIM card and a Swedish bank account in a supported bank (which admittedly is most of them). With Stripe you can take money from anyone with a Visa or Mastercard
> Stripe and Swish solve different problems. Swish is mobile phone based direct bank transfers, Stripe is credit/debit card transactions.
At a higher level of abstraction, these are are the same problem -- conveniently and safely paying money to another entity (whether person or business). If we assume that normally someone has a phone at the same time they have their credit/debit card, then the how isn't really that important is it?
> The big problem with Swish is that it only works if you have a phone with a Swedish SIM card and a Swedish bank account in a supported bank (which admittedly is most of them). With Stripe you can take money from anyone with a Visa or Mastercard
This is why I asked inside countries like this -- if you're in Sweden and (I saw a documentary on DW a while back about how cash is actually becoming so rare that handling it is starting to be disincentivized -- ATMs disappearing, banks not wanting to hold cash because of relative liability, etc), let's assume you have a phone with a Swedish SIM card and a Swedish bank account and a phone.
Swish in Sweden is just the only good example I know of, but I think that after a while something that looks like it will be everywhere (US, EU, UK, etc). Cashless economies are generally welcomed by governments and most businesses, most people don't even know the usual privacy/accessibility/etc talking points (opposite from the usual HN reader).
So again, in a situation where it is very likely that you could use Swish with ~0 fees or Stripe, do people continue choosing Stripe?
Or a better question -- how easy would it be to compete with Stripe (without having to offer the key lower parts of the stack that Stripe initially solved)?
BTW Stripe also does ACH -- I use it for larger payments when dealing with clients and it works very well.
So again, in a situation where it is very likely that you could use Swish with ~0 fees or Stripe, do people continue choosing Stripe?
Why not both? First of all, Swish is only free for transfers to or from private individuals. Companies pay a pr transaction fee. I don't know how the fees compare, but it is probably not a huge difference. If you're a company handling a huge number of transactions pr day I suspect you'll be able to negotiate a better deal with a card processing company.
Also there are still people inside Sweden who have credit/debit cards but not Swish, for example tourists, older people or people here on temporary work contracts.
Secondly there are reasons why people would want to use a credit card instead of having the money taken directly from their bank account. One such reason is if it's a company making the purchase it is much more convenient to use your company card. Another aspect is if you have more than one bank account (say your personal account and a joint account with your spouse) then you might have different cards tied to different accounts. You cannot do that with Swish.
Basically while there is some overlap between Swish and companies like Stripe, they aren't really drop in replacements for each other.
Edit: From a technical point of view there is probably nothing stopping Stripe from adding Swish as a payment option to their API if they wanted to have that as a feature for the Swedish market.
These are very good points. I had it in my head htat
> Why not both? First of all, Swish is only free for transfers to or from private individuals. Companies pay a pr transaction fee. I don't know how the fees compare, but it is probably not a huge difference. If you're a company handling a huge number of transactions pr day I suspect you'll be able to negotiate a better deal with a card processing company.
Yeah but this is just an extension of... taxation when the government does it right? The fee seems to be 2 kronor[0][1] this is static not %-based. I'm not a huge payment processor but $0.24 USD/transaction seems REALLY good to me. The fact that it's not % based is just a complete shift of the cost dynamic -- if you sell something for $1000 and pay 0.24 for the transaction the fee is 0.00024%. I don't know what kind of numbers you have to do to get that from a card processor.
> Also there are still people inside Sweden who have credit/debit cards but not Swish, for example tourists, older people or people here on temporary work contracts.
Yup, I've heard this mentioned, people who went for a concert had a terrible time, etc.
> Secondly there are reasons why people would want to use a credit card instead of having the money taken directly from their bank account. One such reason is if it's a company making the purchase it is much more convenient to use your company card. Another aspect is if you have more than one bank account (say your personal account and a joint account with your spouse) then you might have different cards tied to different accounts. You cannot do that with Swish.
This is a good point -- but I want to push back that you can't do it with Swish now. Doesn't feel like a really hard problem.
> Basically while there is some overlap between Swish and companies like Stripe, they aren't really drop in replacements for each other.
They aren't drop in replacements for each other if any of the scenarios you've outlined is the case, but I intended to restrict the situation to the case where they are roughly identical. In that situation, do people use stripe?
> Edit: From a technical point of view there is probably nothing stopping Stripe from adding Swish as a payment option to their API if they wanted to have that as a feature for the Swedish market.
Ok so this is a bit closer to what I'm trying to get at -- Why would a merchant pay ~3% compared to 2SEK? Is Stripe worth 3% when all you need them to do is process the payment?
MobilePay in Denmark (which is about the same as Swish, with very similar constraints wrt to phone numbers and banks) seems to be trying to enter the online payments business. But it does require MobilePay which is ubiquitous in Denmark, but utterly useless outside of it. So the rollout to other markets is slow to non-existing (and given how Danish banks - which run MobilePay - seem not to be aware of the rest of the world), so if I were a merchant no way in hell I would chose to exclusively accept MobilePay online.
Very excited about this, hoping to see hotel/rental taxes supported. Trying to figure out how different areas tax rentals is kind of a nightmare. Avalara offers this service but we couldn't get past their sales team to actually use their product
We're not there just yet, but feel free to shoot me (kmoriarty@stripe.com) an email with any other tax related requests or requirements, as this is just the beginning!
The next great step would be to manage Tax collecting from Stripe Customer Portal. In this wet a website could redirect the user directly to stripe to fill all information for invoicing instead of saving locally, validating and sent them to stripe
Our company was part of the beta and we were having buggy issues when trying to use Stripe Tax alongside the Customer Portal, which AFAIK they haven't resolved yet. So just FYI if you implement and bump into this, it's them not you.
We shipped customer portal support a few weeks ago, apologies for not following up and letting you know! If there were any other issues though, do let me know -- kmoriarty@stripe.com
Hey! The issue we were having was related to customers being unable to change their subscriptions through the Portal with Tax enabled, which I just tested and still seems to not work. I've sent you an email so hopefully we can figure this out.
One of the things I love about Stripe is how much information they give you on the landing page for the product. Code snippets, examples, clear explanations about what the product does; links to developer documents etc.
Side question but what solutions exist for managing withholding? That presents a huge barrier to entry for certain business models, even more so when you have users living in multiple tax jurisdictions.
Hey! We haven't tackled tax withholding yet. That said, I'd love to learn more about your use case and requirements if you're up for it: kmoriarty@stripe.com
Ah man, I’m so glad this exists. One of my biggest concerns in monetising side-projects has always been running afoul of sales tax law, and this should hopefully help to assuage some of those concerns.
If you're an indie hacker, or solo founder taxes are extremely important and you cannot ignore them if you go over a certain amount.
In the past taxes, VAT and all of that is a pain in the backside for most EU / UK businesses and most go with Paddle because of this.
I am so elated that this is now available (although through an invite), and saves a TON of time, unnecessary annoying scripts and duck tape.
Downvoters: So you can manage taxes and VAT for each different EU member state yourself manually? Is this some sort of side hobby for you? This is a real problem of many businesses.
You still have to calculate all taxes from Stripe from these EU regions and then do that. For those using Stripe before this announcement it was a huge time sink.
never used stripe, but I do like their design choices.
Also given how extensive their APIs are and even offer in-person payments via a physical terminal, why would one choose Stripe over Square? I am guessing these products mean the % transaction cost is slightly more than what is offered by other payment companies (chase, square, boa)?
Almost seems like a no brainer to choose stripe if you want to scale your small business.
Only if you meet the volume thresholds, which vary by country - e.g. for sales to Ireland you must register and pay VAT if your sales are over EUR 35k / year, but in Germany its 100k.
> At the heart of the 2021 e-commerce EU VAT reboot is the introduction of the One-Stop-Shop (‘OSS’) single EU VAT return and the withdrawal of the Distance Selling thresholds.
[...] Non-EU sellers may also apply to use the OSS regime, and just need to nominate any single EU state to register and file in.
Are you sure this still applies in the case of purely digital sales like SaaS, and for businesses selling into an EU country but based outside rather than domestic businesses selling within their own country?
So if this product does not file VATS in 50+ countries (seems impossible anyways) and it does not actually pay these fees. This product is solving a solution that no online retailer should even bother with.
Honestly, until congress fixes interstate commerce and that terrible Wayfair decision, until the VAT process is drastically simplified/unified, nobody should collect or pay these fees to anyone. When they come for it, sue.
The bottom line is this maddening confusion isn't worth dealing with for the business or the state/country.
Can you please ban me? I don't want to be part of this community any more. I appreciate you (you! specifically) holding this place together but it's become one of the most toxic places on the internet for anti-Christian, anti-American and anti-conservative sentiment.
LOL. I wonder what kind of information diet one would have to construct, and how long one would need to adhere to it, to get oneself to a place where they sincerely believe this.
And even if you somehow DID believe that governments never create wealth, you'd need to have also convinced yourself that they can do no good aside from wealth creation. Or possibly that there IS no good aside from wealth creation.
Regardless of what it is, it is a viewpoint totally divorced from reality.
What they never do is "earn." You wouldn't use that verb for money I took under threat of force or imprisonment, right? So why would you use it here? Try "steal," "rob," or, if you're feeling particularly generous, "take."
As for where it's going: Into a hole in the ground? My argument is that governments are inherently inefficient, not that governments shouldn't exist.
Government is emergent. It has to exist. If you see someone having the "Should government exist?" debate they're probably an anarchist in high school. Or an HNer, I guess. It's not a serious intellectual discussion topic. Drop 10 people off on a deserted island and they'll have a government 30 minutes later. There's no "no government."
> Tilly, the 2-year-old Border Collie who was ejected from a car Sunday during a crash, has been found.
> He was found on a sheep farm, where he had apparently taken up the role of sheep herder.
> According to Tilly's owner, he has lost some weight since Sunday's crash and is now drinking lots of water but is otherwise healthy.
> PREVIOUS COVERAGE:
> RATHDRUM, Idaho - The Idaho State Police (ISP) is investigation after a crash blocked SH-41 and Hayden Avenue on Sunday afternoon.
> ISP said they are looking for people who witnessed the incident.
> The crash happened when a GMC Yukon towing a white horse trailer attempted to turn south onto SH-41 when a Buick struck the GMC.
> The driver of the Buick, a man from Spirit Lake, was transported to a nearby hospital and was treated and released. No one else was injured.
> During the crash, a dog was ejected from the rear of the GMC and is still missing.
> ISP said the dog is a 2-year-old Border Collie Heeler mix that goes by the name "Tilly". Tilly has no tail, a dark-colored face, weighs approximately 70 pounds, and was wearing a multi-colored plaid and tan-colored collar with a name tag containing the owner's contact information.
> Tilly was last seen running northwest from the crash scene through the field.
The member states of SST have agreed to pay for those services from several tax SaaS companies. (There is one catch: to avail yourself of this, you must collect tax for all SST states, even though you might be below the threshold in some of them).
The companies participating are Avalara, TaxCloud, Sovos, and Accurate Tax.
For small online businesses I suspect that a lot more can take advantage of this than you might expect. Here's a map showing the SST member states [1]. Although it is missing some big states that you probably do a lot of business in (California for instance), a lot of those big states have quite high thresholds for sales or number of transactions before tax kicks in.
Some of the companies that provide the fee SST service will also add non-SST states for a fee. If you only need one or two non-SST states, it will still probably come out cheaper than using Stripe (and will include reporting and filing).
[1] https://www.streamlinedsalestax.org/