INTEGRATION
TRANSACTION ASSURANCE
CHARGES
DISPUTES & FRAUD
Dispute Lifecycle
Dispute Monitoring
All card networks hold their acquirers responsible for monitoring their (and merchants') dispute metrics. Therefore, it is mandatory to monitor the number and volumes of (fraud) chargebacks and Fraud Notifications at both the BIN and the MID levels. For more information about scheme thresholds, please refer to the network-specific rule manuals. The reporting endpoints allow acquirers to retrieve the data at any required levels to monitor the metrics and rates they want/need to monitor.
Dispute operations include receiving disputes, notifying merchants about new or updated disputes, downloading documentation provided by the issuer, uploading evidence to be submitted as evidence in defense, reviewing the evidence, accepting liability for a dispute, and defending (representing) a dispute. The following diagram depicts an overview of dispute operations. Dispute operations make use of three interrelated objects:
Disputes
Dispute Events
Dispute Event Notifications
Dispute Documents
Disputes
The Dispute object is generated when a first chargeback comes in. A dispute is directly related to a single transaction (if Silverflow processes this transaction, it will also be related to a charge). It has a unique card network reference (disputeReference
) that stays the same throughout the dispute process. All attachments related to the dispute will be attached to the Dispute object.
Dispute Events
The Dispute Event is generated whenever there is a status change on the Dispute. It contains information and a link to any evidence that was passed to the opposing party by either the issuer or the acquirer at that stage of the dispute. The information in the Dispute Event contains the key elements that make the case of the issuer or acquirer at that stage of the dispute based on the card network rules.
Event | Dispute Status | Description | Actionable Status | Who |
New dispute | Received | A new dispute is received | Yes | Evidence Submitter |
Defend or accept action by merchant or acquirer | Acceptance/Defense Initiated | A defense or acceptance has been initiated | No | |
Submit evidence for review | Evidence Submitted | Evidence was submitted by the merchant and needs to be reviewed | Yes | Evidence Reviewer |
Reject submitted evidence | Evidence Rejected | Evidence was rejected by a reviewer and needs to be re-assessed by the submitter | Yes | Evidence Submitter |
Error when submitting defense to schemes | Defense Failed | Technical error when submitting defense to card network | Yes | Evidence Submitter |
Successful submission of defense to schemes | Awaiting Response | A defense was successfully submitted to the card network | No | |
Liability accepted by the issuer or expired dispute | Closed - Won | The issuer has accepted liability for the dispute | No | |
Liability accepted by merchant/acquirer or expired dispute | Closed - Accepted | Liability was successfully accepted for the dispute | No |
Dispute Event Notifications
Event notifications are sent to a URL specified by the Client when creating an event subscription webhook. Events are emitted in case a new Dispute object is created or if the status of an existing Dispute changes. An event notification contains both the Dispute key
and the Dispute Event key
. For more details, please refer to the Event Notifications section.
Documents
A Document is a file with associated metadata that can be uploaded and downloaded through the Silverflow API. Documents such as Dispute documents have to be attached to a business entity. The Document upload process starts with creating metadata information; see Add Dispute Document. New Documents will be created with status pending
. Adding a Document returns a document-key; use that document-key to upload the file using Upload Document. Once the file is successfully updated, the status will be changed to active
. The maximum size for a Document is 10MB. Supported MIME types:
image/jpeg
application/pdf
image/tiff