Продажі всередині мобільного додатку, оплати на iOS, Android і сайті: комісії, VAT, податки, OSS та реальний чистий прибуток у Європі

Коли власник цифрового продукту ставить ціну €10, у голові часто звучить проста математика: “Якщо 100 людей куплять підписку, я зароблю €1000”. Але в реальному житті цифрового бізнесу ця формула майже ніколи не працює так прямо. Між ціною, яку бачить користувач, і грошима, які залишаються на рахунку бізнесу, стоять платформи, платіжні провайдери, VAT, локальні податки, refund-и, chargeback-и, валютні конвертації, бухгалтерія та правила Apple або Google.

У Європі це особливо важливо, тому що продажі цифрових послуг у ЄС часто залежать не лише від країни продавця, а й від країни покупця. Якщо компанія з Польщі продає цифрову послугу користувачу з Німеччини, це не завжди означає польський VAT. Часто потрібно дивитися на країну споживання послуги, тобто на Німеччину. Саме тому ціна “€10 для користувача” і “€10 доходу для власника продукту” — це дві зовсім різні речі.

Ця стаття допоможе розібратися, як працюють продажі всередині додатку, in-app purchase, Apple In-App Purchase, Google Play Billing, оплата через сайт, VAT для цифрових послуг, OSS для цифрових послуг, Merchant of Record, Paddle, Lemon Squeezy, Stripe та інші варіанти прийому платежів для мобільного додатку, SaaS-сервісу або онлайн-платформи в Європі.

Важливо: це не юридична і не податкова консультація. Ставки VAT, комісії Apple, Google, Stripe, Paddle, Lemon Squeezy та локальні податкові правила можуть змінюватися. Перед запуском міжнародних продажів варто проконсультуватися з бухгалтером або податковим консультантом у країні реєстрації бізнесу.

Що таке in-app purchase

In-app purchase — це покупка всередині мобільного додатку. Користувач не переходить на окремий сайт, не вводить вручну дані картки в сторонній формі, а купує прямо в застосунку через механізм платформи: Apple In-App Purchase на iOS або Google Play Billing на Android.

Через in-app purchase зазвичай продають:

• підписки;

• одноразові покупки;

• преміум-функції;

• цифрові послуги;

• доступ до контенту;

• внутрішні кредити;

• ігрову валюту;

• розблокування можливостей;

• додаткові ліміти;

• цифрові товари.

Наприклад, якщо користувач купує Pro-доступ у додатку для планування задач, преміум-фільтри у фото-додатку, внутрішні монети в грі або підписку на освітній контент — це класичний in-app purchase.

Але важливо відрізняти цифрові товари від фізичних товарів або послуг, які споживаються поза додатком. Якщо користувач купує через додаток доставку їжі, таксі, квиток на офлайн-подію, бронювання готелю або фізичний товар з маркетплейсу, це вже інший тип транзакції. Для таких покупок Apple і Google зазвичай не вимагають використовувати саме in-app purchase, тому що товар або послуга споживається не всередині додатку.

Простіше кажучи: якщо користувач платить за щось цифрове, що відкривається або використовується в додатку, платформи майже завжди хочуть, щоб платіж ішов через їхній білінг. Якщо ж користувач платить за реальний товар або офлайн-послугу, можна використовувати Stripe, Adyen, PayPal, локальний еквайринг, банківський переказ або інші методи.

Особливості оплат на iOS

Коли Apple вимагає використовувати In-App Purchase

На iOS правила традиційно суворіші. Якщо додаток продає цифровий контент, цифрову функцію або підписку, яка використовується всередині додатку, Apple зазвичай вимагає використовувати Apple In-App Purchase. Apple прямо описує in-app purchase як спосіб безпечно продавати в додатку віртуальні товари, преміум-контент, цифрові товари й підписки.

Apple In-App Purchase зазвичай потрібен для:

• преміум-доступу до функцій додатку;

• підписки на цифровий сервіс;

• відкриття додаткових можливостей;

• продажу цифрового контенту;

• внутрішньої валюти;

• ігрових предметів;

• платних рівнів;

• платного доступу до спільноти або контенту в додатку.

Наприклад, якщо у вас мобільний SaaS для магазинів і користувач купує тариф Pro, який відкриває більше товарів, більше магазинів, аналітику або рекламу всередині додатку, Apple може вважати це цифровою функцією. У такому випадку спроба відправити користувача на сайт для оплати може призвести до відхилення додатку на review.

