Разработка мобильного приложения для оплаты коммунальных услуг
Приложение для оплаты ЖКХ — это не «форма + кнопка оплатить». Это интеграция с ГИС ЖКХ или биллинговой системой управляющей компании, получение текущих начислений по лицевому счёту, проверка задолженности и передача показаний счётчиков. При этом пользователь хочет оплатить несколько услуг одним нажатием, а банк хочет получить правильно сформированный платёжный ордер с реквизитами.
Интеграция с источниками данных
Основная сложность — разнородность источников. Управляющие компании работают через разные системы: 1С:ЖКХ, Меркурий, РКЦ (расчётно-кассовый центр) или собственный биллинг. У каждого своя схема API — от SOAP-сервисов до REST с JWT. Часть УК до сих пор отдаёт данные только в XML с 2000-х схемами.
Практически: если нет прямого договора с УК, подключаемся через агрегаторов — СМЭВ (Система межведомственного электронного взаимодействия) или платных посредников типа Финтех Хаб, Бесплатный Сервис ЖКХ 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 недель для приложения с поддержкой нескольких УК через агрегатор, передачей показаний и пакетной оплатой. Стоимость рассчитывается индивидуально после анализа требований.