Інтеграція WayForPay зводить три речі: форму оплати в чекауті, серверний зворотний виклик із підписом і статуси замовлення, за якими працює ваша бухгалтерія. Підключаємо картку, Apple Pay і Google Pay, за потреби — оплату частинами окремим способом розрахунку. Далі те, що ламається найчастіше: повторна перевірка статусу, коли виклик не дійшов, повернення з адмінки й подія покупки в аналітиці. WayForPay стоїть на 7 із 33 сайтів, які ми поміряли 31 липня 2026 року, — з цим шлюзом ми маємо справу регулярно.
Замовлення приймаєте на сайті, а гроші — переказом на картку
Менеджер диктує номер у месенджері, покупець надсилає скрин, хтось звіряє це руками. Онлайн-оплата прибирає з ланцюжка людину: гроші йдуть на рахунок компанії, замовлення саме змінює статус, а звірка робиться вивантаженням із кабінету, а не гортанням переписки.
Розберемо вашу ситуацію на безкоштовному аудиті
Сценарій 2 із 4
Опт іде за рахунком, але дрібний клієнт хоче заплатити карткою
Один чекаут тримає обидва сценарії. У виміряному нами оптовому магазині будматеріалів на 3 145 товарів поруч стоять WayForPay, безготівковий розрахунок і готівка: компанія платить за рахунком, роздрібний покупець — карткою, окремого сайту для цього не треба.
Сценарій 3 із 4
Середній чек високий, покупець думає тижнями
Тут має сенс оплата частинами. Ціну вона не змінює, але розбиває її на кілька платежів, а продавець отримує суму повністю. Працює лише на дорогих позиціях: на дешевих комісія з'їдає маржу, і способом майже не користуються.
Сценарій 4 із 4
Шлюз уже стоїть, але замовлення зависають
Гроші списані, у кабінеті провайдера платіж успішний, а в адмінці замовлення досі «очікує оплати». Причина майже завжди одна: зворотний виклик не дійшов або дійшов, а модуль не перепитав шлюз про статус. Це лагодиться без переустановлення магазину.
Кейси
Задачі та результат у цифрах — усі показники зняті нашим виміром
оптовий магазин косметики для б'юті-індустрії, каталог майже 4 тис. позицій
Задача
Дати оптовому покупцеві заплатити карткою онлайн і лишити альтернативні способи розрахунку тим, хто працює за рахунком.
Рішення
Магазин на OpenCart: WayForPay і три альтернативні способи розрахунку, дві служби доставки, повна розмітка магазину, дві мовні версії.
Результат
Вимір 31.07.2026, два послідовні заміри з однаковим результатом: 3 947 товарів, 166 брендів і 47 категорій — 4 167 адрес у канонічній карті сайту. Шість типів JSON-LD на головній, перша відповідь сервера 576,8 мс при 192,4 КБ HTML. Знайдений дефект: паралельно живе стара карта сайту — 7 782 записи на 2 755 унікальних адрес, тобто одночасно дубльована й неповна.
оптовий магазин будівельних матеріалів
Задача
Приймати онлайн-оплату від дрібного опту, лишивши безготівковий розрахунок для компаній, і бачити в аналітиці, що саме купують.
Рішення
Магазин на OpenCart: WayForPay, безготівковий розрахунок і готівка; доставка Новою Поштою й самовивіз. Підключені GTM, GA4 і ремаркетинг Google Ads із подіями перегляду списку товарів.
Результат
Вимір 31.07.2026: каталог 3 145 товарів — рахували посторінково через штатний пошук за унікальними ідентифікаторами в payload події перегляду списку, 31 сторінка по 100 позицій плюс 45. Перша відповідь сервера 547,3 мс, повне завантаження 685,6 мс при 212,1 КБ HTML. Аналітика й ремаркетинг тут справді працюють — у виміряній вибірці радше виняток. Знайдений дефект: /sitemap.xml віддає 200 з порожнім тілом.
оптовий постачальник медичних витратних матеріалів
Задача
Приймати оплату онлайн у B2B-каталозі, де замовлення часто узгоджують у месенджері.
Рішення
Магазин на OpenCart: WayForPay і оплата карткою, доставка Новою Поштою, зв'язок через Viber, Telegram і WhatsApp, лічильник Google Ads.
Результат
Вимір 31.07.2026: карта сайту індексом із п'яти файлів — 1 602 товари, 32 категорії, 17 виробників, 4 інфосторінки й головна, разом 1 656 адрес. Перша відповідь сервера 364,7 мс при 401,6 КБ HTML. Знайдений дефект: структурованої розмітки на головній немає взагалі, мовна версія одна, hreflang відсутній.
Що входить
Повний перелік робіт і того, що ви отримуєте на виході
Оплата карткою в чекауті — Visa, Mastercard, Apple Pay і Google Pay: покупець платить у два дотики, а дані картки лишаються на боці провайдера
Оплата частинами окремим способом розрахунку — вмикаємо, якщо ваш середній чек цього вартий
Зворотний виклик із перевіркою підпису й повторною спробою: замовлення змінює статус навіть тоді, коли перший виклик загубився в мережі
Запит статусу платежу за номером замовлення — страховка на випадок, коли виклик не дійшов узагалі
Відповідність платіжних статусів і статусів замовлення, узгоджена з вашим бухгалтером: «оплачено» на сайті означає те саме, що в звірці
Сторінки успішної й невдалої оплати зі збереженим кошиком — після відмови банку покупець повторює платіж, а не збирає замовлення заново
Повне й часткове повернення з адмінки, з відміткою в самому замовленні
Подія покупки з сумою й складом замовлення в аналітику й рекламні кабінети
Перевірка на живому платежі з поверненням тієї ж суми — приймання не на тестовому режимі
Письмова інструкція менеджеру: що робити з платежем у стані очікування і хто ухвалює рішення про повернення
Гарантія 30 календарних днів на виконані роботи
Коли ця послуга не підходить
Що не входить у роботу — щоб не було сюрпризів на здачі
Договір із платіжним провайдером і проходження перевірки
Комісії еквайрингу й тарифні умови
Фіскалізація платежів — окрема задача
Бухгалтерська звірка й вивантаження в облікову систему
Юридичні тексти про повернення й оферту
Етапи роботи
Прозорі етапи з погодженням на кожному кроці
Загальний строк:3–10 днів
01
Сценарії розрахунку й доступи
0,5–2 робочих дні
Фіксуємо, які способи оплати лишаються в чекауті і що з них означає «оплачено». Забираємо ключ продавця й секретний ключ — їх видають вам, не підряднику.
02
Шлюз і форма оплати
0,5–2 робочих дні
Підключення в тестовому режимі: картка, Apple Pay, Google Pay, за потреби — оплата частинами окремим способом. Тут же дивимось, як сторінка оплати поводиться з мобільного.
03
Зворотний виклик і сценарії помилок
1–3 робочих дні
Перевірка підпису, відповідь у форматі провайдера, повторна спроба, запит статусу платежу за номером замовлення, окрема поведінка для відмови банку й для платежу в очікуванні. Найдовший етап і той, заради якого все й робиться.
04
Статуси, повернення, подія покупки
0,5–2 робочих дні
Зіставлення станів платежу зі статусами замовлення, повне й часткове повернення з адмінки, передача покупки з сумою в GA4 і рекламні кабінети.
05
Живий платіж і передача
0,5–1 робочий день
Оплачуємо реальне замовлення на невелику суму, дивимось статус в адмінці й кабінеті, повертаємо гроші тим самим шляхом. Далі — інструкція менеджеру й доступи.
Безкоштовна перевірка платіжного сценарію
Перед підключенням шлюзу проходимо ваш чекаут як покупець і дивимось, що там уже є. Половина знахідок стосується не платежів, а статусів замовлень — і саме вони потім створюють плутанину в бухгалтерії.
Що ми міряємо
Реальний перелік способів розрахунку в чекаутіПорівнюємо з тим, що написано на сторінці оплати. У виміряних магазинах ми бачили і повний збіг, і випадки, коли сторінка обіцяла більше, ніж чекаут пропонував.
Статуси замовленьЯкі статуси існують і який із них означає «оплачено». Без чіткої відповідності платіж і замовлення живуть окремими життями.
Обробка зворотних викликівЧи перевіряється підпис відповіді шлюзу, що відбувається, якщо виклик не дійшов з першого разу, і чи відповідає ваш сайт так, як цього чекає провайдер.
Повторна спроба оплатиЧи може покупець заплатити за те саме замовлення вдруге після відмови банку. Дуже часто — ні, і сайт віддає помилку без пояснення.
Оплата частинамиЧи потрібен вам цей сценарій. Це окремий спосіб у чекауті з власними умовами, а не варіант звичайної картки.
Що йде в аналітикуЧи передається подія покупки з сумою. У виміряному магазині будматеріалів ремаркетинг налаштований із подіями перегляду списку товарів — це рівень, до якого варто прагнути.
Що ви отримуєте
Звіт із реального чекауту з переліком доступних способів розрахунку.
Схему відповідності платіжних статусів і статусів замовлення.
Оцінку робіт зі строком, з поділом на обов'язкове й бажане.
Розмову на 20–30 хвилин із вами й вашим бухгалтером.
Строк: 1–2 робочих дні
Чому це безкоштовно
Бо перевірка займає години, а неузгоджені статуси замовлень потім коштують днів роботи бухгалтера щомісяця.
Що далі
Після перевірки даємо кошторис на конкретний перелік робіт і строк.
Коротка форма: контакт і адреса сайту
Працюємо офіційно
Договір, акт і рахунок — на кожен проєкт, а не тільки на великий. Без документів у вас немає ні прав на роботу, ні підстави провести витрати.
На кожен проєкт письмовий договір: обсяг, строки, сума, порядок приймання. Після здачі — акт і рахунок, а далі 30 календарних днів гарантії: помилки з нашої вини усуваємо безоплатно. Усне з дзвінка дублюємо письмово того ж дня.
02
ФОП і безготівковий розрахунок
Виконавець — зареєстрований ФОП. Оплата на рахунок із закривними документами.
03
Права й доступи — ваші
Код, дизайн і матеріали переходять до вас після повної оплати. Домен, хостинг, репозиторій, аналітику оформлюємо на вас.
04
Портал клієнта замість переписки
На час роботи ви отримуєте доступ до порталу: договори, рахунки, акти й стан проєкту в одному місці.
05
Сайти в дев'яти країнах
Наші сайти працюють у дев'яти країнах: крім України — Польща, Німеччина, Австрія, Англія, Норвегія, Болгарія, Молдова, Іспанія.
06
Цифри, які можна перевірити
Кожен кейс у портфоліо — з посиланням на живий сайт і технічним виміром.
07
Спершу аудит, потім сума
Прайсу на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази.
08
Кажемо «ні», коли не впевнені
Якщо задача не наша або строк нереальний — скажемо одразу.
01
Договір, акт і гарантія 30 днів
На кожен проєкт письмовий договір: обсяг, строки, сума, порядок приймання. Після здачі — акт і рахунок, а далі 30 календарних днів гарантії: помилки з нашої вини усуваємо безоплатно. Усне з дзвінка дублюємо письмово того ж дня.
02
ФОП і безготівковий розрахунок
Виконавець — зареєстрований ФОП. Оплата на рахунок із закривними документами.
03
Права й доступи — ваші
Код, дизайн і матеріали переходять до вас після повної оплати. Домен, хостинг, репозиторій, аналітику оформлюємо на вас.
04
Портал клієнта замість переписки
На час роботи ви отримуєте доступ до порталу: договори, рахунки, акти й стан проєкту в одному місці.
05
Сайти в дев'яти країнах
Наші сайти працюють у дев'яти країнах: крім України — Польща, Німеччина, Австрія, Англія, Норвегія, Болгарія, Молдова, Іспанія.
06
Цифри, які можна перевірити
Кожен кейс у портфоліо — з посиланням на живий сайт і технічним виміром.
07
Спершу аудит, потім сума
Прайсу на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази.
08
Кажемо «ні», коли не впевнені
Якщо задача не наша або строк нереальний — скажемо одразу.
NDA підписуємо на запит. Після завершення співпраці наші доступи до ваших сервісів видаляємо самі.
Не знайшли свій випадок?
Опишіть, як це влаштовано у вас, — відповімо, чи підходить «Інтеграція WayForPay» і що це означає у вашій ситуації. Без брифу й без дзвінка: одне питання, одна відповідь.
Що впливає на вартість
Чому дві однакові на вигляд задачі рахуються по-різному
Скільки платіжних сценаріїв вмикаємоОдна картка — це форма, зворотний виклик і статус. Плюс оплата частинами — це вже другий сценарій зі своїми станами й своєю поведінкою при поверненні, а не галочка в налаштуваннях.
Стан статусів замовленняКоли статуси заведені й бухгалтер знає, який означає оплату, робота йде по верху. Коли статусів три і всі звуться «в обробці», спершу доводиться будувати схему — це найдовший пункт кошторису.
Платформа й стан чекаутуНа типовій OpenCart чи WooCommerce модуль стає в межах дня. Самописний чекаут — це серверний маршрут, який пишеться руками: підпис, захист від повторної обробки того самого виклику, повтори.
Повернення й звіркаПовернення треба не лише під'єднати, а й вирішити, хто його робить і як воно потрапляє в облік. Без цієї домовленості плутанина повертається через місяць.
Стан аналітикиЯкщо GTM і GA4 уже стоять, подія покупки — це година роботи. Якщо лічильників немає взагалі, спершу ставимо вимірювання: у нашій виборі сайтів були й такі, де не знайшлося жодного лічильника.
Технології та інтеграції
На чому будуємо і з чим це з'єднується
Стек
WayForPay API — картка, Apple Pay, Google Pay і оплата частинами з одного кабінету. Межа: розрахунки в гривні.
Підпис HMAC-MD5 на запиті й відповіді. Формат задає провайдер; захист тримається на секретності ключа, тому в клієнтський код він не потрапляє.
Серверна адреса для результату платежу. Межа: без відповіді у форматі провайдера виклик вважається недоставленим і повторюється.
OpenCart 3 і 4 — готовий модуль ставиться за день. Межа: коробкова версія зазвичай не перепитує статус і не знає ваших назв статусів.
WooCommerce — плагін плюс правки хуків під ваші статуси замовлення.
Next.js — маршрут API на рантаймі Node. Межа: на edge підпис не порахувати.
HTTPS і HSTS — умова роботи шлюзу, а не побажання.
Інтеграції
WayForPay
Visa / Mastercard
Apple Pay / Google Pay
оплата частинами
безготівковий розрахунок
GA4 — подія покупки
Google Ads — ремаркетинг
Google Tag Manager
Коробковий модуль своїми силами проти інтеграції з розбором сценаріїв
Чим цей варіант відрізняється від альтернативи
Модуль «поставили і працює»Наш підхід
Підпис зворотного викликучасто приймається будь-який запит на адресу — статус замовлення можна підробити ззовніперевіряємо на кожному виклику, непідписані відхиляємо
Виклик не дійшовзамовлення лишається неоплаченим, розбирає менеджер рукамиповторна спроба плюс запит статусу платежу за номером замовлення
Статуси замовленняназви за замовчуванням, звірка робиться очимазіставлені з вашими назвами й погоджені з бухгалтером
Повторна оплата того самого замовленняшлюз відхиляє повтор, покупець вирішує, що зламався сайтновий ідентифікатор платежу, попередня спроба лишається в історії
Повернення коштівруками в кабінеті провайдера, в адмінці слідів немаєповне й часткове з адмінки, з відміткою в замовленні
Подія покупкилічильник рахує візити, гроші — нісума й склад замовлення йдуть у GA4 і рекламний кабінет
Що потрібно від вас
Без цього не почнемо — краще підготувати заздалегідь
1Ключ продавця й секретний ключ із вашого кабінету платіжного провайдера.
2Доступи до сайту й адмінки з правами на встановлення модулів.
3Перелік статусів замовлення й рішення, який із них означає оплату.
4Юридичні тексти про повернення коштів — вони мають бути на сайті до запуску.
5Тестове замовлення на невелику суму.
6Бухгалтера або менеджера, який відповідає за звірку платежів.
Якщо чогось із цього немає — скажіть, підкажемо, як зібрати або зробимо самі окремою задачею.
Часті питання
Те, що питають найчастіше — з конкретними відповідями
У мене вже стоїть модуль — навіщо щось переробляти?
Часто нема чого, і ми так і кажемо. Перевірити варто три речі: чи відхиляє ваш сайт зворотний виклик без правильного підпису, чи перепитує він шлюз про статус, коли виклик не дійшов, і чи означає «оплачено» в адмінці те саме, що в кабінеті провайдера. Якщо на всі три «так» — робити нічого не треба, і це буде написано у звіті після безкоштовної перевірки.
Покупець заплатив, а замовлення висить неоплаченим — що це?
Загублений зворотний виклик. Шлюз надсилає результат платежу на вашу серверну адресу і чекає у відповідь власний JSON: номер замовлення, слово accept, час і підпис. Немає такої відповіді — виклик вважається недоставленим, шлюз повторює його, а якщо ваш модуль мовчить весь час, гроші лишаються списаними, а замовлення неоплаченим. Робочий сценарій інший: модуль сам запитує статус платежу за номером замовлення перед тим, як лишити його в підвішеному стані. Окрема рекомендація з практики: статус не змінюється на сторінці, куди повертається покупець після оплати. Він може її закрити, перезавантажити або не дійти взагалі — єдине надійне джерело правди тут серверний виклик.
Покупець хоче оплатити те саме замовлення вдруге — чому не виходить?
Бо ідентифікатор платежу має бути унікальним. Перша спроба вже зайняла номер вашого замовлення, і повторний запит із тим самим номером шлюз відхиляє — покупець бачить помилку і йде. Лікується просто: на кожну нову спробу генерується власний ідентифікатор із суфіксом, а зв'язок із замовленням тримається окремим полем. Десять рядків коду і найчастіша причина «сайт не дає заплатити» з тих, що ми розбирали.
Чи варто вмикати оплату частинами?
Дивіться на середній чек. На дорогих позиціях спосіб знімає бар'єр разової суми: покупець платить кількома платежами, ви отримуєте гроші повністю, ризик несплати бере банк. На дешевих товарах ним майже не користуються, а комісія з'їдає маржу з кожного замовлення. Для закупівель за рахунком він не працює взагалі. І чесна межа: оплата частинами не збільшує кількість людей, які хочуть ваш товар — вона допомагає тим, хто вже хоче, але не готовий заплатити всю суму зараз.
Чи можна оформити повернення з адмінки?
Так, повне або часткове. Технічна частина проста, складніше домовитись про процедуру: хто ухвалює рішення, у який строк і що бачить покупець. Плутанина зазвичай організаційна — повернення роблять то з кабінету провайдера, то з адмінки, і через місяць звірка не сходиться. Тому на передачі ми пишемо коротку інструкцію менеджеру й фіксуємо один шлях.
Як пов'язати платежі з аналітикою?
Подією покупки з сумою й складом замовлення, яка надсилається після підтвердження платежу, а не на сторінці «дякуємо». У виміряному нами оптовому магазині будматеріалів на 3 145 товарів працює зв'язка GTM, GA4 і ремаркетинг Google Ads із подіями перегляду списку товарів — рівень, до якого варто прагнути. Чесна межа: сам лічильник не покращує нічого, а блокувальники й режим згоди роблять GA4 джерелом тенденції, а не бухгалтерською істиною. Зводити його з касою треба свідомо.
Скільки часу займає підключення?
3–10 робочих днів. Сценарії й доступи — від половини дня до двох, шлюз і форма оплати стільки ж, зворотний виклик і сценарії помилок 1–3 дні, статуси з поверненнями й подія покупки — до двох днів, живий платіж і передача — до дня. Нижня межа означає готовий чекаут, де статуси вже заведені. Верхня — коли схему статусів доводиться будувати з нуля або в чекауті одночасно живуть кілька способів розрахунку.
Чи безпечно тримати ключі на сайті?
Секретний ключ живе тільки на сервері й у клієнтський код не потрапляє — інакше підпис зможе згенерувати будь-хто. Дані картки на ваш сайт не приходять узагалі: їх приймає сторона провайдера, тому вимоги до зберігання карткових даних на вас не лягають. Що дійсно у вашій зоні: HTTPS без винятків, окремий ключ для тестів і зміна ключа, якщо доступ до адмінки мав підрядник, з яким ви розійшлися.
Чи можна приймати оплату WayForPay у Telegram-боті?
Можна, і окремий платіжний модуль Telegram для цього не потрібен. Бот створює рахунок запитом CREATE_INVOICE, WayForPay у відповідь віддає посилання invoiceUrl на свою сторінку оплати, і бот надсилає його покупцю в чат. Результат приходить на серверну адресу serviceUrl, і обробляти його треба так само, як виклик із сайту: перевірити підпис і відповісти accept, інакше виклик повторюватиметься. У нашому LEO Chat оплата зараз працює на ключах monobank і LiqPay, WayForPay серед них немає — такий сценарій підключаємо окремою роботою, а чи дозволяє ваш кабінет виставлення рахунків, перевіряємо на розборі.
Прайса на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази, і цифра «від» у такому разі нічого не пояснює. Спершу безкоштовний аудит — рахуємо ваші сторінки, дублі й швидкість, — потім називаємо суму й строк і фіксуємо їх у договорі.