Show the action in review
A refund reviewer needs the charge, amount and currency, as well as the requester and any business context required to decide. A ticket title or an agent-written explanation can help orientation, but the review must show the same values that will be used at execution. Make it easy to see which customer or account the charge belongs to.
Build the review from a validated, normalised request. Represent money in integer minor units and bind the currency explicitly. Define how optional fields and defaults become part of the reviewed action so the executor can reconstruct what the reviewer saw.
Give the approval a narrow lifetime
Record the approval against the request identifier and the exact resource, action and parameters. Include the approver, decision time and expiry. A reviewer’s authority should cover that type of action and that resource at the time the approval is validated.
Before execution, compare the incoming request with the approved request and recheck policy. If the agent changes the amount, obtain a new approval. If permissions change or the review expires during a wait, re-evaluate according to your policy rather than letting the stale approval through.
Design for retries
Approval answers whether an operation may run. Execution can still time out or report an ambiguous result. Keep a stable operation identifier and use the tool’s idempotency mechanism where available. If the downstream result is unknown, inspect or reconcile it before sending a fresh operation.
Test an edited refund after approval, two concurrent submissions, an expired approval and an unauthorised reviewer. For each, check the downstream tool and the decision record. The approval trace should show who reviewed what, while the execution trace should tell you whether the refund went through.
Decide what to do while waiting
A request may stay pending long enough for the underlying record to change. Store a correlation ID and show a clear pending state to the caller. When the reviewer responds, check that the charge still belongs to the same account and that it remains refundable. Define how the agent can cancel or replace an obsolete request, and keep the old decision in the trace.