Descriptor and refund policy playbook

Why do these two artefacts matter so much?

A dispute usually starts as one of two sentences: "I do not recognise this charge" or "I could not get my money back". The descriptor answers the first, the refund policy answers the second. Fixing both costs an afternoon and prevents more disputes than any post-sale tooling.

How should a descriptor read?

The descriptor should be the name the customer believes they bought from, plus a way to reach you. Not the holding company, not an internal abbreviation, not a code.

• Good: the brand name as shown at checkout, plus a support number or short URL.
• Bad: a legal entity the customer has never seen.
• Bad: an abbreviation that is unreadable on a statement line.
• Always: run a live test charge and read it on a real statement before launch.

What makes a refund policy survive review?

Four elements, in plain language, linked at checkout: window, condition, method, response time. Anything conditional or discretionary should be stated as a rule, not left to interpretation.

• Window: a specific number of days from a defined start point.
• Condition: the state the item must be in.
• Method: exactly one step for the customer to start the request.
• Response time: when they hear back, and when the money returns.

What are the failure patterns?

These recur across almost every merchant who arrives with a dispute problem.

• A no-refund policy, which converts every refund request into a chargeback.
• Refunds routed through a form nobody monitors.
• A policy that exists but is not linked at checkout.
• Subscription renewals with no reminder before the charge.
• A support channel slower than the customer's bank.

How do you tell whether it worked?

Watch the mix, not just the count. When descriptor and refund issues are fixed, unrecognised-charge and service-not-provided disputes drop first, and what remains is genuine product or delivery complaints — which you then fix operationally rather than in copy.