In-App Sales in Mobile Apps, Payments on iOS, Android and Websites: Fees, VAT, Taxes, OSS, and Real Net Profit in Europe

When the owner of a digital product sets a price of €10, the first calculation often sounds simple: “If 100 people buy the subscription, I’ll earn €1,000.” But in the real world of digital business, this formula almost never works that directly. Between the price the user sees and the money that actually remains in the business account, there are platforms, payment providers, VAT, local taxes, refunds, chargebacks, currency conversion, accounting, and Apple or Google rules.

In Europe, this is especially important because the sale of digital services in the EU often depends not only on the seller’s country, but also on the buyer’s country. If a company from Poland sells a digital service to a user in Germany, this does not always mean Polish VAT applies. In many cases, you need to look at the country where the service is consumed — in this case, Germany. That is why “€10 for the user” and “€10 of income for the product owner” are two completely different things.

This article explains how in-app sales, in-app purchase, Apple In-App Purchase, Google Play Billing, website payments, VAT for digital services, OSS for digital services, Merchant of Record, Paddle, Lemon Squeezy, Stripe, and other payment options work for mobile apps, SaaS products, and online platforms in Europe.

Important: this article is not legal or tax advice. VAT rates, Apple fees, Google fees, Stripe fees, Paddle fees, Lemon Squeezy fees, and local tax rules may change. Before launching international sales, you should consult an accountant or tax advisor in the country where your business is registered.

What Is an In-App Purchase?

In-app purchase is a purchase made inside a mobile application. The user does not go to a separate website or manually enter card details into an external payment form. Instead, the purchase happens directly inside the app through the platform’s payment mechanism: Apple In-App Purchase on iOS or Google Play Billing on Android.

In-app purchases are commonly used to sell:

• subscriptions;

• one-time purchases;

• premium features;

• digital services;

• access to content;

• internal credits;

• in-game currency;

• feature unlocks;

• additional limits;

• digital goods.

For example, if a user buys Pro access in a task management app, premium filters in a photo app, internal coins in a game, or a subscription to educational content, this is a classic in-app purchase.

However, it is important to distinguish digital goods from physical goods or services consumed outside the app. If a user buys food delivery, a taxi ride, an offline event ticket, a hotel booking, or a physical product from a marketplace through an app, this is a different type of transaction. For such purchases, Apple and Google usually do not require the use of in-app purchase because the product or service is not consumed inside the app.

In simple terms: if the user pays for something digital that is unlocked or used inside the app, the platforms usually want the payment to go through their billing system. If the user pays for a real-world product or offline service, you can usually use Stripe, Adyen, PayPal, local acquiring, bank transfer, or other payment methods.

Payments on iOS

When Apple Requires In-App Purchase

On iOS, the rules are traditionally stricter. If an app sells digital content, digital functionality, or a subscription that is used inside the app, Apple usually requires Apple In-App Purchase.

Apple In-App Purchase is usually required for:

• premium access to app features;

• subscriptions to a digital service;

• unlocking additional functionality;

• selling digital content;

• internal currency;

• in-game items;

• paid levels;

• paid access to a community or content inside the app.

For example, if you have a mobile SaaS product for stores and the user buys a Pro plan that unlocks more products, more stores, analytics, or promotion features inside the app, Apple may treat this as a digital feature. In that case, trying to send the user to a website for payment may lead to the app being rejected during review.

When Apple May Allow External Payments

External payments may be allowed when the purchase relates to:

• physical goods;

• delivery;

• transportation;

• offline services;

• real-world events;

• bookings;

• consultations or services not consumed as digital content inside the app;

• some reader apps;

• specific regional cases;

• external purchase links where permitted by applicable rules.

After the Digital Markets Act in the EU, Apple’s rules became more complex. Apple introduced separate terms for apps in the European Union, including certain options for alternative mechanisms. However, this does not mean that fees disappear completely or that any app can simply add a “pay on website” button. For small businesses, this may actually become more complicated, not easier.

In the EU after the DMA, the logic is no longer simply “Apple or nothing.” It is now “Apple, alternatives, special terms, separate fees, separate risks, and many details.” For a small business, this can require careful analysis before implementation.

Apple Fees

The classic Apple model has long been fairly simple:

Apple’s Small Business Program offers a reduced 15% commission for eligible developers on paid apps and in-app purchases.

