Bulk-refund orders by date range or reason

Refunding a batch of orders by hand is slow and error-prone in the worst possible way: it is money, and a fat-fingered amount does not come back. The times you need it are usually the tense ones, a botched fulfillment run or a pricing mistake that shipped, when you want to move fast and be exactly right at the same time. This recipe keeps the agent on the reading and the arithmetic and keeps every dollar of the deciding with you.

I need to refund a batch of orders and I want to approve every one before any
money moves. Refunds are not reversible, so go slowly.

First pass, change nothing. Find the orders matching [placed between 3 and 5
March with status processing] (or [orders where a note mentions the wrong-size
batch]). Read each one and build me a table: order number, customer, order
total, how much is already refunded, what you propose to refund, and the reason.
Do not issue anything yet.

I will go down that table and tell you which ones to refund and for how much.
Only the ones I approve, and only for the amount I confirm. Then issue them in
batches of [5], and after each batch show me what you just refunded and the
running total before you continue. Add a note to every order you refund saying
the amount and the reason. When you are done, give me the full list of refunded
orders and the total refunded.

If any amount you are about to issue does not match what I approved, stop and
ask me instead of guessing.

Why this is safe to run

The plan is built entirely from reads. Listing the candidate orders and reading each one for its total and existing refunds changes nothing, so you see the full itemized plan, order by order and amount by amount, before a single refund is created. Nothing is refunded until you approve it.

The refund itself is the one write that actually moves money, so it carries the strongest gate in this cookbook: explicit per-order approval, small batches, and a pause after each batch to show you the running total before more goes out. Every refund is capped at what you confirmed, each one leaves a note on its order recording the amount and reason, and the refund ability stays off until you switch it on for a run you are watching. And because a refund is not reversible, the design leans on stopping early rather than fixing after: if an amount does not match what you approved, the agent halts and asks. On top of all that, every call is checked against the capability of the user you bound the agent to and lands in the Activity Log.

One thing this recipe does not do: it cannot email the customer. There is no email-send ability here. If you want to tell a customer their refund went through, ask the agent to draft the message and you send it from wherever you normally reach them. The note it adds lives on the order, and you can mark it customer-facing so it shows in the customer’s account, but that is a note, not an email.

Already connected? You do not have to paste this. Ask your agent for the “bulk-refund by date or reason” recipe, or describe the batch, and it runs the same read-first, approve-each, batch-and-note flow on your own store.