As a merchant, it's crucial to understand the concepts of disputes and chargebacks, as they directly impact your business operations and financial health. Here’s a comprehensive guide to help you navigate these processes.
TABLE OF CONTENTS
- What Are Disputes and Chargebacks?
- Common Dispute Reason Codes
- The Chargeback Lifecycle
- Additional Steps
- Visa Dispute Reason Codes
- Mastercard Dispute Reason Codes
- Support
What Are Disputes and Chargebacks?
Dispute: A dispute occurs when a cardholder contacts their card-issuing bank to request a return of their funds. This mechanism is designed by card networks like Visa, Mastercard, and American Express to protect cardholders from fraudulent activities.
Chargeback: A chargeback is a subsequent action initiated by the issuing bank following a dispute. It involves a forced payment reversal to the customer, typically when the merchant cannot provide valid documentation to refute the dispute.
Common Dispute Reason Codes
Visa
10.4 | Other Fraud: Card-Absent
11.3 | No Authorisation
12.6 | Duplicate Processing
13.1 | Merchandise/Services Not Received
13.2 | Cancelled Recurring
13.3 | Not as Described or Defective
13.6 | Credit Not Processed
13.7 | Cancelled Merchandise/Services
Mastercard
4837 | No Cardholder Authorisation
4853 | Cardholder Dispute (Includes 4841, 4855, 4859, 4860)
The Chargeback Lifecycle
Filing the Dispute: The cardholder files a dispute through their bank, generally within 120 days after purchase, though some schemes allow up to 365 days.
Issuer Review: The issuing bank reviews the case, assigns a reason code, and initiates the dispute.
Card Scheme Handling: The card scheme receives the dispute and forwards it to the acquirer.
Merchant Notification: The acquirer shares the dispute information with either Peach Payments (if you hold an aggregation account) or with you the merchant if you have a direct account with the acquirer.
Merchant Response: The merchant reviews the dispute and provides a defense document if they choose to challenge it. This defense must be submitted within 7 days, including all relevant information to Peach or directly the acquiring bank (depending on your account setup.
Decision Making: The acquirer forwards the merchant’s decision through the scheme to the issuer, who reviews the defense and decides to accept or decline.
Additional Steps
Second presentment: If the issuer declines the merchant’s defense, The merchant can send new case material and evidence to the acquirer for submission. In this case, all the information goes directly to the card scheme (either Visa or Mastercard) rather than the issuer. The card scheme can then begin the arbitration process.
Arbitration: If the second chargeback is declined, arbitration is possible but often not recommended due to high fees (up to $500 plus the disputed amount).
1. Visa Dispute Reason Codes
Category: Fraud (10.x)
10.1 | EMV Liability Shift Counterfeit Fraud
Description: This code is applied when a card-present transaction is disputed as unauthorised and the physical card is subsequently identified as counterfeit.
Evidence Requirements: Documentation must demonstrate that the transaction was processed via an EMV-compliant (chip-enabled) terminal. Liability generally resides with the merchant if the transaction was conducted on a non-chip-ready terminal.
10.2 | EMV Liability Shift Non-Counterfeit Fraud
Description: Applicable to card-present transactions where the cardholder denies authorisation.
Evidence Requirements: Provision of chip-read data (EMV logs) and evidence of successful PIN entry or a verified signature.
10.3 | Other Fraud: Card-Present
Description: Concerns disputed in-person transactions typically involving manual key-entry or self-service terminals.
Evidence Requirements: A signed transaction receipt or technical logs proving the transaction occurred at a secure, attended terminal location.
10.4 | Other Fraud: Card-Absent
Description: Encompasses e-commerce, telephonic, or mail-order transactions where the cardholder denies approving the charge.
Evidence Requirements: Submission of the IP address, device fingerprinting data, and a signed Proof of Delivery (POD) or waybill. It is highly recommended to provide 3D Secure (Verified by Visa) authentication logs to establish a liability shift.
10.5 | Visa Fraud Monitoring Programme
Description: Occurs when Visa’s monitoring systems reverse a transaction due to the merchant exceeding established fraud thresholds.
Evidence Requirements: Detailed records proving the legitimacy of the specific transaction and documentation of the remedial actions taken to enhance fraud prevention protocols.
Category: Authorisation (11.x)
11.1 | Card Recovery Bulletin
Description: Identifies transactions involving cards listed on the Card Recovery Bulletin.
Evidence Requirements: The specific authorisation approval code and terminal logs verifying that the transaction was not manually forced or overridden.
11.2 | Declined Authorisation
Description: Applied when a transaction is submitted following a "Decline" or "Pick Up Card" response from the issuer.
Evidence Requirements: Evidence that a subsequent authorisation request for the identical transaction amount was formally approved by the issuer.
11.3 | No Authorisation
Description: Transactions that reach the clearing stage without a valid authorisation approval.
Evidence Requirements: Confirmation of a valid, approved authorisation code corresponding to the specific transaction date and value.
Category: Processing Errors (12.x)
12.1 | Late Presentment
Description: Occurs when transaction data is submitted to the issuer outside of the prescribed settlement timeframes.
Evidence Requirements: Batch settlement reports and timestamps proving the transaction was submitted within the time limits defined by the network.
12.2 | Incorrect Transaction Code
Description: This code is triggered when an inappropriate transaction code is utilised (for example, a credit transaction processed as a debit).
Evidence Requirements: Documentation clarifying the intended nature of the transaction and proving that the correct financial action was intended.
12.3 | Incorrect Currency
Description: Applicable when the transaction currency does not align with the currency agreed upon by the cardholder.
Evidence Requirements: Documentation proving the cardholder’s explicit consent to the currency used, such as a signed receipt or a timestamped screenshot of the currency selection at checkout.
12.4 | Incorrect Account Number
Description: Concerns transactions posted to an incorrect or unrecognised account.
Evidence Requirements: Proof that the account number utilised matched the credentials provided by the cardholder or evidence of a successful subsequent correction.
12.5 | Incorrect Amount
Description: The cardholder asserts that the amount debited from the account differs from the agreed-upon price.
Evidence Requirements: A signed sales receipt or a formal digital invoice confirming the cardholder's agreement to the specific total.
12.6 | Duplicate Processing
Description: Occurs when the same transaction is processed multiple times.
Evidence Requirements: If the charges relate to distinct purchases, provide separate invoices and unique waybills/PODs for each individual transaction.
12.7 | Invalid Data
Description: Triggered by mismatched or invalid data fields (such as expiry dates) during the authorisation or clearing process.
Evidence Requirements: System logs demonstrating that all mandatory fields (CVV, expiry date, etc.) were transmitted accurately and reconciled with the authorisation request.
Category: Consumer Disputes (13.x)
13.1 | Merchandise/Services Not Received
Description: The cardholder asserts that the purchased goods or services were not delivered.
Evidence Requirements: A signed waybill or Proof of Delivery (POD). For digital products, provide server logs, download confirmation timestamps, or records of service utilisation.
13.2 | Cancelled Recurring
Description: Concerns billing for subscriptions or instalments after the cardholder claims to have revoked authorisation.
Evidence Requirements: Evidence that the cancellation did not comply with the agreed Terms and Conditions or proof of continued service usage following the alleged cancellation date.
13.3 | Not as Described or Defective
Description: The cardholder asserts the goods or services were damaged, defective, or did not match the provided description.
Evidence Requirements: Product photographs, descriptions, or evidence that the customer failed to return the item. If a repair or replacement was facilitated, provide the relevant documentation.
13.4 | Counterfeit Merchandise
Description: Claims that the goods provided were not authentic.
Evidence Requirements: Invoices from authorised distributors, serial numbers, or official certificates of authenticity to validate the product’s provenance.
13.5 | Misrepresentation
Description: The cardholder claims that key information regarding the purchase was misrepresented.
Evidence Requirements: Comprehensive copies of the Terms and Conditions and the original marketing or product descriptions applicable at the time of purchase.
13.6 | Credit Not Processed
Description: A refund or transaction void promised by the merchant was allegedly not executed.
Evidence Requirements: The Acquirer Reference Number (ARN) or a transaction receipt confirming the refund was processed, or evidence justifying the denial of a credit based on established policy.
13.7 | Cancelled Merchandise/Services
Description: The cardholder claims to have returned goods or cancelled a service without receiving the corresponding credit.
Evidence Requirements: Proof that the return was invalid according to the merchant’s policy or documentation that the credit has already been successfully issued.
2. Mastercard Dispute Reason Codes
Category: Administrative and Authorisation
4801 | Requested Transaction Data Not Received
Description: Triggered when a merchant fails to respond to a retrieval request or fails to provide the required transaction documentation within the allotted timeframe.
Evidence Requirements: Ensure the immediate submission of the complete, legible transaction record or invoice upon receipt of an inquiry from the issuing bank.
4802 | Requested Information Illegible or Missing
- Description: Used when the documentation previously submitted by the merchant is of poor quality, incomplete, or cannot be read by the issuing bank.
Evidence Requirements: Submit high-resolution, clear documentation to replace unreadable or incomplete copies previously provided.
4808 | Authorisation (Includes 4812, 4835)
- Description: Covers disputes where a transaction was processed without obtaining a valid authorisation, exceeded a floor limit, or occurred on an expired/not-yet-valid card.
Evidence Requirements: Provide the specific authorisation approval code corresponding to the transaction date and value.
4812 | Account Number Not On File
- Description: Occurs when a transaction is submitted against an account number that does not exist in the issuer’s records.
- Evidence Requirements: Demonstrate that the transaction was successfully authorised and processed against a valid account.
Category: Processing Errors
4834 | Point of Interaction Error (Includes 4831, 4846)
- Description: Encompasses various errors occurring at the terminal, such as incorrect transaction amounts, currency conversion errors (DCC issues), or duplicate charges.
Evidence Requirements: For amount discrepancies (4831), provide the signed receipt. For currency conversion (4846), provide proof of the cardholder’s consent to the specific currency used.
4842 | Late Presentment
- Description: Applied when a merchant fails to settle a transaction within the network’s required window (typically 7 days for most transactions).
- Evidence Requirements: Transaction logs must confirm that data was submitted to the network within seven days of the transaction date.
Category: Fraud and Disputes
4837 | No Cardholder Authorisation
- Description: The cardholder claims they did not participate in or authorise a card-absent transaction (e-commerce, phone, or mail order).
Evidence Requirements: Compile the IP address, a signed waybill, and Mastercard Identity Check (3D Secure) authentication records.
4853 | Cardholder Dispute (Includes 4841, 4855, 4859, 4860)
- Description: A broad category for consumer grievances including goods not as described, services not rendered, cancelled recurring billing, or defective merchandise.
Evidence Requirements: Submit a signed POD or waybill. For cancellation disputes, provide the signed policy and evidence of the cardholder's affirmative consent (for example, a ticked checkbox).
4870 | EMV Chip Liability Shift
- Description: Applicable to counterfeit fraud in a card-present environment where the merchant’s terminal was not EMV-compliant, shifting liability away from the issue.
- Evidence Requirements: Documentation must prove the terminal was EMV-compliant and the transaction was processed as a chip-read transaction.
4871 | Chip Liability Shift: Lost, Stolen, or NRI
- Description: Concerns transactions involving lost or stolen cards where the merchant failed to support PIN-entry on an EMV-capable terminal.
- Evidence Requirements: Provide evidence that the transaction was PIN-verified or that the terminal correctly prompted for PIN entry.
Best Practice Recommendation: It is imperative that merchants ensure Terms and Conditions are conspicuously displayed during the checkout process. Furthermore, all delivery documentation, including waybills and Proof of Delivery (POD) records, should be retained for a minimum of 180 days to facilitate effective dispute resolution. Understanding these processes and preparing adequate documentation can significantly reduce the impact of chargebacks on your business. Please remember, if you are an ISO merchant, your acquiring bank handles your disputes and chargebacks. For Peach Aggregation merchants, we assist with your disputes and chargebacks.
When submitting evidence, please ensure you reply directly to the original dispute notification email. This ensures faster evidence submission to the bank.
Support
For any queries you can reach out to our support team by emailing [email protected]
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article
Still can't find what you're looking for?
Our support team is here to help you with any questions.
Submit a Ticket