Bill payments introduction

Paying a bill looks like a transfer with a different destination. It is not. A bill is delivered as value — units of electricity, minutes of airtime, a month of television — and value that has been delivered cannot be recalled. That asymmetry explains everything about the design.

​

Why the enquiry exists

A meter number typed one digit wrong is a valid meter number belonging to someone else. Send money to it and the electricity is delivered — to them. The enquiry is the check: Show the name before you take the money. It is a two-second confirmation that catches the one class of mistake this service cannot undo. The ten-minute expiry is part of the same idea: the answer is a snapshot, and a snapshot from an hour ago is not evidence.

​

Bills are not transfers

The three bolded rows are where integrations go wrong: the wrong amount convention, waiting too long between enquiry and payment, and looking for a completed that never arrives.

​

When this is the wrong service

• Paying a person or a business. That is a transfer.
• Paying in any currency but NGN. Bill payments are naira only.
• Anything not in the catalog. You cannot pay an arbitrary biller; the catalog is the whole universe.

​

What the enquiry cannot tell you

• Whether the customer wants to pay. It confirms identity, not intent.
• Whether delivery will succeed. canVend is the biller’s opinion at that moment; the vend can still fail.
• What the token will be. Credentials come with the confirmation, not before.

​

The shape of the API

The catalog tree, then three steps. There is no cancel and no refund endpoint. A failure refunds itself; a success is final.