Інтернет торгівля в Україні 2026: огляд, функції та поради

Матеріал актуальний станом на 29 липня 2026 року.

Інтернет-торгівля в Україні давно вийшла за межі окремого сайту з каталогом товарів. Магазини одночасно продають через власний сайт, Prom.ua, Rozetka, соціальні мережі, месенджери та офлайн-точки. Покупці платять карткою, за реквізитами IBAN, під час отримання посилки або кур’єру. Для кожного способу оплати діють свої правила фіскалізації.

Головне питання для власника бізнесу у 2026 році звучить так: чи потрібен РРО/ПРРО для інтернет-магазину? У більшості випадків потрібен. Якщо магазин приймає оплату карткою, через інтернет-еквайринг, платіжний сервіс, готівкою або через власного кур’єра, розрахунок потрібно провести через РРО чи ПРРО та надати покупцю фіскальний чек.

Основний виняток стосується прямого переказу коштів на поточний рахунок продавця за реквізитами у форматі IBAN. Такий переказ вважається банківською операцією, тому РРО/ПРРО зазвичай не застосовується.

Що вважається інтернет-торгівлею у 2026 році

Інтернет-торгівля включає продаж товарів дистанційно, коли покупець обирає товар, оформлює замовлення або проводить оплату через електронний канал. Це може бути не тільки класичний інтернет-магазин.

До онлайн-продажів належать:

• замовлення на власному сайті;
• продаж через маркетплейси;
• замовлення через Instagram, Facebook або TikTok;
• продаж у Telegram, Viber та інших месенджерах;
• оформлення замовлення через мобільний застосунок;
• продаж через телефон після звернення покупця з онлайн-реклами;
• B2B-замовлення через особистий кабінет клієнта.

Канал, у якому покупець написав продавцю, не визначає необхідність використання каси. Ключове значення має спосіб розрахунку. Продаж через Instagram з оплатою карткою підпадає під ті самі вимоги, що й продаж через повноцінний сайт.

Для власників, які тільки планують запуск, корисним буде окремий огляд ніш для інтернет-магазину у 2026 році. Однак модель приймання оплат і фіскалізацію потрібно проєктувати ще до старту розробки, а не після отримання перших замовлень.

Що таке РРО та ПРРО

РРО є фізичним реєстратором розрахункових операцій. Це касовий апарат, який реєструє продажі, друкує чеки та передає інформацію до податкової служби.

ПРРО є програмним реєстратором розрахункових операцій. Він працює як програма на комп’ютері, смартфоні, планшеті, сервері або безпосередньо в системі інтернет-магазину. ПРРО формує електронний фіскальний чек і реєструє його через фіскальний сервер ДПС.

Для інтернет-магазину ПРРО зазвичай зручніший. Його можна підключити до сайту через API, пов’язати з платіжним сервісом, CRM, ERP та службою доставки. Після успішної оплати чек створюється без участі менеджера.

Чи потрібен РРО/ПРРО для інтернет-магазину: таблиця способів оплати

Оплата карткою на сайті

Коли покупець вводить реквізити картки у платіжній формі або використовує Apple Pay чи Google Pay, відбувається розрахункова операція. Банк або платіжний сервіс переказує кошти, але не продає товар від імені інтернет-магазину.

Квитанція платіжного сервісу підтверджує переказ коштів. Вона не замінює фіскальний чек продавця. Після підтвердження успішної оплати магазин повинен провести операцію через РРО/ПРРО та передати покупцю розрахунковий документ.

У технічній реалізації чек не варто створювати одразу після натискання кнопки «Оплатити». Спочатку система має отримати від платіжного сервісу підтверджений статус платежу. Для карткових операцій це зазвичай статус успішного списання або capture, а не попередня авторизація коштів.

Я рекомендую прив’язувати фіскалізацію до серверного повідомлення платіжної системи, тобто webhook. Перенаправлення покупця на сторінку «Дякуємо за замовлення» не є надійним тригером. Користувач може закрити вкладку, втратити з’єднання або не повернутися на сайт після оплати.

Розробляємо ecommerce-проєкти, які допомагають продавати більше

Повний функціонал для онлайн-продажів:

каталог товарів, фільтри, підкатегорії

оплати, доставка, особистий кабінет

інтеграції з CRM/ERP

зручна адмін-панель та аналітика

Замовити оцінку

Дмитро Колесніков

