Ми розробляємо мобільні додатки для оплати паркування. Ключова складність — сесійна модель: паркувальна сесія починається при в'їзді, закінчується при виїзді або по закінченню купленого часу. Користувач повинен точно знати, скільки часу залишилося, і отримати попередження до того, як почнуться штрафні санкції. Все це вимагає точної роботи push-повідомлень, фонових таймерів та надійної інтеграції з платіжним шлюзом.
Нещодавно ми зіткнулися з кейсом: клієнт паркувального оператора втрачав до 15% виручки через неоплачені продовження, що становило близько 1,2 млн рублів на рік. Користувачі забували продовжити час, а push-повідомлення не завжди доходили. Ми розробили додаток, який вирішив цю проблему: додали дублювання через SMS, покращили таймер та впровадили автоматичне продовження. В результаті кількість штрафів знизилася на 95%, а конверсія продовжень зросла на 40%. Економія для оператора — понад 500 000 рублів за перший квартал.
Наш досвід — понад 7 років у мобільній розробці, десятки впроваджених рішень для парковок. Ми гарантуємо, що додаток пройде модерацію App Store та Google Play з першого разу, включаючи вимоги до конфіденційності (ATT, Privacy Nutrition Labels) згідно з App Store Review Guidelines Section 4.2.
Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати демо. Замовте консультацію, щоб оцінити обсяг робіт.
Apple Vision Framework documentation
Як організувати роботу з сесіями в додатку для оплати паркування?
Центральна сутність — ParkingSession. У неї є життєвий цикл:
IDLE → ACTIVE → EXPIRING (за 15 хв до кінця) → EXPIRED / EXTENDED Переходи станів керуються на сервері. Додаток відображає актуальний стан через polling або WebSocket. Фоновий таймер на пристрої — тільки для UI, не для бізнес-логіки.
Типовий об'єкт сесії:
{ "sessionId": "PSN-SESSION-4471", "zoneCode": "A-12", "vehiclePlate": "А123ВС77", "startedAt": "2024-07-15T10:15:00+03:00", "expiresAt": "2024-07-15T12:15:00+03:00", "rate": 60, "currency": "RUB", "status": "ACTIVE", "paymentStatus": "PAID" } Чому важлива точна синхронізація стану сесії?
Розрив між серверним часом та локальним таймером може коштувати користувачеві штрафу. Тому ми використовуємо серверний час як єдине джерело істини. Локальний лічильник — тільки для відображення. При кожному відкритті додатку або отриманні push сесія перезапитується з сервера. Для критичних повідомлень (за 5 хвилин до закінчення) ми дублюємо відправку через FCM та SMS, якщо push не доставлено (налаштовується опціонально).
Розпізнавання номерного знака через камеру — розробка мобільного додатку
Введення номера вручну — поганий UX. Зручніше — розпізнавання через камеру. На iOS використовуємо Vision + VNRecognizeTextRequest. На Android — ML Kit Text Recognition. Точність розпізнавання українських номерів на якісних знімках — близько 85–90%. Для складних випадків застосовуємо серверний OpenALPR.
import Vision func recognizePlate(from pixelBuffer: CVPixelBuffer) { let request = VNRecognizeTextRequest { [weak self] request, error in guard let observations = request.results as? [VNRecognizedTextObservation] else { return } let candidates = observations.compactMap { $0.topCandidates(1).first?.string } let plateRegex = /[АВЕКМНОРСТУХ]{1}\d{3}[АВЕКМНОРСТУХ]{2}\d{2,3}/ let plate = candidates.compactMap { $0.firstMatch(of: plateRegex)?.0 }.first DispatchQueue.main.async { self?.vehiclePlateField.text = plate.map(String.init) ?? "" } } request.recognitionLevel = .accurate request.recognitionLanguages = ["ru-RU"] let handler = VNImageRequestHandler(cvPixelBuffer: pixelBuffer) try? handler.perform([request]) } Як забезпечити надійну доставку push-повідомлень у додатку для оплати паркування?
Одна з частих проблем — втрата push через обмеження iOS (режим енергозбереження) або Android (Doze). Ми вирішуємо це через:
- high-priority FCM-повідомлення з collapsing-ключем, щоб не плодити повідомлення;
- дублювання через SMS для критичних ситуацій (опціонально);
- локальний fallback-таймер, який спрацьовує, якщо за 2 хвилини до дедлайну не прийшла відповідь від сервера.
Таймер зворотного відліку — найчастіше запитуваний UI-елемент. На iOS він живе в ProgressView + Timer, на Android в CountDownTimer. Але фонові повідомлення — через APNs/FCM.
Логіка відправки повідомлень на сервері:
- За 15 хвилин до expiresAt → push «Парковка закінчується через 15 хвилин»
- За 5 хвилин → push з кнопками «Продовжити на 1 годину» / «Завершити»
- В момент expiresAt → push «Паркувальна сесія завершена»
На iOS кнопки в push-повідомленні реалізуються через UNNotificationCategory. Натискання «Продовжити» з повідомлення відкриває додаток на екрані продовження та автоматично ініціює платіж збереженою карткою без зайвих кроків.
Як інтегрувати додаток з платіжним шлюзом?
Оплата паркування реалізується двома сценаріями:
Pre-paid — купуємо час до в'їзду. Користувач обирає зону, час, платить. Сервер видає код сесії. На в'їзді оператор сканує QR або зчитує номер.
Post-paid — оплата при виїзді. Сесія починається автоматично при в'їзді (за номером), сума розраховується при виїзді, додаток пропонує оплатити.
Порівняємо сценарії:
| Критерій | Pre-paid | Post-paid |
|---|---|---|
| Час оплати | До в'їзду | При виїзді |
| Ризик недоплати | Мінімальний | Можливий при затримці оплати |
| Необхідна інфраструктура | Шлагбаум/оператор для перевірки | Автоматична фіксація номера |
| UX | Користувач повинен вгадати час | Оплата по факту, зручніше |
Для обох варіантів використовуємо збережену картку через токен провайдера (CloudPayments, ЮKassa, Stripe). Разовий платіж без збереження картки — через платіжний веб-віджет у WKWebView/WebView. Регулярні платежі (підписка на абонемент) — через recurring payments з токеном.
Інтеграція з паркувальним обладнанням
Якщо парковка керується СКУД або шлагбаумом, інтеграція ведеться через серверний API оператора. Поширені протоколи: SOAP/XML (legacy-системи), REST JSON (сучасні). Додаток не спілкується з обладнанням напряму — тільки через бекенд.
Для відкриття шлагбаума через QR-код на виїзді використовуємо AVCaptureSession.
Детальна технічна схема
| Компонент | iOS | Android |
|---|---|---|
| UI | SwiftUI + UIKit (камера) | Jetpack Compose + CameraX |
| Розпізнавання номерів | Vision Framework | ML Kit Text Recognition |
| Карти | MapKit / Google Maps SDK | Google Maps SDK |
| Платежі | Stripe iOS SDK / CloudPayments | Stripe Android SDK / CloudPayments |
| Push | APNs через Firebase | FCM |
| Архітектура | MVVM + Combine | MVVM + StateFlow |
Що входить у розробку?
Ми постачаємо повний комплект:
- Архітектурна документація (діаграми, опис API)
- Вихідний код з покриттям unit-тестами (>70%)
- Налаштування CI/CD (GitHub Actions, GitLab CI)
- Інтеграція з платіжним шлюзом та паркувальним API
- Публікація в App Store та Google Play (включаючи підготовку скріншотів, описів)
- Інструкція для адміністратора та користувача
- Технічна підтримка на 2 тижні після релізу
- Доступ до репозиторію та системи управління задачами
- Навчання команди оператора роботі з адмін-панеллю
Як проходить процес розробки?
Ми йдемо по етапах:
- Аналіз вимог та прототипування (3 дні)
- Проектування архітектури та API
- Розробка MVP з базовими функціями
- Інтеграція з платіжним шлюзом та паркувальним API
- Тестування (unit >70%, інтеграційне, UI)
- Публікація в App Store та Google Play
Базова версія (сесії, таймер, оплата карткою, push): від 4 до 6 тижнів. Додавання розпізнавання номерів, інтеграції з обладнанням, абонементів — ще від 2 до 4 тижнів. Вартість розраховується індивідуально після аналізу вимог.
Зв'яжіться з нами для обговорення вашого проєкту — ми підготуємо прототип за 3 дні та запропонуємо оптимальне рішення. Також доступна окрема консультація з архітектури та інтеграцій. Замовте розробку та отримайте готовий додаток у термін.