Documentation Index
Fetch the complete documentation index at: https://docs.synctera.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
Disputing a transaction involves a series of actions between the two parties involved in a dispute, where supporting documentation is exchanged until a decision is reached on who is financially responsible. To begin the dispute process a dispute is opened on a transaction. The dispute can be opened through the Synctera Console or the Disputes API, which is described below. When the dispute is opened, a Dispute Case is automatically created. The Dispute and the Dispute case are used to track the dispute details, lifecycle and events that occur during the investigation into the dispute. The Dispute Case and the Dispute Lifecycle are described in this article. Through both the Dispute Case in the Synctera Console, and the Disputes API, the user is guided through the Dispute Flow. Depending on the payment rail of the original transaction that is being disputed, a list of available actions will be returned to process the next step of the dispute. Once an action is created against a dispute, subsequent actions will be made available to the opposing party.Webhook Events
To monitor transaction disputes, webhooks are triggered anytime one of the following events occurs:| Webhook | Description |
|---|---|
DISPUTE.CREATED | A new dispute has been created. |
DISPUTE.UPDATED | An existing dispute has been updated. |
Disputing a Transaction
The following steps will walk you through the process of disputing a transaction. Refer to the links below for specific details on supported payment rails:Card Transaction Disputes
1. Create a Dispute
To create a dispute, use POST /v1/disputes.id attribute and the list of available_actions.
2. Upload Supporting Documents
To add supporting documentation to the dispute, use POST /v1/disputes/{dispute_id}/documentsid attribute as it will be used to include the document in subsequent dispute actions.
3. Create a Dispute Action
Select the action you wish to create from the list ofavailable_actions on the dispute.
To create the action, use POST /v1/disputes/{$dispute_id}/actions
4. Monitor for Network Updates
When a response is received from the network aDISPUTE.UPDATE webhook is triggered and the dispute will contain the updated action history. Depending on the action received a decision on the dispute may be reached or further actions may be available.
In the event that the dispute decision is still ONGOING the update received from the network should contain further evidence for review.
An example DISPUTE.UPDATE for a re-presentment will contain additional dispute info as follows:
supporting_doc_id of the new action as it will be used to retrieve the new document contents for review.
5. Review Additional Supporting Documents
To retrieve supporting documentation from the dispute, use GET /v1/disputes/documents/{document_id}/contents6. File Additional Actions as Needed
If the dispute has reached a final decisionWON or LOST no further action is required. If the dispute decision is ONGOING additional actions will be available on the dispute and a decision on how to continue the dispute is needed based on review of the additional supporting documentation. Actions can continue to be taken to progress the dispute through its lifecycle until a final decision is reached.