Коли Apple може дозволяти зовнішні платежі

Зовнішні платежі можуть бути можливими, якщо покупка стосується:

• фізичних товарів;

• доставки;

• транспорту;

• офлайн-послуг;

• реальних подій;

• бронювання;

• консультацій або послуг, які не споживаються як цифровий контент усередині додатку;

• деяких reader apps;

• окремих регіональних сценаріїв;

• external purchase links у юрисдикціях, де це дозволено відповідними правилами.

Після Digital Markets Act у ЄС правила Apple стали складнішими. Apple запровадила окремі умови для додатків у Європейському Союзі, включно з можливістю використовувати певні альтернативні механізми, але це не означає, що комісії зникають повністю або що будь-який додаток може просто поставити кнопку “оплатити на сайті”. Apple описує зміни для додатків у ЄС як окремий набір умов, пов’язаний із DMA, і зазначає, що розробники можуть продовжувати використовувати App Store та In-App Purchase або розглядати нові можливості за новими правилами.

Окремо Apple має сторінку про комунікацію та просування оферів у App Store в ЄС. Там зазначено, що для iOS/iPadOS додатків у App Store можуть застосовуватись знижені комісії 10% або 17% для цифрових товарів і послуг залежно від сценарію, незалежно від обраної платіжної системи.

Тобто для ЄС після DMA логіка стала не “Apple або нічого”, а “Apple, альтернативи, спеціальні умови, окремі комісії, окремі ризики і багато деталей”. Для маленького бізнесу це може бути не простіше, а навіть складніше.

Комісія Apple

Класична модель Apple довгий час була простою:

Apple Small Business Program передбачає знижену комісію 15% для відповідних розробників на paid apps та In-App Purchases.

Також важливо, що Apple показує proceeds як суму, яку розробник отримує від продажів додатків та in-app purchases після вирахування застосовних податків і комісії Apple.

Тобто якщо користувач платить €10, Apple не просто бере 15% або 30% від “ваших €10 чистими”. Спочатку у багатьох країнах із цієї суми виділяється VAT або інший податок з продажу, а вже потім формується дохід розробника після комісії платформи.

Переваги Apple In-App Purchase

Apple IAP має високу комісію, але було б неправильно дивитися тільки на неї. У Apple In-App Purchase є сильні переваги:

1. Користувачам зручно платити.
   Вони вже мають Apple ID, прив’язану картку, Apple Pay або інший спосіб оплати.

2. Менше тертя в оплаті.
   Людині не потрібно вводити картку на сайті, проходити додаткову реєстрацію або думати, чи можна довіряти формі оплати.

3. Висока довіра.
   Для багатьох користувачів оплата через Apple психологічно безпечніша, ніж оплата на невідомому сайті.

4. Apple бере на себе частину платіжної інфраструктури.
   Платежі, refund-и, частина податкової логіки, звітність у межах App Store Connect — це вже не повністю ваша інфраструктура.

5. Підписки зручно керуються в iOS.
   Користувач може бачити підписки в налаштуваннях Apple ID, скасовувати їх і керувати оплатами.

Недоліки Apple In-App Purchase

Недоліки також суттєві:

1. Висока комісія Apple.
   15–30% — це дуже багато, особливо якщо у продукту вже є інші витрати: сервери, підтримка, реклама, sales, контент, модерація.

2. Менше контролю над білінгом.
   Apple контролює багато елементів платіжного сценарію.

3. Складніше з B2B.
   Якщо клієнту потрібен інвойс, оплата з рахунку компанії, VAT ID, річний контракт або нестандартна ціна, IAP може бути незручним.

4. Складніше зв’язати підписку з конкретним бізнес-об’єктом.
   Наприклад, якщо один користувач має 5 магазинів і хоче оплатити Pro лише для двох із них, Apple-підписки можуть створити додаткову архітектурну складність.

5. Обмеження на редирект на сайт.
   Не можна просто написати в iOS-додатку: “Оплатіть на нашому сайті дешевше”, якщо це порушує правила Apple для вашого типу додатку й регіону.

6. Складність зі знижками, промокодами та кастомними тарифами.
   У Apple є власні механізми промо, але вони не завжди покривають складну SaaS-логіку.

Особливості оплат на Android

Як працює Google Play Billing

