When a customer says “I have paid” but a request still shows pending, the next useful action is to check the original payment. Sending a second request immediately can create confusion about which reference the customer should follow and whether the first attempt will still settle.
Use Payments to establish what was requested and what the platform has recorded. Then compare the related order or service record. A customer message, an order status and a payment-provider outcome are different pieces of evidence.
Gather the information you need
The reviewer needs permission to view Payments and access to the associated order or customer request. Changing money records or issuing refunds requires separate authority. This guide is a checking routine; it does not require making a new collection or refund.
Retain the payment reference, amount, currency, request time and related order or record reference. Ask the customer privately for a provider transaction reference if needed. Do not request their mobile-money PIN, account password or unrelated financial information. Keep examples and screenshots used in team training free of real customer details.
Agree who owns unresolved payments. A named reviewer prevents sales, support and accounts from each sending a new payment request for the same issue.
Find the original request
- Open Payments and select Waiting to review open requests. This includes draft, pending and authorised payments, so open the individual row to understand its state.
- Search using Reference or provider id. Use the reference already associated with the customer request rather than guessing from the amount alone.
- If it is absent, check All and Paid. A request may have settled since the previous review. Clear unnecessary filters before concluding that it is missing.
- Open the payment and compare the amount, payer and method with the details you retained. Read Last problem, when present.
- Read What happened. The timeline records events and their source, such as a provider callback or reconciliation. Use In the books to inspect the associated entries when you need to understand the recorded movement.
The interface lists recent records; a broad unfiltered list is not proof that an older reference never existed. Search for the exact known reference and ask the account's responsible operator to investigate if it still cannot be found.
Understand the state before acting
| State | What it tells the reviewer |
|---|---|
| Draft | The request is recorded but has not yet progressed to a provider payment attempt |
| Pending | Payment has been requested; settlement is not confirmed |
| Authorised | The provider has authorised or held funds, but the request has not reached paid |
| Paid | Settlement has been recorded |
| Failed | The attempt failed; inspect the recorded reason before deciding on another attempt |
| Expired or Cancelled | The request has ended; investigate any conflicting customer evidence before replacing it |
| Partly refunded or Refunded | Payment settled earlier and money has subsequently been recorded as returned |
The Paid view can include refunded payments. Read the current state and refunded amount before treating the full original amount as retained. A status label is more informative when read beside the timeline and reference.
Work through an uncertain payment
Suppose a customer was asked to pay TZS 40,000 for an order. The payment remains Pending after they report approving the request. The reviewer opens the original reference, confirms its amount and notes that no settlement event has arrived.
The reviewer replies privately: “We are checking the original payment reference. Please do not repeat the payment while we confirm its outcome.” They record the provider reference supplied by the customer and assign a follow-up check. This acknowledges uncertainty without claiming either that the money is lost or that the order is paid.
The platform has a background reconciliation process that checks eligible open payments with the provider. It is a recovery mechanism, not a promise that every pending request will settle within a fixed number of minutes. Reopen the payment to read any updated outcome; refreshing the page is not itself a manual provider-reconciliation command.
Compare the business record
After settlement is confirmed, open the related order or Data record and verify the intended next step. Check that you are using the exact reference when one customer has several orders of the same amount.
If the payment is paid but the order is still awaiting action, investigate the link and recorded processing outcome. Do not create another collection to repair a display or workflow mismatch. Customer payment history and the account's overall money summaries answer different questions; use the individual record for this check.
For failed, expired or conflicting outcomes, follow your payment provider's verified findings and your authorized business process before asking again. Preserve the original reference in any replacement request's investigation notes.
Escalate with useful evidence
Record the original reference, amount, time, current state, relevant timeline events and provider reference. Explain the discrepancy precisely: “Customer reports approval; no settlement recorded,” rather than “payments are broken.”
Use a support ticket when the check spans shifts. Keep its owner and next review visible. Read the broader customer-payment guide for the surrounding payment workflow.