Refund to a different payment method

How do we refund to a different payment method when the original card is closed, with the identity verified, the new method captured securely and approval before the money moves?

Treat a refund that cannot go back the way it came as a disbursement with controls. When a refund fails or the customer says the original card is closed, Callvu confirms the refund is due and that the original method is unusable (the issuer's response, the card's status, the time since the payment), verifies the customer's identity at the level a disbursement warrants (a code to the contact on file plus a check against the order's details, more for a large amount), captures the new method on a secure screen (a bank account, a different card in the customer's name, store credit where the customer chooses it) with the ownership checks the method allows, routes every such refund to the refunds desk in the Decision Desk with the verification and the amount, pays on approval, and writes the refund with its reason, the method and the approver to the order management system.

In scopeSimpleCallvu moves: chase and verify, decide, write back

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The refund went to a bank account the caller read out on the phone, and the real customer called a week later asking where their money was.

Today, without Callvu

Refunds normally go back to the original payment method, which is what the card networks require and what makes fraud hard. The exception is when the card is closed, the account is gone or the method cannot receive a refund. Then an agent takes new bank details over the phone, and the exception becomes the fraud path: a caller with an order number redirects a refund, and the real customer loses it.

The rules are clear: refunds go to the original method where it can receive them; a refund elsewhere needs the original to be confirmed unusable, the customer verified as the payer, the new method captured without the agent handling it and checked for ownership, and a second person's approval because it is money leaving to a new destination. The PCI standard and the fraud controls both point the same way.

A refund to a new method is rare, and it should be slow in exactly the places that stop fraud and fast everywhere else.

How it runs

From the requestto the system of record.

A refund to the original method fails with an issuer response that the card is closed, or a customer with a refund due reports the original method is gone. Callvu opens the exception on the refund.

Customer: Verifies identity, enters the new method on a secure screen, and receives the confirmation.
Refunds desk: Approves every refund to a new method in the Decision Desk.
Payment provider: Confirms the original method's status and pays out to the new one with the ownership checks.
Callvu: Confirms the exception, verifies, captures securely, routes, pays on approval and writes.

Confirm the exception
The refund's basis and amount are confirmed from the order (a return received, a cancellation, a dispute outcome), the original method is confirmed unusable (the issuer's response code on the failed refund, the card's status from the provider, the payment's age against the network's refund window), and a refund that could still go to the original method is sent there by rule instead.
Chase and verify identity
The customer is verified at the disbursement level: a one-time code to the contact on file from before the request, a check of the order's details only the payer knows, and for an amount above the threshold a document check; a changed contact in the days before the request is a flag; the customer completes the verification on a secure screen from a link.
Capture the new method and decide
The new method is entered by the customer on a secure screen (a bank account verified by a micro-deposit or an instant account verification showing the name, a different card in the customer's name checked by the provider, or store credit where the customer chooses it), never read to an agent; every refund to a new method goes to the refunds desk in the Decision Desk with the basis, the verification results, the flags and the amount and only the allowed outcomes (approve, approve as store credit, require a stronger verification, or decline with the reason and the alternative).
Pay and write back
On approval the refund is paid to the new method through the provider, the customer receives the confirmation at the contact on file (and the prior contact where it changed), and the refund with its reason, the verification, the method (tokenized) and the approver is written to the order management system, the system of record, against the order.

Where it ends: The refund left to a new destination only after the original was confirmed unusable, the payer verified, the method captured and checked without an agent, and a second person approved, with the whole record on the order. The Decision Trace shows the exception basis, the verification and the approval; the Audit Trace shows the capture (tokenized), the decision and the payment with time.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

PCI DSS: A new card's details are captured on the provider's secure page, tokenized and never seen by the agent or stored by the retailer; bank account details are captured on a secure screen with the provider's verification, keeping the retailer's agents and recordings out of scope and the account data protected under the standard's requirements for sensitive data.
Card network refund rules and the bank account verification rules (the Visa and Mastercard rules that refunds return to the original card where possible; NACHA account validation for new accounts receiving credits): The networks expect refunds to the original card and treat refunds elsewhere as an exception that must be justified; a credit to a new bank account follows NACHA's account validation expectation for the first entry, which the micro-deposit or instant verification satisfies.
Fraud and consumer protection controls (the FTC Act on reasonable security; the state consumer protection statutes on timely refunds; the retailer's disbursement policy): A refund that cannot go to the original method must still be made within a reasonable time, so the controls are proportionate to the amount; the disbursement policy sets the verification levels, the approval authority and the segregation between the person who verifies and the person who approves.

Company policies

A refund goes to the original method whenever it can; the exception needs proof the original is unusable.
The payer is verified at the disbursement level before any new method is captured; a recent contact change is a flag.
The new method is captured on a secure screen with ownership checks, never by an agent, and every such refund is approved by the desk.
The order management system holds the refund with its reason, the verification and the approver.

Controls

Exception confirmation with the original method's status.
Disbursement-level identity verification with change flags.
Secure capture with ownership verification.
Decision Desk approval on every case.
Provider payout and dual confirmation.
Order management write with tokenized method and approver.

Clocks and deadlines

Refund timing: The retailer's policy and the state's reasonable time from the refund's basis, with the customer told the status.
Verification validity: The code and the document check valid for the policy's window.
Bank account validation: The micro-deposit confirmation within its window, or instant verification at capture.

Documents and checks

The refund's basis and the original method's status
The verification results and flags
The new method (tokenized) and its ownership check
The desk's approval
The payment and the order management record

In the Decision Trace

The exception basis.
The verification results and the approval with the person.

In the Audit Trace

The failed original refund with time.
The verification and the capture (tokenized) with time.
The approval and the payment.

The handoff

Between the front doorand the back office.

The front door

A failed refund or the customer's report in any channel; the customer verifies and enters the method from a secure link.

The back office

The refunds desk approves every case; no agent handles the method.

The Decision Desk

Every refund to a new method goes to the refunds desk in the Decision Desk with the basis, the verification, the flags and the amount, and only approve, approve as store credit, require stronger verification, or decline with the reason and the alternative.

Proof

In scope.Proof at scale, not one process at a time.

The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.

More than 1,000 processes are live across Callvu customers.

Across Callvu customers

Questions

What buyers ask next,answered plainly.

When can a refund go to a different method?

Only when the original is confirmed unusable (a closed card, an issuer decline, a payment past the refund window); otherwise the refund goes back the way it came by rule.

How is the customer verified?

At the disbursement level: a code to the contact on file from before the request, a check of details only the payer knows, and a document check above the threshold; a recently changed contact is a flag.

Who approves?

The refunds desk, on every case, with the verification and the amount in view; the approver is recorded on the order.

Related processes

Returns and refunds Account recovery and takeover Chargeback and fraud dispute Gift card balance dispute and replacement Try it in the sandbox All travel and ecommerce processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.