Публічна оферта
Предмет, ціна, момент акцепту, момент надання послуги, порядок оплати, повернення коштів і розірвання. Документ, який у спорі замінює вам договір із кожним клієнтом.
Розробка й аудит юридичних документів онлайн-сервісу — під вашу реальну модель, під вимоги платіжних систем і магазинів застосунків, а не за шаблоном з інтернету.
Публічна оферта — це договір, який ви укладаєте з кожним клієнтом фактом оплати або початком користування сервісом. Щоб вона працювала, у ній мають бути сім умов: предмет, ціна, момент акцепту, момент надання послуги, порядок оплати, умови повернення коштів і порядок розірвання.
Угода користувача (Terms of Use) — окремий документ і про інше: вона регулює правила користування сервісом, а не грошові відносини. Політика конфіденційності — третій документ, про дані. Їх постійно зшивають в один файл, і саме через це в спорі буває незрозуміло, яка умова до чого застосовується.
Комплект підбирається під модель: інтернет-магазину потрібне одне, SaaS з підпискою — інше, маркетплейсу з продавцями-третіми особами — третє.
Предмет, ціна, момент акцепту, момент надання послуги, порядок оплати, повернення коштів і розірвання. Документ, який у спорі замінює вам договір із кожним клієнтом.
Правила користування сервісом, заборонені дії, права на контент, підстави блокування акаунта, обмеження відповідальності, застосовне право і порядок вирішення спорів.
Політики під фактичний склад сервісів: аналітика, платіжні провайдери, розсилки, чат-віджети. З вимогами GDPR, якщо серед користувачів є резиденти ЄС.
Комплект під вимоги App Store і Google Play: опис зібраних даних, видалення акаунта, внутрішні покупки та підписки, вікові обмеження.
Приведення документів до вимог банку, еквайра або PSP — коли підключення вже зупинилось на перевірці або коли ви до неї тільки готуєтесь.
Перевірка того, що вже стоїть на сайті: суперечності між документами, невідповідність реальній моделі, ризикові умови. З переліком правок за пріоритетом.
Їх постійно плутають і часто зшивають в один файл. Насправді вони відповідають на різні питання і в спорі працюють по-різному.
Це пропозиція укласти договір, звернена до невизначеного кола осіб. Коли клієнт оплачує замовлення, він її акцептує — і з цього моменту у вас із ним повноцінний договір, навіть якщо ніхто нічого не підписував. Тому в оферті мають бути чітко описані предмет, ціна, момент, коли послуга вважається наданою, порядок оплати, повернення та розірвання. Саме ці пункти читають і споживач у претензії, і банк під час перевірки.
Terms of Use регулюють не оплату, а поведінку: що користувачу можна робити в сервісі, чого не можна, кому належать права на завантажений контент, за що акаунт блокується, за що ви не відповідаєте. Для сервісу з безкоштовним доступом це взагалі основний документ — оферта там може бути не потрібна зовсім.
Третій документ і третя логіка: які дані ви збираєте, навіщо, кому передаєте і скільки зберігаєте. Її не можна написати «як у всіх», бо вона описує ваш конкретний набір сервісів: систему аналітики, платіжного провайдера, розсилку, чат. Політика, у якій згадані інструменти, яких у вас немає, або не згадані ті, що є, — це не документ, а декорація.
Шаблон описує чужу бізнес-модель. Найпоширеніший результат — умови не збігаються з тим, що реально відбувається: строк повернення інший, момент надання послуги інший, юрисдикція чужа, а іноді в тексті ще й лишається назва компанії, у якої його скопіювали. У спорі зі споживачем суд читає ваш документ буквально, і кожна така розбіжність тлумачиться не на вашу користь.
Другий сценарій дорожчий: платіжна система під час підключення звіряє документи з фактичним змістом сайту. Розбіжність — відмова, а повторний захід зазвичай складніший за перший.
Підписка — окремий випадок, і саме на ньому найчастіше зупиняється підключення рекурентних платежів. До звичайного набору умов додаються ті, яких у разовому продажу немає: порядок автоматичного списання і згода користувача саме на регулярне списання, правила зміни тарифу для тих, хто вже підписаний, порядок скасування і момент, з якого підписка припиняється, доля вже сплаченого періоду при скасуванні, умови пробного періоду й того, що відбувається після його завершення.
Платіжний провайдер перевіряє ці пункти окремо від решти оферти, бо рекурентні списання — зона його власного ризику: саме він отримує чарджбеки, якщо користувач не зрозумів, за що з нього списали гроші вдруге. Тому формулювання «підписка продовжується автоматично» без опису порядку скасування — типова причина відмови, навіть коли решта документів у порядку.
| Чого немає в офері | Що відбувається |
|---|---|
| Моменту акцепту | Незрозуміло, коли договір вважається укладеним. Клієнт заявляє, що ні з чим не погоджувався, і довести протилежне доводиться логами, а не документом. |
| Моменту надання послуги | Незрозуміло, коли зобов'язання виконане. Для цифрового продукту це основна підстава вимоги повернення коштів «послугу не надано». |
| Умов повернення коштів | Застосовуються загальні норми про захист прав споживачів у найширшому тлумаченні. Плюс це перше, що перевіряє банк або PSP перед підключенням. |
| Порядку скасування підписки | Кожне повторне списання стає потенційним чарджбеком. Провайдер бачить у цьому свій ризик і відмовляє в рекурентних платежах. |
| Порядку зміни умов | Нову редакцію не можна застосувати до тих, хто акцептував стару. Фактично на сервісі одночасно діють кілька версій оферти. |
| Застосовного права і порядку спорів | При контрагенті-нерезиденті незрозуміло, куди звертатися. Спір стає дорожчим за предмет спору. |
Умови повернення — найчастіше джерело спорів у цифрових продажах. Коли діє право на відмову протягом чотирнадцяти днів, як зафіксувати момент надання доступу і який комплект документів потрібен для chargeback — у матеріалі повернення коштів за цифровий продукт.
Предмет, ціна, момент акцепту, момент надання послуги, порядок оплати, умови повернення коштів і порядок розірвання. Без будь-якого з цих пунктів оферта перестає виконувати свою головну функцію — замінювати підписаний договір з кожним клієнтом, — і в спорі відсутню умову доводиться доводити іншими доказами.
Підписка додає умови, яких немає в разовому продажу: порядок автоматичного списання і згода на нього, правила зміни тарифу, порядок скасування підписки і момент, з якого вона припиняється, доля вже сплаченого періоду при скасуванні, а також умови пробного періоду. Саме ці пункти найчастіше перевіряє платіжний провайдер перед підключенням рекурентних платежів.
Можна, якщо сама оферта передбачає порядок внесення змін: спосіб повідомлення користувачів, строк до набрання чинності та наслідки незгоди. Якщо такого порядку немає, зміни діють лише для нових клієнтів, а до тих, хто акцептував попередню редакцію, застосовується та, з якою вони погодилися.
Оферта — про гроші: предмет, ціна, оплата, повернення, розірвання. Угода користувача — про правила: що можна і чого не можна робити в сервісі, права на контент, підстави блокування акаунта, обмеження відповідальності. Це різні документи, які в спорі працюють по-різному, і зшивати їх в один файл — поширена помилка.
Шаблон описує чужу модель роботи: інші способи оплати, інші строки, інший склад послуг. Розбіжність між текстом і фактичною моделлю спливає саме в момент спору з клієнтом або перевірки платіжної системи — тобто тоді, коли виправляти вже пізно.
Оферту або договір з клієнтом, політику конфіденційності, а для підписки — окремо умови рекурентних списань і скасування. Перевіряють не наявність файлів, а відповідність їх змісту тому, що фактично відбувається на сайті: реквізити продавця, реальні строки, реальний порядок повернення коштів.
Так. App Store і Google Play мають власні вимоги: опис зібраних даних, можливість видалення акаунта, правила внутрішніх покупок і підписок, вікові обмеження. Комплект для сайту цим вимогам зазвичай не відповідає, і застосунок не проходить рев'ю.
Підключення до платіжної системи зупинилось на перевірці документів? Проведемо аудит наявного комплекту, покажемо, які саме умови не влаштовують провайдера, і приведемо оферту у відповідність до вашої реальної моделі — включно з підпискою й рекурентними списаннями.
Написати в Telegram →Коли регламент застосовується, реєстр обробки, DPA і політики.
Магазин, маркетплейс, спори зі споживачами.
Договори на розробку, NDA, права на продукт.
Вибір юрисдикції, ліцензія, банк і платежі.
Коли працює, коли ні і що має бути в тексті.
Електронний підпис як робочий інструмент.
Партнерські договори у трафіку: що має бути в тексті.
Залиште номер або напишіть у Telegram, і ми повернемось із переліком найближчих кроків.