Skip to main content

Version 2 Rollout

This is the Version 2 (V2) Card Transaction Disputes guide. For the Version 1 flow, see Card Transaction Disputes (V1).The planned rollout for Version 2 of Synctera’s Dispute Management is as follows:
  • Mastercard programs: September 7 – October 7, 2026
    • Synctera will notify you of the exact date. Until then, follow the V1 flow.
  • Visa and PULSE programs: TBD
    • Keep following the V1 flow until further notice.
Key changes between V1 and V2:
  • Reason codes have been streamlined (deprecated codes remain accepted for backward compatibility)
  • Comprehensive evidence gathering at dispute creation to strengthen the case — see evidence in the Create Dispute spec.
  • New lifecycle states, including more granular declined-dispute states: Withdrawn, Refunded, Expired, Rejected
  • Dispute document categories — some reason codes require specific categories on submission

Overview

In order to manage the card dispute process, the Synctera API provides support for the required tasks such as submitting a dispute, uploading supporting documentation, and tracking status through the card network. Synctera evaluates evidence and interacts with the card network on your behalf. As mentioned under Transaction Disputes, a Dispute Case gets automatically created once a dispute is opened. The Dispute Case is used to track and reflect the dispute status through the Synctera Console.

What Transactions Can Be Disputed?

  • Only posted transactions can be disputed, and only if within 120 days from the settlement. A pending transaction cannot be disputed.
  • A dispute cannot exceed the amount of the original transaction.
  • For fraud disputes (reason_code = UNAUTHORIZED_TRANSACTION), the card must be terminated before the dispute can be created.

Chargeback Dispute Lifecycle

The chargeback dispute lifecycle involves a series of actions between the issuer and acquirer, which continues until a decision is reached on who is financially responsible for the dispute. The dispute lifecycle is also described in this article. Card disputes start in EVIDENCE_GATHERING. After evidence is submitted via EVIDENCE_GATHERING.COMPLETE, Synctera evaluates the case and files with the card network when appropriate. Subsequent lifecycle updates (chargeback, representment, outcomes, and similar) are applied automatically and surfaced via DISPUTE.UPDATED webhooks and GET responses.

1. Chargeback

Time frame within 120 days of settlement of the transaction.
A chargeback is filed when the transaction meets the conditions listed in the reason codes found below. This happens after EVIDENCE_GATHERING.COMPLETE, when Synctera determines a chargeback should be filed.

2. Representment

Time frame within 45 days of chargeback.
A representment occurs when the acquiring bank either has evidence to prove that the chargeback does not meet the requirements of the reason code or can provide information that addresses the original reason for the dispute.

3. Pre-arbitration

Time frame within 45 days of representment.
Pre-arbitration is the final chance for the issuing bank to provide further evidence that the cardholder should be refunded for their transaction.

4. Arbitration

Time frame within 75 days of pre-arbitration.
In the event that the issuer and acquirer cannot settle on an outcome of the financial responsibility of the transaction, the dispute can be raised to arbitration. Arbitration leaves the decision of who is financially responsible in the hands of third party arbitrators (the card network).
Issuers and acquirers generally choose to avoid arbitration as it involves fees as high as $500 or more per case in addition to any other fees associated with the dispute.

Write-Offs

In cases where a transaction’s value is lower than the cost of pursuing a dispute, it can be written off instead of filing with the card network. A write-off is submitted (WRITE_OFF.SUBMITTED) automatically or by an issuer, then accepted automatically (WRITE_OFF.ACCEPTED). Any provisional credit is reversed, a final credit is posted, and the dispute is closed.

Automatic Write-Offs

Synctera can configure an automatic write-off threshold for your program. When a dispute is created and both of the following are true, Synctera routes it through the automatic write-off workflow instead of filing with the network:
  • The disputed amount is less than or equal to the configured threshold
  • The dispute is created no more than 120 days after the disputed transaction’s effective date
Those disputes are created with managed_by = AUTO_WRITE_OFF and network = NONE. Synctera later submits a WRITE_OFF action automatically, moving the dispute to the WRITE_OFF lifecycle. No issuer network actions are available on automatic write-off disputes. Automatic write-off is enabled by default with a $25 threshold. Contact your Synctera representative to disable it or change the threshold for your program.

Reason Code

When creating a dispute, the Reason Code is the most critical field in your request. It acts as the formal classification for the claim, signaling to the network exactly why the transaction is being challenged. Selecting the correct code ensures the case is evaluated under the proper network rules and significantly improves the chances of a successful resolution.

Selecting a Reason Code

