A customer pays for electricity and receives no usable token. Your payment provider reports success, the vending partner returned an unclear response and support asks the customer to try again. A second payment may create a second problem without resolving the first.
For South African prepaid platforms, property operators and service providers, the software opportunity is to connect the evidence across this journey. The application must distinguish money received, a token issued, a token delivered and whatever meter outcome is actually known. One transaction status cannot honestly represent all four.
Start with the system boundary
Eskom's prepayment-operation overview describes token-based prepayment and customer entry into a meter. The STS Association's supply-group guidance explains that a token generated within the described system functions in the meter for which it was generated. These are reasons to make meter identity and authorised vending integration central to the product.
A custom application should use the authorised vending provider and the applicable arrangements for the operation. It should not generate substitute tokens, manipulate metering security or claim that a normal application integration can override a rejected token. Token creation and meter behaviour are not features to improvise around.
Write down which system is authoritative for payment, vending, meter details and customer communication. If your platform does not receive meter acceptance telemetry, state that limitation. Sending an SMS is evidence of a communication attempt, not evidence that a meter accepted credit.
Confirm the destination before taking the next step
An illustrative property-management flow begins with a tenant selecting a saved meter. The unit label looks familiar, but the property changed its meter during maintenance and the saved destination was never updated. A technically valid purchase against the old reference is still a customer-service failure.
Give meter records a lifecycle and an owner. Record when a mapping was verified, which unit or customer relationship it belongs to and whether it is active for purchases. When a replacement happens, retain historical purchases under the old meter rather than rewriting them to the new one.
Where the vending provider supports a validation or lookup step, integrate it according to the agreement. Display the confirmation information the customer is entitled to see. Avoid exposing another person's account details through an unrestricted meter-number search. The convenience feature needs an access boundary.
Keep payment and vending attempts separate
Create a purchase reference before initiating payment and link every later attempt to it. Record the provider's payment reference, the vending request reference and their independent outcomes. A payment webhook arriving twice should not create a second vending action.
When a vending request times out, investigate the original attempt through the provider's supported status or recovery mechanism. Do not assume that absence of a response means no token was issued. A retry policy needs to account for the provider's actual idempotency guarantees, not a developer's guess.
If vending ultimately fails, route the purchase to an explicit resolution process. Refund rules, reversal capabilities and customer communications must be agreed with the payment and vending partners. Do not label a case refunded until the relevant authoritative outcome supports that statement.
Support needs evidence rather than another purchase button
Eskom's common prepaid error guidance distinguishes examples such as a used token, a communication problem and an invalid or unauthenticated token. These categories show why a generic failure message is inadequate. They are provider guidance, not universal instructions for every meter model or supplier.
Let a customer report the displayed error and the purchase reference without posting the full token into an unrestricted chat. The support view should identify the relevant provider, meter reference, payment outcome, vending outcome and communication history. Restrict token visibility to the people and processes that need it.
A resend should resend the existing token through an approved channel, not silently vend another token. Record who requested the action and where it was delivered. If a customer changes a phone number during recovery, apply the agreed identity checks before redirecting a valuable token to the new destination.
Make unknown meter outcomes explicit
For a system without connected-meter feedback, the final known platform state may be token delivered. If the customer later reports successful entry, store that as customer-reported information. If an authorised provider supplies acceptance telemetry, preserve its source and timestamp separately.
This distinction improves both analytics and support. A dashboard that calls every issued token energy delivered can overstate what the platform knows. A support person should not have to explain an apparent contradiction between that dashboard and the customer's meter screen.
Keep troubleshooting within the authorised provider's guidance. Present the applicable help route and capture the case reference. The software should make escalation easier, not encourage staff to invent reset instructions for hardware they do not manage.
Test a complete uncertain purchase
The first integration pilot should include one payment provider, one vending provider and a representative customer channel. Test duplicate notifications, an ambiguous vending response, a failed message delivery and a support resend. Include a retired meter mapping and an attempt to view another customer's token.
At the end of each test, reconcile the purchase record against the provider evidence. Confirm that there is one intended commercial transaction and an explainable resolution. Export the investigation history so the operations team can use it without direct database access.
Measure unresolved paid purchases, time to identify the owning provider and repeat contacts for the same issue. These measures focus development on the experience that customers feel. A faster success screen is not useful if the support team still has to search three portals when the token does not arrive.
Use our integration statement-of-work guide to define partner responsibilities and software maintenance agreement guide for ongoing recovery ownership. TuniCyberLabs' custom software development can connect payment, vending and service operations. Discuss a prepaid-platform integration with the authorised providers, current customer channels and a redacted example of a paid purchase that required investigation.