report taxes. Stripe tax does all of that

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

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! :)

Stripe just acquired them in April.

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.

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.

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.

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

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" :(

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.

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!

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

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

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.

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.

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.

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.

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

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.

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

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

AFAIK Paddle solves that too but Stripe doesn't.