How this works

Use this when support must translate a customer’s refund request into an exact payment action. AI reads the request and policy; payment records establish which charge exists, what has already been refunded and the remaining refundable balance.

This workflow covers digital charges rather than physical-item return inspection. Keep cancellation, service access changes and refunding money separate. A polite support answer is not proof that funds moved, and a repeated request must not produce a second refund.

Before you start

Prepare the inputs

support_request

Required

Ticket or email with stable ID

Confirm the requester is entitled to discuss the account; retain the original wording.

charge_history

Required

Processor export or authorized lookup

Include successful, pending and failed refunds, not only the original payment.

refund_policy

Required

Versioned decision rules

Record eligible products, time windows and exception handling.

Implementation, step by step

1. 01

   Resolve the account and charge

   • Match the request to the correct account using approved identity procedures. Retrieve candidate charges from the processor or timestamped local export.
   • Require an explicit charge ID before preparing a payment action. Similar amounts or customer names alone are insufficient when multiple purchases exist.

   Checkpoint: The refund packet refers to one verified account and charge.

2. 02

   Reconcile payment state

   • Check settlement, currency, charge amount, prior refunds, pending refund attempts and dispute status. Calculate the remaining refundable amount deterministically.
   • Distinguish a failed attempt from a pending outcome. Preserve processor transaction references so retries can be reconciled rather than repeated blindly.

   Checkpoint: The available balance and unresolved transactions are explicit.

3. 03

   Apply the approved policy

   • Compare purchase timing, service terms and the stated reason with the current policy. Separate eligibility facts from requested goodwill exceptions.
   • If the policy requires usage evidence, retrieve only relevant fields. Do not infer misuse, intent or customer credibility from writing style.

   Checkpoint: The recommendation identifies its policy basis and any exception owner.

4. 04

   Prepare the action packet

   • Specify charge ID, exact amount, currency, reason, policy version and approval status. Draft a customer response that accurately describes the current stage.
   • Bind any approval to that exact packet and a single-use request key. Changes to the amount or charge require renewed validation within existing authority.

   Checkpoint: A reviewer can approve a specific action without hidden parameters.

5. 05

   Execute only when authorized and verify

   • If the task authorizes the approved refund, refresh charge state and submit once with a stable idempotency key. Otherwise return the packet as a draft.
   • Read the processor receipt and report succeeded, pending or failed accurately. Reconcile unknown outcomes before retries; cancellation or access changes require their own scope.

   Checkpoint: The customer-facing status is backed by a processor record or remains pending.

Decisions along the way

What you will produce

Check the result

• Recalculate the refundable balance including partial refunds.
• Check approval matches the exact charge, currency and amount.
• Ensure pending outcomes never appear as completed refunds.

When something goes wrong

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Run a small pilot

Keep the scope clear

• Payment actions require existing explicit authorization for the account and amount.
• A refund does not automatically cancel the subscription or revoke access.