It is also important to understand that Apple’s proceeds are usually calculated after applicable taxes and Apple’s commission. So if a user pays €10, Apple does not simply take 15% or 30% from “your clean €10.” In many countries, VAT or another sales tax is first separated from the price, and only then is the developer’s revenue calculated after the platform fee.

Advantages of Apple In-App Purchase

Apple IAP has a high fee, but it would be wrong to look only at that. Apple In-App Purchase also has strong advantages.

1. It is convenient for users.
   Users already have an Apple ID, a linked card, Apple Pay, or another payment method.

2. There is less payment friction.
   The user does not need to enter card details on a website, create another account, or think about whether they trust the payment form.

3. High trust.
   For many users, paying through Apple feels safer than paying on an unfamiliar website.

4. Apple handles part of the payment infrastructure.
   Payments, refunds, part of the tax logic, and reporting inside App Store Connect are not entirely your own infrastructure.

5. Subscriptions are easy to manage in iOS.
   Users can view subscriptions in their Apple ID settings, cancel them, and manage payments.

Disadvantages of Apple In-App Purchase

The disadvantages are also significant.

1. High Apple fee.
   15–30% is a lot, especially if the product already has other costs: servers, support, advertising, sales, content, or moderation.

2. Less control over billing.
   Apple controls many elements of the payment flow.

3. More difficult for B2B.
   If the client needs an invoice, company card payment, VAT ID, annual contract, or custom price, IAP may be inconvenient.

4. Harder to connect a subscription to a specific business object.
   For example, if one user has five stores and wants to pay for Pro only for two of them, Apple subscriptions may create additional architectural complexity.

5. Restrictions on redirecting users to a website.
   You cannot simply write in an iOS app: “Pay cheaper on our website” if this violates Apple’s rules for your app type and region.

6. Complex discounts, promo codes, and custom pricing.
   Apple has its own promo mechanisms, but they do not always cover complex SaaS billing logic.

Payments on Android

How Google Play Billing Works

Google Play Billing is the Android equivalent of Apple In-App Purchase for apps distributed through Google Play. Google Play Billing is used for in-app purchases of digital goods and services in apps distributed through Google Play.

Google Play Billing is used for:

• digital subscriptions;

• premium features;

• internal currency;

• digital content;

• feature unlocks;

• paid levels;

• paid digital services inside the app.

At the same time, Google Play Billing is intended for digital goods only. For physical goods, physical services, or other non-digital products, you usually need to look at other payment solutions, such as Google Pay SDK or third-party payment providers.

Google Play Fees

Historically, Google Play, like Apple, had a standard commission of up to 30%, but lower rates are available for many developers. For example, Google has a 15% service fee tier for the first $1 million in earnings, subject to eligibility and enrollment in Play Console.

Google has also been changing its fee structure in certain regions, including the United States, the United Kingdom, and the European Economic Area. Because of this, it is no longer always accurate to simply say “Google takes 30%.” The actual fee may depend on:

• country;

• product type;

• transaction type;

• whether Google Play Billing or alternative billing is used;

• eligibility for reduced fees;

• when the app was installed by the user;

• regional rules.

Android Is More Flexible, but Still Has Rules

Android is often seen as a more flexible platform. This is partly true: there are alternative app stores, sideloading, regional exceptions, alternative billing systems in some countries, and more technical freedom.

But if the app is published on Google Play and sells digital goods or digital services inside the app, Google Play Billing rules still need to be checked carefully. This is especially important if the product operates in Europe, the United States, the United Kingdom, India, South Korea, or other regions where the rules may differ.

Advantages of Google Play Billing

Google Play Billing has many of the same advantages as Apple IAP:

• fast payment;

• familiar payment flow for users;

• trust in Google Play;

• convenient subscription management;

• less own payment infrastructure;

• easier start for a B2C product.

Disadvantages of Google Play Billing

The disadvantages are also similar:

• Google Play fees may significantly reduce margin;

• custom B2B billing is more difficult;

• invoices are not always convenient;

• alternative payment rules must be constantly checked;

• subscription integration requires server-side validation;

• renewals, cancellations, refunds, grace periods, and account holds must be handled correctly.

Website Payments

Payment Options Available on a Website

Website payments are the most controllable option for a business. You build the checkout yourself, manage pricing yourself, decide which countries to support, issue invoices, create coupons, trials, B2B contracts, and annual plans.

For website payments, you can use:

• Stripe;

• Adyen;

• PayPal;

• Paddle;

• Lemon Squeezy;

• Mollie;

• local payment systems;

• bank transfers;

