Auto-refund for double charge needs a stated arrival window

What it is

After two authorizations land on one order, the extra capture should auto-refund, and at detection people should be told: which capture stays, which returns, by when, to which account. The SLA is a checkable date or business-day window, not “we will refund.” Retry interaction should try not to let doubles happen; this is the refund clock after they have, not an idempotent button.

Why it happens

Once a double is on the statement, the loss is visible and anxiety follows the billing cycle. An auto-refund that lives only in an internal ticket sends people to bank disputes, which the merchant then pays for. Notice must include both rail retrieval ids so people can match the bank app. Arrival time varies by original-rail refund; a vague “7–15 days” that does not split merchant initiate from rail credit explodes in the vacuum after the merchant has already paid out. The promise must also say fulfillment of the valid order continues.

Studying it

Mint a double authorization. Compare: refund only in the back office, refunded with no notice, notice with both ids and an arrival window. Watch chargebacks and nudges.

Independent variables: automatic duplicate detection, notice fields, SLA split into merchant vs rail stages. Dependent variables: chargeback rate, in-window nudges, whether people can point to which capture remains.

Labs have no real statement date. A simulated statement list can ask people to mark the line that will disappear. Do not boast that auto-refund is “always”; measure detection, notice, and the clock, not an internal success rate.

Where it stops holding

Two captures that are legs of split tender are not a double; refunding would break a legal combo. Two captures under different merchant ids may be two orders; auto-refund needs a match rule (same intent / same amount / short window) and should miss to a human rather than refund the wrong one. When the rail cannot auto-void, the promise is “refund submitted + rail window,” not instant credit.

Applying it

• Recon jobs that see duplicate captures on one order auto-start refund and notify: kept order id, refund retrieval id, arrival window.
• Split the clock into “we initiated” and “rail credit”; overrun becomes a queryable exception.
• The valid order still fulfills; detail hangs the refund record beside it.
• Verify with a double-charge test: can the notice let someone mark, on a simulated statement, the line that will reverse and the latest date. “The system will handle it” with no date fails the promise.

Related

• Within the group: H7.13.1 Timeout is not failure; query first · H7.13.2 Released stock and coupons must return promptly · H7.13.3 Channel/order mismatch should read as processing
• Adjacent: H7.06 Payment failure · H7.07 Refunds and after-sales · H1.07 Preventing duplicate submit
• Search terms: duplicate capture · auto refund · double charge SLA