Google Play Billing — це аналог Apple In-App Purchase для Android-додатків, які поширюються через Google Play. Google прямо зазначає, що Google Play Billing потрібен для in-app purchases цифрових товарів і послуг у додатках, розповсюджених через Google Play.

Google Play Billing використовується для:

• цифрових підписок;

• преміум-функцій;

• внутрішньої валюти;

• цифрового контенту;

• розблокування можливостей;

• платних рівнів;

• платних цифрових сервісів у додатку.

При цьому Google також зазначає, що Play Billing призначений лише для цифрових товарів, а для фізичних товарів, фізичних послуг або іншого нецифрового контенту потрібно дивитися на інші платіжні рішення, наприклад Google Pay SDK або сторонніх провайдерів.

Комісія Google Play

Історично Google Play, як і Apple, мав стандартну комісію до 30%, але для багатьох розробників доступні знижені ставки. Наприклад, Google має 15% service fee tier для першого $1 млн earnings за умови відповідної реєстрації в Play Console.

У 2026 році Google також оголосив зміни в структурі fee: у США, Великій Британії та Європейській економічній зоні billing fee для Google Play Billing встановлено на рівні 5%, а service fee для нових інсталяцій знижується за новою моделлю.

Через це для Android уже не завжди достатньо сказати “Google бере 30%”. Реальна ставка може залежати від:

• країни;

• типу продукту;

• типу транзакції;

• використання Google Play Billing чи альтернативного білінгу;

• eligibility для зниженої ставки;

• дати встановлення додатку користувачем;

• регіональних правил.

Android гнучкіший, але не без правил

Android часто сприймається як більш гнучка платформа. Частково це правда: існують альтернативні магазини, sideloading, регіональні винятки, альтернативні білінгові системи в окремих країнах і більше технічної свободи.

Але якщо додаток опублікований у Google Play і продає цифрові товари або цифрові послуги всередині додатку, правила Google Play Billing усе одно потрібно уважно перевіряти. Особливо якщо продукт працює в Європі, США, Великій Британії, Індії, Південній Кореї або інших регіонах, де правила можуть відрізнятися.

Переваги Google Play Billing

Google Play Billing має багато тих самих переваг, що й Apple IAP:

• швидка оплата;

• знайомий платіжний сценарій для користувача;

• довіра до Google Play;

• зручне керування підписками;

• менше власної платіжної інфраструктури;

• простіший старт для B2C-продукту.

Недоліки Google Play Billing

Недоліки також схожі:

• комісія Google Play може суттєво зменшувати маржу;

• складніше робити кастомний B2B-білінг;

• не завжди зручно працювати з інвойсами;

• правила альтернативних платежів потрібно постійно перевіряти;

• інтеграція підписок потребує серверної валідації;

• потрібно правильно обробляти renewal, cancellation, refund, grace period, account hold.

Оплата через сайт

Які варіанти оплат можна використовувати на сайті

Оплата через сайт — це найбільш контрольований варіант для бізнесу. Ви самі будуєте checkout, самі керуєте тарифами, самі вирішуєте, які країни підтримувати, які інвойси видавати, як працюватимуть купони, trial, B2B-договори та річні плани.

Для сайту можна використовувати:

• Stripe;

• Adyen;

• PayPal;

• Paddle;

• Lemon Squeezy;

• Mollie;

• локальні платіжні системи;

• банківські перекази;

• SEPA-платежі;

• інвойси для B2B;

• direct debit;

• локальний еквайринг.

Stripe часто використовують SaaS-компанії, маркетплейси та цифрові продукти, тому що він дає гнучку API-інфраструктуру для платежів, підписок, інвойсів, купонів і tax-логіки. Але Stripe — це зазвичай не Merchant of Record у класичному сенсі для всіх сценаріїв, тому відповідальність за VAT, sales tax, правильну юрисдикцію та звітність часто залишається на бізнесі.

Переваги оплати через сайт

Оплата через сайт має кілька серйозних переваг.

Перша перевага — нижча комісія платіжного провайдера.
Якщо Apple або Google можуть брати 15–30%, то картковий платіж через Stripe, Mollie або Adyen часто коштує значно дешевше. Наприклад, Stripe для багатьох європейських карт може мати комісію на рівні близько 1.5% + фіксована сума, хоча конкретна ставка залежить від країни акаунта, типу картки, валюти та інших факторів.

