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.
- Reason codes have been streamlined (deprecated codes remain accepted for backward compatibility)
- Comprehensive evidence gathering at dispute creation to strengthen the case — see
evidencein 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 inEVIDENCE_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).
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
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.
evidence on create, or a dispute document uploaded with a specific category before the case can be filed — see Upload Supporting Documents.
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 inaction_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 inMANUAL_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 matchaction_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 inEVIDENCE_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 setcategory (for example TRANSACTION_RECEIPT, MERCHANT_CORRESPONDENCE, OTHER).
Request
Response
Request
Response
Dispute State
The dispute moves toEVALUATION. 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 aDISPUTE.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 viaDISPUTE.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
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, usePOST /v1/disputes/simulations/{$dispute_id}/actions. Request bodies use state (for example CREATE); matching entries in action_history use status (for example SUBMITTED).

