How to use the Refund Request Generator.
A refund request should connect the purchase to the stated problem and relevant policy. Include only needed transaction details and distinguish the requested outcome from a guaranteed entitlement.
Make the workflow fit your task.
Identify the transaction and problem using the minimum necessary references. Explain the requested refund and any relevant supplied policy, separating apparent errors from confirmed findings. Provide supporting evidence without including full payment credentials.
- What you provide
- Purchase facts and actual seller policy.
- What you get
- Evidence-based refund request without invented entitlements.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Fictional order B42 has two posted USD 40 charges dated 3 September 2026, references TX1 and TX2. Customer believes only one purchase was made. Request investigation.
Completed example
Subject: Possible duplicate charge for order B42 Hello, my records show two posted USD 40 charges on 3 September 2026 for order B42, references TX1 and TX2. I believe I made one purchase. Could you investigate and refund any confirmed duplicate charge? I can provide the relevant transaction records through your secure support channel. Thank you.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Does requesting a refund establish that the merchant must grant it?
No. The outcome depends on the facts and applicable terms; write the request without inventing an entitlement.
Why does a duplicate-charge request need transaction references?
Similar amounts can belong to separate transactions or authorizations. References and dates help the recipient investigate the specific records.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