Друга перевага — більше контролю над клієнтом.
Ви бачите email, billing country, VAT ID, історію інвойсів, тариф, купони, renewal-логіку, статус компанії, спосіб оплати.

Третя перевага — зручність для B2B.
Компанії часто не хочуть купувати підписку через Apple ID менеджера. Їм потрібен інвойс, VAT ID, банківський переказ, оплата на рік, purchase order або договір.

Четверта перевага — гнучкість тарифів.
Можна зробити тариф на 3 магазини, 10 співробітників, 5000 товарів, окремий add-on, ручну знижку для великого клієнта або custom enterprise plan.

Недоліки оплати через сайт

Але сайт — це не “те саме, тільки дешевше”. Разом із контролем приходить відповідальність.

Вам потрібно самостійно вирішувати:

• VAT для цифрових послуг;

• країну покупця;

• B2C/B2B-логіку;

• перевірку VAT ID;

• reverse charge;

• інвойси;

• зберігання доказів місця покупця;

• chargeback-и;

• fraud;

• refund-и;

• subscription lifecycle;

• compliance;

• локальні податкові правила;

• звітність;

• інтеграцію з бухгалтерією.

Якщо Apple або Google у певному сценарії виступають фактичним продавцем для кінцевого користувача або беруть на себе частину збору податків, то при прямому продажі через сайт продавцем часто є саме ваш бізнес. А це означає: якщо ви неправильно визначили VAT, неправильно виставили інвойс або не задекларували продажі, проблема не у Stripe — проблема у вас.

VAT у Європі

Що таке VAT простими словами

VAT — це податок на додану вартість. Для покупця він виглядає як частина ціни товару або послуги. Для бізнесу це податок, який потрібно правильно нарахувати, зібрати, задекларувати й передати відповідній податковій системі.

У ЄС стандартна ставка VAT у кожній країні встановлюється окремо, але загальне правило ЄС каже, що стандартна ставка не може бути нижчою за 15%.

Для цифрових послуг важлива деталь: у B2C-продажах усередині ЄС часто має значення не країна продавця, а країна покупця. Тобто якщо польський бізнес продає цифрову послугу німецькому споживачу, може застосовуватись німецький VAT, а не польський.

Приклади з різними країнами

Власник додатку з Польщі, покупець з Німеччини

Польський власник цифрового сервісу продає підписку фізичній особі з Німеччини. Якщо це B2C цифрова послуга в ЄС, потрібно дивитися на німецький VAT. Стандартна ставка VAT у Німеччині — 19%, але її завжди потрібно перевіряти за актуальними офіційними джерелами перед запуском продажів.

Якщо користувач платить €10 VAT-inclusive, то приблизно:

• ціна для користувача: €10;

• VAT 19% усередині ціни: €1.60;

• база без VAT: €8.40.

Власник додатку з Польщі, покупець з Іспанії

Якщо покупець — фізична особа з Іспанії, для B2C цифрової послуги може застосовуватись іспанський VAT. Стандартна ставка VAT в Іспанії — 21%.

При ціні €10 VAT-inclusive:

• ціна для користувача: €10;

• VAT 21% усередині ціни: €1.74;

• база без VAT: €8.26.

Власник додатку з Польщі, покупець зі США

Якщо покупець зі США, EU VAT зазвичай не застосовується, тому що покупець не перебуває в ЄС. Але це не означає, що податків немає взагалі. У США можуть виникати sales tax-правила залежно від штату, економічного nexus, типу продукту, Merchant of Record або платіжної моделі.

Тобто “не ЄС” не означає “податкова пустеля”. Це означає, що потрібно перевіряти правила конкретної юрисдикції.

Власник додатку з Німеччини, покупець з Франції

Німецька компанія продає цифрову послугу французькому B2C-покупцю. У такому випадку часто важлива Франція як країна споживання послуги. Стандартна ставка VAT у Франції — 20%.

Власник додатку з Естонії, покупець з Італії

Естонський SaaS продає цифровий сервіс фізичній особі з Італії. Для B2C цифрової послуги в ЄС може застосовуватися італійський VAT. Стандартна ставка VAT в Італії — 22%.

B2C, B2B, VAT ID і продажі за межі ЄС

B2C продаж

B2C — це продаж фізичній особі. Якщо фізична особа в ЄС купує цифрову послугу, часто застосовується VAT країни покупця. Саме тут виникає найбільше питань з OSS, визначенням країни покупця та доказами місця споживання.

