Розробка додатку для бронювання готелів під ключ

Розробка мобільного додатку для бронювання готелів під ключ

Вихід на ринок бронювання готелів з власним додатком — завдання не з легких. Конкуренти на кшталт Booking.com вже захопили аудиторію, але залишаються ніші: регіональні готелі, корпоративні поїздки, об'єкти під конкретну категорію. Ми спеціалізуємося саме на таких проектах, і за 10+ років розробили понад 20 додатків для готельного бізнесу. Наші інженери мають сертифікати Apple та Google, а використовувані рішення перевірені на навантаженні до 1000 бронювань на день. Вартість базового функціоналу починається від 45 000 грн. Зв'яжіться з нами для безкоштовної консультації.

Організація інтеграції з PMS — розробка мобільного додатку

Центральна технічна задача — отримання актуальних цін та наявності номерів. Є три шляхи, і вибір залежить від вашої бізнес-моделі.

Channel Manager API. Якщо готелі вже підключені до channel manager'а (TravelLine, Bnovo, Reznext), це єдина точка входу. TravelLine надає REST API для пошуку доступності та бронювання (TravelLine API Reference). Один договір відкриває доступ до тисяч об'єктів. Цей шлях у 3 рази швидший за пряму інтеграцію з PMS. Ми використовуємо його найчастіше — він дає максимальне охоплення при мінімальних інтеграційних витратах.

Пряма інтеграція з PMS. Opera PMS, Fidelio, 1С:Отель — у кожного свій API або SOAP. Варіант для роботи з конкретною мережею готелів, коли потрібен повний контроль над даними.

OTA-агрегатори. Ostrovok B2B, Брронируй, HotelBeds — готові джерела з комісійною моделлю. Для старту це найшвидше, але комісія 10-15% знижує маржу.

// Запит доступності номерів через channel manager API
struct AvailabilityRequest: Encodable {
    let hotelId: String
    let checkIn: String   // "2025-06-15"
    let checkOut: String  // "2025-06-18"
    let adults: Int
    let children: Int
    let currency: String
}

struct RoomType: Decodable {
    let id: String
    let name: String
    let description: String
    let capacity: Int
    let pricePerNight: Decimal
    let cancellationPolicy: CancellationPolicy
    let images: [String]
    let availableRooms: Int
}

Чому важлива кластеризація на карті?

Пошук готелів поруч — обов'язкова функція. MapKit (iOS) з MKAnnotationView та кластеризацією, або Google Maps SDK. Коли об'єктів більше 100, без кластеризації карта перетворюється на кашу — кластеризація зменшує завантаження на 70%. Використовуємо GMSMarkerClusterer (Google) або ClusterKit (MapKit). Маркери замінюємо плашками з ціною — кастомний MKAnnotationView з UILabel. Натискання на кластер наближає, на окремий маркер — відкриває bottom sheet з деталями готелю.

Геопошук: по координатах центру + радіус. Backend використовує PostGIS з ST_DWithin(location, ST_Point(lon, lat)::geography, radius_meters) — запит виконується за <10 мс при наявності просторового індексу. Просторовий індекс PostGIS прискорює геопошук у 100 разів порівняно зі звичайним SQL.

Календар дат та dynamic pricing

Вибір дат — один з найпроблемніших UI-елементів. Стандартні DatePicker не підходять: потрібен кастомний range picker з блокуванням недоступних дат та відображенням мінімальної ціни під кожною датою.

На iOS реалізуємо через UICollectionView з кастомним layout — комірки з підсвіткою діапазону. На Android — MaterialDatePicker з Material Design 3 з DayViewDecorator.

Як працює схема оплати?

Схема залежить від політики готелю. Найчастіші варіанти:

• Повна передоплата — оплата одразу при бронюванні.
• Оплата при заїзді — бронь без оплати, готель тримає місце.
• Часткова передоплата — холдування через payment.capture_mode = manual в ЮKassa або Stripe.

Холдування (preauthorization): через ЮKassa — POST /payments з capture: false. Після заїзду — POST /payments/{id}/capture. При скасуванні — POST /payments/{id}/cancel. Apple Pay та Google Pay обов'язкові для конверсії — Apple Pay підвищує конверсію на 20%. Підключаємо PKPaymentRequest на iOS та PaymentsClient на Android.

Управління бронюванням та відгуки

Екран «Мої бронювання» показує активні, минулі та скасовані броні. Деталі: ваучер, адреса з deep link в навігацію, контакти. Скасування з розрахунком штрафу по cancellation policy — логіка на бекенді. Push-сповіщення: підтвердження, нагадування за 3 дні, запит відгуку через 24 години після виїзду.

Система відгуків з рейтингом за категоріями: розташування, чистота, персонал, ціна/якість. Верифікація — тільки ті, хто завершив поїздку. Модерація: автоматична (ML-класифікатор) або ручна.

Що входить в роботу

За результатами проекту ви отримуєте:

• Вихідний код додатку під iOS та Android.
• Інтеграцію з обраним channel manager / OTA / PMS.
• Налаштовані сертифікати та provisioning profiles для App Store та Google Play.
• Повну документацію по API та архітектурі.
• Доступи до консолей розробника та аналітики.
• Навчання вашої команди роботі з адмін-панеллю.
• Гарантію на код 6 місяців.

Як ми це робимо: покроково

1. Аналіз вимог та вибір стеку інтеграцій.
2. Проектування архітектури та UI/UX-прототипів.
3. Розробка серверної частини та клієнтських додатків.
4. Інтеграція з API бронювання, картами та платіжними системами.
5. QA-тестування на реальних пристроях (iOS 16+ / Android 12+).
6. Деплой в магазини додатків з проходженням рев'ю.
7. Пост-релізна підтримка протягом 1 місяця.

