Utility Bills Payment Mobile App Development
Utility bill payment app — not "form + pay button." It's integration with housing utility billing systems or property management company systems, getting current charges by account, checking debt and meter readings submission. While user wants to pay multiple utilities at once, bank wants correctly formatted payment order with proper requisites.
Integration with Data Sources
Main complexity — heterogeneous sources. Management companies work via different systems: 1C:Zhkh, Mercury, RCC (settlement and cash center) or custom billing. Each has own API scheme — from SOAP services to REST with JWT. Some companies still provide data only in XML from 2000s.
Practically: without direct contract with company, connect via aggregators — SMEV (Inter-agency Electronic Exchange System) or paid intermediaries like FinTech Hub, Free Housing Utility API, EPS (Unified Payment System). Aggregator normalizes data from different companies into single format — saves month of adapter development.
// Request charges by account number
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 // "Cold water supply"
let amount: Decimal
let debt: Decimal
let meterValue: Double? // current readings
}
Meter Readings Submission
Separate scenario often complicating app. User enters readings — sent to billing via PUT /meters/{meterId}/readings. Problem: billing accepts readings only in certain period (e.g., 15-25th). Outside period — error 403 READINGS_NOT_ACCEPTED_NOW. Must explicitly show this in UI, not "Unknown error."
Also nuance: readings must be greater than previous. Client validation doesn't replace server but saves requests — immediately block input of lower value with hint.
Payment Part
For payment use SBP (most convenient for utilities — no commission for individuals), YooKassa or bank acquiring (if company signed contract). Form PaymentOrder with recipient requisites: INN, KPP, BIC, company account, payment description with account number.
For batch payment multiple utilities — each goes as separate payment, because different services have different requisites. Visually one flow for user, technically — several sequential POST /payments. Cancelling one shouldn't roll back completed ones.
Android button Google Pay via PaymentsClient from com.google.android.gms:play-services-wallet. iOS — PKPaymentRequest via PassKit. Both require Merchant ID and acquiring agreement.
Notifications and History
Push via FCM/APNs: new charges (come beginning of month), debt reminder, payment confirmation. Payment history stored locally in Core Data / Room with server sync — user should see receipts offline.
Timeline and Stages
Audit available data sources from company → billing integration or aggregator → account screen → meter readings → payment flow → history and notifications → testing.
4–6 weeks for MVP with one company. 8–12 weeks for app supporting multiple companies via aggregator, meter readings and batch payments. Cost calculated individually after requirements analysis.