Разработка мобильного приложения для ЖКХ — наша специализация. Такое мобильное приложение для управляющей компании позволяет автоматизировать сбор показаний, начисление и приём платежей. За 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 недель для приложения с поддержкой нескольких УК через агрегатор, передачей показаний и пакетной оплатой. Стоимость рассчитывается индивидуально после анализа требований.
Закажите разработку мобильного приложения для оплаты коммунальных услуг — свяжитесь с нами, мы подготовим коммерческое предложение в течение дня. Получите консультацию: заполните форму на сайте или позвоните нам.