Розробка мобільного застосунку для електронного гаманця

Мобільний застосунок гаманець: де ламається логіка платежів

Пік навантаження в гаманцевому застосунку — не відкриття екрана, а момент підтвердження операції. Користувач натискає «оплатити», мережа на секунду зникає, запит іде повторно — і ось уже два однакових списання в історії.

Саме на таких сценаріях ламається логіка платежів: розсинхрон балансу при паралельних операціях, завислі транзакції, які висять у статусі «в обробці» добами, і подвійні списання при обриві зв'язку.

Кожен із цих збоїв коштує довіри: користувач бачить неправильний залишок один раз — і видаляє застосунок.

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

Звідси класика: списання пройшло, відповідь до клієнта не дійшла, клієнт надіслав повтор — і операція виконалася двічі.

Друге джерело збоїв — паралельність. Користувач платить в одному вікні й одночасно отримує переказ в іншому; два потоки читають один і той самий залишок, обидва вважають його достатнім, обидва списують. Без блокувань і єдиної точки обліку баланс з'їжджає навіть без обривів зв'язку.

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

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

Архітектура гаманця: реєстр операцій, резервування, звірка

Реєстр операцій як єдине джерело правди

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

Тому облік будуємо на незмінному реєстрі операцій — кожен запис фіксує суму, тип, статус і пов'язаний ідентифікатор, а поточний баланс виводиться з журналу.

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

Резервування коштів і звірка транзакцій

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

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

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

Що обирають під навантаження

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

Опишіть вашу схему обліку та провайдерів — повернемося з оцінкою та планом щодо архітектури.

Етапи розробки гаманцевого застосунку: від аудиту до передачі

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

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

Нижче — маршрут, за яким ми ведемо проєкт. Кожен етап закінчується артефактом, який можна перевірити, а не усним «готово».

1. Аудит поточної схеми. Дивимося, як операції проходять зараз: де зберігається баланс, хто джерело істини, які провайдери та банки вже підключені, як обробляються повернення та скасування. На виході — карта потоків і список вузьких місць.
2. Проєктування моделі операцій. Фіксуємо стани платежу (створено, в обробці, підтверджено, відхилено, повернено), правила ідемпотентності та порядок звірки. Це ядро: від нього залежить, як поводитиметься застосунок при обриві зв'язку.
3. Впровадження платіжного модуля. Підключаємо еквайринг, поповнення, виведення та перекази між користувачами, налаштовуємо вебхуки та повторні спроби. Кожен сценарій отримує зрозумілий код помилки, а не «щось пішло не так».
4. Проєктування операцій і лімітів. Логуємо кожен рух коштів, налаштовуємо ліміти, антифрод-правила та ролі доступу до адмін-панелі. Історія операцій має збігатися з даними провайдера до копійки.
5. Тестування платежів на реальних сценаріях. Проганяємо успішні та провальні кейси: недостатньо коштів, таймаут провайдера, подвійне натискання, повернення, скасування на середині. Окремо — перевірка на слабкому каналі та при перезапуску застосунку.
6. Передача та документація. Віддаємо вихідні коди, схеми потоків, опис інтеграцій, інструкції з розгортання та чекліст для підтримки. Команда замовника може розвивати продукт без нас.

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

Чим відрізняється передплачений гаманець від розрахункового рахунку в застосунку?

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

У передплаченому гаманці користувач спочатку вносить кошти на рахунок емітента, і лише потім витрачає їх із балансу. Застосунок оперує не грошима напряму, а зобов'язанням: баланс — це запис у внутрішньому реєстрі, який емітент зобов'язаний погасити під час операції.

Звідси жорсткі обмеження — ліміти на поповнення та залишок, заборона на перекази третім особам понад встановлений поріг, обов'язкова ідентифікація при перевищенні рівнів.

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

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

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

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

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

У моделі розрахункового рахунку повернення йде на банківський рахунок, а застосунок лише відображає статус — але зобов'язаний показати користувачеві, куди саме прийдуть гроші та коли.

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

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

Кейс: як ми прибрали подвійні списання та завислі платежі

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

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

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

Без нього будь-який ретрай на боці застосунку чи мережі створював нову транзакцію замість продовження наявної.

Що змінили

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

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

Додали скінченний автомат статусів із явними переходами та таймаутами: «зависла» операція після закінчення вікна очікування автоматично йде на звірку з банком, а не залишається в невизначеності. Фоновий воркер доро́збирає такі випадки без участі людини.

Метрики до та після

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

Ідемпотентність — не прикраса, а базова вимога до будь-якого платіжного застосунку: без неї ретраї та нестабільна мережа гарантовано породжують розходження. Ми проєктуємо такі контури так, щоб коректність не залежала від якості зв'язку на боці користувача.

Сумісність, міграція та відкат: що обговорити до старту

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

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

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

Як переносяться дані гаманця? Через поетапну звірку: спочатку тіньовий запис у нове сховище, потім порівняння контрольних сум за балансами та історією, і лише після збігу — перемикання читання.

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

Що як реліз виявиться проблемним? Тримаємо зворотну сумісність форматів і прапорці вмикання: нова логіка гаситься віддалено, застосунок продовжує працювати на попередньому контракті. Користувач не втрачає доступ до балансу навіть при відкаті.

На руки замовник отримує:

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

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