• SEPA payments;

• B2B invoices;

• direct debit;

• local acquiring.

Stripe is commonly used by SaaS companies, marketplaces, and digital products because it provides a flexible API infrastructure for payments, subscriptions, invoices, coupons, and tax logic. However, Stripe is usually not a Merchant of Record in the classic sense for all scenarios. This means that responsibility for VAT, sales tax, correct jurisdiction, and reporting often remains with the business.

Advantages of Website Payments

Website payments have several major advantages.

The first advantage is lower payment provider fees.
While Apple or Google may charge 15–30%, a card payment through Stripe, Mollie, or Adyen is often much cheaper. For many European cards, payment provider fees may be around 1.5–3% plus a fixed fee, although the exact rate depends on the account country, card type, currency, and other factors.

The second advantage is more control over the customer.
You can see the email, billing country, VAT ID, invoice history, pricing plan, coupons, renewal logic, company status, and payment method.

The third advantage is convenience for B2B.
Companies often do not want to buy a subscription through a manager’s Apple ID. They need an invoice, VAT ID, bank transfer, annual payment, purchase order, or contract.

The fourth advantage is pricing flexibility.
You can create a plan for 3 stores, 10 employees, 5,000 products, a separate add-on, a manual discount for a large client, or a custom enterprise plan.

Disadvantages of Website Payments

But website payments are not simply “the same thing, only cheaper.” With control comes responsibility.

You need to handle:

• VAT for digital services;

• buyer country detection;

• B2C/B2B logic;

• VAT ID validation;

• reverse charge;

• invoices;

• evidence of the buyer’s location;

• chargebacks;

• fraud;

• refunds;

• subscription lifecycle;

• compliance;

• local tax rules;

• reporting;

• accounting integration.

If Apple or Google acts as the effective seller to the end user in a certain scenario, or handles part of the tax collection, then in direct website sales the seller is often your business. This means that if you determine VAT incorrectly, issue invoices incorrectly, or fail to declare sales, the problem is not Stripe’s — it is yours.

VAT in Europe

What Is VAT in Simple Terms?

VAT stands for value-added tax. For the buyer, it looks like part of the price of a product or service. For the business, it is a tax that must be correctly calculated, collected, declared, and paid to the appropriate tax authority.

In the EU, the standard VAT rate is set separately by each country, although EU rules set certain minimum requirements.

For digital services, one detail is especially important: in B2C sales within the EU, what often matters is not the seller’s country, but the buyer’s country. So if a Polish business sells a digital service to a German consumer, German VAT may apply, not Polish VAT.

Examples with Different Countries

App Owner from Poland, Buyer from Germany

A Polish digital service owner sells a subscription to an individual in Germany. If this is a B2C digital service in the EU, German VAT may apply. The standard VAT rate in Germany is 19%, but it should always be checked using current official sources before launching sales.

If the user pays €10 VAT-inclusive, approximately:

• price for the user: €10;

• VAT at 19% included in the price: €1.60;

• amount excluding VAT: €8.40.

App Owner from Poland, Buyer from Spain

If the buyer is an individual from Spain, Spanish VAT may apply to a B2C digital service. The standard VAT rate in Spain is 21%.

With a VAT-inclusive price of €10:

• price for the user: €10;

• VAT at 21% included in the price: €1.74;

• amount excluding VAT: €8.26.

App Owner from Poland, Buyer from the United States

If the buyer is from the United States, EU VAT usually does not apply because the buyer is outside the EU. But this does not mean there are no taxes at all. In the US, sales tax rules may apply depending on the state, economic nexus, product type, Merchant of Record model, or payment structure.

So “outside the EU” does not mean “tax-free space.” It means you need to check the rules of the specific jurisdiction.

App Owner from Germany, Buyer from France

A German company sells a digital service to a French B2C customer. In this case, France as the country of consumption may be relevant. The standard VAT rate in France is 20%.

App Owner from Estonia, Buyer from Italy

An Estonian SaaS sells a digital service to an individual in Italy. For a B2C digital service in the EU, Italian VAT may apply. The standard VAT rate in Italy is 22%.

B2C, B2B, VAT ID, and Sales Outside the EU

B2C Sale

B2C means a sale to an individual consumer. If an individual in the EU buys a digital service, VAT of the buyer’s country often applies. This is where most questions about OSS, buyer country detection, and evidence of location appear.

B2B Sale