Технічний директор Brainlab

Оплата за реквізитами IBAN

РРО/ПРРО може не застосовуватися, якщо продавець надає покупцю реквізити свого поточного рахунку у форматі IBAN, а покупець самостійно здійснює переказ на цей рахунок.

У такій схемі важливі три умови:

1. кошти надходять на підприємницький поточний рахунок продавця;
2. покупець використовує реквізити IBAN;
3. операція проводиться як банківський переказ, а не як картковий платіж через інтернет-еквайринг.

Сам факт використання мобільного банкінгу не робить операцію картковою оплатою. Покупець може відкрити застосунок банку та переказати кошти на IBAN. Це залишається переказом з рахунку на рахунок.

Але QR-код або кнопка «Сплатити» можуть працювати по-різному. Один QR-код містить IBAN і призначення платежу. Інший відкриває платіжну сторінку еквайрингу. У першому випадку РРО/ПРРО зазвичай не потрібен, у другому потрібен. Рішення має визначати тип транзакції, а не назву кнопки на сайті.

Оплату на номер картки не варто використовувати як заміну підприємницькому рахунку та фіскалізації. Така схема створює проблеми з ідентифікацією платежів, обліком доходів, поверненнями та підтвердженням походження коштів.

Післяплата через Нову пошту та інших операторів

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

На практиці можливі дві моделі.

Оператор приймає оплату від свого імені

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

Продавець у такому випадку вкладає в посилку видаткову накладну або інший документ, який підтверджує походження та передачу товару.

Оператор лише передає кошти продавцю

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

Не можна визначити правильну схему лише за написом «післяплата» в кабінеті служби доставки. Потрібно перевірити договір, порядок приймання коштів, призначення платежу, документи оператора та момент переходу товару покупцю.

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

Оплата власному кур’єру

Якщо кур’єр магазину передає товар і приймає готівку або карткову оплату, фіскальний чек потрібно сформувати під час розрахунку.

Для цього кур’єр може використовувати:

• мобільний застосунок ПРРО;
• смартфон або планшет із доступом до кабінету продавця;
• мобільний POS-термінал, пов’язаний із ПРРО;
• заздалегідь підготовлений сценарій фіскалізації в системі доставки.

Чек не слід формувати вранці перед виїздом кур’єра, якщо покупець ще не оплатив товар. Замовлення можуть скасувати, частину товарів можуть не прийняти, а сума розрахунку може змінитися. Фіскалізацію потрібно пов’язувати з фактичним розрахунком.

Продаж через маркетплейси та соціальні мережі

Продаж через маркетплейс не звільняє продавця від використання РРО/ПРРО. Спочатку потрібно визначити, хто приймає оплату від покупця.

Якщо маркетплейс виступає продавцем або комісіонером, сам приймає кошти та видає чек відповідно до договору, обов’язок може бути покладений на платформу. Якщо маркетплейс лише передає замовлення, а оплату отримує магазин, фіскалізацію проводить магазин.

Те саме стосується Instagram, Telegram та Viber. Сторінка в соціальній мережі є лише каналом комунікації. Якщо покупець платить карткою або готівкою, продавцю потрібен РРО/ПРРО.

Коли бізнес виходить одночасно на Prom.ua, Rozetka та інші майданчики, ручна обробка швидко перестає працювати. В окремій статті ми розібрали експорт товарів з Prom.ua та синхронізацію продажів із маркетплейсами.

Передоплата, часткова оплата та оплата кількома способами

Замовлення не завжди оплачується одним платежем. Магазин може отримати аванс, а залишок суми покупець сплатить під час доставки. Інший варіант: частина суми закривається бонусами, а частина карткою.

У таких сценаріях система повинна зберігати:

• загальну вартість замовлення;
• суму кожного платежу;
• час і спосіб кожної оплати;
• зв’язок платежу з конкретним замовленням;
• номери сформованих фіскальних документів;
• суму, яку ще має сплатити покупець.

Неправильна реалізація призводить до подвійної фіскалізації або, навпаки, до чека лише на частину вартості товару. Тому правила передоплати потрібно описати в технічному завданні до початку інтеграції.

Повернення товару та коштів

Автоматизація РРО/ПРРО не закінчується після успішного продажу. Інтернет-магазин повинен коректно обробляти скасування, часткові повернення, повні повернення та заміну товару.

