Разработка мобильного приложения для автобусных билетов
Рынок автобусных перевозок в России — это тысячи перевозчиков с разными учётными системами, отсутствие единого API и агрегаторы, у которых актуальность расписания оставляет желать лучшего. Именно поэтому автобусный ticketing сложнее авиационного, несмотря на кажущуюся простоту направления.
Источники данных и интеграция
Три основных пути:
Собственная система перевозчика. Разрабатываем для конкретного перевозчика — у него есть своё расписание и кассовая система (как правило, Автовокзал, Радар, Transinfo или 1С). Интегрируемся напрямую через REST или XML API. Надёжно, но закрытая аудитория.
Агрегаторы. Tutu.ru, Busfor, CheckMyBus предоставляют API для белых партнёров. Доступ — по договору. Tutu API — REST/JSON, актуальные расписания по большинству направлений РФ и СНГ. CheckMyBus — для международных маршрутов.
Собственная агрегация. Парсинг и прямые договоры с перевозчиками — самый дорогой и трудоёмкий вариант, но даёт контроль над данными и маржой.
Поиск и доступность мест
Поиск: откуда-куда, дата, количество пассажиров. Автодополнение остановок — через UISearchTextField (iOS) с debounce 300ms или 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.
Оплата
СБП — основной способ оплаты для автобусных билетов: низкая комиссия, мгновенное зачисление. Ю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 статуса рейса. Push за 2 часа и за 30 минут до отправления. Если перевозчик поддерживает трекинг GPS — показываем текущее положение автобуса на карте через MapKit / Google Maps SDK.
Сроки
4–6 недель для приложения под конкретного перевозчика или с агрегаторским API. Стоимость рассчитывается индивидуально после анализа требований.