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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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..
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.
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.)
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.
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.
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.
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.
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?)
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?
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.)
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.
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.
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.
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.
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.
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.
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.
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! :)
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.
> 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.
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.
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.
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)
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.
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?
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.
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.
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.
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!
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.
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.
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
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.
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!
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.
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.
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).
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.
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).
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.
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.
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.
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
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.
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.
> 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.
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.
> 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.
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 ;)
382 comments
[ 4.9 ms ] story [ 316 ms ] thread[0] https://www.venable.com/insights/publications/2019/05/will-t...
But 0.5% fee per transaction is.. steep.
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.
A glass of water has more value to you when you're thirsty.
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
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.
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.
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.
[0]: https://arstechnica.com/cars/2021/06/volkswagen-plans-to-off...
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.
But if they wanted to, they could hike prices tomorrow - same with any other alternatives.
I solved this partially by using Wise (formerly Transferwise) for USD->XYZ conversion and paying way less now.
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 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.
Why not? Wouldn't fixed fees be preferable to a relative basis for something like this?
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.
Here's a twitter thread of everything you had to do previously: https://twitter.com/vvoyer/status/1347488977738149888
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.
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.
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.
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.
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.
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.
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.
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.
They fixed this a little while back. There's now a fully independent sandbox environment: https://developer.paddle.com/getting-started/sandbox
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.
https://en.wikipedia.org/wiki/South_Dakota_v._Wayfair,_Inc.
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.)
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.
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.
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.
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 can argue against reality all you want, but it won't change decades of history, nor will it change how the world actually works.
Actually the same rules apply to both. See https://blog.taxjar.com/international-sellers-deal-sales-tax...
1) We monitor your transaction and compare them to local thresholds so you know where/when you may need to register: https://stripe.com/docs/tax/set-up#monitoring-your-obligatio...
2) We provide documentation/links to the exact sites to register: https://stripe.com/docs/tax/registering#list-of-state-and-co...
In the future though we'd love to also offer registrations on your behalf, this is just the beginning!
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?
At some point you may reach a limit where you need to file taxes in other places as well.
But as a one man operation that sounds unlikely.
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.
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.)
- 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.
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.
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.)
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.
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.
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.
Australian companies can only get paid in AUD. I've been getting killed on this for years, Stripe keeps saying "soon" :(
AFAIK Paddle solves that too but Stripe doesn't.
US filing partner TaxJar EU filing partners Taxually Marosa"
Yay for automation, but is using third parties to file taxes not open to fraud and potential error (if you don't do it yourself?)
Stripe just acquired them in April.
https://www.irs.gov/businesses/small-businesses-self-employe...
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! :)
Unless your provider really sucks, it's always important to evaluate carefully and ideally stick with them unless it is really that bad.
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.
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.
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.
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)
They’ve really delivered with an outstanding solution.
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.
Each country has their own laws about how tax works for online sales, and who is expected to pay it.
You can choose to ignore what governments in other countries expect. But that’s your decision.
It seems to be a huge mess. Even if you know how much to pay for different countries, registration for paying taxes can be painful.
Correct for the 1st part, on the 2nd part there is a VAT MOSS (One Stop Shop) where you report it in one place your sales/VAT for all the EU countries
Avalara (https://www.avalara.com/us/en/products/sales-and-use-tax/ava...) has been one of the go-to software platforms for this purpose. At least according to my wife, who is a CFO, and generally has to manage this stuff.
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.
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.
https://ec.europa.eu/taxation_customs/business/vat/oss_en
Stripe tax should away the headache of being on the wild ride that is EU VAT as EU citizen.
Congrats on the launch!
Octobat may still be cheaper depending on your transaction volume.
Does Stripe do well in a world where governments provide efficient and easy online payments? Places like Sweden with Swish.
Does Stripe do well in a world where governments provide simplified/near-zero-work tax calculation mechanisms? <todo: find an example>.
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.
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.
> 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?
[0]: https://insights.nordea.com/en/innovation/the-benefits-of-sw...
[1]: https://medium.com/@etiennebr/swish-the-secret-swedish-finte...
Stripe's VIES validation only takes place once and there is no way to retrigger it.
For compliance purposes you have to validate it yourself every quarter or so, on recurring transactions.
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.
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.
Not a huge deal, and I still love Stripe!
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.
https://stripe.com/en-de/pricing
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.
To keep track of VAT rates, we use https://vatlayer.com/
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.
They also have one that gives the most recent day if that better floats you boat: https:///www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.x...
If you need a specific range of dates for specific currencies, they've got that covered too. Here it is for USD and GBP: https://sdw-wsrest.ecb.europa.eu/service/data/EXR/D.GBP+USD....
Specify the range by adding query parameters startPeriod=YYYY-MM-DD and endPeriod=YYYY-MM-DD.
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!
* Selling goods
* Selling electronic services 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. :DEDIT: Turns out I have no idea how to format lists on HN.
https://www.avalara.com/vatlive/en/eu-vat-rules/distance-sel...
Which at the lowest end is € 35,000 per country.
Countries like the UK for example have a VAT threshold of £85,000 for businesses located inside that country.
This is one of the problems of online marketplaces - they have VAT added to them, even when the individual (small) business doesn't need to pay it.
VAT is a big compliance burden for small businesses which is why every country has revenue thresholds under which you don't need to charge it.
Either way, we will be reviewing and onboarding users as quickly as possible after you submit your interest!
IOSS (EU) <150 EUR
VOEC (Norway) <3000 NOK
HMRC (United Kingdom) <135 GBP
> you may be liable to collect and pay VAT to the customer's country's tax authorities
I thought selling to businesses outside EUFT was the same as selling to businesses inside the EUTF.
In many jurisdictions your advertised price (e.g. for German users on your german page) needs to include taxes.
Of course offering one price for everyone is fine as well.
These rules are usually B2C only. For B2B either way is fine.
(I'm definitely no tax expert. Do you own research if needed;) )
~~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.
[1]https://www.gesetze-im-internet.de/pangv/BJNR105800985.html
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.
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).
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.
In that case, the price will change when the delivery/payment details are entered.
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.
I don't know how much it's worth, but properly supporting tax takes a lot of effort to do correctly in real-time.
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?
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.
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.
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.
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.
https://stripe.com/docs/billing/customer/tax-ids
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!)
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.
Fair play to you!
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 ;)