Якщо покупцю повертають кошти за операцією, яка була фіскалізована, потрібно сформувати відповідний розрахунковий документ на повернення. Звичайного статусу «Повернено» в CRM або банківської квитанції недостатньо.

Для часткового повернення система має передати в ПРРО конкретні позиції, їх кількість і суму. Не варто створювати повернення як довільну знижку на загальну суму. Такий підхід ускладнює товарний облік і звірку чеків із замовленнями.

Хто може працювати без РРО/ПРРО

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

РРО/ПРРО може не застосовуватися, зокрема:

• при оплаті виключно банківським переказом на поточний рахунок за IBAN;
• у випадках, прямо передбачених статтею 9 Закону України № 265/95-ВР;
• ФОП першої групи в межах дозволених для цієї групи видів діяльності.

Для ФОП першої групи є окрема проблема. Регулярний продаж через інтернет-магазин, маркетплейс або соціальні мережі може не відповідати переліку діяльності, дозволеної для першої групи. Тому звільнення від РРО не означає автоматичного дозволу вести повноцінну інтернет-торгівлю на цій групі.

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

Які штрафи діють у 2026 році

З 1 серпня 2025 року завершився період застосування зменшених фінансових санкцій. У 2026 році за проведення розрахункової операції без РРО/ПРРО, на неповну суму або без видачі належного розрахункового документа застосовуються стандартні штрафи:

• 100% вартості товарів, робіт або послуг, проданих із порушенням, за перше порушення;
• 150% вартості товарів, робіт або послуг за кожне наступне порушення.

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

За великої кількості замовлень контроль за такими операціями має виконувати система.

Чому ручне формування чеків не підходить інтернет-магазину

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

Проблеми починаються під час росту:

• платежі надходять у неробочий час;
• одне замовлення містить десятки позицій;
• ціна в CRM відрізняється від ціни, введеної касиром;
• менеджер плутає передоплату та повну оплату;
• після повторного webhook створюється другий чек;
• повернення не пов’язується з первинним продажем;
• замовлення з різних каналів потрапляють до різних кабінетів;
• неможливо швидко звірити банк, замовлення та фіскальні документи.

Саме тому автоматизація інтернет-магазину повинна охоплювати не тільки склад і відправлення, а й повний цикл оплати, фіскалізації та повернення коштів.

Як працює інтеграція з РРО/ПРРО

Інтеграція з РРО/ПРРО з’єднує інтернет-магазин, платіжний сервіс і програмну касу. Після підтвердження оплати система автоматично збирає інформацію про замовлення, передає її до ПРРО, отримує фіскальний номер і надсилає чек покупцю.

Типовий процес виглядає так:

1. Покупець оформлює замовлення на сайті.
2. Система створює замовлення з унікальним номером.
3. Покупець переходить до платіжного сервісу.
4. Платіжний сервіс підтверджує успішну оплату через webhook.
5. Магазин перевіряє суму, валюту, статус і номер платежу.
6. Модуль фіскалізації визначає, чи потрібен чек для цього способу оплати.
7. До ПРРО передаються товари, кількість, ціни, знижки та форма оплати.
8. ПРРО реєструє операцію на фіскальному сервері ДПС.
9. Номер і дані чека записуються в замовлення.
10. Покупець отримує чек на email або наданий номер телефону.
11. CRM, ERP та бухгалтерська система отримують фінальний статус операції.

Цей ланцюжок повинен працювати на сервері. Не можна покладатися на браузер покупця або ручне оновлення сторінки.

Які дані магазин передає до ПРРО

Для фіскалізації недостатньо передати тільки загальну суму. Система повинна сформувати структурований склад чека.

Зазвичай передаються:

• номер замовлення;
• назва кожного товару;
• SKU або внутрішній код;
• кількість;
• ціна за одиницю;
• сума позиції;
• знижка;
• вартість доставки, якщо вона входить у розрахунок продавця;
• форма оплати;
• податкова група товару;
• код УКТ ЗЕД для товарів, для яких він обов’язковий;
• дані касира або електронного підпису;
• контакт покупця для надсилання електронного чека.

Назви товарів у чеку мають бути зрозумілими. Записи на кшталт «Товар 1» або «Замовлення №1234» не дають нормального товарного обліку. Найкраще використовувати єдиний каталог номенклатури для сайту, ERP, складу та ПРРО.

Архітектура автоматичної фіскалізації

