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

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

Ринок автобусних перевезень у Росії—тисячі перевізників з різними обліковими системами, відсутність єдиного API та агрегатори, у яких актуальність розпису залишає бажати кращого. Саме тому автобусний ticketing складніше авіаційного, незважаючи на видиму простоту напрямку.

Джерела даних та інтеграція

Три основних шляхи:

Власна система перевізника. Розробляємо для конкретного перевізника—у нього є свій розпис та касова система (як правило, Avtovokzal, Radar, Transinfo або 1C). Інтегруємось безпосередньо через REST або XML API. Надійно, але закрита аудиторія.

Агрегатори. Tutu.ru, Busfor, CheckMyBus надають API для white-label партнерів. Доступ—за договором. 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.

Оплата

СБП—основний спосіб оплати для автобусних квитків: низька комісія, миттєве зарахування. YooKassa або 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. Вартість розраховується індивідуально після аналізу вимог.