Refund Operations: Controls, the Chargeback Double-Pay Trap, and Refund Fraud

Most teams treat a refund as a support outcome — a button an agent clicks to make a customer happy. Operationally it is a money-movement control problem, and the failure modes are expensive: duplicate refunds, chargeback double-pays, refund fraud, failed refunds to dead credentials, misrouted refunds on rails with no refund primitive at all, and reconciliation breaks that surface at month-end. A refund moves real money back out of the business, usually across the boundaries of three or four teams — support, payments, risk, and finance — and the losses happen in the seams between them. It also does not behave the same way twice: a card refund, a wallet refund, and an account-to-account refund are different money movements wearing one name. This runbook is the operator's control stack for refunds across those rails — how to issue them without paying twice, getting defrauded, misrouting them, or breaking the books. For the upstream mechanics of which instrument to use — void, reverse, or refund — see the authorization, capture, and settlement lifecycle.

What refund operations covers

Refund operations is the set of controls around the full lifecycle of a credit back to a customer: eligibility, approval (who can issue a refund, up to what value, with what second sign-off), the rail and destination (back to the original payment method and, where the rail requires it, freshly re-verified), full vs partial amounts, timing, what happens when a refund fails, how it reconciles against the original charge, and the abuse controls that stop refunds from being exploited. That picture holds reasonably well on card rails. On wallet, account-to-account, and alternative payment method rails, the rail, the destination, and what "fails" even means work differently enough to need their own treatment, covered below. None of it is hard in the happy path — all of the cost is in the edges.

Refund vs void vs reversal vs chargeback

The first control is choosing the right instrument, because they have very different costs. A void and an authorization reversal both cancel an uncaptured hold before settlement — no money has moved, so the cheapest correct action on a not-yet-captured order is to void it, not refund it. A refund returns funds already captured and settled: a new credit to the original card, on which your original processing fees are usually not returned. A chargeback is a forced reversal initiated by the cardholder's bank, carrying a fee and counting toward your dispute ratio. Operators routinely default to refunds when a void would have been free and instant, and they routinely let a refundable complaint escalate into a chargeback that costs several times more.

The instrument mechanics live in the lifecycle article above; what matters here is the operating rule — before capture, void or reverse; after capture, refund; and never let a complaint you would have refunded become a chargeback.

Refund paths across rails: card, wallet, A2A, and APM

Everything above describes the card-scheme picture, and it is the picture most refund tooling is built around. It is incomplete: the moment a customer can pay by wallet, bank transfer, or a local alternative payment method, "refund" stops being one mechanism and becomes a different money movement on every rail.

Card rails are the standardised case: a refund is a distinct, scheme-defined credit transaction linked back to the original authorization, routed through the same card network and, generally, the same acquirer that processed the sale.

Digital wallets sit close to cards when the wallet is a pass-through (Apple Pay, Google Pay) — the underlying card network still processes the credit — but diverge when the wallet is closed-loop: a refund credits an internal wallet balance rather than moving money through a card network at all, and cashing that balance out to a bank account is a separate, slower step for the customer.

Account-to-account (A2A) and instant-payment rails are the largest structural gap, and the one most refund tooling gets wrong. Card schemes give you a refund primitive: an operation the network recognises as linked to, and bounded by, the original sale. Most A2A and instant rails — SEPA Instant Credit Transfer in the eurozone, Faster Payments in the UK, PayTo on Australia's NPP — have no such thing. There is no refund message type. A "refund" on these rails is a brand-new credit transfer, initiated by you, in the opposite direction, carrying none of the network-level linkage, finality, or recourse a card refund carries: it debits your account and credits the customer's like any other payment you originate, rather than reversing anything at scheme level. It can be sent to the wrong or a closed account, it settles or fails on that rail's own timeline, and it will not appear linked to the original sale in reconciliation unless you build that linkage yourself. The SEPA R-transaction reference catalogues how many distinct reject, return, and recall codes exist on SEPA rails alone — evidence of how much more varied A2A failure handling is than the card world's narrow refund-decline vocabulary.

