A chargeback filed after a replacement was sent requires two linked fulfillment stories: the original order/problem and the replacement resolution. The merchant should not simply submit tracking for whichever package shows delivered. It needs to explain why the replacement existed, what it was intended to resolve, whether the customer accepted that resolution, and what happened to the original item and any refund.

Build a paired timeline so the reviewer can distinguish original shipment, complaint, replacement authorization, replacement shipment, delivery, return of original goods if required, and the eventual chargeback.

Reconstruct the original failure

Preserve the original order, shipment/service record, and customer complaint that led to replacement. State whether the problem was non-receipt, damage, defect, wrong item, or another documented issue.

Do not hide the initial failure. The replacement only makes sense if the case clearly shows what the merchant was trying to remedy.

Document the replacement agreement

Save the support message or workflow showing that a replacement was offered or accepted, whether it was in lieu of refund, and any return condition for the original item.

If the merchant sent a replacement without customer confirmation, do not assume the customer agreed to give up a refund right. Record the actual communication.

Track the replacement independently

Give the replacement its own order/RMA/shipment reference, items, tracking, delivery event, pickup, or digital access record. Avoid presenting original and replacement tracking numbers without labels.

If the replacement was also delayed or lost, that becomes a material adverse fact.

Account for the original merchandise

Show whether the customer returned, kept, refused, or was told to dispose of the original item. For serial-controlled goods, record unit identifiers if the merchant normally retains them.

The financial analysis differs when the customer ends up with two units versus one replacement for one returned unit.

Check refunds and duplicate remedies

Search for refunds, store credits, coupons, or manual reimbursements issued alongside the replacement. Calculate the total remedy already provided.

A support team can accidentally create a replacement and a refund while a dispute is pending, turning a valid service recovery into a double-loss.

Present two lanes in the evidence packet

Use one lane for original transaction and one for replacement, connected by the complaint/resolution event. Then show the chargeback date after both lanes.

This is clearer than a single chronology that jumps between two shipment IDs and forces the reviewer to infer which package is which.

Fix replacement controls

Require replacement orders to reference the original order and resolution type. Surface replacement delivery and refund status in the support view.

That linkage prevents future dispute teams from discovering after the deadline that the decisive evidence lived under a separate zero-dollar order.

Example: replacement delivered while the original enters return transit

A damaged item is replaced at no charge. The replacement is delivered, the original is returned, and the customer later disputes the original purchase expecting a refund as well. A response that says only 'replacement delivered' omits why the replacement was sent and what happened to the original item.

Build two linked lanes: original order → problem report → return, and replacement order → shipment → delivery. Add the remedy the customer accepted and any promise of refund versus replacement. This distinguishes a completed replacement resolution from a case where the merchant still owed money.

Record remedy acceptance before closing the complaint

When a replacement is offered, store whether the customer accepted replacement instead of refund, the replacement order ID, shipment or service completion, and any conditions such as returning the original item. Do not mark the complaint 'resolved' simply when a replacement order is created.

Close the loop only after the promised remedy is completed or the customer declines it. If the replacement fails, arrives damaged, or is never collected, the dispute story changes and the evidence must reflect that second failure rather than the initial good-faith attempt.

Treat a replacement as a new fulfillment lane tied to the original complaint

A replacement should never erase the original failed order from the record. Build two lanes: original purchase and replacement. Lane one shows what went wrong—non-delivery, defect, wrong item, damage, or another failure. Lane two shows the customer's acceptance of the replacement remedy, replacement order or shipment ID, item or service supplied, delivery or access, and any later complaint. This makes it possible to show that the merchant acknowledged the first problem and what it did to resolve it.

Track the original merchandise after replacement. It may be lost, returned, recovered, kept by the customer, or still in transit. If both original and replacement are ultimately delivered, the merchant needs a policy and communication trail for what happens next. If the customer returns one unit, record which one. Otherwise inventory and payment records can diverge and a dispute packet may accidentally count the same product twice.

Reconcile money separately from goods. A replacement can be the remedy instead of a refund, but only if the customer accepted or the transaction terms support that resolution. If the merchant also issued a partial credit, coupon, or full refund, show it. If the customer received the replacement after filing the chargeback, the timing matters and should be stated rather than implying the dispute was invalid from the beginning.

Make replacement acceptance a structured event. Support should record what remedy was offered, what the customer chose, the replacement ID, and completion status. Fulfillment should link the new shipment to the original order, and finance should see any related credit. This prevents unresolved complaints from being marked closed simply because a replacement label was created.

Stop automatic case closure when a replacement label is only created

A replacement workflow should distinguish approved, label created, shipped, delivered, and failed. Closing the complaint at label creation can make support believe the customer was made whole even if the package never leaves the warehouse. Use delivery or another appropriate completion event as the resolution state.

If the replacement fails, reopen the case automatically or create an exception. This small control improves both customer service and evidence because the merchant's 'resolved' status will correspond to an actual completed remedy rather than an intention.

Reconcile replacement value when the substitute item differs from the original

A replacement can be a different model, size, color, or upgraded product because the original is unavailable. Preserve the customer's acceptance and any price adjustment. If the substitute is lower value and no credit was issued, that may become a description or amount issue even though delivery succeeded. If it is higher value offered at no charge, document the concession. Replacement evidence should therefore show not only that another package arrived but what value the customer agreed would resolve the original complaint.

Replacement cases need a value ledger as well as a shipment ledger. Record the original item and price, replacement item, any upgrade or downgrade, additional payment, refund, return of the original, and final customer possession. If the replacement had a different SKU or value, explain how the merchant and customer agreed to that remedy. Also check whether the original payment remained appropriate after the replacement or whether a partial credit became due. A tracking record proving the replacement arrived is useful, but it does not by itself show that the economic resolution was correct. The response should connect delivery of the substitute item to the amount still being defended.

VERIFY CURRENT RULES

Primary references

Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.

Scope: This guide is educational merchant-operations information. It is not legal advice, banking advice, or an interpretation of card-network rules for a specific case.