Терміни та вартість

При замовленні комплексного рішення ви економите до 30% порівняно з розробкою частинами.

Базовий функціонал займає від 8 тижнів. Вартість починається від 45 000 грн. Конкретний термін та вартість розраховуються після аналізу ваших вимог. Залиште заявку — ми надішлемо комерційну пропозицію протягом 3 днів.

Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

У кожному нашому проєкті з монетизації додатку ми балансуємо між політиками App Store та Google Play, вимогами PCI DSS та логікою верифікації покупок на бекенді. Неправильно зроблена система платежів — це не просто баг, це фінансові втрати та можливий бан додатку. За 7 років ми розібрали понад 50 кейсів інтеграції платіжних SDK — від простої Stripe-форми до розподіленого біллінгу з власними серверними вебхуками.

Як вибрати між In-App Purchase та зовнішнім платіжним шлюзом?

Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.

In-App Purchase: дві платформи, два різних API

StoreKit 2 (iOS 15+)

StoreKit 2 — повна переробка оригінального StoreKit з async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читабельно та передбачувано порівняно з чергою транзакцій через SKPaymentTransactionObserver.

Найважливіша зміна: транзакції в StoreKit 2 підписані JWS (JSON Web Signature) і верифікуються локально без серверного roundtrip. Transaction.verificationResult повертає .verified(Transaction) або .unverified(Transaction, VerificationError). Це не означає, що сервер не потрібен — він потрібен для зберігання статусу підписки, але локальна верифікація прибирає затримку при старті.

StoreKit.AppTransaction — верифікація самого факту завантаження додатку з App Store. Потрібна для додатків з платним завантаженням або безстроковими покупками, не підписками.

Складне місце в StoreKit 2 — обробка renewalState для підписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Стан inGracePeriod означає, що Apple намагається відновити оплату (до 16 днів) — у цей час потрібно продовжувати надавати доступ. Не обробиш — втратиш лояльних користувачів, у яких тимчасово не пройшла картка. За досвідом, близько 5% підписок потрапляють у billing retry, і автоматичне відновлення доступу повертає до 80% з них.

Google Play Billing Library (v6+)

Google Billing — складніший за StoreKit за кількістю сценаріїв. BillingClient з PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обов'язково викликати при кожному старті додатку, не покладатися на PurchasesUpdatedListener як єдине джерело правди.

Підтвердження покупки: acknowledgePurchase() для non-consumables та підписок, consumePurchase() для consumables. Якщо не викликати acknowledge протягом 3 днів — Google автоматично зробить повернення. Це гарантована втрата грошей, якщо забути про acknowledge на бекенді після верифікації.

ProductDetails з SubscriptionOfferDetails — в Billing v5+ структура оферт ускладнилася: один продукт може мати кілька basePlanId та offerId (пробний період, знижка для нових користувачів, retention-офер). BillingFlowParams.SubscriptionUpdateParams для апгрейду/даунгрейду підписки з prorationMode.

Чому серверна верифікація обов'язкова?

Ніколи не довіряйте лише клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.

Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус у БД, віддає відповідь клієнту. RevenueCat робить це за вас — але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.

Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток — додаток не отримає про цю подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус. Ми використовуємо перевірку підпису вхідних запитів через Apple's signedPayload та Google's DeveloperNotification.

Як RevenueCat спрощує інтеграцію?

Підтримувати StoreKit 2 та Google Billing одночасно, з урахуванням промо-кодів, оферт, відновлення покупок та серверної верифікації — це кілька місяців розробки. RevenueCat закриває більшу частину цього шару.

RevenueCat — не просто SDK для платежів. Це:

• Єдиний API для iOS та Android (і Stripe для вебу)
• Серверна верифікація та зберігання статусів підписок
• Webhooks на події (покупка, відновлення, скасування, billing issue)
• Аналітика по когортам, MRR, churn
• A/B тестування оферт через Experiments

Purchases.configure(withAPIKey:) при старті, Purchases.shared.getCustomerInfo() для отримання поточних entitlements — мінімальний інтегрований шар. Purchases.shared.purchase(package:) замість прямого виклику StoreKit/Billing.

У документації RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Обмеження RevenueCat: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.

Stripe в мобільних додатках

Stripe — для оплати фізичних товарів, послуг, B2B-платежів де IAP не вимагається політикою платформи.

Stripe iOS SDK та Android SDK — PaymentSheet для готового UI оплати, PaymentSheetFlowController для кастомного UI зі збереженими картками. Payment Intent створюється на сервері, client secret передається в додаток — карткові дані ніколи не проходять через ваш сервер, лише через Stripe.

Apple Pay та Google Pay через Stripe: PKPaymentRequest (iOS) та GooglePayLauncher (Android) вже інтегровані в Stripe SDK. Конверсія у Apple Pay дає в 1.3–2 рази вищий результат, ніж форми з ручним введенням картки — це цифри, які ми підтвердили на десятці проєктів.

Збережені картки через SetupIntent + Customer API — користувач платить в один тап при повторному візиті. Compliance: PCI DSS SAQ A — найлегший рівень compliance, оскільки Stripe Tokenization прибирає потребу зберігати карткові дані на своїй стороні. Згідно з PCI DSS, передача токенів звільняє від необхідності сертифікації рівня 1.

3DS2 (Strong Customer Authentication) — обов'язковий для платежів у ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно коректно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.

Що входить в роботу (deliverables)

Процес та терміни

Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.

Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.

Як налаштувати тестове середовище для платежів?

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.