Fetch the bill. Pay the bill. Keep the reference.

The rule that shapes every BBPS payment: the bill is fetched from the biller before payment starts. The customer enters the identifier the biller uses (a consumer number, a policy number, a loan account), the biller returns what's due, and only then does the customer pay.

For prepaid services, such as recharges, there's no bill to fetch in the usual sense; the Directions say the customer's relationship with the biller is validated through the platform instead. Either way, the customer pays against something the biller has confirmed, which is what makes a wrong-account payment rare.

The Directions define a bill broadly: any notice for payment raised by a biller, for recurring or one-off payments, including notices for recharging prepaid services. Billers can be companies, government departments, public sector undertakings and even individuals, connected through a biller operating unit.

In practice that covers utilities such as electricity, water and gas, telecom and broadband, and categories like insurance premiums and loan repayments. The live list of categories and billers is maintained by NBBL and changes over time, so check it rather than relying on any fixed list, including ours.

Customers come back to a bill payment app for one reason: it remembers their bills and tells them what's due. The fetch step that BBPS requires is also what makes that possible. The app can check a saved biller for a new bill and remind the customer before the due date, instead of waiting for them to remember.

Show the customer what the biller sent back (the name on the account, the amount and the due date) before they pay, and show any convenience fee on the same screen as the pay button. Most bill payment complaints start with a customer who paid the wrong bill or was surprised by a fee.

For a biller, BBPS is reach. A biller connects through a biller operating unit, directly or through a biller aggregator, and becomes payable from customer operating units across the network. RBI's Directions require those units to give their customers access to all billers onboarded on BBPS.

In return the biller has to answer fetch requests reliably and confirm payments promptly. A biller whose fetch is slow or often fails is one whose customers pay late, and then call.

A bill payment in your app has more states than a simple payment, because two different things can go wrong: the fetch and the payment. Model them separately. A fetched bill that the customer hasn't paid is not a failed payment, and a payment whose confirmation is late is not a failed one either.

Store the BBPS reference the moment it exists and never create a second payment for the same bill while one is unconfirmed. When the customer comes back asking, the reference is how everyone finds the same payment.

The fetched bill is the biller's view of what's due, and it's the safest amount to pay. But customers do ask to pay more, less or early, and the answer isn't yours to decide. Whether a biller accepts a different amount from the fetched bill, or a payment after the due date, is set by the biller and shows up in how its bills are presented.

Design for the common cases: pay the full fetched amount by default, make any editable amount clearly the customer's choice, and warn when a bill is past its due date, since the biller may add charges your app can't see.