Dispute cases

Overview

The Dispute Case provides a place to track customer disputes of transactions that occur. Anytime a customer disputes a transaction made on their card or their account, a Dispute Case must be created to track the lifecycle and events that occur during the investigation into the dispute, including provisional credit amounts and final outcomes.

Customers can dispute transactions for many reasons ranging from not recognizing the transaction to fraudulent transactions by an unauthorized user. The most common reasons for disputes are as follows:

• Amount discrepancy
• Duplicate/Unauthorized transaction
• Victim of fraud, card theft, or identity theft
• Returned merchandise (generally not covered by Reg E)
• Product/Service not as described or not received (generally not covered by Reg E)

Best Practices

The following are best practices for resolving disputes:

• Before creating a dispute, the customer must contact the merchant directly to resolve the issue. If the issue cannot be resolved, a  dispute can be initiated.
• The disputed transaction must be posted to the customer account. A pending transaction cannot be disputed.
• Request supporting documentation, such as receipts or email communication with the merchant and timelines.
• When a card is reported lost, stolen, or compromised, immediately freeze the card to prevent unauthorized transactions. 

When to use the Dispute case type

Dispute Cases should be created manually anytime a customer notifies a Company that they would like to dispute a transaction, whether the notification is via phone call, email, or other means in the Company’s application. This case will track dates and actions taken around disputes, like when the dispute was opened, when the investigation must be completed, when provisional credit was provided, what the amount was, and what the final outcome of the dispute investigation was.

What's displayed for Dispute cases

Customer 

Users must Select Customer to search for the customer. 

You can search for the customer by name, phone number, email, or SSN. 

Account

Select the account accordingly. The account options will depend on the customer selection. If the customer has multiple accounts, ensure you select the account associated with the transaction that will be disputed. 

Transaction

Select the disputed transaction. The transaction options will depend on the account chosen. If you cannot find the transaction, ensure you selected the correct customer account and that the transaction has been posted. A pending transaction cannot be disputed.    

Card Possession and Merchant Name

The Merchant name will automatically populate based on the transaction selection. Select the Card Possession Status, either In Possession or Lost/Stolen. 

External case number

Used for linking the Synctera Dispute Case to other case systems where disputes are also being tracked and investigated. This field is optional. 

Date reported by customer

The date the customer contacted the Company to dispute the transaction. This calculates due dates for provisional credit, investigation completion, and Reg E related dates. The date defaults to the date the case was created. However, if the case is not opened when the customer contacts the Company, it must be updated. The date should be backdated to match if the customer contacted the Company outside business hours or left a voicemail. 

Important dates

Due dates indicate the dates to complete certain aspects of the investigation to meet Reg E timelines. Specifically the standard and extended Provisional Credit Deadlines and the standard and extended Investigation Completion Deadlines. These are auto-calculated based on the Date Reported by the Customer.

Dispute Amount

Used to store the amount the customer is disputing on the transaction. The dispute may be the entire transaction or a partial amount.

Dispute Type

The specific type of dispute the customer is opening, based on defined network dispute types (Fraud, Authorization, Processing, or Consumer).

• Fraud: A cardholder submits a fraud dispute when they see a transaction on their statement that they do not recognize, which can result from a lost or stolen card or a stolen PAN.
• Authorization: An authorization dispute typically occurs when there is a clearing transaction without authorization. In this scenario, the customer account balance may be negative. 
• Processing: A processing error dispute occurs when the transaction was expected, but data such as the transaction amount or account number are incorrect.
• Consumer: A consumer dispute occurs when the customer has a dispute with the merchant, such as a claim that incorrect or defective merchandise was received or that they did not receive the product/service. In this case, the customer demands their money back, and the merchant has refused.

Provisional credit info

Used to store the date and amount of any provisional credit provided to the customer, and if required, the date and amount of that provisional credit that was reversed at the final outcome of the investigation.

Final message date

Used to note the last contact date with the customer to ensure and have proof of compliance with Reg E timelines. Attach any evidence and communication with the customer to the case.

Reviewing and decisioning cases  

Submit case

Take this action when the initial information about the dispute has been gathered and entered into the Synctera Console. From there, the information will be relayed to Marqeta, who will be performing the investigation at the network level and providing updates and possibly requests for further information or documentation from the customer who opened the dispute.

Cancel case

In the scenario where the customer would like to cancel a dispute, the case can be canceled as well.

Mark complete

Take this action when a final decision has been made on the dispute and credit has been provided. This is a terminal state and should be used when the dispute has been confirmed as valid or not valid. Once the case is put into this state, there can be no further action taken.

Mark transaction as fraudulent

Take this action when it is determined by the investigation that the transaction being disputed was fraudulent. This will update the transaction fraud model and notify it that the transaction was fraudulent, helping the model to learn that those types of transactions for the customer should be considered fraud going forward.