B2B продаж

B2B — це продаж бізнесу. Якщо покупець — компанія з валідним VAT ID в іншій країні ЄС, часто може застосовуватись reverse charge. У такому випадку продавець може не нараховувати VAT у своєму інвойсі, а покупець сам обліковує VAT у своїй країні.

Але це не можна робити “на око”. Потрібно:

• отримати VAT ID;

• перевірити його валідність;

• зберегти доказ перевірки;

• правильно оформити інвойс;

• правильно відобразити операцію в обліку.

Покупець із VAT ID

Якщо покупець надає валідний VAT ID, це сильний сигнал, що транзакція може бути B2B. Але сам факт введення номера не завжди достатній. Номер потрібно перевірити, наприклад через VIES або інший офіційний механізм перевірки.

Покупець без VAT ID

Якщо покупець не надає VAT ID, його зазвичай обробляють як B2C. Навіть якщо він пише назву компанії в полі “Company name”, але не надає валідний VAT ID, для VAT-логіки це може не бути повноцінним B2B-продажем.

Продаж у межах ЄС

Для B2C цифрових послуг у межах ЄС найважливіші питання:

• яка країна покупця;

• яка ставка VAT;

• чи потрібно використовувати OSS;

• які докази місця покупця зберігати;

• чи ціна включає VAT;

• як формувати інвойс або receipt.

Продаж за межі ЄС

Якщо покупець за межами ЄС, EU VAT може не застосовуватись. Але можуть бути:

• UK VAT;

• US sales tax;

• Canadian GST/HST;

• Australian GST;

• Norwegian VAT;

• Swiss VAT;

• локальні digital services tax або аналоги;

• правила marketplace facilitator або Merchant of Record.

Саме тому міжнародний SaaS або мобільний додаток рано чи пізно стикається з питанням: “Ми хочемо самі керувати всіма податками чи краще використати Merchant of Record?”

OSS для цифрових послуг

Що таке OSS

OSS, або One Stop Shop, — це механізм, який дозволяє бізнесу декларувати VAT з продажів у різні країни ЄС через одну країну реєстрації. Європейська комісія описує OSS як електронний портал, який бізнес може використовувати для виконання VAT-зобов’язань щодо e-commerce продажів споживачам у ЄС.

Ідея OSS проста: якщо ви продаєте B2C цифрові послуги покупцям у різних країнах ЄС, вам не обов’язково окремо реєструватися для VAT у Німеччині, Іспанії, Франції, Італії та кожній іншій країні. Ви можете зареєструватися в OSS у своїй країні й подавати звітність централізовано.

Приклад OSS

Уявімо компанію або підприємця в Польщі. Він продає цифрову послугу покупцям у:

• Німеччині;

• Іспанії;

• Франції;

• Італії.

Без OSS теоретично могла б виникнути потреба розбиратися з VAT-реєстрацією в кожній країні окремо. З OSS польський бізнес може декларувати VAT через польську систему OSS, розподіляючи суми за країнами споживання.

Але OSS не скасовує VAT. Це дуже важливо. OSS — це не спосіб “не платити VAT”. Це спосіб простіше його декларувати й перераховувати.

Коли OSS особливо корисний

OSS корисний, якщо:

• ви продаєте цифрові послуги фізичним особам у різних країнах ЄС;

• у вас сайт із прямими платежами;

• ви не використовуєте Merchant of Record;

• Apple або Google не покривають вашу конкретну податкову логіку;

• ви хочете масштабувати B2C-продажі по Європі.

Як визначати країну покупця

Які дані можна використовувати

Для цифрових B2C-послуг у ЄС важливо мати докази країни покупця. На практиці використовують кілька типів даних:

Чому не завжди достатньо просто спитати країну

Якщо ви просто додаєте поле “Country” і повністю довіряєте відповіді користувача, це може бути слабким місцем. Користувач може помилитися, вказати країну проживання, країну громадянства, країну компанії, країну картки або просто обрати країну з нижчим VAT.

Для звичайного маленького продукту це може здаватися дрібницею. Але коли продажі ростуть, така “дрібниця” перетворюється на податковий ризик.

Ідеальна логіка — мати кілька доказів:

• billing country;

• IP country;

• card issuing country;

• billing address;

• VAT ID для B2B;

• country у профілі;

• лог змін країни;

• timestamp згоди користувача.

