Recover an electricity token without purchasing twice

An electricity customer may need help even after the purchase request was accepted. The receipt page should be able to recover the original purchase and display its token without sending another payment.

First confirm the meter type

A prepaid purchase and a postpaid payment have different outcomes. A postpaid payment should not promise a recharge token. Save the meter type with the order and use it when deciding which receipt fields to show.

For a successful prepaid purchase in production, the signed webhook is what carries the token, at data.object.token. The production transaction endpoints do not return it, so persist the token when the webhook arrives and serve the receipt from your own record. A sandbox transaction does return data.attributes.token, so a receipt page built only against the sandbox can look complete and still have nothing to show in production.

Recover the existing transaction

1. Load the customer's existing order after checking that they are authorized to view it.
2. Retrieve the stored RizPay transaction ID. If the create response was lost, look up the stored external reference.
3. Check the final status and meter type.
4. Display a persisted prepaid token only to the authorized customer.
5. Keep an unresolved or missing-token purchase in a follow-up state rather than submitting it again.

Do not derive or invent a token from a transaction reference. A retry should retrieve the original receipt; it should not create a second bill purchase.

Make the receipt usable

Preserve the exact token string delivered by the webhook. A copy action can help a customer move it to another device, but the page should still show the text clearly. Do not insert a token into a public URL, social share card, browser analytics event or searchable help page.

Let a customer return to their transaction history to retrieve the receipt. Protect that history with your application's authentication and authorization checks. Knowing a meter number or transaction ID should not grant access to someone else's token.

Separate purchase and meter problems

A successful purchase result does not tell your app why a physical meter rejects a token. Confirm the selected meter, distributor, meter type and stored token before escalating through the relevant support process. Avoid diagnosing a physical-meter problem from a single API response.

If the original order is still pending, show that its outcome is being checked. If it has been reversed, reconcile the money state before offering another purchase. A second payment should always be an explicit, separately confirmed order.

Test the support path

Test a valid prepaid success, a postpaid success, a pending purchase, a lost create response and a webhook that arrives before the receipt page loads. Also test an attempt to retrieve another customer's receipt. The technical goal is one purchase whose result remains recoverable.