B2B means a sale to a business. If the buyer is a company with a valid VAT ID in another EU country, reverse charge may often apply. In this case, the seller may not charge VAT on the invoice, and the buyer accounts for VAT in their own country.

But this cannot be done “by guesswork.” You need to:

• collect the VAT ID;

• validate it;

• keep proof of validation;

• issue the invoice correctly;

• record the transaction correctly in accounting.

Buyer with a VAT ID

If the buyer provides a valid VAT ID, this is a strong signal that the transaction may be B2B. But simply entering a number is not always enough. The VAT ID should be validated, for example through VIES or another official validation mechanism.

Buyer Without a VAT ID

If the buyer does not provide a VAT ID, they are usually treated as B2C. Even if they enter a company name in the “Company name” field, without a valid VAT ID this may not be treated as a proper B2B transaction for VAT purposes.

Sales Within the EU

For B2C digital services within the EU, the most important questions are:

• what is the buyer’s country;

• what VAT rate applies;

• whether OSS should be used;

• what evidence of buyer location should be stored;

• whether the price includes VAT;

• how to generate the invoice or receipt.

Sales Outside the EU

If the buyer is outside the EU, EU VAT may not apply. But there may be:

• UK VAT;

• US sales tax;

• Canadian GST/HST;

• Australian GST;

• Norwegian VAT;

• Swiss VAT;

• local digital services taxes or equivalents;

• marketplace facilitator or Merchant of Record rules.

That is why an international SaaS or mobile app sooner or later faces the question: “Do we want to manage all taxes ourselves, or should we use a Merchant of Record?”

OSS for Digital Services

What Is OSS?

OSS, or One Stop Shop, is a mechanism that allows businesses to declare VAT from sales in different EU countries through one country of registration.

The idea behind OSS is simple: if you sell B2C digital services to customers in different EU countries, you do not necessarily need separate VAT registrations in Germany, Spain, France, Italy, and every other country. You can register for OSS in your own country and file VAT reports centrally.

OSS Example

Imagine a company or entrepreneur in Poland. They sell a digital service to buyers in:

• Germany;

• Spain;

• France;

• Italy.

Without OSS, there could theoretically be a need to deal with VAT registration in each country separately. With OSS, the Polish business can declare VAT through the Polish OSS system, allocating the amounts by country of consumption.

But OSS does not cancel VAT. This is very important. OSS is not a way to “avoid paying VAT.” It is a way to declare and remit VAT more easily.

When OSS Is Especially Useful

OSS is useful if:

• you sell digital services to individuals in different EU countries;

• you have a website with direct payments;

• you do not use a Merchant of Record;

• Apple or Google does not cover your specific tax logic;

• you want to scale B2C sales across Europe.

How to Determine the Buyer’s Country

What Data Can Be Used?

For B2C digital services in the EU, it is important to have evidence of the buyer’s country. In practice, several types of data are used:

Why It Is Not Always Enough to Simply Ask the User’s Country

If you just add a “Country” field and fully trust the user’s answer, this can become a weak point. The user may make a mistake, enter their country of residence, citizenship, company country, card country, or simply choose a country with lower VAT.

For a small product, this may seem like a minor detail. But when sales grow, this “minor detail” becomes a tax risk.

The ideal logic is to have several pieces of evidence:

• billing country;

• IP country;

• card issuing country;

• billing address;

• VAT ID for B2B;

• country in the profile;

• log of country changes;

• timestamp of user confirmation.

Example: User Lives in Germany but Pays with a Polish Card

Imagine this situation:

• the user lives in Germany;

• in checkout, they enter billing country: Germany;

• their IP address is also from Germany;

• but the card was issued in Poland.

What should the business do?

In this case, billing country and IP point to Germany, while the card points to Poland. This does not automatically mean fraud. The person may have moved, may work in Germany, but still use a Polish bank. Or it may be a Polish citizen living in Germany.

A practical approach:

1. Do not block automatically.
   Different countries in the evidence do not always mean fraud.

2. Use billing country as the main evidence if it is supported by other signals.
   If billing country is Germany and IP is Germany, it is reasonable to apply German VAT.

3. Store all evidence.
   Billing country, IP country, card country, date, invoice, user ID.

4. If the evidence strongly conflicts, ask for clarification.
   For example, if billing country is Germany, IP is Spain, card is Poland, and the address is missing, you may ask the user to confirm their billing address.

5. For B2B, validate VAT ID.
   If the user provides a valid German VAT ID, the logic will differ from B2C.