Надійна інтеграція з РРО/ПРРО потребує окремого шару бізнес-логіки. Я не раджу вбудовувати всі правила безпосередньо в кнопку оплати або в один плагін checkout.

У системі мають бути такі компоненти:

Модуль платежів

Він приймає повідомлення від банків та платіжних сервісів, перевіряє цифровий підпис webhook і змінює статус платежу.

Модуль правил фіскалізації

Він визначає, чи потрібно створювати чек. Наприклад, для карткової оплати результатом буде «фіскалізувати», а для підтвердженого переказу на IBAN може бути «не фіскалізувати».

Черга операцій

Запит до ПРРО не повинен блокувати оформлення замовлення. Операція додається в чергу, обробляється окремим процесом і повторюється у разі тимчасової помилки.

Захист від дублів

Платіжні системи можуть повторно надсилати webhook. Для кожного платежу потрібен унікальний ключ ідемпотентності. Якщо чек уже створений, повторне повідомлення не повинно створити другий документ.

Журнал подій

Система зберігає час отримання платежу, запит до ПРРО, відповідь сервера, номер чека, помилки та повторні спроби. Без журналу технічна підтримка не зможе пояснити, чому конкретне замовлення залишилося без чека.

Моніторинг

Власник або відповідальний менеджер повинен отримати повідомлення, якщо чек не зареєстрований протягом заданого часу, закінчився сертифікат, не відкрито зміну або сервіс ПРРО не відповідає.

Що робити, якщо ПРРО або фіскальний сервер недоступний

Тимчасова технічна помилка не повинна призводити до втрати замовлення. Але магазин також не може просто позначити операцію як завершену та забути про чек.

Правильний сценарій включає:

1. збереження платежу та складу замовлення;
2. фіксацію причини помилки;
3. повторну спробу за заданим графіком;
4. обмеження кількості автоматичних повторів;
5. сповіщення відповідального працівника;
6. перевірку, чи не був чек створений під час попередньої спроби;
7. завершення фіскалізації після відновлення сервісу.

Підтримку офлайн-режиму потрібно налаштовувати відповідно до можливостей конкретного ПРРО та чинного порядку його застосування. Не кожна хмарна інтеграція реалізує офлайн-режим однаково.

Як надсилати електронний чек покупцю

Покупець може отримати фіскальний чек у паперовій або електронній формі. Для інтернет-магазину логічно використовувати електронний документ.

Чек можна надсилати:

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

Зберігати чек лише в особистому кабінеті або надсилати покупцю звичайне посилання на сторінку магазину ризиковано. Система повинна зафіксувати спосіб і факт передання розрахункового документа покупцю.

Під час checkout варто заздалегідь отримувати email або телефон та пояснювати, що контакт використовується для надсилання документів про замовлення.

Інтеграція ПРРО з CRM, ERP і складом

Окремий ПРРО вирішує лише задачу створення чека. Повна автоматизація інтернет-магазину з’єднує фіскалізацію з іншими системами бізнесу.

Після успішної оплати та створення чека система може автоматично:

• перевести замовлення в статус «Оплачено»;
• зарезервувати товар на складі;
• створити завдання на комплектацію;
• сформувати накладну служби доставки;
• передати продаж до ERP або бухгалтерської системи;
• зменшити залишки на сайті та маркетплейсах;
• надіслати покупцю чек і номер відправлення;
• додати операцію до звіту звірки;
• передати дані до системи аналітики.

У такій архітектурі ПРРО стає частиною загального процесу, а не окремим кабінетом, у якому менеджер дублює роботу. Саме так має виглядати цифрова трансформація торгового бізнесу.

Автоматизація продажів із кількох каналів

У 2026 році інтернет-магазин рідко працює тільки на одному сайті. Замовлення можуть одночасно надходити з WooCommerce, OpenCart, кастомної платформи, Prom.ua, Rozetka та CRM.

Якщо кожен канал має власний модуль фіскалізації, виникає кілька проблем:

• різні назви одного товару;
• різні правила округлення та знижок;
• повторне створення чеків;
• відсутність єдиного журналу;
• складна звірка повернень;
• залежність від кількох плагінів різної якості.

Краще створити центральний модуль замовлень і платежів. Він приймає дані з усіх каналів, приводить їх до єдиного формату та передає в ПРРО.

