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

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

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

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

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

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

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

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

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

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