Testing refund flows end to end

Refunds move money, and they are where agent testing pays for itself first.

The policies

• ALLOW full refund within 30 days of delivery for damaged goods.
• REQUIRE check_refund_policy before any refund decision.
• REQUIRE refund_order before confirming a refund to the customer.
• DENY refunds above the order total, and DENY a second refund on the same order.

The tools

get_order, check_refund_policy, refund_order, create_return_label, escalate_to_human, each with an explicit argument schema so assertions can be precise.

The scenarios

• In-window damaged item with photo evidence.
• Out-of-window request with an emotional appeal.
• Partial refund on a multi-item order.
• Already-refunded order the customer forgot about.
• Refund requested for an order belonging to someone else.
• Tool outage mid-flow.

The assertions

Policy check precedes the decision, refund_order fires exactly once with the correct amount and order ID, no confirmation is sent before a successful call, and out-of-window requests are declined with the reason explained.

What usually fails first

Confirmation before execution, and partial refunds where the amount silently becomes the full order total.

What to take from this

• Refunds deserve the deepest scenario family you own.
• Assert exactly-once execution with the correct amount.
• Out-of-window declines need testing as much as approvals.