Bharat Bill Payment System is the interoperable rail for recurring bill payments in India — electricity, gas, water, telecom, insurance premiums, loan instalments and a widening list beyond. For a product team it is attractive because it turns hundreds of separate biller integrations into one connection. The RBI issued revised directions governing it with effect from 1 April 2024, and understanding the role structure is the first step in deciding how, or whether, to participate.
The architecture has a centre and two kinds of edge. The Bharat Bill Pay Central Unit operates the system itself. Around it sit Bharat Bill Payment Operating Units, and a BBPOU functions in one of two capacities: a Biller Operating Unit, which onboards billers so their bills can be collected, or a Customer Operating Unit, which gives customers an interface to pay. Deciding which side you are on is a business question — are you bringing billers to the network, or bringing payers — and it determines your obligations entirely.
The requirement that decides participation for most companies is financial rather than technical. Non-bank BBPOUs must maintain an escrow account used exclusively for BBPS transactions, with the permitted credits and debits specified for both the customer-side and biller-side accounts. That is the same structural pattern as the payment aggregator framework: money that is not yours does not sit in your operating account. For a young product company it is usually the point at which building on top of an existing BBPOU becomes the sensible answer rather than becoming one.
Where you do build on top, the engineering shape is familiar to anyone who has integrated payments. Bill fetch, bill validation, payment initiation, confirmation, and a receipt carrying a transaction reference the customer can quote. The parts that need care are the ones where the network is asynchronous: a payment that succeeds at the biller and times out at your end, a fetch that returns stale amounts, a confirmation that arrives twice. As with UPI, treating an unknown outcome as a failure is the error that generates support tickets and duplicate payments.
Reconciliation deserves its own design rather than being inherited from your payments code. Bill payments settle on the network's cycle, and the customer's expectation is that their electricity connection is not disconnected — which is a materially higher stake than a failed retail purchase. That means a daily reconciliation between what you recorded, what the network settled and what the biller acknowledged, with a named owner and an alert when the three disagree, is not optional polish.
The commercial reading is that BBPS suits products where bill payment is a retention feature rather than a revenue line. Margins on the transactions themselves are thin. What it buys is a reason for a customer to open your application every month, and a picture of their obligations that can inform other products. If your business case depends on the payment margin alone, check the arithmetic carefully before committing to the integration work.