Приклад: користувач живе в Німеччині, але платить польською карткою

Уявімо ситуацію:

• користувач живе в Німеччині;

• у checkout вказав billing country: Germany;

• IP-адреса також з Німеччини;

• але картка випущена в Польщі.

Що робити бізнесу?

У такому випадку billing country і IP показують Німеччину, а картка — Польщу. Це не обов’язково означає шахрайство. Людина могла переїхати, працювати в Німеччині, але користуватися польським банком. Або це може бути польський громадянин, який проживає в Німеччині.

Практичний підхід:

1. Не блокувати автоматично.
   Різні країни в доказах — не завжди fraud.

2. Використовувати billing country як основний доказ, якщо він підтверджується іншими сигналами.
   Якщо billing country Germany і IP Germany, логічно застосувати німецький VAT.

3. Зберегти всі докази.
   Billing country, IP country, card country, дату, invoice, user ID.

4. Якщо докази конфліктують сильно — запитати уточнення.
   Наприклад, якщо billing country Germany, IP Spain, card Poland, а адреса не заповнена, можна попросити підтвердити billing address.

5. Для B2B — перевіряти VAT ID.
   Якщо користувач надає валідний німецький VAT ID, логіка буде іншою, ніж для B2C.

Приклади розрахунків ціни та чистого доходу

Нижче — приблизні приклади. Вони не є податковою консультацією. Для простоти припустимо:

• ціна для користувача вже включає VAT;

• Apple/Google комісія рахується від суми без VAT;

• податок на прибуток умовно 19%;

• Stripe або аналогічний провайдер: умовно 2.5% + €0.25;

• ставки VAT: Німеччина 19%, Іспанія 21%, Франція 20%, Італія 22%;

• без урахування refund-ів, chargeback-ів, валютної конвертації, бухгалтерських витрат і withholding tax.

Приклад 1: користувач платить €10 за цифрову послугу на iOS

Для прикладу візьмемо країну з VAT 20%.

Висновок простий: при ціні €10 різниця між 15% і 30% комісією дуже відчутна. Якщо продукт має високу собівартість, платну рекламу або підтримку, 30% комісії може з’їдати більшу частину маржі.

Приклад 2: користувач платить €10 через сайт за допомогою Stripe або аналогічного провайдера

Припустимо VAT 20%, платіжна комісія 2.5% + €0.25.

На сайті комісія нижча, тому чистий дохід може бути вищим. Але разом із цим бізнес сам відповідає за VAT-логіку, OSS, інвойси, fraud, chargeback-и та compliance.

Приклад 3: польський власник додатку продає послугу німецькому покупцю за €10

Припустимо це B2C цифрова послуга, ціна включає німецький VAT 19%, оплата через сайт, комісія провайдера 2.5% + €0.25.

Приклад 4: польський власник додатку продає послугу іспанському покупцю за €10

Припустимо B2C цифрова послуга, VAT Іспанії 21%, оплата через сайт.

Різниця між Німеччиною та Іспанією не драматична при €10, але на великих обсягах продажів різниця в 1–3% VAT між країнами вже добре відчувається.

Приклад 5: польський власник додатку продає послугу покупцю зі США за €10

Припустимо EU VAT не застосовується, але платіжний провайдер бере 2.9% + €0.30 через міжнародну картку.

Але тут важливе застереження: EU VAT може не застосовуватись, але залежно від структури бізнесу, nexus і моделі продажу можуть виникати правила sales tax у США або інші локальні вимоги.

Приклад 6: яку ціну поставити, щоб отримати €5 чистого доходу

Тепер практичне питання: якщо бізнес хоче отримати приблизно €5 чистими після VAT, комісії та умовного податку на прибуток 19%, яку ціну потрібно поставити?

Припущення:

• ціна для користувача включає VAT;

• Apple/Google комісія 15% або 30%;

• сайтова оплата: 2.5% + €0.25;

• податок на прибуток: 19%;

• без інших операційних витрат.

Ціна для €5 чистого доходу: iOS або Android з комісією 15%

Ціна для €5 чистого доходу: iOS або Android з комісією 30%

Ціна для €5 чистого доходу: оплата через сайт

Що видно з таблиці? Якщо ваша мета — максимальна маржинальність, сайтова оплата часто виграє. Але якщо ваша мета — мінімум тертя для мобільного B2C-користувача, Apple IAP або Google Play Billing можуть давати кращу конверсію. Іноді краще отримати меншу маржу з більшої кількості оплат, ніж більшу маржу з checkout, до якого користувачі не доходять.