Alternative payment methods (APMs) — konbini payments, PromptPay, Boleto, and many local bank-transfer methods — often have no refund API at all. Stripe's documentation is direct about this: for payment methods "without native refund support," Stripe has to collect the customer's bank details out-of-band before it can push the money back, putting the refund into a requires_action state while it emails the customer for banking details — the no-native-refund problem made concrete in a major PSP's own product design.

Before promising a refund SLA, check what the rail actually supports. A card refund and an A2A "refund" are different money movements with different failure modes wearing the same name.

Instant-payment refund limitations

Card refunds inherit the scheme's dispute machinery as a backstop: if a refund goes wrong, a chargeback is still available. Instant and A2A rails offer no equivalent. UK Faster Payments is explicit: a payment cannot be recalled once it has reached the beneficiary's institution — the only path is a voluntary Credit Payment Recovery request the receiving bank is not obliged to honour. SEPA Instant Credit Transfer has a comparable construct in its "recall" R-transaction: the originating PSP can request a recall using published reason codes, but the beneficiary PSP's agreement is required — a request, not a forced reversal — and it fails outright if the funds have already left the beneficiary account.

This changes what "recourse" means:

• There is no chargeback path. If your reverse credit transfer is misdirected or delayed, you depend on the receiving institution's cooperation, not a dispute network.
• The refund is irrevocable once sent, exactly like the original sale was. A duplicate or mis-keyed refund transfer on an instant rail cannot be pulled back through the scheme — why idempotency and destination verification matter more here, not less (see the idempotency section below).
• Confirmation-of-payee-style checks reduce misdirection risk but don't eliminate it, and only apply where the rail supports them; not every corridor has an equivalent to Verification of Payee under the EU Instant Payments Regulation.

Do not promise A2A or instant-rail customers the same recourse as card customers. Verify the destination account before pushing a reverse transfer, treat it as a new, re-verified payment rather than a status change on the old one, and for high-return categories consider defaulting to a card or wallet payment method where a real refund primitive exists.

The chargeback double-pay trap

This is one of the most expensive refund failures, and it is almost always an operations problem, not a payments one. The trap: a cardholder disputes a transaction with their bank and, in parallel, asks you for a refund. Your support team — not seeing the open dispute — issues the refund. The dispute then settles as a chargeback. You have now paid the customer twice: once via the refund, once via the chargeback, plus the chargeback fee. It is common enough that operators should treat it as a control failure, not an edge case. It happens because support and the dispute team work from different queues, because refund status is not checked against dispute status, and because the timing of a refund can cross the timing of a dispute.

The controls are specific:

• Lock refunds on any transaction with an open dispute or inquiry. If a chargeback or a pre-dispute alert exists, a separate refund is the wrong action — the dispute process itself returns the funds.
• Sync the support and chargeback queues. Support agents must see dispute status before refunding; the dispute team must see refund status before representing.
• If a chargeback arrives after you already refunded, contest it with proof of the credit. Card rules provide for exactly this: the cardholder's claim is typically a "credit not processed" dispute, and the merchant may be able to rebut it by submitting evidence that the credit was already issued — the refund's date and amount — though the outcome depends on scheme rules, acquirer handling, timing, and evidence quality. Always represent a post-refund chargeback with that proof rather than accepting it outright.
• Deflect before you refund-and-dispute. Pre-dispute programs — Visa's Rapid Dispute Resolution and Order Insight, Mastercard's Ethoca Alerts and Consumer Clarity — let you resolve or deflect a complaint before it becomes a chargeback, and a refund issued at that stage is recorded against the dispute rather than alongside it. Branding for these programs shifts; verify current names and rules with your acquirer.

The economics also favor deflection: a chargeback costs far more than its face value once you add the fee and ratio impact, so an early refund is usually the cheaper outcome — provided it is issued before the dispute exists, not after.

Original-payment linkage and route enforcement

