Webpay інтеграція: де ламається оплата в мобільному застосунку
Оплата в мобільному застосунку ламається не на етапі списання, а на стику між застосунком, платіжною формою та бекендом. Класичний сценарій: користувач оплатив, повернувся з платіжної форми — а замовлення в застосунку все ще «очікує оплати».
Причина в тому, що повернення з форми та підтвердження платежу від шлюзу надходять різними шляхами й у різний час, і застосунок дізнається про успіх раніше, ніж бекенд отримав підтвердження. Якщо цей момент не оброблено, виникає розсинхронізація статусів замовлення та платежу.
Другий частий клас збоїв — завислі транзакції. Користувач закрив форму, втратив мережу, згорнув застосунок — і платіж залишився в проміжному стані без фінального статусу.
Без періодичної звірки зі шлюзом такі операції накопичуються, підтримка отримує звернення «гроші списалися, замовлення не створено», а бухгалтерія — розбіжності. Окремий біль — повторні спроби: користувач натискає «оплатити» ще раз, і з'являється дубль.
Третій шар — саме повернення з платіжної форми. На частині пристроїв і версій системи застосунок вивантажується з пам'яті під час оплати, і повернення приводить не на той екран, а на головну. Користувач вважає, що оплата не пройшла, і йде — хоча платіж успішний.
Усі три збої лікуються на рівні архітектури: ідемпотентні ключі на платежі, підтвердження статусу тільки від шлюзу, а не від застосунку, фонова звірка завислих операцій і коректна обробка повернення. Нижче розбираємо, як це закривається в Webpay інтеграції — від схеми статусів до обробки обривів.
Що змінюється після коректної інтеграції платіжного шлюзу
Коректна інтеграція платіжного шлюзу змінює не «красу» екрана оплати, а поведінку всієї воронки.
Частка успішних оплат зростає завдяки тому, що застосунок коректно обробляє повернення користувача з банківського вікна, повторює запит статусу замість сліпої довіри відповіді та не втрачає платіж при обриві зв'язку на середині сценарію.
Підтвердження замовлення надходить від шлюзу, а не від клієнта, тому замовлення не «зависає» в невизначеному стані.
Окремо зникає клас відмов, який зазвичай списують на «примхливих користувачів»: подвійні списання при повторному натисканні кнопки, платежі без підтвердження при закритті вікна, втрачені повідомлення при перемиканні між застосунком і банком.
Кожен такий випадок — це не лише повернення коштів, а й звернення до підтримки, ручне звіряння та втрачена довіра. Коли стан платежу визначається за статусом зі шлюзу, а не за фактом натискання кнопки, ці відмови просто перестають виникати.
Конверсія оплати — це наслідок передбачуваності. Користувач бачить зрозумілий результат: оплата пройшла — замовлення підтверджено, оплата не пройшла — можна повторити без ризику заплатити двічі. Чим менше невизначеності на цьому кроці, тим вища частка тих, хто доходить до кінця.
Ми розбираємо сценарій оплати повністю — від вибору способу до підтвердження замовлення — і закриваємо саме ті місця, де втрачаються успішні оплати. Опишіть задачу, і ми повернемося з оцінкою та планом робіт.
Способи підключення: платіжна форма, SDK, прямий виклик
Є три принципово різні шляхи: готова платіжна форма, мобільний SDK і прямий виклик платіжного інтерфейсу. Вибір визначається тим, наскільки глибоко оплата вбудована в сценарій застосунку і хто відповідає за інтерфейс — платіжний провайдер чи ваша команда.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Платіжна форма | Швидкий запуск, стандартна оплата товару або підписки | Інтерфейс і логіку веде провайдер, кастомізація мінімальна |
| Мобільний SDK | Оплата всередині застосунку, потрібен нативний екран і збережені картки | Потребує оновлення застосунку при змінах на стороні провайдера |
| Прямий виклик | Свій інтерфейс оплати, нестандартні сценарії, маркетплейс | Уся логіка статусів, повторів і помилок — на вашій стороні |
Платіжна форма
Це найбільш передбачуваний варіант: застосунок відкриває готовий екран оплати, а весь розбір статусів, повторів і помилок бере на себе провайдер.
Підходить, коли оплата — окремий крок, а не частина складного сценарію, і коли важливіше запуститися швидко, ніж керувати кожною деталлю інтерфейсу. Обмеження одне: ви приймаєте чужу логіку екрана як є.
Мобільний SDK
SDK дає нативний інтерфейс оплати всередині застосунку і доступ до збережених карток — конверсія на повторних покупках помітно вища, ніж при переході на зовнішню форму.
Ціна — прив'язка до версії SDK: при змінах на стороні провайдера оновлювати застосунок доводиться вам, а не йому. Для регулярних платежів і підписок це зазвичай виправдано.
Прямий виклик
Прямий виклик платіжного інтерфейсу дає повний контроль над екраном оплати і дозволяє вбудувати його в будь-який нестандартний сценарій — часткова оплата, спліт між отримувачами, власна логіка повторів.
Натомість ваша команда відповідає за обробку статусів, ідемпотентність запитів і розбір відмов. Такий шлях обирають, коли готові варіанти не покривають бізнес-логіку.
На практиці варіанти часто комбінують: форма — для разових покупок, SDK — для підписок, прямий виклик — для окремих сценаріїв. Опишіть, як влаштована оплата у вашому застосунку, — повернемося з оцінкою та планом по кожному шляху.
Етапи впровадження: від аудиту поточної оплати до передачі
Впровадження платіжного шлюзу — це не «підключити кнопку оплати», а вибудувати ланцюжок від кошика до підтвердження замовлення так, щоб жоден сценарій не втрачав гроші й не залишав клієнта із завислою оплатою.
Працюємо за фіксованою послідовністю: кожен етап закінчується артефактом, який можна перевірити, а не обіцянкою «все готово».
- Аудит поточної оплати. Розбираємо, як гроші ходять зараз: які способи оплати увімкнені, де створюється транзакція, хто і коли отримує підтвердження від банку, як обробляються відмови та повернення. На виході — карта поточних сценаріїв із вузькими місцями: дублі замовлень, втрачені оплати при обриві зв'язку, ручні звірки.
- Схема інтеграції. Проєктуємо потік платежу: момент створення транзакції, редірект або вбудовану форму, точки повернення в застосунок, обробку асинхронних повідомлень від шлюзу. Фіксуємо, що відбувається при закритті застосунку на середині оплати і як замовлення звіряється з реальним статусом транзакції.
- Налаштування та підключення. Налаштовуємо середовища, ключі та підписи, пов'язуємо застосунок зі шлюзом, проводимо тестові платежі в пісочниці. Окремо перевіряємо повернення та повторні спроби — саме тут найчастіше розходяться суми й статуси.
- Перевірка сценаріїв. Проганяємо повний набір: успішна оплата, відмова банку, недостатньо коштів, таймаут, повторна оплата того самого замовлення, повернення. Кожен сценарій — з очікуваною поведінкою інтерфейсу та записом у системі, щоб підтримка бачила історію, а не гадала.
- Документація. Описуємо схему потоку, список статусів транзакцій, порядок розбору інцидентів і точки, куди дивитися при розходженні. Документ залишається у вашої команди — новий розробник входить у тему без переказів.
- Передача рішення. Передаємо налаштовану інтеграцію, доступи та інструкції, разом розбираємо один реальний платіж від початку до кінця. Після передачі ваша команда може змінювати тарифи та способи оплати, не зачіпаючи логіку транзакцій.
Опишіть, як оплата влаштована зараз, — повернемося з оцінкою та планом за цими етапами.
Що замовник отримує на руки: конфігурація, схеми, регламенти
Передаємо не «доступ до кабінету», а робочу систему: конфігурацію шлюзу, схеми руху платежу, правила доступу та регламенти на випадок збою. Нижче — що саме залишається у вашої команди після запуску.
- Конфігурація шлюзу — параметри мерчанта, прив'язка терміналів до сценаріїв оплати, налаштування повторних спроб і таймаутів, розділення тестового та бойового контурів.
- Схеми потоків оплати — як проходить одностадійний і двостадійний платіж, де виконується холдування, у який момент замовлення вважається оплаченим і як обробляється повернення.
- Політики доступу — ролі для розробників, підтримки та фінансів, обмеження прав на повернення та ручні операції, порядок ротації ключів.
- Обробка станів замовлення — таблиця відповідності статусів шлюзу та статусів у вашій системі, включно з проміжними та спірними випадками.
- Регламент розбору збоїв — покроковий порядок дій при неуспішному платежі, завислій транзакції та розбіжності сум, із зазначенням відповідальних і строків реакції.
- Документація для команди — інструкція з підключення нових сценаріїв, чек-ліст приймання платежу та опис типових помилок із причинами.
- Скрипти перевірки — набір тестових сценаріїв, якими ваша команда сама перевіряє оплату після будь-яких змін у застосунку.
Кожен артефакт прив'язаний до конкретної дії: налаштування — щоб змінювати поведінку без правок коду, схеми — щоб новий розробник зрозумів потік за день, регламенти — щоб інцидент розбирався за кроками, а не з пам'яті. Опишіть вашу задачу — повернемося з оцінкою та планом робіт.
Кейс: як скоротили частку неуспішних оплат у застосунку
Клієнт — сервіс доставки із застосунком на iOS та Android — прийшов із конкретним болем: частка неуспішних оплат трималася на рівні 18-20%, а пік відмов припадав на вечірні години, коли навантаження максимальне.
Користувач натискав «Оплатити», отримував таймаут або помилку, гроші не списувалися, замовлення не оформлювалося. Частина клієнтів зверталася до підтримки, частина просто закривала застосунок і більше не поверталася.
Що було до інтеграції
Оплата йшла через один шлюз із синхронним підтвердженням: застосунок чекав на відповідь від платіжного сервісу і лише потім показував статус замовлення. За мережевих просідань запит висів до таймауту, а повторна спроба створювала другий платіж — доводилося розбиратися вручну.
Час підтвердження замовлення сягав 40-60 секунд, звернення до підтримки на тему оплат становили близько третини всіх тікетів.
Що змінили
Наші інженери підключили Webpay як основний платіжний шлюз і перевели підтвердження на асинхронну схему: застосунок одразу показує проміжний статус, а фінальний результат надходить через повідомлення від платіжного сервісу.
Додали ідемпотентність запитів — повторна спроба не створює дубль платежу, а повертає статус вихідної операції. Налаштували автоматичне скасування в разі відмови банку та зрозумілі повідомлення про помилку прямо в інтерфейсі оплати.
Результат інтеграції
Частка неуспішних оплат знизилася з 18-20% до 4-6% протягом першого місяця після запуску. Час підтвердження замовлення скоротився до 3-5 секунд у більшості сценаріїв.
Звернення до підтримки щодо оплат упали майже втричі — основна маса проблем закривається автоматично, без участі оператора. Окремо зазначимо: відмови банків більше не губляться, а коректно обробляються зі зрозумілим статусом для користувача.
Чим відрізняється платіжна форма від прямого виклику шлюзу?
Платіжна форма — це готовий інтерфейс, який шлюз віддає застосунку: екран введення картки, 3-D Secure, обробка відмов і повторних спроб уже реалізовані на боці провайдера.
Застосунок відкриває форму й отримує назад результат операції — статус, ідентифікатор транзакції, причину відмови. Прямий виклик шлюзу — протилежний підхід: наш код сам збирає запит, сам малює екран оплати, сам обробляє відповідь і всі проміжні стани.
Різниця не в тому, «що швидше підключити», а в тому, хто відповідає за поведінку інтерфейсу та обробку збоїв на кожному кроці.
Контроль інтерфейсу — головний вододіл. Форма живе всередині свого контейнера: верстку, тексти, порядок полів і поведінку при помилках задає провайдер, і підлаштувати їх під дизайн застосунку можна лише в межах, які він дозволяє. Прямий виклик віддає нам весь екран: свої поля, свою валідацію, свою логіку підказок і повторів.
Це дорожче в розробці — потрібно акуратно обробити введення картки, термін дії, коди помилок і стани завантаження, — але саме тут з'являється повний контроль над тим, що бачить і відчуває користувач у найвідповідальніший момент.
Стійкість до збоїв у двох підходів влаштована по-різному. Форма бере на себе типові відмови: таймаути, відхилені картки, повторну автентифікацію — застосунок просто реагує на підсумковий статус.
При прямому виклику ці сценарії лягають на нас: потрібно коректно розрізняти «операція не пройшла» і «відповідь не дійшла», не втрачати платіж при обриві зв'язку й не списувати гроші двічі при повторному надсиланні. Тут допомагає ідемпотентність запитів і чітка звірка статусу на боці сервера, а не лише на клієнті.
Практичний вибір зазвичай такий: форма — коли важливіше швидко вивести оплату в продакшн і не витрачати ресурс на рідкісні сценарії; прямий виклик — коли оплата вбудована в ключовий сценарій продукту й інтерфейс має бути своїм.
Часто беруть гібрид: форма для базового потоку, прямий виклик — для повторних платежів і підписок, де важливі свої екрани та своя логіка повторів. Ми розбираємо сценарії оплати в застосунку й пропонуємо варіант під задачу, а не за замовчуванням.
Технічні сумніви перед підключенням інтеграції Webpay
Перед стартом інтеграції в технічної команди зазвичай накопичується список питань, які потрібно зняти до першого рядка коду: як зберігаються ключі, що відбувається з платежем при втраті мережі, хто відповідає за повернення. Нижче — розбір типових сумнівів, з якими приходять замовники.
Де зберігати ключі та секрети платіжного шлюзу?
Секретні ключі та токени не потрапляють ні в мобільний клієнт, ні в репозиторій. Підпис запиту робиться на серверній стороні, застосунок спілкується лише зі своїм бекендом.
На стороні сервера ключі лежать у захищеному сховищі та підставляються в рантаймі — так витік збірки застосунку не дає доступу до приймання платежів.
Що буде, якщо у клієнта обірветься зв'язок під час оплати?
Платіж ініціюється на сервері, а застосунок лише відстежує його статус. При обриві зв'язку клієнт повертається до екрана очікування, а стан операції підтягується з бекенду при наступному запиті. Клієнт не платить двічі: повторна спроба ідемпотентна за ідентифікатором замовлення.
Як влаштовані повторні спроби при невдалому списанні?
Повтори виконуються з обмеженням за кількістю та з наростаючою паузою, щоб не забивати шлюз при масових збоях. Кожна спроба логується із причиною відмови, а фінальний статус фіксується в замовленні. Клієнт бачить зрозумілий результат, а не завислий екран.
Як працюють повернення та скасування?
Повернення ініціюється на сервері за ідентифікатором вихідного платежу та проходить як окрема операція зі своїм статусом. Часткове повернення можливе, якщо це підтримує тарифний план мерчанта. Усі рухи за замовленням залишаються в журналі — при розборі видно, де саме зупинилася операція.
Чи потрібно переписувати застосунок під інтеграцію?
Ні. Платіжний сценарій виноситься в окремий модуль, решта коду не зачіпається. Це дозволяє оновлювати логіку оплати незалежно від релізів застосунку та відкочувати її без перезбірки.
Опишіть ваш сценарій оплати — повернемося з оцінкою та планом інтеграції.
Обговоримо ваше завдання і повернемося з планом
Щоб повернутися з точною оцінкою, а не з діапазоном «від і до», нам потрібно зрозуміти вашу поточну схему оплати: який провайдер використовується зараз, де саме в застосунку відбувається списання, як обробляються повернення та повторні спроби.
Від цього залежить обсяг робіт — іноді достатньо підключити платіжний модуль до наявного еквайрингу, іноді потрібно переробити весь сценарій оформлення замовлення.
Опишіть завдання у вільній формі — цього достатньо, щоб ми склали картину і підготували план інтеграції з етапами, термінами та зонами відповідальності.
Якщо зараз оплата йде через веб-форму або сторонній сервіс, так і напишіть: ми оцінимо, що переноситься як є, а що доведеться перезібрати під мобільний сценарій.
Що ви отримаєте після розбору завдання:
- оцінку робіт з інтеграції Webpay — окремо за кожним етапом, без прихованих пунктів;
- план інтеграції: підготовка, підключення, тестовий контур, виведення в продакшн;
- розбір поточної схеми оплати та точок, де вона втрачає конверсію;
- перелік доопрацювань на стороні застосунку та на стороні сервісу;
- схему обробки повернень, скасувань і повторних списань;
- умови підтримки після запуску: що входить, як передаються звернення, час реакції;
- ризики за термінами та способи їх зняти до старту робіт.
Ми не беремо завдання «на подивитися» і не обіцяємо зробити його в межах однієї розмови. Натомість розбираємо вашу схему, ставимо уточнювальні питання щодо спірних місць і повертаємося з оцінкою та планом — далі ви вирішуєте, стартуємо чи ні.
Напишіть, як у вас влаштована оплата сьогодні і що хочете отримати в результаті. Цього достатньо, щоб ми повернулися з конкретикою.
