Розробка мобільного додатку для ЖКГ — наша спеціалізація. Такий додаток для керуючої компанії дозволяє автоматизувати збір показань, нарахування та прийом платежів. За 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? // поточні показання } | Джерело | Складність інтеграції | Час на адаптацію | Вартість (місяць) |
|---|---|---|---|
| Прямий API КК | Висока (індивідуальна схема) | 2–4 тижні | Немає абонплати |
| Агрегатор | Низька (єдиний REST) | 1–2 тижні | 10 000 – 30 000 грн |
Як вирішується проблема передачі показань лічильників?
Користувач вводить показання — вони йдуть у білінг через 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 рази швидше впроваджується, ніж класичний еквайринг.
| Спосіб оплати | Комісія для користувача | Швидкість впровадження | Вимоги до провайдера |
|---|---|---|---|
| СБП | 0% | 1–2 дні | Будь-який банк з СБП |
| Банківська картка | 0–2% | 2–4 тижні | Договір з еквайєром |
Автоплатежі та сповіщення про заборгованість
Автоплатежі налаштовуються через регулярні платежі за розкладом. Користувач вказує суму та день списання, система автоматично перевіряє нарахування та ініціює оплату через СБП або картку. При нестачі коштів — push-сповіщення про необхідність поповнити картку. Сповіщення про заборгованість налаштовуються через Firebase Cloud Messaging або APNs. Система надсилає пуш, коли баланс стає від'ємним або наближається термін оплати.
Як влаштований процес розробки та тестування?
Ми йдемо від аудиту джерел до деплою. Процес включає наступні кроки:
- Аудит доступних джерел даних КК (ГІС ЖКГ, білінг, агрегатор).
- Проектування моделі даних з можливістю додавання нових постачальників.
- Розробка екранів: особові рахунки, передача показань, оплата.
- Інтеграція платіжного шлюзу (СБП, еквайринг).
- Налаштування push-сповіщень та історії платежів.
- Тестування на реальних даних з імітацією граничних випадків (подвійна оплата, збій шлюзу).
- Деплой в App Store та Google Play.
- Документація та навчання оператора.
Час відповіді API білінгу зазвичай 200-500 мс, що дозволяє оплачувати рахунки за 2-3 секунди. Економія на комісіях при переході на СБП може становити до 300 000 грн на рік для КК з оборотом 15 млн грн.
Що входить у роботу
- Аналіз доступних джерел даних КК (ГІС ЖКГ, білінг, агрегатор)
- Інтеграція та тестування платіжного шлюзу
- Розробка екрану особових рахунків, передачі показань, пакетної оплати — весь функціонал білінгу ЖКГ у мобільному додатку
- Налаштування push-сповіщень та історії платежів
- Завантаження в App Store та Google Play (сертифікати, згоди)
- Документація API та інструкція для оператора
- Навчання команди замовника (2–3 години)
- Гарантійна підтримка 12 місяців
Етапи та терміни
4–6 тижнів для MVP з однією КК. 8–12 тижнів для додатку з підтримкою кількох КК через агрегатор, передачею показань та пакетною оплатою. Вартість розраховується індивідуально після аналізу вимог.
Замовте розробку мобільного додатку для оплати комунальних послуг — зв'яжіться з нами, ми підготуємо комерційну пропозицію протягом дня. Отримайте консультацію: заповніть форму на сайті або зателефонуйте нам.