Electricity meter verification API: confirm before paying
Build a meter verification step for Nigerian electricity payments, preserve the verified details and prevent changes between confirmation and purchase.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
A customer enters a meter number, sees a familiar name and taps Pay. Your application needs to preserve exactly what they confirmed. If the biller, meter number or meter type changes afterwards, that earlier verification should no longer authorize the purchase.
Build a verification record
Start with the electricity catalogue and select the intended distributor from the returned product attributes. Keep the product ID as a string. For the sandbox walkthrough, request /products/electricity without a distributor parameter and inspect the returned records rather than assuming the first record is the biller you need.
Send product_id, meter_number and meter_type to POST /purchases/verify, relative to the environment's API base URL. Verification uses the view_products scope. This is a verification request; the purchase is a separate operation with its own permission and customer authorization.
Read data.verified and the customer fields in data.customer. Require a true verification result before offering the final confirmation. Show the returned customer name, biller, meter number and meter type privately to the person making the payment. If details are missing or do not match what the customer expects, stop and let them correct the selection.
Tie confirmation to the selected target
| Change after verification | What your checkout should do |
|---|---|
| Customer corrects a meter digit | Verify the corrected meter |
| Customer chooses another distributor | Select the new product and verify again |
| Customer switches prepaid to postpaid | Verify the new type before proceeding |
| Customer changes the amount | Recheck the accepted range and confirm the new total |
| An old checkout is reopened | Refresh the selection and verification before a new submission |
Keep a server-side snapshot of the verified target and the customer's confirmation. At submission, compare the purchase fields with that snapshot. Do not trust hidden form fields to preserve the biller or meter type. Verification does not reserve a price, fund an account or guarantee that a later purchase will complete.
Test a mismatch deliberately
Use a sandbox key and the configured electricity fixtures from the sandbox reference. Test an edited meter after verification, an unavailable product and an unsuccessful verification response. A simulator response does not establish that a real customer's meter is valid.
For sandbox electricity purchases, leave out the optional phone number so the meter number selects the fixture outcome. Preserve the meter type established for the selected product and verified target. After a purchase starts, use its saved transaction identity to follow the result; rerunning verification is not a way to resolve an existing pending purchase.
Your release check should demonstrate that someone cannot verify one target and submit payment to another by changing the request in their browser.