Shopify Admin
Shopify Dispute Statuses Explained: Open, Submitted, Won, and Lost
A Shopify dispute status tells you where the case sits in the bank-response process. Open generally indicates that the merchant response has not yet been sent. Submitted indicates external review. Won and Lost record outcomes. Shopify defines these native states in its Admin dispute guidance.
Read the state from the current case, not from an older email, an order tag, or a colleague’s summary. The practical question is who owns the next action: the merchant, the external review process, or a separate internal follow-up.
Read Open as an available-work stage
Open means the ordinary response has not yet been submitted. It is the stage in which the merchant should identify the claim, verify the deadline, and choose the available response route.
It does not mean that the order itself is unfulfilled or unpaid. Nor does it mean that every possible merchant action remains available indefinitely. The live deadline and controls define the current opportunity.
An open case needs a decision owner. That owner may accept the claim, decide to contest it, or resolve a factual uncertainty before deciding. Leaving the state visible without assigning responsibility does not complete the task.
Where the case is handled through another documented resolution route, do not force it into an assumed Open stage. Some cases do not offer the ordinary response window.
Read Submitted as a handoff to review
Submitted tells the merchant that the case has moved into review. The main operational responsibility changes from completing the available response to observing the external state and preserving the record.
Do not interpret Submitted as Won, or as a promise that funds will return. It confirms a process stage, not the bank’s conclusion. It also should not be confused with merely saving an internal draft or timeline comment.
If a team member says “submitted,” ask what native record supports that statement. The purpose is not bureaucracy; it is to distinguish a merchant intention from an actual transmission state.
Shopify’s process guide separates response submission from the later outcome. Use that distinction when reporting progress to finance or management.
Read outcomes without overstating them
Won and Lost describe the result recorded for the case. The merchant should still read the associated amount and any relevant financial details, particularly where recovery is partial or other adjustments exist.
A favorable outcome does not mean every cost of the original order has disappeared. An unfavorable outcome does not explain the customer’s intent or every event behind the complaint. Keep the result separate from broader conclusions about misconduct or operational performance.
| Native state | Main stage | Useful merchant question |
|---|---|---|
| Open | Response opportunity | What decision and action remain before the live deadline? |
| Submitted | External review | What is the current recorded state, and is there a specific information gap? |
| Won | Favorable outcome recorded | What amount and separate follow-up does the result establish? |
| Lost | Unfavorable outcome recorded | What final result and separate follow-up must be recorded? |
The table maps action ownership. It is not a promise that every case passes through every state in that order.
A hypothetical stale status report
A fictional music-accessory store maintains an internal case list. An employee records a dispute as Open on Monday. On Wednesday, the native case changes to Submitted. On Friday, another employee reads Monday’s note and asks why nobody has completed the response.
The problem is an undated internal interpretation that has fallen behind the native record. The correct update is “Submitted, observed Friday, native case reference attached.” There is no need to change the order’s fulfillment state or invent a new deadline.
Now suppose the case later shows Won. The employee should record the outcome and assign any distinct financial check. They should not assume that the original bank deposit will be reversed and recreated in an obvious one-to-one pattern.
The example is hypothetical. Its lesson is that a state is an observation at a point in time, and a copied state needs its source and date.
Use a status note with a source
A reusable note has four fields: native state, observation time, source case, and next responsible actor. For example: “Submitted; checked at [time]; native case [reference]; external review ongoing, internal owner [name] monitors updates.”
If there is a conflict between an email and the native page, record both timestamps and verify the live case. An earlier notice can be accurate about an earlier stage without being suitable for today’s action.
Avoid using “closed” as a substitute for every final-looking situation. A customer-service conversation can close while the bank case remains submitted. An internal review can finish while finance has a separate task.
Reading statuses well means translating them into the next real responsibility. It keeps the merchant focused on the action that belongs to the current stage and prevents historical notes from directing present-day work.
Review the latest dispute status with Lower Chargeback.
Related reading in this collection:
- Where to Find All Open Chargebacks and Inquiries in Shopify Admin
- Shopify Order Tags vs Chargeback Status: Avoid a False Closed Case
- Using Shopify Sidekick to Understand a Chargeback Reason