IKEDC electricity payment API integration

RizPay documents Ikeja Electric as IKEDC, while the catalogue returns Ikeja Electric in the distributor attribute. Keep the full biller name visible alongside that mapping in your own checkout, especially when users are choosing among electricity providers.

Design the checkout

Prepaid and postpaid selections have different receipt expectations. Preserve the meter type on the order and do not render a token box simply because the distributor is IKEDC. Wait for a successful prepaid result that actually includes a token.

Discover current products

Use a sandbox key with the view_products scope. Keep the key in a server environment variable. The request below reads the catalogue; it does not buy a service.

curl --fail-with-body --silent --show-error --max-time 20 \
  -H "Authorization: Bearer ${RIZPAY_API_KEY:?Set a sandbox API key}" \
  "https://my.rizpay.app/api/partners/sandbox/v1/products/electricity"

Read products from data and their details from attributes. Follow pagination.total_pages when you need the complete list. Select an actual returned ID, not a guessed or documentation-example ID. Catalogue availability can change: refresh an unavailable selection and let the customer choose again.

The electricity catalogue is returned unfiltered because it has no service-code filter. Read the distributor attribute on each returned product and select the one for the biller you are integrating before continuing.

Electricity uses the amount selected by the customer, within the product's accepted range. Show the requested amount and your own checkout fees before confirmation. Do not estimate a guaranteed unit allocation from a marketing page; keep any token or units from the completed transaction with the receipt.

Confirm the payment target

Before purchasing, POST to /purchases/verify with product_id, meter_number and meter_type. Continue only when data.verified is true and the customer confirms the returned details. A successful HTTP response alone is not the verification decision. Reverify if any payment-target field changes.

Prepare one purchase per order

The purchase request uses product_id, meter_number, meter_type, amount, external_reference. Enable the relevant purchase permission (purchase_electricity) and read_transactions for status checks. Confirm your key's permissions against the authentication reference when moving from sandbox to production.

This is the JSON body shape for a sandbox purchase. Replace every dollar-prefixed placeholder before sending it, using the product you selected and your stored order reference. Leave the optional phone number out of a sandbox electricity body: the sandbox picks its outcome from the first recipient field present, so a phone number would replace the meter number as the fixture selector. The meter type must be the one on the product you selected and on the customer's verified meter, because a mismatched meter type is forwarded to the biller rather than rejected. The recipient values below are sandbox fixtures, not real recipients. For variable-amount products, choose an amount within the selected product's limits.

{
  "product_id": "$RIZPAY_PRODUCT_ID",
  "meter_number": "11111111111",
  "meter_type": "$RIZPAY_SELECTED_METER_TYPE",
  "amount": "1000.00",
  "external_reference": "$RIZPAY_ORDER_REFERENCE"
}

Send the body to POST /api/partners/sandbox/v1/purchases. Generate and persist the reference once for the order, following the documented format. Do not make a new reference simply because a request timed out. Keep product selection, pricing and authorization on your server; a browser or mobile app must never contain the partner secret.

Follow the result

Persist data.id from an accepted purchase and inspect data.attributes.status. An accepted request can still be pending. Read the existing purchase with GET /purchases/:id and reconcile signed webhook events with your stored order. If the response was lost, look up the existing external reference before considering another purchase.

A DUPLICATE_REFERENCE response establishes that a reference has already been used; it does not prove fulfillment. Retrieve the existing transaction and check its status. Only successful is a completed purchase. Handle failed and reversed outcomes according to the returned transaction and your own ledger; do not issue a second refund because the same event arrives again.

What if the payment is successful but the prepaid token is missing?

Do not create a token or purchase again automatically. Retrieve the existing transaction and follow the support path with its reference. Your customer should see that the payment needs follow-up, without an invented recharge code.

Before accepting real orders

Test a successful purchase, an unresolved pending result and a failure. Confirm that a repeated submit cannot make a second local order and that the receipt reflects the final state. Use the sandbox's configured test recipients rather than arbitrary phone or meter numbers. Sandbox delivery is simulated and is not a measurement of live biller reliability.

Read the product reference, sandbox guide and pricing explanation before enabling production access.