Разработка мобильного приложения для автобусных билетов

Разработка мобильного приложения для автобусных билетов

Мы разрабатываем мобильные приложения для продажи автобусных билетов с интеграцией в учётные системы перевозчиков. В отличие от авиации, где работают стандартизированные GDS, автобусный ticketing сталкивается с разрозненными API, устаревшими протоколами и отсутствием единого реестра перевозчиков. Многие перевозчики до сих пор используют XML-протоколы 2000-х, без поддержки REST, поэтому мы адаптируем парсинг под каждую систему — от 1С до специализированных касс «Автовокзал». Важно сохранить скорость ответа: среднее время API перевозчика не должно превышать 500 мс, иначе пользователь покинет приложение. Именно поэтому клиентам требуется сложная система интеграций, офлайн-режим и гибкая логика возвратов.

Наша команда имеет 6 лет опыта в разработке транспортных приложений, реализовала более 15 проектов для автобусных перевозчиков и агрегаторов. Мы гарантируем качество на каждом этапе — от аналитики до поддержки после релиза. Свяжитесь с нами для оценки вашего проекта или получите консультацию по интеграции.

Источники данных и интеграция

Три основных пути:

• Собственная система перевозчика. Разрабатываем для конкретного перевозчика — у него есть своё расписание и кассовая система (как правило, Автовокзал, Радар, Transinfo или 1С). Интегрируемся напрямую через REST или XML API. Надёжно, но закрытая аудитория.
• Агрегаторы. Tutu.ru, Busfor, CheckMyBus предоставляют API для белых партнёров. Доступ — по договору. Tutu API — REST/JSON, актуальные расписания по большинству направлений РФ и СНГ. CheckMyBus — для международных маршрутов.
• Собственная агрегация. Парсинг и прямые договоры с перевозчиками — самый дорогой и трудоёмкий вариант, но даёт контроль над данными и маржой.

Интеграция с СБП позволяет принимать платежи быстрее, чем через карты, а комиссия 0.4–0.7% экономит до 30% затрат на эквайринг.

Почему автобусные приложения требуют особого подхода?

В отличие от авиабилетов, где данные стандартизированы через системы бронирования, автобусные перевозчики используют десятки различных учётных систем с несовместимыми протоколами. Часть перевозчиков не поддерживает электронные билеты — только бумажные, что нужно явно показывать в UI перед покупкой. Кроме того, схемы мест в автобусах сильно различаются: от простого «есть место» до послойной сетки с проходами и различными классами. Это делает UI более сложным, а тестирование — критически важным. Согласно App Store Review Guidelines (Section 4.2, 5.1), такие приложения должны явно указывать все ограничения.

Как происходит интеграция с перевозчиком?

1. Аудит API перевозчика — изучаем документацию, тестируем endpoints, выявляем ограничения (например, отсутствие корзины или невозможность возврата).
2. Разработка адаптера — пишем модуль для приведения данных к единому формату. Используем Codable (iOS) или Kotlinx.serialization (Android).
3. Тестирование на боевых маршрутах — прогоняем до 100 сценариев: покупка, возврат, смена места, опоздания.
4. Deploy в песочницу — перевозчик тестирует на своих данных.
5. Релиз в App Store и Google Play — с обеспечением соответствия App Store Review Guidelines (разделы 4.2, 5.1).

Поиск и доступность мест

Поиск: откуда-куда, дата, количество пассажиров. Автодополнение остановок — через UISearchTextField (iOS) с debounce 300 мс или SearchBar + Flow в Jetpack Compose. База остановок кэшируется локально: полный список автовокзалов России — около 3000 записей, грузим при первом запуске и обновляем еженедельно.

Выбор места. Не все перевозчики поддерживают схему автобуса с выбором конкретного места — часть продаёт просто «место в автобусе». Когда схема есть, рендерим как строки по rows и cols из API, отмечаем занятые.

// SwiftUI: сетка мест в автобусе struct BusSeatMapView: View { let seats: [[BusSeat?]] // nil = проход var body: some View { VStack(spacing: 4) { ForEach(seats.indices, id: \.self) { row in HStack(spacing: 4) { ForEach(seats[row].indices, id: \.self) { col in if let seat = seats[row][col] { SeatCell(seat: seat) } else { Spacer().frame(width: 32) } } } } } } } 

Электронный билет

После оплаты генерируем PDF с QR-кодом билета. Важно: часть перевозчиков не принимает электронные билеты — только распечатанные. Это ограничение нужно явно показывать в UI перед покупкой, иначе получим волну негативных отзывов.

QR хранится в FileManager (iOS) или filesDir (Android) для офлайн-доступа. Push-уведомление за 2 часа до отправления через FCM/APNs.

Как обеспечивается офлайн-доступ к билетам?

Мы кэшируем QR-коды и данные билетов локально, чтобы пассажир мог предъявить билет без интернета. Для этого используем FileManager (iOS) или filesDir (Android) с шифрованием. Список билетов синхронизируется при каждом подключении к сети, а уведомления о задержках и отменах приходят через push-сервисы.

Оплата

СБП — основной способ оплаты для автобусных билетов: низкая комиссия (0,4–0,7%), мгновенное зачисление. ЮKassa или CloudPayments для карт. Apple Pay и Google Pay повышают конверсию на финальном шаге — не забываем о них.

Для ряда перевозчиков нужна оплата наличными при посадке: бронирование места без оплаты с резервированием на 30 минут. Схема холдирования — не нужна; достаточно флага payment_method: cash в бронировании.

Возврат билетов

Возврат через API перевозчика или агрегатора. Условия у всех разные — отображаем их на экране покупки, не прячем в пользовательское соглашение. Технически: DELETE /orders/{id} или POST /orders/{id}/refund. Деньги возвращаются на карту через 3–10 рабочих дней в зависимости от банка.

Типичная политика: бесплатная отмена за 3+ часа до отправления, штраф 10–30% за отмену менее чем за 3 часа. Конкретные условия приходят из API вместе с расписанием.

Уведомления и трекинг

Отслеживание задержки — через API перевозчика если поддерживается, либо через периодический polling статуса рейса каждые 5 минут. Push за 2 часа и за 30 минут до отправления. Если перевозчик поддерживает трекинг GPS — показываем текущее положение автобуса на карте через MapKit или Google Maps SDK.

Что входит в работу

• Документация по интеграции (описание API, схемы данных, примеры запросов).
• Доступ к тестовому API (песочница) для отладки.
• Обучение персонала перевозчика работе с приложением.
• Сопровождение при релизе в App Store и Google Play.
• Гарантия на исправление критических ошибок в течение 30 дней после сдачи.
• Исходный код и права на приложение (вы получаете full ownership).

Сроки

4–6 недель для приложения под конкретного перевозчика или с агрегаторским API. Стоимость рассчитывается индивидуально после анализа требований. Закажите разработку под ключ — свяжитесь с нами для предварительной оценки. Грамотная интеграция с источниками данных сокращает время вывода на рынок до 30%.

Получите консультацию по вашему проекту — мы поможем выбрать оптимальный путь интеграции.