Вибір платформи має враховувати ці інтеграції. У статтях про Laravel та OpenCart і WooCommerce та кастомну CMS ми окремо порівнювали можливості готових модулів і розробки власної інтеграційної логіки.

Автоматизація інтернет-магазину як операційна система бізнесу

Власник магазину не отримує переваги лише від факту встановлення ПРРО. Результат з’являється, коли оплата, чек, замовлення, склад, доставка та бухгалтерський облік працюють як один процес.

Добре налаштована автоматизація дає практичний ефект:

• менше ручних операцій;
• нижчий ризик пропущених або подвійних чеків;
• швидша обробка замовлень у неробочий час;
• точні залишки в усіх каналах продажу;
• простіша звірка платежів із банком;
• контроль повернень;
• можливість масштабувати продажі без пропорційного збільшення штату.

Наступним рівнем може бути прогнозування попиту, персоналізація пропозицій і автоматична робота з покинутими кошиками. Ці сценарії детальніше описані в матеріалі про використання ШІ в інтернет-магазині.

Проте спочатку потрібно навести лад у базових даних: товарах, цінах, залишках, оплатах і статусах замовлення. Штучний інтелект не виправить систему, в якій один платіж має три різні номери, а назви товарів не збігаються між сайтом і складом.

Як впровадити інтеграцію з РРО/ПРРО

1. Описати всі способи оплати

Потрібно скласти список платіжних сценаріїв: картка на сайті, IBAN, післяплата, готівка кур’єру, POS-термінал, маркетплейси, бонуси, передоплата та оплата частинами.

2. Визначити відповідального за фіскалізацію

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

3. Упорядкувати каталог

Товари повинні мати стабільні SKU, назви, ціни, податкові групи та коди, якщо вони обов’язкові. Один товар не повинен мати різні ідентифікатори в магазині, CRM і ПРРО.

4. Вибрати ПРРО з API

Потрібно перевірити документацію, підтримку webhook, повернень, офлайн-режиму, кількох касирів, тестового середовища та експорту даних.

5. Розробити карту статусів

Статуси «Створено», «Очікує оплату», «Авторизовано», «Оплачено», «Фіскалізовано», «Відправлено», «Повернено» мають чітко відрізнятися. Статус замовлення не повинен автоматично підміняти статус платежу.

6. Реалізувати тестові сценарії

Перед запуском потрібно перевірити успішну оплату, відмову банку, повторний webhook, часткове повернення, повне повернення, скасування замовлення, зміну складу замовлення та недоступність ПРРО.

7. Запустити моніторинг і звірку

Щоденний звіт повинен показувати замовлення, за якими отримано оплату, але не створено чек, а також чеки без пов’язаного замовлення.

Типові помилки під час інтеграції

Фіскалізація за сторінкою успішної оплати

Покупець може не повернутися на сайт. Потрібно використовувати серверний webhook.

Відсутність захисту від повторних повідомлень

Один платіж може створити два чеки. Кожна операція повинна мати ключ ідемпотентності.

Одна загальна позиція замість товарів

Запис «Замовлення на 5 000 грн» ускладнює товарний облік і повернення окремої позиції.

Плутанина між IBAN та еквайрингом

Обидва способи можуть відкриватися в банківському застосунку, але мають різну правову та технічну природу.

Ігнорування повернень

Продаж автоматизували, а повернення менеджер оформлює вручну. У результаті дані банку, CRM і ПРРО не збігаються.

Відсутність журналу помилок

Без технічного журналу неможливо встановити, чи був чек відхилений, загублений або створений двічі.

Надмірна залежність від одного плагіна

Готовий модуль може підійти для простого магазину. Але перед запуском потрібно перевірити його поведінку при повторних платежах, знижках, часткових поверненнях і зміні API постачальника.

Коли потрібна готова інтеграція, а коли кастомна розробка

Готовий модуль підходить магазину з одним сайтом, одним платіжним сервісом, простим каталогом і невеликою кількістю стандартних сценаріїв.

Кастомна інтеграція потрібна, коли:

• замовлення надходять із кількох сайтів і маркетплейсів;
• використовується власна ERP або CRM;
• є часткові оплати та складні знижки;
• працюють кілька юридичних осіб або ФОП;
• потрібна автоматична маршрутизація платежу на відповідну касу;
• магазин має кілька складів;
• повернення можуть бути частковими;
• потрібні внутрішні звіти та автоматична звірка;
• готовий плагін не підтримує бізнес-логіку компанії.

