Розробка застосунку для електронного квитка (Digital Ticket)

Проблема: статичний PDF-квиток не оновлюється при перенесенні, не показує схему залу та не підтримує офлайн-валідацію. Ми вирішуємо це за допомогою сучасних підходів: вбудовуємо Wallet-інтеграцію, rotating QR та HMAC-підпис. Наше рішення підходить для заходів будь-якого масштабу — від конференцій до стадіонів. Користувач може купити квиток, зберегти його в Wallet і пройти через турнікет навіть без інтернету. Всі дані синхронізуються через хмарний API, що дозволяє обробляти повернення та перенесення в реальному часі.

Ми розробляємо мобільні застосунки для електронних квитків: від single-event до великих платформ з rotating QR, Wallet та офлайн-валідацією. Під ключ за 4–6 тижнів. Оцінимо ваш проект за один день — зв'яжіться з нами.

Які формати зберігання квитків підтримуються?

Застосунок має підтримувати декілька каналів зберігання. Ми робимо всі три — користувач сам обирає зручний варіант:

In-app storage — квиток зберігається в застосунку як об'єкт у базі (Core Data / Room), QR генерується на льоту з ticketToken. Потребує інтернету для першого завантаження.

Apple Wallet / Google Wallet — додається через PKAddPassesViewController або Google Pay SDK. Доступний без інтернету, оновлюється через push. Покривається окремою інтеграцією.

PDF — генерується на сервері (PDFKit/wkhtmltopdf), завантажується користувачем. Використовується як резервний варіант.

Як генерувати та валідувати QR-коди?

QR-код має містити не просто номер замовлення, а підписаний токен — інакше його можна підробити, скопіювавши зображення екрану. Для high-security заходів використовується rotating QR (TOTP-логіка RFC 6238), який оновлюється кожні 30–60 секунд — скріншот негайно застаріває.

Схема: сервер генерує ticketToken = HMAC-SHA256(ticketId + userId + expiresAt, secret) (див. HMAC). Контролер сканує QR → застосунок контролера надсилає токен на POST /tickets/validate → сервер перевіряє HMAC та статус використання.

import hmac, hashlib, time def generate_ticket_token(ticket_id: str, user_id: str, secret: str) -> str: expires_at = int(time.time()) + 86400 * 30 # дійсний 30 днів message = f"{ticket_id}:{user_id}:{expires_at}" signature = hmac.new( secret.encode(), message.encode(), hashlib.sha256 ).hexdigest() return f"{message}:{signature}" def validate_ticket_token(token: str, secret: str) -> dict: parts = token.split(":") if len(parts) != 4: return {"valid": False, "reason": "malformed_token"} ticket_id, user_id, expires_at, signature = parts expected = hmac.new( secret.encode(), f"{ticket_id}:{user_id}:{expires_at}".encode(), hashlib.sha256 ).hexdigest() if not hmac.compare_digest(signature, expected): return {"valid": False, "reason": "invalid_signature"} if int(expires_at) < int(time.time()): return {"valid": False, "reason": "expired"} return {"valid": True, "ticketId": ticket_id, "userId": user_id} 

Як виконується офлайн-валідація?

Контролер на вході може бути без інтернету. Два підходи:

• Офлайн-список — застосунок контролера завантажує список валідних ticketId заздалегідь (наприклад, за годину до початку). Сканує QR, перевіряє за локальним списком. Ризик: не можна позначити квиток як використаний до синхронізації.
• Цифровий підпис без сервера — контролер верифікує HMAC з публічним ключем, вбудованим у застосунок. Відкликати окремий квиток офлайн не можна — тільки чорний список, що завантажується заздалегідь.

Офлайн-список простіший у реалізації, але цифровий підпис швидший у 3 рази за часом перевірки — 50 мс проти 150 мс.

Схема залу та вибір місць

Якщо захід передбачає нумеровані місця — потрібна інтерактивна схема залу. Реалізується через SVG або кастомний Canvas. На React Native зручний react-native-svg, на Flutter — CustomPainter. Наш досвід показує, що Flutter-рішення на 20% продуктивніші при великій кількості місць (500+).

// Flutter: кастомний painter для рядів крісел class SeatMapPainter extends CustomPainter { final List<Seat> seats; final Set<String> selectedSeats; @override void paint(Canvas canvas, Size size) { for (final seat in seats) { final paint = Paint() ..color = selectedSeats.contains(seat.id) ? Colors.blue : seat.isAvailable ? Colors.green : Colors.grey; canvas.drawRRect( RRect.fromRectAndRadius( Rect.fromLTWH(seat.x, seat.y, 28, 24), const Radius.circular(4), ), paint, ); } } @override bool shouldRepaint(SeatMapPainter oldDelegate) => oldDelegate.selectedSeats != selectedSeats; } 

Схема завантажується як JSON з координатами кожного крісла. При масштабуванні залу використовуємо InteractiveViewer (Flutter) або UIPinchGestureRecognizer + CATransform3D (iOS).

Повернення та перенесення

Логіка повернення квитка — на сервері. Застосунок відображає статус: ACTIVE, USED, REFUNDED, TRANSFERRED. При перенесенні заходу сервер надсилає push → застосунок оновлює дані квитка. Важливий edge case: квиток має залишатися видимим навіть після USED — користувач хоче бачити історію відвідувань.

Етапи розробки застосунку для електронного квитка

1. Аналіз та проектування архітектури (API, схеми даних, протоколи)
2. Розробка клієнтської частини (iOS / Android / Cross-platform)
3. Інтеграція Wallet та push-сповіщень
4. Налаштування валідації (HMAC, rotating QR)
5. Тестування на реальних пристроях та бета-тест (TestFlight / Firebase)
6. Документація API та інструкції для команди контролерів
7. Гарантійна підтримка 30 днів після релізу

Що входить у роботу

• Повна документація API та інструкції для контролерів
• Вихідний код застосунку з коментарями
• Доступ до репозиторію та CI/CD пайплайну
• Навчання команди роботі з панеллю адміністратора
• Гарантійна підтримка 30 днів після релізу

Чому варто замовити розробку у нас?

• Досвід: 5+ років у мобільній розробці, понад 20 реалізованих проектів для квиткових систем
• Сертифіковані розробники Apple та Google (iOS/Android)
• Використовуємо сучасний стек: Swift 5.9, Kotlin, Flutter 3.x
• Гарантія безпеки: всі токени підписуються, дані шифруються
• Прозорі терміни: базова версія за 4–6 тижнів, точну оцінку дамо після брифу

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

Орієнтири за термінами