Бізнес може приймати замовлення на сайті, у соцмережах, месенджерах або через інвойси. Якщо інформація про оплату, фіскалізацію та виконання продажу зберігається в різних системах, контролювати весь процес складніше: підтверджений платіж можна вчасно не передати в роботу, а повернення чи чек — не відобразити у внутрішньому обліку. Розбираємо, як звести продажі з різних каналів в одну систему, пов’язати платіж із конкретним замовленням і простежити його до фактичного зарахування коштів.
Де втрачається зв’язок між оплатою та замовленням
Розрив між замовленням і оплатою може виникнути, коли їх фіксують у різних системах. Наприклад, клієнт домовляється про покупку з менеджером у соцмережі або месенджері, а менеджер вносить замовлення до CRM чи внутрішньої таблиці та окремо формує рахунок для оплати.
Інвойс — один із прикладів такого сценарію. За внутрішніми даними WayForPay, з 1 січня 2017 року до 11 серпня 2026 року користувачі платформи створили та відправили 16 641 476 інвойсів. Підприємець може вказати суму та параметри платежу й надіслати клієнту готове посилання через електронну пошту, SMS або месенджер.
Після оплати в платіжній системі з’являється транзакція, яку потрібно зіставити із замовленням у внутрішньому обліку. Якщо між цими записами немає однозначного зв’язку, працівнику доводиться шукати потрібний платіж за сумою, часом операції, номером телефону або іншими даними клієнта. За великої кількості продажів ручна звірка забирає більше часу та збільшує ймовірність помилки.
Для інтегрованих платежів WayForPay передбачає orderReference — унікальний номер замовлення в системі продавця, який передається разом із платіжним запитом. За ним можна перевірити статус і суму транзакції, а також дані про повернення та інші параметри конкретної операції.
Якщо автоматичної інтеграції немає, зв’язок між замовленням і платежем можна фіксувати у внутрішньому реєстрі. Головне — мати однозначний номер або інший ідентифікатор, за яким працівник зможе знайти відповідну транзакцію без ручного пошуку за кількома параметрами.
Статус платежу і статус замовлення потрібно вести окремо
Після того як платіж пов’язаний із конкретним замовленням, бізнесу потрібно окремо відстежувати стан транзакції та етап виконання. Ці процеси рухаються паралельно: платіж може ще перебувати в обробці або завершитися відмовою, тоді як саме замовлення вже створене у внутрішній системі.
У WayForPay, зокрема, передбачені статуси InProcessing для операцій в обробці, Pending для транзакцій на антифрод-перевірці, Approved для успішних платежів, а також Expired, Declined, Refunded/Voided і RefundInProcessing. Статус Approved означає, що платіж успішно проведено та кошти списано з картки клієнта. InProcessing і Pending свідчать, що операція ще не отримала фінального результату.
Внутрішній статус замовлення відповідає вже на інше питання — що відбувається з покупкою після оплати. Залежно від бізнес-моделі це можуть бути етапи «прийнято в роботу», «комплектується», «відправлено» або «виконано».
Тому одного поля «оплачено / не оплачено» для контролю продажу недостатньо. Бізнесу потрібно окремо бачити результат транзакції та поточний етап виконання замовлення. Наприклад, статус Approved підтверджує оплату, але сам по собі не означає, що товар уже передали на склад, відправили покупцеві або послугу надали.
Читайте також: Як фрилансеру обрати платіжний сервіс: головні критерії
Які дані варто звести в один реєстр
Після того як замовлення пов’язане з конкретною транзакцією, бізнесу потрібен єдиний запис про весь продаж. Він має дозволяти за кілька хвилин зрозуміти, звідки надійшло замовлення, чи проведена оплата, на якому етапі виконання воно перебуває та чи виникали повернення або інші зміни.
Базова частина такого запису:
- номер замовлення;
- дата;
- канал продажу;
- контактні дані покупця та сума.
Канал варто фіксувати окремо: сайт, месенджер, соцмережа, інвойс чи інше джерело. Це допомагає відновити контекст продажу, якщо клієнт звернеться повторно або працівнику потрібно буде перевірити, де саме оформлювали покупку.
До цього запису додаються дані про оплату: ідентифікатор транзакції, її статус, сума та час проведення. Водночас статус виконання замовлення ведеться окремо. Наприклад, платіж уже може бути підтверджений, а товар ще чекати на комплектацію. Так працівник бачить дві різні частини процесу та не сприймає успішну транзакцію як автоматично виконане замовлення.
Для операцій, де це актуально, у реєстрі також варто передбачити поля для фіскального чека, повернення коштів і коментаря відповідального працівника. Якщо покупцеві повернули частину суми, змінився склад замовлення або виникла проблема з його виконанням, ця інформація залишається прив’язаною до того самого продажу.
Корисно одразу визначити й відповідального за поточний етап. Тоді запис показує не тільки стан замовлення, а й наступну дію: менеджер має підтвердити деталі, склад — підготувати товар, бухгалтер — перевірити повернення. Це особливо важливо, коли з одним продажем працюють кілька людей і передають його один одному.
Для невеликого бізнесу такий реєстр можна вести в структурованій таблиці. Зі зростанням кількості замовлень частину даних доцільно автоматично передавати до CRM, CMS або системи управління замовленнями. У будь-якому форматі структура має давати однаковий результат: за номером замовлення працівник бачить його джерело, оплату, поточний етап, відповідального та всі зміни, що відбулися після оформлення.
Що має відбутися після підтвердження оплати
Після підтвердження транзакції її результат потрібно передати в систему, де бізнес веде замовлення. Інакше в платіжному кабінеті операція вже матиме успішний статус, а у внутрішньому обліку замовлення залишатиметься без оновлення.
У невеликому бізнесі сигналом для наступної дії може бути повідомлення про оплату. У WayForPay можна налаштувати сповіщення про успішні та неуспішні платежі через електронну пошту, Telegram або мобільний застосунок. Працівник отримує інформацію про нову транзакцію, перевіряє пов’язане з нею замовлення та передає його далі за внутрішнім процесом.
За більшого обсягу операцій цей етап можна автоматизувати. Для інтегрованих платежів WayForPay використовує serviceUrl, на який система продавця отримує дані про результат транзакції. Окремий параметр returnUrl визначає сторінку, на яку буде перенаправлений покупець після оплати.
Цю різницю важливо враховувати під час налаштування процесу. Сам факт переходу клієнта на сторінку після оплати не повинен бути єдиним сигналом для зміни статусу замовлення. Результат транзакції система продавця може отримати безпосередньо через serviceUrl.
Якщо WayForPay не отримує коректної відповіді від сервера продавця, повідомлення надсилаються повторно протягом чотирьох діб або до отримання правильної відповіді. Обробка таких запитів має враховувати можливість повтору: одна й та сама транзакція не повинна вдруге запускати комплектацію, відправлення товару чи відкриття доступу до цифрового продукту.
Таким чином, після підтвердження платежу бізнесу потрібен чітко визначений маршрут замовлення: хто або яка система отримує інформацію про оплату, яка дія виконується наступною та де фіксується її результат. Це дозволяє не залишати успішну транзакцію окремим записом у платіжному кабінеті без подальшого виконання.
Читайте також: Регулярні платежі: як налаштувати стабільний дохід для бізнесу з платіжними інструментами WayForPay
Операції поза стандартним сценарієм потребують окремого контролю
Навіть за налагодженого обліку частина операцій потребуватиме ручної перевірки. Це може бути транзакція, яка тривалий час залишається в обробці, повернення без фінального статусу, платіж, який не вдалося зіставити із замовленням, або продаж, де один із передбачених етапів не завершився.
Такі випадки доцільно відокремлювати від основного потоку завершених операцій. Для кожного з них у реєстрі варто фіксувати причину перевірки, поточний статус, наступну дію та строк, коли до операції потрібно повернутися. Наприклад, для платежу в обробці це може бути повторна перевірка статусу, а для транзакції без знайденого замовлення — звірка номера, суми та даних покупця.
Операція має залишатися в такому переліку, доки не буде зрозуміло, чим вона завершилася:
- платіж підтверджено або відхилено;
- повернення проведено;
- помилку передано на виправлення тощо.
Після цього запис можна повернути до загального потоку із зафіксованим результатом.
Такий підхід дозволяє працювати з винятками окремо, не переглядаючи щоразу весь масив транзакцій. Наступним рівнем контролю стає регулярна звірка замовлень, платежів, фіскальних документів і фактичних надходжень коштів.
Три рівні звірки: замовлення, чеки та виплати
Операційна звірка
На цьому рівні внутрішній реєстр замовлень зіставляють із даними платіжного сервісу. Мета — знайти розбіжності між двома джерелами: успішний платіж без відповідного замовлення, замовлення з позначкою про оплату без підтвердженої транзакції або різницю в сумі.
У WayForPay для такої перевірки можна сформувати звіт за потрібний період, статус, магазин і тип транзакції. До нього за замовчуванням входять номер замовлення, час запиту та платежу, статус операції, сума, комісія, дані клієнта, товари й спосіб оплати. Звіт можна завантажити у форматі CSV або Excel.
Результатом звірки має бути не повторна ручна перевірка всього масиву продажів, а перелік операцій, де дані не збігаються. Такі записи уже можна передати до окремої черги, про яку йшлося вище, та з’ясувати причину розбіжності.
Читайте популярне: Як читати договір з надавачем платіжних послуг: на що звертати увагу бізнесу
Фіскальна звірка
Окремо перевіряють операції, для яких має бути сформований фіскальний документ. Тут потрібно зіставити оплату з відповідним чеком, перевірити суму, а за наявності товарних позицій — їх коректність. Під час повернення також потрібно переконатися, що відповідна операція відображена у фіскальному обліку.
У Державній податковій службі нагадують, що під час інтернет-продажів розрахунки готівкою, платіжною карткою та в інших передбачених законом випадках потребують застосування РРО або ПРРО. Водночас законодавство містить винятки для окремих способів переказу коштів, тому порядок фіскалізації потрібно визначати з урахуванням конкретної моделі розрахунків.
Зауважимо, що через ПРРО WayForPay за останні дев’ять років було сформовано 12 387 868 чеків на загальну суму 17,23 млрд грн. В особистому кабінеті на платформі можна переглядати фіскалізовані операції та завантажувати відповідні чеки. Під час повного або часткового повернення через сервіс чек повернення також створюється автоматично.
Фінансова звірка
Останній рівень — перевірка фактичного руху коштів. Успішна транзакція підтверджує оплату покупцем, але зарахування грошей на розрахунковий рахунок бізнесу відбувається окремо.
Під час такої звірки дані про проведені платежі, комісії та повернення порівнюють із сумами, які бізнес очікує отримати, а потім — із фактичними зарахуваннями за банківською випискою. Якщо суми не збігаються, потрібно визначити, які операції сформували різницю.
За правилами WayForPay, виплата коштів, що надійшли від клієнтів, відбувається наступного банківського дня на реквізити, зазначені в налаштуваннях магазину. У вихідні та святкові дні такі виплати не проводяться.
Так три звірки закривають різні етапи одного продажу: операційна допомагає знайти розбіжності між замовленням і платежем, фіскальна — між розрахунковою операцією та чеком, фінансова — між проведеними платежами та коштами, які фактично надійшли бізнесу.
Як перевірити власний процес
Швидкий аудит можна почати з кількох практичних запитань:
- Чи зможе працівник за номером замовлення швидко знайти пов’язаний платіж, його статус і подальші зміни.
- Чи є в бізнесу окремий перелік операцій, які потребують перевірки або ручного втручання.
- Чи зрозуміло команді, який саме сигнал підтверджує успішну оплату та запускає подальшу роботу із замовленням.
- Чи можна за обраний період зіставити замовлення з платежами, фіскальними документами та фактичними надходженнями на рахунок.
- Чи є визначений порядок дій, якщо дані між цими джерелами не збігаються.
Якщо на одне з цих запитань немає чіткої відповіді, саме цю ділянку процесу варто перевірити першою.
Ознайомтеся з іншими популярними матеріалами:
Чому клієнти кидають покупки на етапі оплати