When I launched OtterSay, I assumed the payment side was the easy part. Sign up for Stripe, integrate a checkout, start accepting payments. The hard part was supposed to be the product.
Six weeks before launch, I started digging into how payments would actually work for a global digital product. What I found made me stop and rethink the entire architecture. Not the product architecture. The legal one.
This is the thing I wish someone had handed me before I started.
The assumption that feels right
If you run a company in the Czech Republic, or anywhere in the EU, the first instinct is completely reasonable: my company is Czech, my taxes are Czech, and any customer who buys from me is buying from a Czech company, so Czech rules apply.
I held that assumption confidently right up until the moment I actually looked into it.
What the rules actually say
In 2015, the EU rewrote the rules for digital services. Before that, companies like Amazon, Apple, and Google were routing all their EU sales through Luxembourg to benefit from its low VAT rate. The fix was simple in principle: tax follows the customer's location, not the seller's.
This means: if you're a Czech company and a German customer buys your SaaS, they pay German VAT (19%). A Hungarian customer pays Hungarian VAT (27%). The customer's country gets the revenue, not yours.
The EU isn't the only one. The UK adopted the same logic after Brexit. Australia has it. Canada has it. Japan, Singapore, Norway, India, South Africa: all have adopted some version of the same 'place of consumption' principle. The US has its own variant through state-level sales tax, which is messier but directionally identical.
To be precise about what this does and doesn't cover: your company's location still governs corporate income tax (Czech, 21% on worldwide profit). That part of the instinct was right. But consumption tax (VAT, GST, sales tax) is governed by where your customer lives, not where you are.
What the reality looks like for a solo founder
Running the numbers on what 'go global without planning for this' actually looks like:
EU: You need to register as a VAT payer in Czech Republic, then register for the One Stop Shop (OSS) system. OSS lets you file one quarterly return covering all 27 EU member states. Not ideal, but manageable.
UK: UK VAT from your very first sale. No threshold for foreign sellers. One product sold for £10 means you must register.
US: State sales tax, triggered by 'economic nexus' thresholds (typically $100k revenue or 200 transactions in a state). Some states tax SaaS products (Texas, New York, Washington). Others don't (California, Florida). Different thresholds, different forms, different filing schedules across 45+ states.
Australia, Canada, Norway, Switzerland, Japan, Singapore: each has its own GST or VAT registration, its own threshold, its own return schedule.
That's potentially 20+ separate tax registrations. Monthly or quarterly filings in multiple languages. And Czech accountants who actually understand digital services tax well enough to file OSS correctly are rarer than you'd think.
The realistic annual cost of doing this properly, without help: 10-15k EUR in accountant fees, several hundred hours tracking thresholds and deadlines, and a constant background risk of getting something wrong.
The Stripe Tax misunderstanding
When I first hit this wall, my instinct was: great, Stripe Tax handles all this. I'll enable it at launch and figure out the details later.
This is dangerous for a specific reason.
Stripe Tax is a calculator. It calculates the correct rate for a given transaction based on where the customer is. That's genuinely useful. But it doesn't register you anywhere, it doesn't file anything, and it doesn't remit anything to any tax authority. Until you're actually registered in a jurisdiction, every sale you make there creates a tax liability you've collected nothing for.
That liability doesn't go away. You can't retroactively clean it up without paying it out of your own margin. The obligation is created at the moment of sale, not the moment you decide to deal with it.
'Optimize taxes later' doesn't work. The silent accumulation is the trap.
Three layers most founders conflate
There are three separate things here, and conflating them is the core mistake:
A payment processor (Stripe, Mollie, PayPal) moves money from the customer to you. You are still the legal seller. You owe all the taxes.
A tax calculator (Stripe Tax, TaxJar, Avalara) calculates the correct rate for a transaction. You are still legally responsible for collecting and remitting it.
A Merchant of Record (Paddle, Lemon Squeezy, Polar, FastSpring) becomes the legal seller on your behalf. Your customer's receipt shows their name, not yours.
Only the third option actually removes the compliance burden. The first two just make you better at carrying it.
What a Merchant of Record actually does
A Merchant of Record (MoR) is a legal arrangement, not a specific company. Multiple providers offer it: Paddle, Lemon Squeezy (acquired by Stripe in 2024), Polar, FastSpring.
When you sell through an MoR: the customer legally buys from the MoR (their name is on the receipt and in the customer's bank statement). The MoR is already registered for tax in every relevant jurisdiction globally. The MoR collects and remits all consumption taxes. The MoR pays you the net amount minus their fee. Your job is to issue one B2B invoice per month to the MoR at 0% Czech VAT (export of a B2B service to a US company). Every international sale becomes one revenue line per month in your accounting.
The cost is typically 5% + $0.50 per transaction (Paddle, Lemon Squeezy) or 4% + $0.40 (Polar).
One thing that surprised me when I first looked at MoR providers: you don't need separate product pages or sites for this. MoR is just a checkout layer. Your product site stays exactly the same. The only thing that changes is what happens when someone clicks 'Subscribe': instead of opening Stripe, it opens the MoR's checkout. After payment, customers return to your site. Your branding stays yours.
Why 5% is actually cheap
Five percent sounds like a lot until you compare it to the alternative.
For a solo founder going global without an MoR: EU OSS registration and quarterly filings, UK VAT registration and quarterly returns, US nexus tracking across 45+ states with filings wherever you cross thresholds, and similar setups for Australia, Canada, Japan, and wherever else your customers happen to live.
At 500 EUR per month revenue, 5% costs you 25 EUR per month. The break-even against professional accountancy fees across multiple jurisdictions isn't a close call. It's not even the same order of magnitude.
The 5% buys you something more valuable than money, though: it buys you the cognitive load of not tracking thresholds and deadlines across 20 jurisdictions while you're trying to build a product.
One Czech-specific trap that catches prepared founders too
Even if you go with an MoR and solve the global problem, there's a Czech-specific obligation most micro-founders miss entirely: identifikovaná osoba (identified person) status.
In Czech tax law, you become an identifikovaná osoba the moment you receive a B2B cross-border service from an EU or non-EU supplier. That includes Stripe fees, OpenAI API charges, Google Ads, AWS or Google Cloud hosting. You're required to register within 15 days of the first such purchase, regardless of your revenue, regardless of whether you're a full VAT payer (plátce DPH). Most micro-founders discover this well after the fact.
This doesn't affect your prices or your customers at all. But it creates a reporting obligation, and missing the registration deadline creates a compliance problem that takes effort to unwind.
The mental shift that makes this clear
The thing that finally clicked for me was a reframe: stop asking 'what tax do I charge?' and start asking 'who is the legal seller in this transaction?'
If you're the seller, you owe consumption tax everywhere your customers live. If an MoR is the seller, they owe it. You just sell B2B to one US company, and Czech law applies to that one relationship.
That's the whole game. One question, and the rest of the architecture follows from it.
What I decided
I'm going with Paddle as MoR for all consumer-facing digital products. The reasoning: all-in 5% pricing without international card surcharges (Lemon Squeezy adds +1.5% for non-US cards), EUR payout option which keeps Czech accounting simpler, and it sits independently from Stripe (Lemon Squeezy was acquired by Stripe in 2024, which introduces some uncertainty).
For Czech and Slovak customers specifically (once volume justifies splitting the flow), I'll handle those through direct Stripe integration. Domestic DPH at around 1.4% Stripe fees saves roughly 3.5% against Paddle's cut. Worth doing, but only as a Phase 2 optimisation, not a Day 1 decision.
For direct B2B clients: mPohoda invoicing with reverse charge, handled entirely separately.
The lesson isn't 'avoid global payments.' It's 'understand the actual architecture before you pick your tools.' The compliance burden for global digital sales is real, and ignoring it doesn't make it go away. It just means you're accumulating liability while someone else with the same product is building without the risk.