Порівняльна таблиця каналів оплати

Merchant of Record

Що таке Merchant of Record

Merchant of Record — це компанія, яка юридично виступає продавцем для кінцевого покупця. Вона приймає оплату, обробляє податки з продажів, може формувати інвойси, управляти refund-ами, chargeback-ами, частиною compliance і потім виплачує вам гроші як постачальнику продукту.

Paddle пояснює Merchant of Record як юридичну особу, відповідальну за продаж товарів або послуг кінцевому клієнту, яка управляє платежами та пов’язаними зобов’язаннями, включно зі збором sales tax, PCI compliance, refund-ами та chargeback-ами.

Lemon Squeezy також позиціонує себе як Merchant of Record і зазначає, що бере на себе tax compliance для цифрових продажів.

Що можуть брати на себе Paddle або Lemon Squeezy

Merchant of Record сервіси можуть допомагати з:

• VAT;

• sales tax;

• GST;

• інвойсами;

• платежами;

• refund-ами;

• chargeback-ами;

• tax calculation;

• tax remittance;

• compliance;

• локальними податковими правилами для цифрових продуктів.

Paddle вказує, що обробляє sales tax для цифрових продуктів у юрисдикціях, де це є юридичною вимогою, включно з VAT, GST, sales taxes та іншими локальними еквівалентами.

Lemon Squeezy у своїй документації зазначає, що як Merchant of Record він бере на себе sales tax для продажів через платформу, але бізнесу все одно може знадобитися платити податок на дохід, отриманий у вигляді payouts.

Переваги Merchant of Record

Merchant of Record може бути дуже корисним, якщо ви хочете продавати міжнародно, але не хочете одразу будувати власну податкову інфраструктуру.

Основні переваги:

1. Менше VAT-головного болю.
   MoR бере на себе значну частину податкової логіки з продажів.

2. Швидший старт.
   Можна швидше запустити продажі в різних країнах.

3. Зручно для міжнародного SaaS.
   Особливо якщо у вас B2C або self-serve B2B.

4. Менше compliance-ризику на старті.
   Ви не мусите одразу розбирати кожну країну окремо.

5. Інвойси й tax receipts.
   Багато MoR-сервісів автоматизують документи для покупців.

Недоліки Merchant of Record

Але MoR — це не магічна таблетка.

Недоліки:

1. Вища комісія.
   MoR зазвичай дорожчий за Stripe як звичайний payment gateway.

2. Менше контролю.
   Формально продавцем для покупця є MoR, а не ваш бізнес.

3. Залежність від платформи.
   Якщо сервіс змінить правила, комісію або заблокує акаунт, це може вплинути на ваш cash flow.

4. Не завжди підходить для мобільних додатків.
   Якщо iOS або Android-додаток продає цифрові функції всередині додатку, правила Apple/Google можуть вимагати IAP/Play Billing або спеціальних умов.

5. B2B enterprise може бути складнішим.
   Великі компанії іноді хочуть договір саме з вашим юридичним entity, а не з Paddle або Lemon Squeezy.

Що краще обрати

Якщо продукт — мобільний додаток із цифровою підпискою

Для iOS найчастіше потрібно планувати Apple In-App Purchase. Для Android — Google Play Billing. Навіть якщо вам не подобається комісія Apple або комісія Google Play, порушення правил може коштувати дорожче: відхилення оновлення, блокування платежів або проблеми з review.

Практична стратегія: почати з IAP/Play Billing, правильно побудувати серверну валідацію підписок, а вже потім аналізувати, чи доступні легальні альтернативні payment flows у конкретних регіонах.

Якщо продукт має і сайт, і мобільний додаток

Це найцікавіший сценарій. Можна мати:

• IAP для мобільних користувачів;

• сайтову оплату для web-користувачів;

• B2B-інвойси для компаній;

• MoR для міжнародних self-serve продажів;

• окремі тарифи для app/web.

Але потрібно бути дуже обережним із комунікацією всередині iOS-додатку. Не кожен текст, кнопка або банер із “купіть дешевше на сайті” буде дозволений.

Якщо це B2B SaaS

Для B2B SaaS сайтова оплата або інвойси часто кращі за IAP. Бізнес-клієнтам потрібні:

• VAT ID;

• інвойси;

