Hacker News Reader

Comment by vvoyer | Hacker News Reader

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.

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.

View on HN

    report taxes. Stripe tax does all of that

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"

Thanks, I updated my comment.

> It doesn't say they file the taxes for you

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?)

Gusto files your taxes for you.

I pay TaxJar to prepare and file my sales tax returns for me.

Stripe just acquired them in April.

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.

https://www.irs.gov/businesses/small-businesses-self-employe...

Not literally all. I can name several small businesses which do their own taxes.

-—> small <—-

Yes. The comment I responded to said "literally all companies", not "literally all large companies".

fwiw I upvoted you because I should have wrote "a vanishingly small amount of businesses, many who are probably screwing things up pretty badly"

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 redefinition of "literally" to mean "not literally" is an abomination and should not be tacitly accepted.

Yeah, but they would lose their license and customers and be sued for damages. The world is not a libertarian / individualistic wild west.

I was part of the beta too for my education site (https://learnetto.com) and I couldn't agree more - Stripe has done a stellar job.

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.

Unless your provider really sucks, it's always important to evaluate carefully and ideally stick with them unless it is really that bad.

> 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.

I imagine that most businesses have bigger risks to deal with than this, especially in early to mid stages (where Stripe seems to target).

Perhaps. You should always keep that in mind, though, and avoid building your system tightly-coupled to any single supplier.

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.

Do you feel like the value is worth with the fee Stripe is charging?

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.

Do you know if Paddle files taxes for you? And just send you 1099? Or it is similar to Stripe Tax, they just collect and you have to file taxes?

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.

Interesting insights into the TOS of Paddle. Have you compared the TOS of Paddle to FastSpring?

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.

Thanks for the first-hand insights.

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.

Thanks, there's lots of useful info there.

> they don't really have any sort of proper test system, which is pretty unbelievable

They fixed this a little while back. There's now a fully independent sandbox environment: https://developer.paddle.com/getting-started/sandbox

Wow, how did I not know that? Thank you!

> 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.

That's the reason I use 2Checkout (formerly Avangate). I can issue one invoice a month, in my own currency. That saves a lot of work and aggravation.

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.

You don't have to collect tax for states you don't have a presence in. They have no jurisdiction outside their borders.

That used to be the law, but is no longer as of 2018:

https://en.wikipedia.org/wiki/South_Dakota_v._Wayfair,_Inc.

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.

This is my point.

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.)

I understand the current rulings. I am saying they are erroneous. We (who I replied to and myself) understand what is going on. It is not consistent.

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.

Actually the same rules apply to both. See https://blog.taxjar.com/international-sellers-deal-sales-tax...

My purchases on AliExpress have been being charged my state sales tax for quite some time.

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.

Good question! Today you would still need to register yourself, however we tried to make this as easy as possible in two ways:

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!

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?

As long as you are small enough, that's what everyone does. Pay taxes in your own jurisdiction, ignore foreign taxes.

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.

I thought Avalara was the leader in this space. What is their pricing, I can't find it on the site.

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.

Only true for EU-domiciled companies - https://stripe.com/docs/payouts#supported-accounts-and-settl...

We are. If I understand correctly also the UK, where I believe GP is based.

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.

True, but wise accounts make it easier and also cheaper than 2% that Stripe charges.

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.

Except for the vast majority of countries supported by Stripe, you can only be paid in your local currency.

Australian companies can only get paid in AUD. I've been getting killed on this for years, Stripe keeps saying "soon" :(

What about invoicing to the customer?

AFAIK Paddle solves that too but Stripe doesn't.

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.

I think you still need to collect VAT ID on your website and associate it to a stripe customer

Nope, no need! Tax ID is validated when you accept the payment: https://stripe.com/docs/tax/checkout#create-session.

Precision: if you're using Stripe checkout only. On a custom integration you do need to get the customer VAT ID and add it to your Stripe customer

Wao! Does it works for metered-usage plans too?

So what are the advantages of Paddle?

They support PayPal

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.

Reply on news.ycombinator.com