A refill, a cancellation and a partial order need different follow-up. Treating them as the same kind of refund request makes support harder and can lead to incorrect wallet adjustments. Start with the order record and the conditions of the service the customer purchased.
What a refill request means
A refill asks for an eligible service to be replenished under its refill conditions. It is not a new purchase and does not mean the customer receives money back. Availability depends on the service, its stated conditions and the upstream provider’s support.
Check the original order date, service description and provider response. A refill button is a way to request action; it is not proof that replenishment has finished. Avoid promising a completion time that the provider has not confirmed.
Check eligibility before requesting another refill
- Confirm that the purchased service includes refill support.
- Check its applicable period and other conditions.
- Review any existing refill request and its current status.
- Keep the original order ID and provider reference attached to the investigation.
If the service no longer appears in your current catalog, use the original order details rather than assuming today’s replacement service has the same conditions.
A cancellation request is not a confirmed cancellation
Some services support cancellation requests through their provider API. Whether an order can be stopped depends on the service and its current processing state. Sending the request does not establish that delivery stopped or that a refund is due.
Check the provider’s response and subsequent status updates. Tell the customer whether the request is pending or confirmed. Do not resend the purchase to another provider while the first order might still be active.
How to investigate a partial order
A partial status indicates that only part of the requested quantity was fulfilled according to the order record. Review the remaining quantity and the recorded charge or refund before making a manual adjustment.
For illustration, an order for 1,000 units might report 300 remaining. That suggests 700 were fulfilled, but the financial adjustment must follow the actual service pricing and recorded transaction. Do not calculate a refund from a screenshot alone, especially for fixed-price packages or services with different billing units.
Keep wallet adjustments traceable
Before crediting a customer, check whether an automatic adjustment already exists. Compare the customer order, upstream order and wallet history. A provider refund and a customer refund are separate records and may require reconciliation.
When a manual correction is necessary, record the reason and the related order ID. This gives another administrator a clear explanation and prevents the same ticket being credited twice.
Write useful service descriptions and support replies
State refill and cancellation conditions where customers choose a service. In a ticket reply, explain the current order status, what you have requested and what still needs confirmation. “Request submitted” is more useful than saying an unresolved order is fixed.
Check the provider connection guide if statuses are not updating, or read about drip-feed orders when the purchase contains scheduled runs.
