Розробка мобільного додатка для ресторана (оплата по QR)
QR-оплата в ресторані на перший погляд виглядає просто: сканував — заплатив. На деле інтеграція ломається на стику кількох шарів — генерація QR на стороні касової системи, синхронізація статусу оплати між офіціантським планшетом та додатком гостя, та обробка таймаутів, коли еквайер відповідає пізніше, ніж закривається рахунок.
Де найчастіше ломається інтеграція
Найчастіша проблема — гонка станів при QR-оплаті через СБП (Систему швидких платежей). Гість сканує динамічний QR, сформований через API ЮKassa або CloudPayments, робить переказ. Банк відправляє webhook на ваш сервер. Але додаток вже показує "Чекаємо підтвердження" та через 30 секунд — "Час очікування вичерпаний". Причина — webhook прийшов через 35 секунд з-за мережевих затримок на стороні банку, а polling на мобільному клієнті зупинився раніше.
Розв'язання: WebSocket-канал між сервером та мобільним клієнтом замість polling. Сервер при отриманні webhook одразу пушить статус на пристрій. Таймаут на клієнті збільшуємо до 3 хвилин, але візуально показуємо прогрес — анімація очікування не повинна зависнути "навічно" з точки зору UX.
Друга проблема — сканування QR на iOS через AVFoundation. Стандартний AVCaptureMetadataOutput з типом .qr іноді не читає роздруковані QR при поганому освітленню ресторана. Додаємо torchMode = .auto та програмно виставляємо videoZoomFactor при низькому brightness з AVCaptureDevice.exposureTargetBias.
Як виглядає стек та архітектура
На iOS — SwiftUI + Combine для стану екрану оплати, AVFoundation для сканування, URLSession з async/await для запитів до бекенду. На Android — Jetpack Compose, CameraX з QRCodeAnalyzer поверх ML Kit Barcode Scanning, Retrofit + OkHttp.
Серверна частина: генерація динамічного QR через API еквайера (у ЮKassa це POST /v3/payments з confirmation.type = qr), отримання confirmation_url, WebSocket-сповіщення клієнту, обробка webhook з верифікацією підпису sha256.
Для меню та каталогу блюд — звичайний REST, дані кешуємо локально через Core Data (iOS) або Room (Android), щоб меню відкривалось без інтернету.
Схема взаємодії
[Мобільне додаток гостя]
|
| Запрос рахунку (tableId)
v
[Бекенд ресторана]
|
| POST /v3/payments → ЮKassa API
v
[ЮKassa] → повертає confirmation_url (QR)
|
| WebSocket push при отриманні webhook
v
[Мобільне додаток] → статус "Оплачено"
Етапи роботи
Починаємо з аудиту касової системи ресторана — потрібно зрозуміти, через який протокол вона спілкується (iiko, r_keeper, Poster, або самописна). Інтеграція з iiko через iiko.transport API додає близько 2 днів до терміну. Потім:
- Дизайн екранів: меню, кошик, екран оплати з QR
- Реалізація сканування та генерації QR
- Інтеграція з платіжним провайдером
- Тестування webhook'ів у Sandbox
- Збирання та публікація в App Store / Google Play
Сроки
MVP з QR-оплатою та меню — 2–3 тижні. З повнофункціональною інтеграцією касової системи та версіями для iOS та Android — до 5 тижнів. Вартість розраховується індивідуально після аналізу вимог.