Prepaid water top-up not credited? Check these states

Find out which part of the top-up is pending

When a resident says a prepaid water top-up has not arrived, first locate the existing attempt. The question may concern the payment, the intended meter, the credit-delivery process or the meter’s response. Starting another attempt before identifying the current state can make the investigation harder.

Use the provider’s approved support route and keep the payment reference, amount and meter identifier together. Do not ask the resident to share a wallet PIN, and do not treat a screenshot or an entry in a local demo as a verified provider response.

The four states to distinguish

A useful prepaid workflow shows what is known at each boundary. Payment accounting belongs to the payment process; acceptance of credit belongs to the meter or the approved vending integration.

Match the account, meter and existing request

Before investigating delivery, confirm the meter identity attached to the account and the request. Keep an asset serial separate from a communications identifier or a customer’s phone number. A replacement meter should have its own identity and an explicit relationship to the earlier record.

Do not assume all prepaid meters use the same delivery method. Token, keypad and connected-device arrangements depend on the installed model and the approved vendor integration. A device catalogue or a connectivity label is not proof that the installation is supported.

Missing acknowledgement is a state to investigate

If the integration expects acknowledgement and none has arrived, keep the credit outcome pending. Check the existing request and the available device evidence before creating another credit. An idempotent retry should refer to the same logical request rather than silently multiplying the value.

In a fictional WaterPesa example, the payment is confirmed and a token is prepared, but acknowledgement is missing. The example keeps credit pending and reconnection on hold. It does not create a usable token or communicate with real hardware.

Credit and reconnection are different decisions

Even when credit acceptance is known, service reconnection may be a separate controlled action. The relevant operator needs the organization’s service rules, permissions and equipment checks. Do not display a meter as reconnected merely because a wallet transaction succeeded.

Keep requests, acknowledgements and observations separate. An acknowledgement that a command was received is not the same thing as evidence of its physical result. Preserve the record of what was requested and what was actually observed.

A support handoff checklist

Give the next responsible team enough context to inspect the existing attempt without creating a new one. A clear response should tell the resident what is confirmed and what is still being checked.

• Original payment attempt, reference, amount and currency.
• Correct account and meter identity.
• Existing vending or credit-delivery request.
• Current acknowledgement or acceptance evidence, where the integration supports it.
• Separate service-state decision and responsible operator.
• A customer update that does not promise an unverified outcome.

Common questions