Price and Net Income Calculation Examples

The examples below are approximate. They are not tax advice. For simplicity, we assume:

• the price shown to the user already includes VAT;

• Apple/Google fee is calculated from the amount excluding VAT;

• income tax or corporate tax is assumed at 19%;

• Stripe or similar provider: approximately 2.5% + €0.25;

• VAT rates: Germany 19%, Spain 21%, France 20%, Italy 22%;

• refunds, chargebacks, currency conversion, accounting costs, and withholding tax are not included.

Example 1: User Pays €10 for a Digital Service on iOS

For this example, let’s use a country with 20% VAT.

The conclusion is simple: at a €10 price point, the difference between a 15% and a 30% fee is very noticeable. If the product has high costs, paid advertising, or support expenses, a 30% fee can consume a large part of the margin.

Example 2: User Pays €10 Through a Website Using Stripe or a Similar Provider

Assume 20% VAT and a payment provider fee of 2.5% + €0.25.

On the website, the fee is lower, so net income may be higher. But the business is responsible for VAT logic, OSS, invoices, fraud, chargebacks, and compliance.

Example 3: Polish App Owner Sells a Service to a German Buyer for €10

Assume this is a B2C digital service, the price includes German VAT at 19%, payment goes through a website, and the provider fee is 2.5% + €0.25.

Example 4: Polish App Owner Sells a Service to a Spanish Buyer for €10

Assume this is a B2C digital service, Spanish VAT is 21%, and payment goes through a website.

The difference between Germany and Spain is not dramatic at €10, but at larger sales volumes, a 1–3% VAT difference between countries becomes very noticeable.

Example 5: Polish App Owner Sells a Service to a Buyer in the United States for €10

Assume EU VAT does not apply, but the payment provider charges 2.9% + €0.30 for an international card.

However, there is an important warning: EU VAT may not apply, but depending on the business structure, nexus, and sales model, US sales tax rules or other local requirements may apply.

Example 6: What Price Should You Set to Receive €5 Net Income?

Now let’s look at a practical question: if a business wants to receive approximately €5 net after VAT, platform/payment fees, and assumed 19% income tax, what price should it set?

Assumptions:

• the user-facing price includes VAT;

• Apple/Google fee is 15% or 30%;

• website payment fee is 2.5% + €0.25;

• income tax is 19%;

• no other operating costs are included.

Price for €5 Net Income: iOS or Android with 15% Fee

Price for €5 Net Income: iOS or Android with 30% Fee

Price for €5 Net Income: Website Payment

What does this show? If your goal is maximum margin, website payments often win. But if your goal is minimum friction for mobile B2C users, Apple IAP or Google Play Billing may deliver better conversion. Sometimes it is better to receive a lower margin from more purchases than a higher margin from a checkout users never complete.

Comparison Table of Payment Channels

Merchant of Record

What Is a Merchant of Record?

Merchant of Record is a company that legally acts as the seller to the end customer. It accepts the payment, handles sales taxes, may issue invoices, manages refunds, chargebacks, part of compliance, and then pays you as the product provider.

What Paddle or Lemon Squeezy Can Handle

Merchant of Record services can help with:

• VAT;

• sales tax;

• GST;

• invoices;

• payments;

• refunds;

• chargebacks;

• tax calculation;

• tax remittance;

• compliance;

• local tax rules for digital products.

Advantages of Merchant of Record

A Merchant of Record can be very useful if you want to sell internationally but do not want to immediately build your own tax infrastructure.

Main advantages:

1. Less VAT complexity.
   The MoR handles a significant part of sales tax logic.

2. Faster launch.
   You can start selling in different countries faster.

3. Convenient for international SaaS.
   Especially for B2C or self-serve B2B.

4. Lower compliance risk at the beginning.
   You do not need to immediately analyze every country separately.

5. Invoices and tax receipts.
   Many MoR services automate documents for customers.

Disadvantages of Merchant of Record

But MoR is not a magic solution.

Disadvantages:

1. Higher fee.
   MoR is usually more expensive than Stripe as a regular payment gateway.

2. Less control.
   Formally, the seller to the buyer is the MoR, not your business.

3. Dependency on the platform.
   If the service changes rules, fees, or blocks an account, this can affect your cash flow.

4. Not always suitable for mobile apps.
   If an iOS or Android app sells digital features inside the app, Apple/Google rules may require IAP/Play Billing or special terms.