A refund should never be issued as a free-standing payment; it should be created as a child object of the original transaction, referencing the original charge, PaymentIntent, or transfer ID directly. Both major PSPs enforce this structurally: Stripe requires a refund to reference the original charge or PaymentIntent, and Adyen requires a payment to be captured before it can be refunded against that payment. That linkage is what makes deduplication, the double-pay check above, and cross-currency reconciliation possible — a refund with no pointer back to its origin is an unexplained debit that support, finance, and risk each have to re-investigate independently.

Linkage also decides the route: the refund should generally go back through the same PSP, acquirer, and card network that processed the original sale, not just the same payment method. For Visa specifically, this isn't just practice — it's the rule, with a defined escape ladder, not open merchant discretion. Visa's Core Rules open with a qualifier worth keeping intact: "To the extent possible, the Merchant must process a Credit Transaction" back to the same payment credential used on the original sale — a real requirement, but bounded by what's actually possible, not absolute.

When the original credential can't be credited, Visa allows exactly two fallback routes, each gated by its own conditions:

• A secondary payment credential — but only if one is available, a receipt or other proof of purchase exists, and either the trigger is unavailability — "The original Payment Credential is unavailable (account is closed, transferred, reported lost/stolen)" — or a credit authorization to the original credential was declined.
• Failing that, alternate means — cash, check, in-store credit, or a prepaid card — restricted to four triggers: "The Cardholder does not have a Transaction Receipt or other proof of purchase"; "The customer is not the original Cardholder and is returning a gift"; the cardholder claims the original prepaid card was discarded; or "The Authorization Request for a Credit Transaction to the original or secondary Payment Credential receives a Decline Response."

