Розробка мобільного додатка для оплати комунальних послуг
Додаток для оплати ЖКХ — це не "форма + кнопка оплатити". Це інтеграція з ГІС ЖКХ або біллінговою системою управляючої компанії, отримання поточних нарахувань по лицевому рахунку, перевірка задолженості та передача показань лічильників. При цьому користувач хоче оплатити кілька послуг одним нажатням, а банк хоче отримати правильно сформований платіжний ордер з реквізитами.
Інтеграція з джерелами даних
Основна складність — різнорідність джерел. Управляючі компанії працюють через різні системи: 1С:ЖКХ, Меркурій, РКЦ (розрахунково-касовий центр) або власний біліліт. У кожного своя схема API — від SOAP-сервісів до REST з JWT. Деякі УК до сих пір відправляють дані тільки в XML з 2000-х схемами.
Практично: без прямого договору з УК підключаємось через агрегаторів — СМЕВ (Система міжвідомчої електронної взаємодії) або платних посередників типу FinTech Hub, Безплатний Сервіс ЖКХ API, EPS (Єдина платіжна система). Агрегатор нормалізує дані з різних УК у єдиний формат — економить місяць розробки адаптерів.
// Запрос нарахувань по лицевому рахунку
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 та договору з еквайером.
Сповіщення та історія
Push через FCM/APNs: нові нарахування (приходять на початку місяця), нагадування про задолженість, підтвердження оплати. Історія платежів зберігається локально у Core Data / Room з синхронізацією з сервером — користувач має бачити квитанції офлайн.
Етапи та сроки
Аудит доступних джерел даних УК → інтеграція з біллінгом або агрегатором → екран лицевих рахунків → передача показань → платіжний флоу → історія та сповіщення → тестування.
4–6 тижнів для MVP з однією УК. 8–12 тижнів для додатка з підтримкою кількох УК через агрегатор, передачею показань та пакетною оплатою. Вартість розраховується індивідуально після аналізу вимог.