Visa condition 13.8 concerns an Original Credit Transaction that was not accepted. This is a credit-flow problem, so the merchant should trace the intended credit from initiation through processor response and final status. A screenshot showing that staff clicked 'refund' is not the same as proof that the credit was accepted and completed.
Begin with the live case and identify the specific credit transaction, amount, date, reference, and status. Then reconcile it against the original sale or account event that caused the credit. Current Visa and processor documentation should be used for rule-specific requirements.
Identify the original credit transaction
Save the merchant record that initiated the credit: refund event, standalone credit workflow, account adjustment, or other supported operation. Capture amount, currency, timestamp, order or case reference, and processor transaction ID.
Keep the credit separate from the original purchase. The response should make clear which transaction is the credit and which transaction, if any, it relates to.
Read the processor response, not the staff action
Retrieve the processor status and response for the credit. A merchant interface may display 'submitted' or 'created' before the downstream network accepts the transaction. The evidence needs to show what actually happened after initiation.
If the credit failed, was rejected, reversed, or remained pending, record that honestly. A later manual correction should be shown as a separate event rather than retroactively describing the first credit as successful.
Reconcile amount, currency, and account reference
Confirm the credit amount and currency match the merchant's intended resolution. Use the masked or tokenized account references made available by the processor; do not collect or display full card numbers.
If the merchant attempted multiple credits, list each with its status. This prevents the reviewer from confusing a failed first attempt with a later successful one or from adding separate credits together incorrectly.
Check whether the customer was made whole another way
Look for an alternate refund, store credit, replacement, cash reimbursement, or another financial adjustment. These events may explain the merchant's operational history but should not be presented as if they are the same as an accepted Original Credit Transaction.
If a different remedy was agreed with the customer, preserve the communication and financial record. The case narrative should distinguish the resolution path from the specific network transaction being disputed.
Build a credit-status timeline
Use a compact sequence: credit initiated, processor response, any failure/reversal, retry, final accepted credit if one exists, and customer communication. Attach the original processor records behind that timeline.
Avoid lengthy product or service evidence unless the live case makes it relevant. The dispute is about the credit transaction's acceptance, so payment-system records should lead.
Audit the refund/credit workflow after the case
Repeated 13.8 cases can expose retry logic, unsupported transaction types, processor routing problems, expired credentials, or staff misunderstanding of status labels. Tag the actual failure mode and test the same path outside the dispute queue.
Update internal status language so staff can distinguish initiated, pending, accepted, failed, and reversed credits. Clear operational labels reduce both customer confusion and weak dispute packets.
Example: first credit rejected, second credit accepted
A merchant initiates an Original Credit Transaction, sees a created/pending status, and tells the customer the credit is complete. The processor later rejects it. A second attempt succeeds three days later. Visa 13.8 evidence should show both events rather than treating the original staff action as a successful credit.
The operational fix is also clear: customer-facing systems should not say 'refunded/credited' until the processor reaches the appropriate completed status.
Reconcile the credit path at processor-status level
For an Original Credit Transaction problem, an internal refund button, accounting note, or customer-service promise is not enough. Record the credit transaction identifier, submission time, target account reference available to the merchant, processor response, rejection reason if any, retry, and final posted or settled outcome.
If the first credit failed and a second succeeded, preserve both. This avoids a common evidence error in which the merchant proves that staff attempted a credit but never proves that value reached the payment system successfully.
Follow the credit until it is accepted, rejected, replaced, or otherwise resolved
An Original Credit Transaction dispute should be treated as a status investigation. Record the original sale or event that led to the credit, the OCT amount and currency, the receiving account reference available from the processor, the processor response, and the final status. A staff action saying 'credit sent' is not enough if the network or processor rejected it. The merchant needs to know whether the customer's account actually received an accepted credit transaction.
If the first credit was rejected, document what happened next. Was a second OCT attempted, was a different refund method used, did the merchant issue another form of payment, or did support simply assume the first attempt succeeded? Show each attempt separately with identifiers and amounts. Avoid duplicate compensation if multiple teams respond to the same failed credit through different channels.
Reconcile currency and amount carefully. If the underlying obligation was in one currency and the credit in another, preserve the provider records that explain the path. If the customer was made whole through another valid method, document that resolution and verify the current dispute workflow with the processor. The article should not imply that an alternative payment automatically satisfies every network requirement; it should make the economic and processing facts visible.
Use 13.8 cases to improve outbound-credit operations. Monitor rejected OCTs, reason codes, retries, unsupported destinations, account changes, and staff follow-up. Create an exception queue so a rejected credit cannot sit in a 'sent' status. Customers should receive accurate confirmation only after the payments system confirms the state the business is claiming.
Distinguish OCT rejection from customer non-recognition of a completed credit
A customer may say they did not receive a credit even when the processor shows the OCT was accepted. That is different from a processor-rejected OCT. Preserve the accepted status and reference, then follow the processor's current guidance for the live dispute without claiming when the receiving bank must display the funds.
If the OCT was rejected, the merchant needs an exception path that selects another valid resolution method where appropriate. Support should see the rejection and not tell the customer the credit is complete. The difference between accepted and merely attempted credit should be explicit in both internal status and customer communication.
Notify support only after credit status reaches a customer-safe state
Customer messaging should distinguish credit initiated, accepted by the processor, failed, or replaced with another resolution. Avoid automatic emails that say 'refund complete' at the moment an OCT request is merely created. If the credit later rejects, the customer has received a false confirmation that can trigger a dispute. Tie notification templates to the payment state that operations considers reliable and create an exception message when additional action is required.
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.