5. B2B enterprise may be more complex.
   Large companies sometimes want a contract directly with your legal entity, not with Paddle or Lemon Squeezy.

What Should You Choose?

If the Product Is a Mobile App with a Digital Subscription

For iOS, you should usually plan for Apple In-App Purchase. For Android, Google Play Billing. Even if you dislike the Apple fee or Google Play fee, violating platform rules may cost more: rejected updates, blocked payments, or app review problems.

A practical strategy: start with IAP/Play Billing, build proper server-side subscription validation, and only then analyze whether legal alternative payment flows are available in specific regions.

If the Product Has Both a Website and a Mobile App

This is the most interesting scenario. You can have:

• IAP for mobile users;

• website payments for web users;

• B2B invoices for companies;

• MoR for international self-serve sales;

• separate plans for app/web.

But you need to be very careful with communication inside the iOS app. Not every text, button, or banner saying “buy cheaper on our website” will be allowed.

If It Is a B2B SaaS

For B2B SaaS, website payments or invoices are often better than IAP. Business clients usually need:

• VAT ID;

• invoices;

• reverse charge;

• company card payment;

• bank transfer;

• annual contracts;

• custom pricing;

• multiple users;

• role-based access;

• accounting documents.

Apple IAP can be inconvenient for complex B2B SaaS, especially if the subscription is linked not to a single user, but to a company, store, team, or workspace.

If You Sell Digital Services to Individuals in the EU

Here, the main topic is VAT in Europe. If you sell directly through a website, you need either:

• to register and work through OSS;

• to use a Merchant of Record;

• or to have another correct tax model.

For a small start, MoR can be a practical option. For a larger business, your own Stripe + tax + OSS infrastructure may be more profitable, but also more complex.

If the Business Is Just Testing an Idea

If you do not yet know whether there is demand, you should not immediately build a perfect international tax system for six months.

For testing, you can consider:

• Apple IAP / Google Play Billing for a mobile MVP;

• Paddle or Lemon Squeezy for web sales;

• a simple Stripe integration if sales are limited and your accountant confirms the model;

• manual invoices for the first B2B clients.

The main thing is not to launch chaotic payments in 20 countries without understanding who collects VAT and who is the seller to the end customer.

If the Business Already Has Many Customers in Different Countries

Then it is worth investing in proper financial architecture:

• tax engine;

• VAT ID validation;

• OSS;

• automated invoicing;

• subscription management;

• revenue recognition;

• accounting integration;

• refund/chargeback processes;

• country evidence storage;

• separate B2B/B2C logic.

At this stage, “we just accept cards through Stripe” may no longer be enough.

If Maximum Margin Is Important

Website payments through Stripe, Adyen, Mollie, or local acquiring often win. But only if you can correctly handle VAT, OSS, fraud, and compliance yourself.

If you receive €1 more from each payment through your website but lose 40% of conversions because checkout is complicated, the economics may be worse than using IAP.

If Minimum Legal Complexity Is Important

In this case, the winners are often:

• Apple IAP for iOS;

• Google Play Billing for Android;

• Merchant of Record for web sales.

They are more expensive, but they reduce part of the complexity. For a small team, this can be worthwhile: it may be better to pay a higher fee and focus on the product than spend months building tax infrastructure without stable sales.

Conclusion

There is no single perfect payment method for every digital product. Apple In-App Purchase and Google Play Billing are convenient for users, inspire trust, and work well for mobile B2C products, but Apple fees and Google Play fees can significantly reduce margin.

Website payments are often cheaper in terms of fees and provide more control over customers, pricing, invoices, B2B logic, and the financial model. But they also bring complexity: VAT for digital services, OSS for digital services, buyer country detection, evidence of place of consumption, chargebacks, fraud, and compliance.

Merchant of Record services such as Paddle or Lemon Squeezy can be an excellent compromise for SaaS and digital products that want to sell internationally without building full tax infrastructure. But this comes with higher fees and less control over part of the customer/payment flow.

Before launching a digital product in Europe, you need to calculate not only the user-facing price. You need to calculate VAT, platform fees, payment provider fees, income tax, administrative costs, refunds, accounting, and Apple/Google rules. Sometimes €10 at checkout becomes €7 before income tax. Sometimes it becomes €5. And sometimes even less, once advertising, support, and operating costs are included.

The best strategy is not to search for “the cheapest payment method,” but to build a model that fits your product: B2C or B2B, mobile-first or web-first, EU-only or global market, small MVP or mature SaaS with customers in dozens of countries.