Design an Electricity Bill Payment System for Millions of Customers

What happens when millions of customers try to pay their electricity bills on the last day of the month? The challenge isn't simply processing payments quickly. It's ensuring that every collected payment reaches the correct utility, every rupee is accounted for, and no customer is penalized because a legacy billing system is slow.

This system design explores a BBPS-style payment aggregator handling millions of transactions across thousands of utilities, each with different billing systems, processing limits, and integration capabilities.

What You'll Learn

• How to handle millions of bill payments during predictable end-of-month peaks.
• Why bill lookup must not become a prerequisite for payment.
• How idempotency prevents duplicate collection during retries.
• How per-utility queues, rate limits, and circuit breakers isolate legacy systems.
• How escrow, double-entry accounting, and three-way reconciliation protect customer funds.
• How autopay scheduling reduces peak load while preserving customer consent.
• How receipts and payment timestamps protect customers from late-fee disputes.

The Core Architecture

The platform separates customer payment collection from utility bill posting. Payment orchestration, bill presentment, channel adapters, durable queues, utility-specific adapters, a double-entry ledger, and reconciliation services work together to ensure that slow downstream systems do not interrupt customer payments.

The Most Important Design Decision

A payment becomes collected when the money has successfully entered the aggregator's collection flow. Utility posting and acknowledgement are tracked as separate lifecycle stages. This lets the system issue a receipt immediately while retaining responsibility for delivering the payment to the utility.

• Collection: Confirm the money movement and record the payment durably.
• Posting: Deliver the payment through a durable, utility-specific queue.
• Reconciliation: Match payment-provider records, aggregator ledgers, and utility acknowledgements.
• Resolution: Retry uncertain operations safely and refund payments that cannot be credited.

Key Takeaway

In a financial system, accepting a payment is only half the responsibility. The system must also prove where the money went, ensure the correct account receives credit, and resolve every discrepancy without silently losing a transaction.

Explore the complete system design for the APIs, database schema, payment lifecycle, per-utility backpressure, autopay scheduling, escrow settlement, and failure-recovery workflows.