Chargeback vs Refund: Who Initiates Each and Why It Matters

A refund is initiated by the merchant through the payment workflow. A chargeback is initiated through the cardholder’s bank. Both can return money to a buyer, but they travel through different processes, create different records, and leave the merchant with different responsibilities.

This difference matters most when a customer says “I want my money back.” That sentence expresses a desired outcome. It does not identify whether the merchant is considering a refund, answering an existing bank dispute, or doing both kinds of operational work around the same purchase. Shopify describes the bank process in its chargeback overview.

Identify who started the money movement

A merchant refund begins with an authorized store decision and a refund transaction. It might follow a return, an order adjustment, a service failure, or a goodwill resolution. The merchant should be able to identify what was refunded, how much, when, and against which payment.

A chargeback begins outside that refund decision. The cardholder contacts the issuer, and the payment system creates a case. The merchant receives a dispute reason and, where applicable, a response opportunity.

The distinction remains even when the underlying complaint is identical. An item arriving broken can produce a direct request to the store or a bank claim. Understanding the complaint does not tell you which financial process has already started.

Keep customer resolution and case resolution separate

Your store can resolve a complaint in ordinary language without the bank case being resolved in the payment system. A customer might accept an explanation, agree to a replacement, or say they have contacted their bank. Those are meaningful developments, but they do not replace the case status.

Similarly, a refund request is not proof that a refund was processed. A support note saying “approved” describes a decision. The payment record establishes the transaction. Confusing approval, processing, and completion makes it difficult to explain what the customer should expect.

Use verbs carefully in internal records. “Requested,” “approved,” “issued,” and “case closed” describe different events. Attach the source and date to the event you can actually verify. If you only know that a colleague promised a refund, record that promise rather than writing that funds have been returned.

This language discipline is useful for finance, support, and dispute review because each team can see what remains unresolved without reconstructing the entire conversation.

Check the existing state before another payment action

The presence of a bank case changes the context of any proposed refund. Shopify’s native dispute instructions state that the disputed payment cannot be refunded through Shopify once the chargeback process has started. They distinguish inquiries from chargebacks when discussing refund availability.

Treat that as a reason to verify the state first. Do not assume a separate transfer, gift card, or unrelated payment will close the bank case. An additional transfer can create a second value movement while leaving the original dispute active.

This is not a refund tutorial. The decision point is whether the action under discussion belongs to a normal refund workflow or an existing bank process. Once that is clear, follow the applicable native instructions and approval authority.

Shopify’s refund documentation describes the merchant refund workflow. Its existence should not be read as permission to apply every refund action to every disputed payment.

A hypothetical customer conversation

Imagine a fictional luggage store receives a complaint about a $160 bag. On Monday, support approves a refund. On Tuesday, the customer says they have disputed the charge. On Wednesday, an operations employee reviews the order.

A weak record says: “Refunded; close complaint.” It assumes that Monday’s approval became a transaction and that any bank case is therefore finished.

A useful record asks three separate questions. Was a refund transaction actually created? Is there a bank case, and for which payment? What is its current state? The answers might show an approved but unprocessed refund and an open chargeback. Alternatively, they might show a completed refund and a bank case that still needs attention.

The merchant must preserve that sequence. The dates explain why the customer acted and help the team avoid describing a later event as if it had happened earlier.

Label records so the distinction survives handoff

Use separate fields for customer remedy, refund transaction, and dispute case. For example: “Remedy approved: full purchase amount. Refund record: pending verification. Bank case: open, native reference recorded. Next owner: payments lead.”

That short entry is more useful than a broad “money returned” label. It tells the next reader what is known and what must still be checked.

A refund and a chargeback can relate to the same complaint, but they are not interchangeable records. Clear identification of initiator, transaction, and case state is the foundation for deciding what the merchant should do next.

Review dispute status with Lower Chargeback before making your merchant decision.

Explore dispute monitoring

Related reading in this collection:

• What Is a Chargeback? A Shopify Merchant’s Starting Guide
• Chargeback Fees vs Payment Processing Fees: Read the Right Cost Line
• Return Abuse vs Chargeback Abuse: Two Different Loss Paths