Як ми зробили додаток, що рятує конверсію оплат по IBAN

Привіт, DOU! Мене звати Андрій. Я хочу поділитися нашим досвідом розв’язання однієї з найболючіших проблем українського e-commerce та фрілансу — оплати на рахунки ФОП за довжелезними реквізитами.

Ми зіткнулися з тим, що клієнти банально відвалювалися на етапі чекауту, коли бачили необхідність вручну копіювати 29 символів IBAN, ЄДРПОУ та безпомилково вводити призначення платежу. З іншого боку, підключення класичного інтернет-еквайрингу (Apple Pay / Google Pay) забирає 1.5-2% маржі на комісіях, що для багатьох бізнесів є критичним.

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

Технічна задача: обійти еквайринг, але зберегти UX «одного кліка»

Наша головна мета полягала в тому, щоб змусити банківські додатки (Приват24, Monobank тощо) самостійно парсити та підставляти всі дані для платежу. Ми дослідили формат стандартизованих платіжних QR-кодів, який підтримується українськими банками. Суть полягає у формуванні правильного payload’у, який містить зашиті параметри:

— IBAN отримувача;
— ЄДРПОУ;
— Сума;
— Точне Призначення платежу.

Замість того, щоб змушувати ФОПа кожного разу вручну формувати такий код або використовувати не завжди зручні банківські інтерфейси, ми вирішили автоматизувати цей процес.

Архітектура рішення: як працює Foppy під капотом

Ми побудували платформу, яка працює як прошарок між ФОПом та його клієнтом. Флоу виглядає так:

1. Генерація інвойсу: ФОП через адаптивний веб-інтерфейс створює рахунок. Наш бекенд автоматично формує унікальне посилання (інвойс).
2. Формування Payload: При відкритті інвойсу клієнтом, бекенд на льоту формує платіжний рядок з усіма необхідними параметрами. Особливу увагу ми приділили санітизації даних, оскільки банки дуже чутливі до форматування та спецсимволів у призначенні платежу.
3. Рендеринг QR: На фронтенді ми перетворюємо цей платіжний рядок на графічний QR-код.

Коли клієнт відкриває наше посилання, він бачить адаптивний інвойс. Якщо він відкрив його з десктопу — він просто сканує QR телефоном. Якщо з мобільного — він сканує його через додаток свого банку або робить скриншот для зчитування. Банківський додаток миттєво зчитує всі дані і мапить їх у відповідні поля.

Клієнту залишається натиснути лише одну кнопку — підтвердження платежу, без ручного вводу. Відсоток помилок у призначенні платежу (через які податкова може забракувати платіж) падає до нуля.

Оскільки всі виставлені рахунки та їх статуси проходять через нашу базу даних, ми вирішили закрити ще одну біль розробників-ФОПів — подачу декларацій. Ми реалізували механізм генерації CSV-звітів. Замість того щоб вручну вивантажувати виписки з банку і зводити їх у Excel, наша система збирає всі транзакції за обраний квартал у готовий для податкової формат.

Висновки

Завдяки фокусу на правильній генерації та обробці платіжних QR-кодів, ми змогли дати ФОПам інструмент, який залишає їм 100% суми (0% комісії еквайрингу, оскільки це прямий переказ) та дає клієнтам UX, максимально наближений до 1-click payment, усуваючи біль ручного вводу.

Будемо раді почути технічний фідбек від ком’юніті! Чи стикалися ви з проблемою генерації платіжних QR для наших банків? Які підводні камені знаходили при роботі з форматами Привату та Моно?

P.S. Якщо комусь з ФОПів цікаво потестити, як ця архітектура працює на практиці для власного бізнесу — ми залишили промокод DOU на 1 місяць безкоштовного тарифу Pro. Посилання на проєкт тут.