Shopping Agents Need a Refund Status Vocabulary

A shopping assistant's explanation of a refund should reflect the state that the business can verify. A customer asking for money back, a merchant approving a request and a payment provider processing a refund are different events. If the assistant compresses them into one confident sentence, the customer may receive a promise that the underlying workflow has not fulfilled.

Stripe's refund documentation provides a useful payment-provider example: refunds can be partial, and a refund can remain pending or fail. It also distinguishes refunding a successful payment from canceling a payment that has not completed. These documented possibilities are the starting point for this article. The customer communication framework below is Aeris editorial analysis, not a universal description of every merchant or payment method.

Define words before automating replies

Start with the phrases currently used by customer support. Identify which underlying fact each phrase is intended to convey. Request received might mean that the merchant has captured the customer's request. Approved might refer to an internal decision. Submitted might describe a request accepted by a payment service. Each label should have a documented source and a clear limit on what it proves.

The labels do not need to be identical across every internal system. They do need a deliberate mapping to the customer-facing vocabulary. Ask the operational owner to review that mapping with the people who handle exceptions. Avoid wording that suggests money is already available to the customer when the evidence only establishes an earlier processing stage. If the evidence is incomplete, explain the pending step in plain language.

Keep the amount and scope attached

A refund may concern only part of an order or payment. Design the review so the assistant can distinguish the relevant items, the approved amount and the associated reference. The customer should not need to infer whether a message refers to the entire purchase. Use the currency and scope supported by the authoritative record, and route contradictions to a person who can investigate.

Consider a hypothetical order with several items and a request involving only one of them. A general message saying the order was refunded could create a different expectation from a message describing the approved partial amount. This example is an interface-design problem, not a claim about a particular merchant. Test whether an unfamiliar reviewer can identify what has changed and what remains unresolved.

Separate explanation from authority

An assistant that can explain a policy should not automatically gain authority to approve every request or move funds. Document which actions it may take, which decisions require an authorized reviewer and which provider responses count as evidence. Keep the explanation workflow useful even when the next step must be handed to a person. A clear handoff is preferable to an invented completion state.

The escalation record should contain the minimum context needed to continue the case through approved systems. Do not paste payment credentials or unnecessary personal information into general-purpose logs or messages. Give the receiving team a case reference, the unresolved question and the last verified state. The customer-facing reply can then describe who is reviewing the issue without exposing internal details.

Test the uncomfortable states

A useful review includes a pending case, a failed case, a partial amount and a disagreement between two records. Ask what the assistant would say in each situation and what evidence would allow that wording to change. Include a customer who returns later to ask for an update. The answer should be based on the current authorized record rather than a confident repetition of an earlier message.

Review the timing language as carefully as the status label. Use provider- and merchant-approved guidance for the relevant payment method. Do not let a generic template invent a deadline or treat an estimate as a guarantee. If a stated review time passes, the workflow should assign the unresolved case to an owner rather than simply producing another reassuring paragraph.

The next step

Choose one refund journey and write a short vocabulary with an evidence source for each term. Review representative exceptions with support and payment operations, then test the assistant's language against those cases. The objective is a reliable explanation of what is known, what remains pending and what happens next. Automation becomes more useful when its confidence follows the evidence.

Source reviewed September 21, 2026: Stripe Documentation, Refund and cancel payments. The proposed language review is Aeris editorial analysis. Merchant policies, applicable obligations and payment-method behavior need separate validation.