Chargeback fundamentals
The Three Chargeback Clocks: Filing, Merchant Response, and Bank Review
Chargebacks run on three different clocks: the cardholder’s filing window, the merchant’s response deadline, and the bank’s review period. Confusing them can make a merchant believe a case is too late to exist, that there is more response time than the case allows, or that a decision should already have arrived.
The safest rule is simple: identify whose action each date controls. A long period in consumer guidance is not extra time for the merchant to respond. A response due date is not a promised bank decision date.
Clock one: the cardholder’s filing opportunity
The filing clock concerns when a cardholder can raise a payment issue under the applicable rules. Its starting event and duration can depend on the transaction, reason, payment system, and jurisdiction. An order date alone is therefore an unreliable basis for declaring a claim impossible.
Consumer rights information also has a defined scope. For example, the US Consumer Financial Protection Bureau discusses credit-card complaint routes in its purchase dispute guidance. That guidance should not be copied into a universal merchant deadline rule for every country and case.
For merchant operations, record the actual case arrival and the relevant transaction. If the timing seems unusual, preserve the question for the processor. Do not ignore an open case because an employee remembers a generic filing limit from another context.
This clock answers whether and when the buyer can initiate a process. It does not tell your staff when their response becomes unavailable.
Clock two: the merchant’s live response deadline
The response clock governs the merchant’s available action in the current case. Read it from the applicable native record, including its time zone and any submission state that affects editability.
This is the date your operational owner must understand. A customer’s message, a support conversation, or a promise to withdraw the claim should not silently replace it. Unless the actual case changes, the merchant should continue to treat the displayed deadline as the relevant boundary.
Shopify’s Admin documentation explains the native due-date display and the limit on evidence after the deadline. The screen-level lookup is a separate task; conceptually, this clock belongs to the merchant’s response opportunity.
If the case transitions into another stage, verify its current deadline again. Do not assume that an earlier notice remains the correct source for the new state.
Clock three: the bank’s review period
Once the response is submitted, the bank process reviews the case. That elapsed period belongs to the external decision stage. The merchant can monitor the native status, but waiting does not imply that the response window remains open.
Avoid putting the end of an estimated review period into a cash forecast as guaranteed recovery. The case may resolve unfavorably, partially, or on a different schedule from the estimate. The Shopify process guide describes review timing in its workflow; the actual result must still be observed.
An internal follow-up date is useful here, provided it is labeled correctly. “Review status on Friday” is a merchant reminder, not the bank’s deadline. Keeping that distinction visible prevents self-created dates from being mistaken for external commitments.
A hypothetical timeline with three owners
Consider a hypothetical purchase on 3 March for delivery later that month. A bank case reaches the merchant on 18 April. The native case gives a response deadline of 29 April in the store’s time zone. The merchant submits on 25 April, and the case then shows a review state.
The 3 March purchase date is part of the transaction history. The filing rules concern the buyer’s route and applicable starting event. The 29 April date concerns the merchant’s available response. The interval after 25 April concerns the bank’s review.
None of those dates can substitute for another. The merchant cannot use a consumer filing window to extend 29 April. It cannot assume that 29 April is the bank’s decision date. It should not report the case as overdue merely because an internal employee expected a result sooner.
All dates and amounts in this example are hypothetical; the method is to label ownership and meaning before taking action.
Use a date register that prevents substitution
| Date field | Record beside it |
|---|---|
| Transaction or promised-service date | What event occurred and which transaction it concerns |
| Case opened or received | Source and timestamp of the case notification |
| Merchant response due | Native case, time zone, and current response state |
| Response submitted | Confirmation source and actual submission time |
| Internal review reminder | Staff owner and purpose of the check |
| Outcome date | Native result and when it was observed |
A good register does not need to contain a guessed bank decision date. It needs to distinguish verified dates from estimates and internal reminders.
Before acting on any chargeback date, finish the sentence “This date controls…” If the answer is unclear, resolve that ambiguity first. Knowing which clock you are reading is the foundation for making the right decision at the right time.
Explore Lower Chargeback to review the merchant response deadlines on your disputes.
Related reading in this collection:
- What Is a Chargeback? A Shopify Merchant’s Starting Guide
- Does Canceling a Shopify Order Cancel Its Chargeback?
- Can You Refund a Shopify Inquiry Before It Becomes a Chargeback?