To ensure your dispute meets all technical requirements, please refer to the supported codes in our documentation.
View the Codes: Click the link below and ensure the Card Dispute tab is selected in the Body parameters section to see the full list of codes and required documentation.
Some reason codes also require additional evidence on create, or a dispute document uploaded with a specific category before the case can be filed — see Upload Supporting Documents.
Please ensure you are using Active codes. While some legacy codes are still accepted for backward compatibility, they are deprecated and will be automatically mapped to their modern equivalents by the API. Using the active code from the start ensures better tracking and transparency for your case.

Card Dispute Lifecycle States

Available Actions

Actions on a card dispute come from different actors. FinTech actions are available via the Disputes API. Issuer actions may be issued automatically or manually by a Synctera operator when a case needs review. Acquirer / network actions are applied automatically as the case progresses with the card network and appear in action_history via DISPUTE.UPDATED webhooks.

Issuer Actions (FinTech)

Issuer actions available to FinTechs via the Disputes API.

Issuer Actions (Synctera)

Issuer actions that may be issued automatically or manually by a Synctera operator (for example in MANUAL_REVIEW after chargeback or representment review, or after a pre-arbitration rebuttal). These appear in action_history and trigger DISPUTE.UPDATED webhooks.

Acquirer / Network Actions

Applied automatically as the dispute progresses with the acquirer and card network. Action values below match action_history responses.

Provisional Credits

Provisional credits may be issued to the cardholder as a temporary measure while investigating the dispute. Whether or not a provisional credit is required, is determined by the applicable regulations. The relevant regulations/timelines that apply can be derived from the transaction being disputed by identifying which type of card program the transaction belongs to.

To Summarize:

  • Regulation E (US) applies to consumer debit transactions - it mandates issuance of provisional credit to the customer account while the dispute is under investigation (within 10 business days for established customers, and within 20 business days for new customers)
  • Regulation Z (US) applies to consumer credit transactions - it mandates that a transaction that is under dispute is not included in the outstanding/due balances, and is not included in the available credit balance
  • These regulations also have strict timelines around customer notifications, which is ultimately the responsibility of the FinTech - for details, see this article
  • There are no specific regulations around commercial transactions
  • Card networks also have their own “zero liability” policies - cardholders won’t be held responsible for unauthorized charges made with their card or card information provided they promptly report the issue
  • Note that although issuance of provisional credit may not be mandated by regulations, the FinTech may still decide to issue provisional credit

Complex Business Flow Example

The following example walks through a card dispute: create → upload evidence → complete evidence gathering → chargeback filed → provisional credit → representment → dispute lost.

1. Dispute Created

A dispute is created on behalf of the cardholder. Disputes start in EVIDENCE_GATHERING. Include any required evidence fields for the chosen reason_code.
Request
Response

2. Upload Documents and Complete Evidence Gathering

Supporting documentation is uploaded to the dispute. Files must be JPEG, PNG, or PDF, max 4.5MB each, up to 10 documents. Optionally set category (for example TRANSACTION_RECEIPT, MERCHANT_CORRESPONDENCE, OTHER).
Request
Response
Complete evidence gathering to create and file the case with the network.
Request
Response

Dispute State

The dispute moves to EVALUATION. Synctera then evaluates and may file a chargeback (or write-off / request review). Further network steps arrive as webhook-driven action history updates.

3. Chargeback Submitted

After evaluation, Synctera files a chargeback with the card network. This appears as a DISPUTE.UPDATED webhook with CHARGEBACK.SUBMITTED in action_history. The dispute moves to CHARGEBACK.

Dispute State

4. Post Provisional Credit

A provisional credit may be issued after the chargeback has been filed.
Request
Response

Dispute State

5. Webhook Received for Representment

Dispute State

A representment from the acquirer is reflected on the dispute via DISPUTE.UPDATED, including any supporting documentation from the network.

6. Dispute Lost

The issuer records that the cardholder accepts liability after representment (DISPUTE.LOST).
Request

Dispute State

The dispute now reflects the final decision. Any outstanding provisional credit is reversed on a delay (not immediately).

7. Close Dispute

After the provisional credit has been reversed (credit_status = NONE), close the dispute.
Request

Simulating Network Dispute Actions

Sandbox Environment OnlySimulations are intended for use only in the testing environment to simulate a network action on a dispute. For dispute creation and issuer actions, follow the steps listed in the Transaction Disputes API Guide.
In production, acquirer / network actions are applied automatically as the case progresses with the card network. In sandbox, use simulations to advance those same steps without waiting on a live network response. Network dispute simulations must follow the logical order of the dispute lifecycle — for example, after a chargeback is submitted you can simulate a representment. For a complete list of network actions, see Acquirer / Network Actions. To progress a dispute to the next lifecycle and simulate a network response, use POST /v1/disputes/simulations/{$dispute_id}/actions. Request bodies use state (for example CREATE); matching entries in action_history use status (for example SUBMITTED).