BBPS: How Bharat Bill Payment Works

BBPS is an integrated bill payment system that connects billers, such as electricity distribution companies, telecom operators, gas companies and insurers, to the customers who pay them, through a network of agent institutions and customer facing apps. The central unit, NPCI Bharat BillPay Limited, sets the rules, certifies the participants, and operates the central switch that routes bill fetch and payment messages between the biller and the customer channel. A biller onboards through a biller operating unit, and a customer pays through a customer operating unit, which may be a bank app, a wallet app or a physical agent outlet. The BA must understand this three layer structure, because a requirement that confuses a biller operating unit with a customer operating unit will lead to the wrong integration design. Biller aggregators sit between the individual billers and the BBPS switch, and they simplify onboarding for smaller billers that cannot integrate directly. An aggregator collects bill data from many billers, normalises it into the BBPS message format, and presents it to the switch, and in the reverse direction it distributes payment confirmations back to the billers. For a large biller such as a state electricity board, a direct integration may make sense, but for a small municipal water supplier an aggregator is faster and cheaper. A BA documenting a BBPS integration must capture whether the biller connects directly or through an aggregator, the message formats, the bill fetch response time, and the reconciliation file that the aggregator sends at the end of the day. The choice affects the cost, the timeline and the support model. The customer journey for paying a bill through BBPS has a clear sequence that must be designed end to end. The customer selects the biller category, such as electricity, chooses the specific biller, enters the consumer number, and the system fetches the bill from the biller in real time, showing the amount due, the due date and any late fee. The customer confirms the amount, chooses a payment method such as UPI, debit card or wallet, authenticates, and receives a confirmation with a BBPS transaction reference and a receipt. If the bill fetch fails because the biller system is down, the customer must see a clear message and must not be allowed to pay an estimated amount. The BA should specify the timeout for the bill fetch, the retry logic, and the receipt fields, including the consumer number, the bill period and the reference number. Settlement in BBPS follows the payment rail chosen by the customer, and the biller receives the funds through its operating unit, usually on the same day or the next working day. The customer operating unit collects the payment, the central unit routes the confirmation to the biller, and the settlement is completed through the banking system, with a settlement file that lists every transaction by reference. Reconciliation is critical because a customer who has paid must never be marked as a defaulter by the biller. The biller reconciles the BBPS payment file against its own billing system, and any payment that appears in BBPS but not in the biller system becomes an exception that must be resolved within a defined time. The BA must define the settlement cycle, the file format and the exception ageing rule. What a BA documents for a BBPS integration is a complete pack, the biller onboarding checklist, the category and biller master data, the bill fetch and payment API specifications, the customer journey screens, the error codes and messages, the receipt format, the settlement and reconciliation reports, and the complaint handling flow for a payment that succeeded but was not updated by the biller. The pack should also include the limits, such as the maximum bill amount per transaction, and the support for part payments where the biller allows them. A real example is a customer paying a 1,850 rupee electricity bill for a BESCOM consumer number in Bengaluru through a bank app. The BA test cases must cover a successful payment, a bill fetch failure, a payment timeout with an unknown status, and a duplicate payment attempt, each with the expected customer message and the expected system state.