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

Розробка мобільного додатку для ЖКГ — наша спеціалізація. Такий додаток для керуючої компанії дозволяє автоматизувати збір показань, нарахування та прийом платежів. За 5 років ми реалізували понад 15 проєктів для КК та агрегаторів, накопичивши досвід інтеграції з десятками білінгових систем. Уявіть: користувач відкриває додаток, вводить показання лічильника, бачить нарахування та оплачує все за три тапи. Але за цим стоять десятки інтеграцій — від ГІС ЖКГ до білінгу конкретної КК, від СБП до push-сповіщень. Якщо API не готовий або дані надходять у «сирому» вигляді, терміни зриваються. Ми знаємо, як обійти граблі.

Як налагодити інтеграцію з ГІС ЖКГ?

Основна складність — різнорідність джерел. Керуючі компанії працюють через різні системи: 1С:ЖКГ, Меркурій, РКЦ або власний білінг. У кожної своя схема API — від SOAP-сервісів до REST з JWT. Частина КК досі віддає дані тільки в XML із застарілими схемами. Агрегатор даних (наприклад, Фінтех Хаб, Безкоштовний Сервіс ЖКГ API, EPS) нормалізує інформацію з різних джерел у єдиний формат — це економить до 80% часу на інтеграцію.

Практично: якщо немає прямого договору з КК, підключаємося через систему міжвідомчої електронної взаємодії або платних посередників. Агрегатор нормалізує дані з різних КК у єдиний формат — економить місяць розробки адаптерів.

// Запит нарахувань за особовим рахунком
struct BillingRequest: Encodable {
    let accountNumber: String
    let period: String // "2025-03"
}

struct BillingResponse: Decodable {
    let services: [UtilityService]
    let totalDebt: Decimal
    let lastPaymentDate: Date?
}

struct UtilityService: Decodable {
    let id: String
    let name: String        // "Холодне водопостачання"
    let amount: Decimal
    let debt: Decimal
    let meterValue: Double? // поточні показання
}

Як вирішується проблема передачі показань лічильників?

Користувач вводить показання — вони йдуть у білінг через PUT /meters/{meterId}/readings. Білінг приймає показання тільки у визначений період (наприклад, з 15 по 25 число). Поза періодом — помилка 403 READINGS_NOT_ACCEPTED_NOW. Потрібно явно показувати це в UI, а не «Невідома помилка».

Ще тонкість: показання повинні бути більшими за попередні. Валідація на клієнті не замінює серверну, але економить запити — одразу блокуємо введення меншого значення з підказкою.

Чому СБП зручніше для ЖКГ?

Для оплати використовуємо СБП (найзручніший для ЖКГ — немає комісії для фізосіб), ЮKassa або еквайринг банку (якщо КК уклала договір напряму). Формуємо PaymentOrder з реквізитами отримувача: ІПН, КПП, МФО, рахунок КК, призначення платежу з особовим рахунком.

При пакетній оплаті кількох послуг — кожна йде окремим платежем, тому що в різних служб різні реквізити. Візуально це один флоу для користувача, технічно — кілька послідовних POST /payments. Скасування одного не повинно відкочувати вже проведені.

На Android кнопка Google Pay через PaymentsClient з com.google.android.gms:play-services-wallet. На iOS — PKPaymentRequest через PassKit. Обидва варіанти вимагають Merchant ID та договору з еквайєром. СБП в 3 рази швидше впроваджується, ніж класичний еквайринг.

Автоплатежі та сповіщення про заборгованість

Автоплатежі налаштовуються через регулярні платежі за розкладом. Користувач вказує суму та день списання, система автоматично перевіряє нарахування та ініціює оплату через СБП або картку. При нестачі коштів — push-сповіщення про необхідність поповнити картку. Сповіщення про заборгованість налаштовуються через Firebase Cloud Messaging або APNs. Система надсилає пуш, коли баланс стає від'ємним або наближається термін оплати.

Як влаштований процес розробки та тестування?

Ми йдемо від аудиту джерел до деплою. Процес включає наступні кроки:

1. Аудит доступних джерел даних КК (ГІС ЖКГ, білінг, агрегатор).
2. Проектування моделі даних з можливістю додавання нових постачальників.
3. Розробка екранів: особові рахунки, передача показань, оплата.
4. Інтеграція платіжного шлюзу (СБП, еквайринг).
5. Налаштування push-сповіщень та історії платежів.
6. Тестування на реальних даних з імітацією граничних випадків (подвійна оплата, збій шлюзу).
7. Деплой в App Store та Google Play.
8. Документація та навчання оператора.

Час відповіді API білінгу зазвичай 200-500 мс, що дозволяє оплачувати рахунки за 2-3 секунди. Економія на комісіях при переході на СБП може становити до 300 000 грн на рік для КК з оборотом 15 млн грн.

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

• Аналіз доступних джерел даних КК (ГІС ЖКГ, білінг, агрегатор)
• Інтеграція та тестування платіжного шлюзу
• Розробка екрану особових рахунків, передачі показань, пакетної оплати — весь функціонал білінгу ЖКГ у мобільному додатку
• Налаштування push-сповіщень та історії платежів
• Завантаження в App Store та Google Play (сертифікати, згоди)
• Документація API та інструкція для оператора
• Навчання команди замовника (2–3 години)
• Гарантійна підтримка 12 місяців

Етапи та терміни

4–6 тижнів для MVP з однією КК. 8–12 тижнів для додатку з підтримкою кількох КК через агрегатор, передачею показань та пакетною оплатою. Вартість розраховується індивідуально після аналізу вимог.

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

Платежі в мобільних додатках: 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 місяці.

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