Chargeback fundamentals
The Shopify Chargeback Process: Who Acts at Each Stage?
In a Shopify card dispute, the merchant supplies facts and chooses available merchant actions, the payment infrastructure carries the case, and the cardholder’s bank makes the dispute decision under the applicable process. Shopify provides the merchant-facing workflow for Shopify Payments; it is not the authority that decides whether the customer’s claim succeeds.
Knowing who owns each step saves time. A missing button, an unanswered bank allegation, and an outcome you disagree with are different problems. Sending all three to the same party with the same request is unlikely to resolve them. Shopify states its decision boundary in its chargeback process guidance.
Distinguish the parties by function
The cardholder is the person whose payment is challenged. The issuer is the cardholder’s bank. The merchant is the business that accepted the purchase. The acquiring side and processor connect that merchant to card payment processing. The card network supplies the framework through which participants exchange payment and dispute messages.
Shopify sits in the merchant’s operational experience, with Shopify Payments providing a native payment workflow where applicable. A third-party gateway can put a different provider between the merchant and the dispute process. Product names do not eliminate these underlying roles.
These functions may be delivered through related companies or arrangements. You do not need to reconstruct every contractual entity before reviewing a case. You do need to know which portal contains the official merchant response and which support team can investigate access or transmission problems.
Stripe’s overview of chargebacks describes the participants in the wider card process. Use that background to understand responsibilities, while following the instructions of your own payment provider.
Map stages to the next responsible actor
| Stage | Main actor | Merchant’s useful task |
|---|---|---|
| Cardholder raises concern | Cardholder and issuer | Establish what transaction and allegation reached the store |
| Case enters merchant workflow | Payment infrastructure and provider | Verify the current native case and available actions |
| Merchant review | Merchant | Decide the position and assign the work |
| Merchant response transmission | Provider’s documented channel | Confirm the recorded submission state |
| Case review | Issuer and applicable card process | Monitor status and preserve the record |
| Outcome recorded | Bank process, then provider records | Interpret the result and assign financial follow-up |
The table is deliberately about ownership, not exact elapsed time. An issuer’s filing window, a merchant’s response deadline, and a later review period are separate clocks. The case-specific deadline belongs in the live record.
Some cases are handled through an automatic resolution arrangement and do not offer the ordinary response stage. If the native case has no contest option, first identify its actual route instead of assuming an employee has failed to locate a universal button.
Route the problem to the party able to act
Start by writing the obstacle as a sentence. “We do not understand the customer’s allegation” calls for reviewing the case and any issuer details. “Our authorized user cannot access the dispute page” calls for an access investigation. “The case says submitted, but we need to know what was transmitted” calls for checking the native response record.
A disagreement with the outcome is another category. A platform support agent cannot turn a general statement that the merchant is right into a replacement bank decision. If you contact support, identify the observable system problem or information gap that support can actually investigate.
This makes escalation more productive without giving up a legitimate concern. “Please check whether the response file is available for this case” is a verifiable request. “Please reverse the bank because the parcel was delivered” assigns authority to the wrong party.
A hypothetical responsibility failure
A fictional outdoor store receives a nonreceipt chargeback. Its support team assumes the fulfillment team will answer because shipping is involved. Fulfillment assumes Shopify will contact the carrier. Finance records the debit but does not assign a merchant response owner.
All three teams perform a plausible piece of work, yet nobody owns the merchant decision. The failure is not missing expertise; it is a missing handoff between roles.
A corrected allocation gives operations ownership of the case, fulfillment responsibility for factual shipment information, and finance responsibility for identifying the financial movement. The named merchant owner verifies the available response route and its deadline. Shopify’s native workflow carries the response where applicable. The bank reviews it.
No role is expected to control something outside its authority. This makes it easier to see whether the next step is waiting on a colleague, a platform event, or an external decision.
Make the ownership record reusable
For each case, capture the processor, official portal, merchant decision owner, information contributors, submission confirmation, and current external stage. Name a backup for the merchant owner when absence could interrupt the work.
At handoff, use a sentence with an actor and an output: “Fulfillment will confirm the shipment record for this order”; “Operations will determine the response position”; “Finance will identify the disputed debit.” Avoid the vague instruction “handle chargeback,” which hides several distinct responsibilities.
A clear process map cannot promise a favorable outcome. It gives every issue a sensible destination and prevents a case from spending its response window between teams that each believe someone else owns it.
Explore Lower Chargeback’s Safety information to understand the product’s role in your workflow.
Related reading in this collection:
- What Is a Chargeback? A Shopify Merchant’s Starting Guide
- Shopify Chargeback Reasons: A Plain-English Map for Merchants
- Failed Delivery Attempts: Who Contacts the Customer and What Happens Next?