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

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

Если приложение продаёт цифровой контент или подписки — Apple и Google требуют использовать их платёжные системы. Обойти это нельзя: нарушение правил 3.1.1 App Store или Google Play Developer Policy приводит к удалению приложения. Физические товары и сервисы, оказываемые офлайн, — другая история.

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: платный (бесплатно до $2.5k MRR, дальше процент от дохода), не подходит для очень сложных flow с несколькими storefront-ами или кастомными bundle-ами. Однако для типового SaaS-приложения экономия на собственной разработке составляет $15–30 тыс. — интеграция окупается за 2 месяца.

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.

Стоимость рассчитывается индивидуально исходя из набора инструментов и сложности серверной логики. В среднем мы укладываемся в бюджет $5k–15k на типовую интеграцию, но экономия от предотвращения ошибок и churn окупает эти вложения за 2–3 месяца.

Получите консультацию по вашему проекту — свяжитесь с нами. Мы поможем выбрать оптимальную архитектуру платежей, которая пройдёт ревью сторов и не сломается при пиковых нагрузках.