Разработка приложения для электронного билета (Digital Ticket)

Разработка приложения для электронного билета (Digital Ticket)

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

Мы разрабатываем мобильные приложения для электронных билетов: от single-event до крупных платформ с rotating QR, Wallet и офлайн-валидацией. Под ключ за 4–6 недель. Оценим ваш проект за один день — свяжитесь с нами. Стоимость разработки обычно варьируется от 2 до 5 миллионов рублей в зависимости от сложности, а использование готовых модулей позволяет сэкономить до 30% бюджета — в денежном выражении это до 1.5 млн рублей.

Какие форматы хранения билетов поддерживаются? — разработка приложения для

Приложение должно поддерживать несколько каналов хранения. Мы делаем все три — пользователь сам выбирает удобный вариант:

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 недель, точную оценку дадим после брифа

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

Ориентиры по срокам

Стоимость рассчитывается индивидуально — пишите, оценим за один день.