(None of this ladder applies to a Faster Refund delivery, which follows a separate Visa Direct process. The rule's own footnotes also carve out two narrower exemptions: the same-credential requirement does not apply to the Cardholder Loyalty Program, and does not apply to a Straight Through Processing Transaction.)

The operator payoff: a gift return from someone other than the original cardholder, a no-receipt return, and a discarded-prepaid-card claim aren't rule-bending workarounds — they're named, scheme-recognised routes to cash, check, or store credit. Refunding to a different card or issuing cash purely for convenience, with none of those conditions met, is not a permitted case and is exactly what weakens dispute evidence later. This is Visa's rule specifically — PaymentBrief could not check Mastercard's rulebook, so don't assume the same fallback structure applies there.

The same logic applies on A2A rails, where the reverse transfer should be initiated by the PSP that received the original payment, since it alone holds the mandate reference and transaction context needed to route it correctly.

This is a real problem for merchants running multiple PSPs — a primary and backup acquirer, or a different processor per region. Refunding a PSP-A sale through PSP B is not a refund; it's a fresh, unlinked payout with no record of the original sale. Route every refund through the PSP identified on the original transaction record, and send anything unresolvable to manual review.

The harder case is when the originating PSP is no longer available — offboarded, contract ended, or shut down. Before any migration completes, resolve open refund exposure first: archive the original transaction references (PSP transaction ID, network reference, IBAN and end-to-end ID for A2A) for every transaction still inside its refund window, and confirm contractually whether the outgoing PSP retains an obligation to process historical refunds afterward. Where it doesn't, the fallback is a manual, verified payout on an alternative rail — logged as an exception, since it won't carry the same dispute-evidence value as a same-route refund.

Refunds against dead and reissued credentials

A refund can fail for reasons that have nothing to do with the request itself — the destination credential no longer exists. What happens next depends entirely on the rail.

• Card, account still open. An expired or reissued card usually does not break the refund: the issuer resolves the credit to the account behind the card. The account being open is exactly what keeps this case off Visa's fallback ladder above — that ladder triggers only when the original credential is genuinely unavailable. As a matter of PSP behaviour, not scheme rule, Stripe describes it this way: "Refunds to expired or cancelled cards are handled by the customer's card issuer and, in most cases, credited to the customer's replacement card. If no replacement exists, the card issuer usually delivers the refund to the customer using an alternate method (for example, check or bank account deposit)."
• Card, account closed. With no account left to credit, the refund is rejected back to the PSP — this is one of Visa's own named unavailability triggers (account is closed, transferred, reported lost/stolen) for the secondary-credential fallback covered above. Adyen's webhook model has a specific state for this — funds "returned to Adyen" because the shopper's account is no longer valid — with guidance to confirm the shopper's account status before retrying rather than resubmitting blind; Adyen also performs refund authorization with the issuer and notes that even "When a refund authorization is declined, we still try to process the refund." Stripe surfaces the same outcome as a failed refund (expired_or_canceled_card, lost_or_stolen_card) and returns the funds to your balance, not the customer's.
• Tokenised and on-file cards. A PSP-side saved-card token can go stale the same way a raw PAN does. Network tokens — issued by the card networks rather than the PSP — are more resilient: because the network updates the token behind the scenes on reissue, a network-tokenised refund is more likely to resolve correctly without manual intervention than a PSP token pointing at a dead PAN.
• A2A and instant rails. There is no issuer-side auto-routing to fall back on. A reverse transfer to a closed or renamed bank account simply fails and returns to the sender, like any other misdirected payment on that rail.
• Wallets. A closed wallet account behaves like a closed bank account for a closed-loop wallet, or falls back to the funding instrument behind it for a pass-through wallet — reintroducing the card-refund failure modes one layer down.

The common operator discipline across all of these: never assume a submitted refund settled. Monitor the failure event on every rail you support (refund.failed and equivalent), and have a pre-built alternative-payout path ready — collecting new bank details, issuing a check, or crediting store credit as a last resort — rather than improvising one after a customer complains a second time.

Refund fraud and abuse controls

Refunds move money out, which makes them a fraud surface. The patterns:

• Duplicate-refund requests — the customer claims a refund never arrived and requests another; the control is matching against already-issued refunds, not re-issuing on assertion.
• Social-engineered support refunds — an attacker convinces an agent to refund a transaction they did not make, or to a changed payment method; the controls are original-instrument-only refunds and approval limits that escalate high-value or unusual refunds.
• Post-consumption refunds — refunding digital goods or services already consumed; gate refunds on usage/consumption state, not just on the purchase.
• Friendly fraud — the customer disputes or demands a refund on a legitimate purchase; this is the same population as first-party fraud chargebacks, and refund abuse and dispute abuse are the same problem viewed from two queues.
• Promo and referral interactions — refunds that unwind a purchase while keeping the promo credit, or that launder referral incentives; coordinate with promo and referral abuse controls.
• Marketplace collusion — buyer and seller colluding on refunds to extract platform funds (covered in the marketplace section below).

The unifying control is treating refunds like any other outbound payment: approval thresholds, segregation of duties (the agent who issues is not the only check on a large refund), velocity limits, and a logged reason and approver on every refund.

When a refund fails

Refunds fail, and the failure is often silent until the customer complains again. The common cases:

• Dead or reissued credentials — the destination card, account, or wallet no longer resolves the way it did at the time of sale; the specific failure mode and what the operator must do differs sharply by rail, covered in full above.
• Partial-refund mismatch — refunding more than the remaining refundable balance, or splitting a refund incorrectly, is rejected; cap every refund at the original amount and track the remaining balance in your own ledger, not just the PSP's.
• Processor or acquirer failure — a refund can fail on the rail like any payout; when it does, this becomes an outbound-money problem, so work the payout and disbursement failure runbook for the rail leg, then resume.
• Refund pending too long — a refund stuck in pending is the most common source of "I was refunded but I don't see the money" tickets. Stripe's own guidance is blunt: a successful refund typically takes five to ten business days to appear on the customer's statement, and if it fails after already showing pending, recovering funds to your balance "can take up to 30 days from the post date." Give the customer the honest answer — your system succeeding and the bank posting to a statement are two different events with an issuer-controlled gap you can't compress — and where the rail supports a trace reference (an ARN, STAN, or RRN on cards; an end-to-end ID on SEPA), hand it over so their own bank can look it up directly.
• The issuer-posting clock is not the end-to-end clock, and conflating them is what makes "I don't see it" tickets hard to answer well. Visa sets a hard deadline for the issuer's own step, measured from settlement: "An Issuer must post a Credit Transaction Receipt to a Cardholder's account within 5 calendar days from the Settlement date" outside the US; in the US Region, that tightens to 3 business days for credit cards and 1 business day for Visa Check Cards, "unless circumstances or account history warrant a delay". That clock starts after your PSP has already submitted the credit for settlement, and it covers only the issuer's posting step — it says nothing about how long the PSP or acquirer takes to get the credit to settlement in the first place, which is where Stripe's five-to-ten-business-day, end-to-end figure above actually lives. When a customer says "I don't see it," the honest diagnostic split is: has settlement happened yet (a PSP/acquirer question with no scheme-level deadline attached), and if it has, is the issuer still inside its own posting window.
• A distinct acquirer-side mechanism, not a refund path. Visa separately gives the acquirer a back-office window to correct its own inadvertently processed credit — 30 calendar days from the processing date (45 in the US Region for PIN-Authenticated Visa Debit). That's error correction for the acquirer's own mistake, not the customer-facing refund process this runbook otherwise covers, and not the void/reversal instrument defined earlier — worth knowing exists, not something support should reach for when a customer is waiting on a refund.

Whatever the failure, the rule is the same: detect it (do not assume a submitted refund settled), decide the alternative rail, and communicate honestly.

Marketplace and split refunds

On a marketplace or platform, a refund is not one money movement — it unwinds a split. A buyer refund has to claw back the seller's share (often by reversing the transfer), decide whether the platform's fee is also refunded, and handle the case where the seller's balance is now negative. That is its own operations problem, covered in the marketplace split-payment operations runbook; this runbook handles the single-merchant case. The cross-references that matter: a split refund can drive a seller into a negative balance (a recovery problem), and buyer–seller collusion on refunds is a marketplace-specific fraud surface. Decide refund allocation and seller-debit policy before you need them, not during the first dispute.

FX exposure and settlement timing on refunds

Two mechanical problems sit underneath every cross-currency or refund-heavy day.

FX on refunds. A cross-border card sale converts at the rate in force at the time of sale; the refund, issued days or weeks later, converts at whatever rate applies when it executes. The cardholder is normally refunded the original transaction-currency amount, so the customer doesn't carry the FX risk — you do, on the settlement-currency side, and the two legs won't net to zero. The gap has nothing to do with your FX markup pricing and everything to do with two conversions on two different days at two different rates; dynamic currency conversion adds a second layer on top. A2A and instant rails carry the same exposure with no scheme-level mechanism to true it up — the reverse transfer is simply converted at execution. Book the FX difference as its own deliberate ledger line rather than letting it distort the refund amount.

Negative settlement balances. A refund-heavy day — a mass recall, a promo unwind, a batch of goodwill refunds — can push outbound refunds above inbound captures, taking the net settlement position negative. Stripe funds refunds from your available balance and, if that balance can't cover them, holds card refunds as pending until it recovers, automatically debiting the linked bank account in some regions. Adyen shows the same mechanic at the individual-payment level: stacked partial refunds and chargebacks can leave a single payment's balance negative before it even touches the account-level balance. Neither is a bug — both are the acquirer protecting itself from paying out money it doesn't hold. Monitor available balance against the open refund queue, not just captures, and pre-fund ahead of any foreseeable high-refund event. To trace where a negative balance came from, the settlement file is the record of truth — see reading Stripe and Adyen settlement files.

Idempotency and ledger design for refunds

Idempotency: the single most dangerous retry. Refund requests are the one place in payment operations where a duplicate is not a nuisance — it is an unrecoverable cash loss. A duplicate charge can be disputed back by the customer's bank; a duplicate refund has no equivalent clawback, because you already voluntarily sent the money. Stripe's pattern is the reference: the client generates an idempotency key (a V4 UUID or equally high-entropy string), attaches it to the refund request, and Stripe caches the resulting status and body against that key for at least 24 hours — a retry with the same key returns the original result, and a retry with the same key but different parameters is rejected outright.

Design the key deliberately: derive it from the original transaction ID plus a request reference your own system controls, so a retried UI submission, a duplicate support-ticket action, or a replayed webhook naturally collides with the prior key and is deduplicated. Treat idempotency key, amount, and destination as a three-way check before a refund leaves your system, and make webhook consumers idempotent on the refund ID itself.

Ledger representation: partial refunds and over-refund prevention. Represent every refund as its own ledger entry linked to the original transaction ID, never as an edit to the original row. Maintain a running remaining refundable balance per transaction — original amount minus prior successful refunds. PSPs enforce a hard cap on their side (Stripe: total refunds can never exceed the original amount) — but that check happens after your own system has told a support agent the request was accepted, and isn't safe against two requests submitted concurrently. Do the remaining-balance check, and decrement it atomically, in your own ledger before the request reaches the PSP — this is also what prevents the accumulation problem across multiple legitimate partial refunds issued by different agents over time, keeping each visible rather than collapsed into a single "refunded" boolean.

Reconciliation controls

A refund that is not reconciled is a loss you will find at month-end, if at all. Every refund must carry, and be matched on, a small set of keys: the refund ID, the original transaction ID it credits, the order ID, and the dispute/chargeback ID if one exists — so a refund and a chargeback for the same sale are visibly linked rather than double-counted. Partial refunds must reconcile to the running remaining balance, not the original amount. Cross-currency refunds will not match the original charge to the cent because the FX rate moved between charge and credit; reconcile on the transaction linkage and the original-currency amount, and book the FX difference deliberately. On A2A and instant rails there is no scheme-issued refund ID, so the linkage between the reverse transfer and the original payment (end-to-end ID, mandate reference, or your own internal reference) has to be created and preserved by your own system. Match every refund to its settlement batch before the accounting close. When the books and the processor disagree, work the PSP reconciliation failure runbook with the refund and dispute dimensions added to the match key.

The refund control table

Operator readiness checklist

• Refund eligibility and policy documented; the refundable window and conditions are explicit.
• Approval limits and segregation of duties: who can refund, up to what value, with what second sign-off.
• Refunds are idempotent — the key is deterministic, not random per click — and capped at the original amount in your own ledger, not just at the PSP.
• Original-instrument-only refunds, routed through the PSP that processed the original sale, with a documented fallback for when that PSP is offboarded.
• Refund routing is rail-aware: card and wallet refunds use the scheme's refund primitive; A2A and instant-rail "refunds" are a fresh, re-verified transfer with no assumed chargeback recourse.
• Dead-credential handling defined per rail, with the alternative payout each failure triggers.
• Refunds locked on any transaction with an open dispute or pre-dispute alert.
• Support and chargeback queues synced; refund status and dispute status visible to both.
• Post-refund chargebacks represented with the credit's date and amount.
• Refund-failure handling: detect, choose an alternative rail, collect new details, communicate honestly with a trace reference where available.
• Reconciliation match keys: refund ID + original transaction + order + dispute ID + settlement batch, plus an equivalent linkage key on rails that issue none; FX booked deliberately.
• Negative settlement balance from refund-heavy days monitored against the open refund queue, with a funding buffer for known events.
• Refund abuse controls: usage checks, velocity limits, a logged reason and approver on every refund.

What this runbook does not cover

It does not cover the instrument mechanics of void vs reversal vs refund (the lifecycle article above), the marketplace split-refund accounting (the marketplace runbook above), contesting the substance of a dispute on its merits (the chargeback representment guide), or the scheme-by-scheme catalogue of A2A return and recall reason codes (the SEPA R-transaction reference). It is the operations layer that sits across all of those and across rails: how to issue refunds — card, wallet, A2A, or APM — at scale without paying twice, getting defrauded, misrouting them, or breaking the books.