Архітектуру потрібно вибирати не за кількістю замовлень сьогодні, а за процесами, які магазин планує підтримувати протягом наступних років. При цьому checkout має залишатися простим для покупця. Про вплив технічних рішень на оформлення замовлення можна прочитати в матеріалі про конверсійний дизайн інтернет-магазинів.

Практичний висновок для власника інтернет-магазину

У 2026 році відповідь на питання «чи потрібен РРО/ПРРО» залежить насамперед від способу оплати.

Оплата карткою, через платіжний сервіс, готівкою або власному кур’єру потребує фіскалізації. Прямий банківський переказ на поточний рахунок за IBAN зазвичай проводиться без РРО/ПРРО. Для післяплати та маркетплейсів потрібно перевірити договір і визначити, хто фактично приймає оплату та видає чек.

ПРРО для інтернет-магазину краще розглядати не як окрему касову програму, а як частину системи продажів. Інтеграція з РРО/ПРРО повинна автоматично обробляти оплату, створювати чек, передавати його покупцю, оновлювати CRM і склад, а також контролювати повернення та помилки.

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

Часті запитання

Чи потрібен РРО/ПРРО для інтернет-магазину у 2026 році?

Так, у більшості випадків. РРО або ПРРО потрібен при оплаті карткою, через платіжний сервіс, готівкою, POS-терміналом або власному кур’єру. Винятком може бути прямий переказ на поточний рахунок продавця за реквізитами IBAN.

Чи потрібен ПРРО при оплаті карткою на сайті?

Так. Оплата банківською карткою через інтернет-еквайринг є розрахунковою операцією. Квитанція банку або платіжного сервісу не замінює фіскальний чек продавця.

Чи потрібен РРО при переказі на IBAN?

Зазвичай ні, якщо покупець самостійно переказує кошти на поточний рахунок продавця за реквізитами IBAN. Важливо, щоб це був банківський переказ, а не карткова оплата через еквайринг.

Чи потрібен РРО при оплаті на номер картки?

Оплату на номер картки не слід прирівнювати до переказу на підприємницький рахунок за IBAN. Для такої моделі потрібно окремо оцінити рух коштів і вимоги до фіскалізації. Для інтернет-магазину безпечніше використовувати офіційний рахунок, еквайринг і ПРРО.

Хто видає чек при післяплаті?

Це залежить від договору зі службою доставки або фінансовим оператором. Якщо оператор від свого імені приймає оплату та видає фіскальний чек, окремий чек продавця може не знадобитися. Якщо оператор лише переказує отримані кошти, обов’язок може залишатися за продавцем.

Чи можна надіслати електронний чек на email?

Так. ПРРО дозволяє сформувати електронний чек і надіслати його покупцю на email, номер телефону або через інший погоджений електронний канал.

Коли потрібно створювати чек при онлайн-оплаті?

Після отримання підтвердження успішної розрахункової операції. Технічно краще використовувати серверний webhook платіжного сервісу, а не повернення покупця на сторінку магазину.

Чи може інтернет-магазин автоматично формувати чеки?

Так. Інтеграція з РРО/ПРРО через API дозволяє автоматично створювати чек після оплати, записувати його номер у замовлення та надсилати документ покупцю.

Чи потрібно оформлювати чек при поверненні коштів?

Якщо первинний продаж був проведений через РРО/ПРРО, при поверненні потрібно сформувати відповідний розрахунковий документ. Для часткового повернення вказуються конкретні товари та суми.

Що краще для інтернет-магазину: РРО чи ПРРО?

Для більшості інтернет-магазинів зручніший ПРРО. Він підтримує електронні чеки, API-інтеграції, автоматичну роботу з оплатами та підключення до CRM, ERP і маркетплейсів.

Нормативна база та офіційні роз’яснення

• Закон України № 265/95-ВР про застосування РРО та ПРРО;
• роз’яснення ДПС щодо онлайн-продажів і РРО/ПРРО у 2026 році;
• роз’яснення ДПС щодо оплати на рахунок у форматі IBAN;
• розділ ДПС про програмні РРО.

Матеріал має оглядовий характер. Для нестандартної агентської схеми, післяплати, роботи з кількома ФОП або продажу товарів зі спеціальними вимогами до обліку доцільно перевірити договори та отримати індивідуальну податкову консультацію.