American Express C02 is a clean example of why refund operations need an audit trail. The Cardmember says a credit expected from the merchant was not processed. The merchant’s best evidence is not a policy page or customer-service explanation; it is the financial record showing what credit was due and what happened to it.
Pull the original Amex charge and the alleged refund into the same case file. Verify the amount, date, transaction reference, and final processor status.
Trace the credit from promise to settlement
Start with the event that created the refund expectation: a return, cancellation, price adjustment, duplicate correction, or explicit merchant promise. Then follow the refund through the payment system. If the credit completed, preserve the processor reference. If it failed, identify the error rather than presenting the internal approval as success.
A support ticket can establish that the merchant intended to refund the Cardmember, but it cannot by itself establish that American Express received a credit transaction.
Tie the credit to the disputed charge
Use the original transaction ID, card payment amount, and refund amount. For accounts with multiple purchases, this avoids accidentally presenting a refund from a different order. If the credit was partial, explain the retained portion and why.
If a credit was processed after the chargeback began, follow the acquirer or processor’s instructions so the same amount is not returned twice. Store the chargeback case ID with the refund record when possible.
For Amex C02, the practical question is whether the merchant owed a credit and whether that credit was actually processed. Start with the event that created the refund obligation: return accepted, cancellation approved, price adjustment, duplicate corrected, or service failure. Then connect that obligation to a processor-level credit reference. Internal accounting entries and store-credit balances should be labeled accurately because they are not the same as returning funds to the original payment method.
When no credit was owed
If the merchant’s position is that no refund was due, show the purchase-time terms and the event that made the request ineligible. That might be a non-returned item, a service already completed, or a request outside a disclosed policy window. Keep the response factual.
A strict policy is not automatically a strong case. The merchant still needs to show it was the policy applicable to the transaction and that support did not later make a separate promise to credit the Cardmember.
Refund control points worth monitoring
Create a report of approved refunds that lack completed processor credits after an expected interval. Reconcile wrong amounts, wrong transactions, failed refunds, and duplicate refunds separately. Finance should be able to identify every refund still between “approved” and “completed.”
That control reduces C02 exposure and also improves customer support, because agents can see whether a refund is pending in the payment system rather than telling the Cardmember to wait without evidence.
Use C02 outcomes to audit the refund stack
A C02 loss caused by a failed refund integration is a software or finance defect. A loss caused by a support promise that did not reach finance is a handoff defect. A loss caused by unclear policy may be an editorial or customer-experience defect.
Tag the failure mode. The chargeback reason is only the starting label; the merchant needs a more specific internal category to prevent recurrence.
If the merchant issued only a partial refund, explain the calculation and supporting policy rather than presenting the partial credit as though it resolved the full complaint. Save the return authorization, inspection result where relevant, refund amount, date, and payment reference. A clean refund workflow reduces C02 risk because the same record that proves a credit also alerts the team when a promised credit never left the internal system.
Example: Amex C02 after a partial refund
A customer returns one of two items and the merchant owes a $60 credit against a $140 order. Support says the return was received, but only a $40 credit was processed because the warehouse used the wrong line item. A C02 response must reconcile the expected credit with the actual credit and explain the remaining $20 difference.
The original sale may be valid, but the dispute is about the credit. A clean file shows return receipt, credit calculation, processor refund record, and any correction. If the merchant's own math is wrong, contesting the difference is not justified.
Reconcile the expected Amex credit against the credit that actually settled
For C02, write down the customer's expected credit before looking at the merchant's refund label. What event created the expectation—a return received, canceled order, price adjustment, support promise, or duplicate charge correction? Record the promised amount and date. Then retrieve the payment-system credit transaction and identify its amount, status, processing date, and reference to the original charge. The merchant's case depends on actual money movement, not on an internal status that may have been set when a refund was requested.
Partial credits require arithmetic that should be visible. If a $240 purchase included two items and the customer returned one worth $90, the file should show the original $240 charge, the $90 credit due, any restocking or other disclosed adjustment if applicable, the credit actually processed, and the remaining $150 tied to retained goods. If only $70 was credited because staff selected the wrong line, the merchant should not defend the missing $20 as though the full refund completed. Correct the difference and document the correction.
When the merchant says no credit was due, preserve the purchase-time policy and the facts that place the transaction outside it. That may involve return condition, timing, a nonrefundable custom service, or a request that did not involve an actual merchant promise. Do not use a current policy version to explain a sale governed by older terms. Also keep customer communication in sequence: a support agent who explicitly promised a credit can create a materially different factual record from a request that was clearly denied from the start.
Use C02 cases to audit the refund stack. Look for refund requests that remain pending, failed processor calls, support tools that display 'refunded' too early, manual credits missing original-transaction references, and partial refunds whose expected and processed amounts differ. A monthly reconciliation between support concessions and settled credits can catch many of these problems before an Amex dispute arrives.
A C02 packet should show the customer's net position after every credit
When several credits or adjustments exist, calculate the customer's net position rather than presenting one refund in isolation. Start with the original Amex charge, subtract every completed credit tied to it, and show the amount the merchant still retained. If one refund attempt failed and a later one succeeded, include both statuses so the reviewer does not mistake two refund IDs for two completed credits. This net-position view also helps the merchant detect accidental over-refunding while the dispute remains open.
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.