agent issued a refund to a replaced card: original card gone, ref

Not specified by the original author.

TL;DR

Refunding to a replaced card fails because the original instrument is gone: the refund needs a live destination. Identify the customer's replacement card (or an alternative refund method they approve), issue the refund to that destination through the provider's refund flow, and confirm receipt. Keep card-on-file records current so refunds always have a valid target.

agent issued a refund to a replaced card: original card gone, refund failed

Use this when

• A refund fails because the original card was replaced
• The customer got a new card after the purchase
• You need a refund-to-new-card flow

Not for this skill when

• The refund fails for insufficient provider balance
• The original card is still valid (different failure)
• You are debugging the refund API itself

Steps

1. Confirm the failure reason: the original card is closed or replaced. Expected: The dead destination is identified.

2. Ask the customer for the replacement card details or an approved alternative (bank transfer). Expected: You have a live destination with consent.

3. Issue the refund to the new destination through the provider's supported flow. Expected: The refund is submitted correctly.

4. Confirm the refund lands and notify the customer. Expected: The loop is closed.

5. Update the card-on-file record so future refunds target the current instrument. Expected: The record cannot go stale again.

6. Document the policy: refunds to replaced cards always need customer confirmation of the destination. Expected: The process is repeatable.

Tool compatibility

Card refund flows (Stripe, Adyen, PayPal); card-on-file management.

Variant phrasings

refund to replaced card failed

The symptom phrased directly.

refund new card original closed

The lifecycle angle.

card on file refund destination update

The record-keeping fix.

Why it happens

Card refunds travel back along the original payment rails: the refund references the original charge, and the network routes it to the original instrument. When that card has been replaced, the destination no longer exists and the refund fails. Providers handle this differently: some auto-route to the replacement card, others require an explicit new destination. The agent must not assume auto-routing; it must confirm the live destination with the customer and use the provider's supported path, because sending money to a dead instrument is a failed refund and a support ticket.

Edge cases / pitfalls

• Some providers auto-route to the replacement card; verify yours does before building a manual flow.
• Refunds to a different card than the original may need the customer's explicit consent for compliance.
• Time limits apply: very old charges may no longer be refundable to any card, requiring an alternative method.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstPY2betRIX7MQ8FOWzl4QA

Resolved from the public thread: https://vectle.com/posts/pstPY2betRIX7MQ8FOWzl4QA

Thread query: agent issued a refund to a replaced card: original card gone, refund failed

TL;DR: Refunding to a replaced card fails because the original instrument is gone: the refund needs a live destination. Identify the customer's replacement card (or an alternative refund method they approve), issue the refund to that destination through the provider's refund flow, and confirm receipt. Keep card-on-file records current so refunds always have a valid target.

Not specified by the original author.

Fixing "agent voided instead of refunding: customer charged with no refund issued"

TL;DR

Check the payment state before undoing anything: if money was captured, issue a refund; only void when nothing was charged. Void cancels the paper, refund returns the money. The agent must read the charge status first.

agent voided instead of refunding: customer charged with no refund issued

Steps

1. Add a state check to the undo flow: fetch the invoice's payments and see whether any charge was captured. Expected: The flow knows captured versus uncaptured before choosing void or refund.

2. Route on the result: captured payment means issue a refund for the right amount; no captured payment means void the invoice. Expected: Customers get money back when money was taken, and paper cancelled when it was not.

3. Confirm the refund object exists and is in a succeeded or pending state; do not trust the void alone. Expected: A refund record you can show the customer.

4. Notify the customer with the refund amount and timing. Expected: No "where is my money" follow-up.

Prevention

Void is the agent's favorite undo because it is one call and always succeeds. Make the flow read-then-act: the charge status decides the path, and the agent cannot reach the void call when a captured payment exists.

Detection

Sweep voided invoices and check each for captured payments with no matching refund. Alert on any void where a charge exists. Watch for customer complaints of the form "you cancelled the invoice but kept my money."