• reverse charge;

• оплата карткою компанії;

• банківський переказ;

• річні контракти;

• кастомні тарифи;

• кілька користувачів;

• рольова модель;

• бухгалтерські документи.

Apple IAP для складного B2B SaaS може бути незручним, особливо якщо підписка прив’язується не до одного користувача, а до компанії, магазину, команди або workspace.

Якщо продаються цифрові послуги для фізичних осіб у ЄС

Тут головна тема — VAT в Європі. Якщо ви продаєте напряму через сайт, потрібно або:

• реєструватися й працювати через OSS;

• або використовувати Merchant of Record;

• або мати іншу коректну податкову модель.

Для маленького старту MoR може бути практичним варіантом. Для більшого бізнесу власна Stripe + tax + OSS-інфраструктура може бути вигіднішою, але складнішою.

Якщо бізнес тільки тестує ідею

Якщо ви ще не знаєте, чи буде попит, не варто одразу будувати ідеальну міжнародну tax-систему на 6 місяців розробки.

Для тесту можна розглянути:

• Apple IAP / Google Play Billing для мобільного MVP;

• Paddle або Lemon Squeezy для web-продажів;

• просту Stripe-інтеграцію, якщо продажі обмежені й бухгалтер підтвердив модель;

• ручні інвойси для перших B2B-клієнтів.

Головне — не запускати хаотичні платежі в 20 країн без розуміння, хто збирає VAT і хто є продавцем для кінцевого клієнта.

Якщо бізнес уже має багато клієнтів у різних країнах

Тоді варто інвестувати в нормальну фінансову архітектуру:

• tax engine;

• VAT ID validation;

• OSS;

• automated invoicing;

• subscription management;

• revenue recognition;

• бухгалтерську інтеграцію;

• refund/chargeback процеси;

• country evidence storage;

• окрему логіку B2B/B2C.

На цьому етапі “ми просто приймаємо картку через Stripe” вже може бути недостатньо.

Якщо важлива максимальна маржинальність

Найчастіше виграє сайтова оплата через Stripe, Adyen, Mollie або локальний еквайринг. Але тільки якщо ви здатні самостійно правильно обробити VAT, OSS, fraud і compliance.

Якщо через сайт ви отримуєте на €1 більше з кожної оплати, але втрачаєте 40% конверсії через складний checkout, економіка може бути гіршою, ніж через IAP.

Якщо важлива мінімальна юридична складність

Тут часто виграють:

• Apple IAP для iOS;

• Google Play Billing для Android;

• Merchant of Record для web-продажів.

Вони дорожчі, але зменшують частину складності. Для маленької команди це може бути вигідно: краще платити більшу комісію і фокусуватися на продукті, ніж витратити місяці на податкову архітектуру, не маючи стабільних продажів.

Висновок

Немає одного ідеального способу оплати для всіх цифрових продуктів. Apple In-App Purchase і Google Play Billing зручні для користувача, викликають довіру й добре працюють для мобільних B2C-продуктів, але комісія Apple і комісія Google Play можуть суттєво зменшити маржу.

Оплата через сайт часто дешевша за комісіями й дає більше контролю над клієнтом, тарифами, інвойсами, B2B-логікою та фінансовою моделлю. Але разом із цим вона приносить складність: VAT для цифрових послуг, OSS для цифрових послуг, визначення країни покупця, докази місця споживання, chargeback-и, fraud і compliance.

Merchant of Record сервіси типу Paddle або Lemon Squeezy можуть бути чудовим компромісом для SaaS і цифрових продуктів, які хочуть продавати міжнародно без повної податкової інфраструктури. Але за це доведеться платити вищу комісію й приймати менший контроль над частиною customer/payment flow.

Перед запуском цифрового продукту в Європі потрібно рахувати не тільки ціну для користувача. Потрібно рахувати VAT, комісії платформ, платіжні комісії, податок на прибуток, адміністративні витрати, refund-и, бухгалтерію та правила Apple/Google. Іноді €10 на checkout — це €7 до податку. Іноді — €5. А іноді ще менше, якщо додати рекламу, підтримку й операційні витрати.

Найкраща стратегія — не шукати “найдешевший платіж”, а будувати модель, яка відповідає вашому продукту: B2C чи B2B, мобільний чи web-first, ЄС чи глобальний ринок, маленький MVP чи зрілий SaaS із клієнтами в десятках країн.