Skip to main content

​
Filing a Case via API

Filing submits a dispute to the card network on behalf of the cardholder. For context on where filing fits in the dispute lifecycle, see What Are Disputes?. You can file a case using the file case endpoint.
Once a case is filed with the card network, it cannot be modified or deleted.

​
file_mode Options

Cases support two filing modes: auto - Your workflow rules will be evaluated and Decisionly will determine whether the case should be filed. This is the recommended mode for most use cases. chargeback - Decisionly will attempt to file the case as a chargeback, regardless of your workflow rules. Use this when you want to bypass workflow rule evaluation.

​
Queueing a Case That Is Too Early to File

Some card networks require a waiting period before filing for dispute types, for example a credit_not_processed chargeback cannot be filed until 15 days after the refund promise date for Visa. See Filing Timelines for the waiting period that applies to each network and dispute reason. If you file a case before its waiting period has passed, the request fails with a filing_too_early validation error. Instead of tracking the earliest filing date yourself and retrying, you can pass queue_if_too_early to queue the case for automatic filing:
Queue a case that is too early to file
If the case is blocked only by a waiting period, the request returns 202 Accepted and the case is queued. Decisionly will automatically file once its waiting period has passed. If you use file_mode auto, your workflow rules will be run first, and the case will only be queued if it would have been filed but for the waiting period. You can track queued cases through webhooks: case.queued fires when the case is queued, case.chargeback_filed fires when it is later filed, and case.chargeback_needs_review fires if the case needs manual review.
Queueing is opt-in. Without queue_if_too_early, a case that is too early to file is rejected with a filing_too_early error and is never queued. The flag has no effect when the case fails validation for any other reason — those requests still return 400 with the full list of errors.