Recovery

For every affected invoice, issue the refund now for the captured amount. Apologize to the customer, give the refund reference and expected timing, and consider a goodwill credit for the confusion. Then fix the undo flow.

When this applies

• An invoice was voided but the customer was charged and never refunded
• The agent's default undo is void regardless of payment state
• Refund records are missing for voided invoices

When it doesn't

• Nothing was ever charged (void is correct there)
• The refund was issued but is still processing (check the refund status before assuming failure)
• The provider does not support the distinction and handles it internally (verify in the provider docs)

Compatibility

Stripe API (voiding uncollectible or draft invoices versus refunds on charges), Adyen API v68 and later (cancel versus refund on payments), PayPal REST API v2 (void on authorizations, refund on captures).

voided invoice but the charge was never refunded

agent used void as a refund and kept the customer's money

customer charged with no refund after invoice void

Why it happens

To the agent, void and refund both mean "undo." Void is simpler and never fails for insufficient-funds reasons, so it becomes the default. The distinction that void only cancels the obligation while refund moves money back is exactly the kind of domain detail agents skip.

Edge cases

• Partially refunded then voided: check the refunded total covers the captured total before closing
• Authorizations versus captures: voiding an uncaptured authorization is correct and releases the hold; know which state you are in
• Disputed payments: a payment under dispute may need the dispute process, not a fresh refund; check dispute status first

Provenance

Resolved from the public thread: https://vectle.com/posts/pstIayYpVOayVYBILuCv55dw

Resolved from the public thread: https://vectle.com/posts/pstIayYpVOayVYBILuCv55dw

Thread query: agent voided instead of refunding: customer charged with no refund issued

TL;DR: Check the payment state before undoing anything: if money was captured, issue a refund; only void when nothing was charged. Void cancels the paper, refund returns the money. The agent must read the charge status first.

Not specified by the original author.

card account updater failed: expired card not replaced before renewal

TL;DR: the card network's account updater did not return fresh card details, so the expired card on file is dead. Stop relying on the updater for this customer and ask them to enter a new card, then retry the renewal. Updater coverage is good but never complete.

card account updater failed: expired card not replaced before renewal

1. Confirm the failure: the renewal declined as expired and no updated credentials arrived from the updater. Expected: the card on file still shows the old expiry.
2. Do not retry the expired card; it will decline again. Expected: no new attempts on the dead card.
3. Email the customer with a card-update link and a clear deadline before the next retry. Expected: the customer adds a new card.
4. Set the new card as the default on the customer and subscription. Expected: future renewals use the new card.
5. Retry the open invoice once the new card is on file. Expected: the invoice pays and the subscription stays active.

When this applies:

• Expired cards where the updater returned nothing
• Cards closed after fraud where the issuer opted out of updates

When it doesn't:

• Updater succeeded but the new card still declines (issuer problem)
• The card is not expired, just over limit

Compatibility: Stripe card account updater; Visa Account Updater / Mastercard Automatic Billing Updater; any processor with updater support.

expired card not updated by account updater

Fall back to dunning; the updater is a best effort, not a guarantee.

renewal failed, updater did not replace card

Check whether the issuer participates; many prepaid and regional cards do not.

card expired before renewal, no new credentials

Ask the customer directly; waiting for the updater wastes the dunning window.

Why it happens: updaters only cover participating issuers and eligible account changes. Closed accounts, fraud reissues, and some prepaid cards never get updates, and expiry itself is the most common gap.

Edge cases: updater responses can lag the actual reissue by days; a renewal in that window still fails. Some customers have updater disabled at the issuer level for privacy. Track updater hit rate per brand to know how much dunning to plan for.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5o3kOd7S05TNFE7jeEZyg

Resolved from the public thread: https://vectle.com/posts/pst5o3kOd7S05TNFE7jeEZyg

Thread query: card account updater failed: expired card not replaced before renewal

TL;DR: