Credit-not-processed disputes look simple because merchants usually know whether they “issued a refund.” The problem is that different systems use that phrase for different states. Support may mean approved. Finance may mean queued. The processor may mean pending. The card statement may not yet show a completed credit.
A defensible response traces the money. It shows the original payment, the reason a credit was expected, the actual refund transaction, and the amount and status of that credit.
Create a two-transaction ledger
Put the sale and credit side by side: payment ID, date, amount, refund ID, refund date, refund amount, and final status. If the merchant issued more than one partial credit, show the total and what each adjustment represented.
This layout immediately reveals common mistakes such as a refund sent to the wrong order, an amount mismatch, or a support promise that never became a payment event.
If the refund is complete, prove the processor event
Use the processor’s transaction record, not only the customer-facing email. A refund confirmation generated before processor completion can be useful context but should not be presented as final settlement evidence.
When the customer says the credit is missing, avoid guessing how many days their bank will take. State what the merchant can prove: submission date, amount, reference, and current status.
Build a three-part refund record: why the credit was due, whether the merchant approved it, and whether the payment system actually processed it. A warehouse return scan can prove goods came back, but it does not prove finance issued the credit. A support ticket can show approval, but it does not prove settlement. The processor refund ID, amount, date, and connection to the original payment are the financial evidence that closes the chain.
If the merchant refused the credit, show why
A denied refund needs the actual case history. Provide the return or cancellation request, the relevant purchase-time terms, the merchant’s response, and the factual reason the request was not eligible. If the merchant later promised an exception, include it.
A generic policy page cannot answer whether the customer returned the item, cancelled within time, or received the service.
Avoid double reimbursement after the chargeback opens
Once a formal dispute is active, follow the processor’s instructions before issuing a separate refund. A merchant can lose money twice if it sends a new credit while the issuer is already reversing the transaction.
If a refund preceded the chargeback, make the existing credit the center of the response and tie it clearly to the disputed payment.
Close the gap between support and finance
Create an automated or daily report of refund promises that lack completed processor credits. Give support visibility into actual payment status so customers receive accurate answers.
A rising credit-not-processed rate is often less about card-network rules and more about broken internal handoffs. Fixing the handoff prevents disputes and reduces manual reconciliation.
For partial credits, state the math explicitly. If a $200 order received a $150 refund because $50 represented a non-returned item, the evidence should show the line items and policy supporting that result. Avoid vague statements such as “refund already sent” when the customer disputed the full amount. Clear amount reconciliation also prevents the business from issuing a second refund after a chargeback has already debited the same transaction.
Example: refund promised, initiated, then reversed
Support approves a refund and the processor initially shows it as pending, but a later system event reverses or fails the credit. The customer then files a credit-not-processed dispute. A screenshot captured during the pending state would create a misleading packet if the final processor status is not checked.
Always save the complete refund lifecycle: approval, initiation, processor reference, failure/reversal if any, retry, and final completion. This also gives operations a clear failure mode to fix when the support system marks a case 'refunded' too early.
Audit the refund promise, processor event, and customer balance as three separate facts
Credit-not-processed disputes often contain three states that merchants accidentally collapse. A support agent can promise a refund, the merchant can initiate a processor refund, and the cardholder can ultimately receive a posted credit. Those are related but not identical events. Record each with date, amount, system, and identifier. If support promised $120 but finance initiated $100, the case has an amount mismatch. If the processor shows the $120 refund failed, the merchant has not completed the credit merely because the commerce platform says refunded.
Build a refund bridge from the original payment to the offsetting transaction. Include original charge ID, original amount, refund ID, refund amount, status, and processing date. For partial refunds, explain the retained amount with item or service detail. For multiple refunds, show the cumulative credit. This lets the reviewer see whether the disputed amount was already economically returned rather than forcing them to interpret several screenshots from unrelated systems.
When the merchant says a credit was not owed, the file should show the request and the reason it was declined. Preserve the purchase-time return or cancellation terms, the condition or timing of the request, and the merchant's response. A denial is different from an approved-but-delayed credit, so do not use policy language to cover a processing failure. If a support representative made a concession outside standard policy, that promise becomes part of the factual history and should be reconciled honestly.
Create controls that prevent disputes from being the first place refund errors are discovered. Reconcile approved concessions against completed processor credits, flag failed and long-pending refunds, and require support tools to distinguish 'refund requested' from 'refund completed.' When a chargeback opens, search the refund ledger before any manual credit is issued. That one check can prevent the merchant from losing the sale once through a refund and again through the dispute.
Reconcile refund destination when customers have multiple cards or payment attempts
A refund can be valid yet appear confusing if it returns to a different visible card reference because of card reissue, tokenization, wallet routing, or a payment method update. Preserve the processor's link between the refund and original charge and use provider documentation to explain the destination where needed. Do not infer the full account number or ask staff to compare sensitive card details manually.
If the customer used multiple payment attempts, make sure the refund was applied to the transaction that actually settled. A support team can accidentally refund a failed or duplicate order record while the challenged charge remains untouched. Transaction IDs, not customer name or order amount alone, should drive the reconciliation.
When a credit was actually processed, verify that the evidence shows a completed money movement rather than an internal note or customer-service promise. Record the refund amount, date, original transaction reference, refund transaction or processor ID, and the destination payment method where the processor exposes it. If the refund was partial, show the remaining amount separately. If no refund was due, preserve the policy and the factual reason the case fell outside it, while avoiding language that suggests a policy automatically overrides card-network rights. The key operational question is whether the merchant can reconcile the customer's claimed missing credit with a concrete refund event or with a documented reason no credit was initiated. That distinction is much stronger than a screenshot that simply says “refunded” without traceable payment data.
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.