How to Spot Duplicate Refund Requests Across Channels

Treat two contacts as possible duplicates when they concern the same order, line item, reason, and requested outcome.

Do not decide refund eligibility during this check. First, connect the contacts to one case and confirm the payment state.

Use the five-part case match

Check these fields in order:

1. Customer identity: email, phone, or marketplace account.
2. Order identity: store order number and sales channel.
3. Item identity: line item, quantity, and variant.
4. Issue identity: reason and event date.
5. Outcome identity: requested refund, replacement, credit, or status update.

Two messages can be separate issues even when they use the same order number. One customer can report a missing item and a damaged item in the same order.

Build one shared case record

Field	Record
Primary case ID	The one case that owns the work
Order and channel	Order number and sales channel
Line items	Exact items and quantities
Contact links	Email, chat, social, and marketplace message IDs
Current payment state	Paid, partially refunded, refunded, or another verified state
Earlier action	Action, amount, method, time, and operator
Approved next outcome	One authorized result or review owner
Customer update	Last message and next update time

Shopify separates order, payment, fulfillment, and return statuses. Review the correct status before you join cases. See Shopify's order-status guide.

Check the payment evidence

Open the order record. Read the timeline and payment details.

For a possible duplicate, record:

• The original payment method
• The refund amount
• The refund status
• The refund event time
• Any error message
• The operator or system that made the event

Shopify recommends reviewing the order timeline, payment method, amount, status, and errors when a refund has a problem. See Shopify's refund troubleshooting guide.

This evidence check prevents a second team from acting on an old message.

Classify the contact

Use one of these labels:

• Duplicate contact: Same issue and same requested outcome. Link it to the primary case.
• Status request: The customer asks about an existing action. Add the message to the same case.
• New issue: The order is the same, but the item, reason, or outcome is different.
• Unclear: A required identifier is missing. Ask for the missing fact before classification.

Worked example

This example is fictional.

A shopper emails about a refund for one blue shirt. Two hours later, the shopper sends a chat message about the same item.

The order timeline shows one pending refund for that line item. The chat is a status request, not a new refund case.

The agent links the chat to the email case. The agent does not issue another payment action.

Separate detection from authorization

The person who matches cases does not need refund authority.

Use this boundary:

• The case matcher collects and links evidence.
• The policy owner decides eligibility.
• The authorized operator performs the approved action.
• The system record stores the result.

See the ecommerce refund-processing guide for the broader role and queue. See ecommerce customer support for general support capacity.

An assistant can keep the linked-case record current. The store must own refund policy and payment authority.