A customer emails asking where the refund went. Your admin panel says “refunded,” dated six days ago. Their bank account says nothing arrived. Support sends back the standard line: it can take up to ten business days to show on a statement. Nobody in that exchange is lying, and nobody walks away satisfied either.
Multiply that message by every refund request a month and you have a support cost that never shows up on a P&L line called “refund turnaround time.” Worse, if part of the delay is genuinely internal — not the bank’s queue at all — it’s a control gap hiding behind a customer-facing excuse. The number most teams quote publicly is rarely the number that actually explains the complaint.
Why “we issued the refund” isn’t the whole story
Refund turnaround time ecommerce teams report to customers is really two separate clocks running one after another, and almost nobody measures them separately. The first clock is internal: everything between a customer asking for money back and the business actually triggering that refund inside the payment platform. The second clock belongs to the card network and the issuing bank, and it starts only once the first clock stops.
Collapse both clocks into one number and you lose the ability to see where the real delay sits. A refund that took nine days to reach a customer’s statement might have taken six of those days inside your own workflow — sitting in an inbox, waiting on a sign-off, waiting for a warehouse scan — and only three in transit through the card network. Or the split could run the other way. Without separating the two, every slow refund gets blamed on “the bank,” and the actual bottleneck never gets fixed.
The ownership gaps usually look familiar once someone maps them out: a refund request sitting unread in a shared inbox over a weekend, an approval that depends on one person checking email once a day with no backup, a returned item that arrives at the warehouse and sits unscanned for two or three days before anyone logs it. None of these show up as “refund delay” in a support ticket. They show up as a customer who thinks your business is slow to give money back, when the truth is closer to: nobody owns the handoff.
Map the six stages a refund actually passes through
A refund isn’t one event. It’s a sequence, and each stage has a different owner and a different failure mode. Laying it out this way is the only way to find where a specific refund actually stalled, instead of guessing.
| Stage | Who owns it | Where it breaks |
|---|---|---|
| 1. Request logged | Support agent / help desk | Sits unassigned in a shared inbox over a weekend before anyone reads it |
| 2. Eligibility review | Support agent, against policy | Agent isn’t sure if an exception applies and waits for a second opinion instead of escalating |
| 3. Approval / exception decision | Team lead or founder | Sign-off depends on one person checking email once a day; no backup approver exists |
| 4. Return receipt confirmation | Warehouse or 3PL | Item arrives and sits unscanned for two or three days before anyone logs it |
| 5. Refund initiated in platform | Support agent or finance | Approved refunds pile up and get processed in a weekly batch instead of daily |
| 6. Bank / card network posting | Card issuer, outside the business | Customer checks their statement before the network has finished routing the credit |
Stages one through five sit inside the business. Stage six doesn’t, and treating it as if it does is where most of the public frustration comes from.
A stall-test for each stage
Mapping the stages is only useful if you also know roughly how long each one should take before it counts as stuck. None of these are hard rules — order volume and team size change the math — but they’re a reasonable starting point for a small operation to flag a refund before a customer has to chase it.
- Stage 1 to 2: if a logged request sits without an eligibility decision for more than one business day, it’s been forgotten, not reviewed.
- Stage 2 to 3: if eligibility is confirmed but approval hasn’t happened within 48 hours, the approver is a single point of failure.
- Stage 3 to 4: for returns requiring a physical item back, this stage will legitimately run several days — measure it, but don’t penalize the team for shipping time.
- Stage 4 to 5: once an item is scanned in, the refund should trigger the same day or the next business day, not on a weekly batch.
- Stage 5 to 6: the moment the refund is initiated in the platform, your team’s clock stops. Anything past this point belongs to the card network, not to operations.
A returned order that arrives on a Friday afternoon is a useful test case. If the item sits unscanned until Monday, that’s a warehouse staffing gap, not a card network delay — and it’s exactly the kind of gap that gets mislabeled as “bank processing” in a support reply, because nobody wants to tell a customer the item has been sitting on a shelf.
| If approval delays or unclear eligibility rules are the pattern you recognize:The Return & Refund Operations Handbook lays out approval thresholds, exception routing and refund SLAs you can put in place this week — view the Handbook. |
Internal cycle time vs. bank processing time — stop measuring them as one number
Once a refund leaves your platform, the timeline is no longer yours to control, and it helps to know roughly what that stage actually costs so you can stop apologizing for it as if it were an internal failure.
Card issuers generally take about three to seven business days to post a merchant-initiated credit once it’s been processed and submitted through the network, according to consumer-finance guidance from Experian.
U.S. News & World Report notes that a wait of up to ten business days after a merchant processes a refund is still within normal range, and that a formal dispute — as opposed to a standard merchant-agreed return — follows a completely different and much longer timeline, since it involves the card issuer investigating the claim rather than simply posting a credit.
That means a refund your team triggers on a Monday can reasonably take until the following Wednesday or later to appear on a customer’s statement, purely on the bank side, with zero internal delay involved. Knowing that range matters for two reasons: it tells support agents what to say with confidence instead of guessing, and it gives operations a baseline to subtract from the total complaint timeline so the internal number left over is the one worth fixing.
This split also changes what a support reply should say. “Your refund can take up to ten business days to post once it’s issued” is accurate and defensible. “We’re still processing your refund” after the platform already shows it as issued is not — it’s a guess dressed up as a status update, and customers can usually tell the difference even if they can’t name it.
A refund SLA tracker you can build today
You don’t need new software to separate the two clocks. A shared sheet with the fields below, filled in per refund, is enough to see the pattern within a few weeks.
| Field | What it captures |
|---|---|
| Order ID | Links the refund back to the original transaction |
| Request logged date | When the customer first asked, not when someone replied |
| Eligibility decision date | When policy fit was confirmed, approved or flagged as an exception |
| Approval date | When a decision-maker actually signed off, separate from the review step |
| Return received date | When the warehouse or 3PL scanned the item in, if a physical return applies |
| Refund initiated date | When the credit was actually triggered inside Shopify, Shopee or Lazada |
| Internal cycle time (days) | Refund initiated date minus request logged date — the number the business controls |
| Customer-confirmed posting date | Optional follow-up field, useful for pattern-spotting but not for grading the team |
The field that matters most is internal cycle time, because it’s the only number your team fully controls. Once you’re logging it consistently, look at the median rather than the average — a single stuck refund from a busy week will skew an average and hide what’s normal.
Across 9,025 orders and a 1.71% overall refund rate, the pattern that separated a well-controlled refund cycle from a painful one was almost never the card network. It was stage three — the approval hop — which is the step most teams leave undocumented and dependent on one person’s calendar.
Where this fits in your existing return and refund SOP
Refund turnaround time doesn’t sit on its own. It connects directly to how returned inventory gets handled once it arrives, which shapes stage four of the map above — see how that decision plays out in Dispose vs Resell Returned Inventory: A Decision Framework for DTC Brands. It also depends on a clean handoff between the warehouse and support, covered in How Untracked Return Inventory Quietly Becomes a Warehouse and Brand Risk.
Fix the handoffs in those two areas and stage four of the refund map — the return receipt step — usually stops being the bottleneck it currently is.
Get an outside read on where your cycle time is stuck
Most teams already sense which stage is the problem before they’ve measured anything — someone mentions the approval queue, or the warehouse mentions a backlog, in passing during an unrelated conversation. The tracker above exists mainly to turn that hunch into a number you can act on, and to stop the conversation from ending at “the bank is slow,” which is rarely the full answer and almost never the fixable part.
| Two ways to move on this:Build the SLA and approval structure yourself with the Return & Refund Operations Handbook — it covers eligibility rules, approval thresholds, exception handling and the refund KPIs to track going forward.Or, if you’d rather have someone look at your specific workflow first, request the complimentary 30-minute Operations Review through the Professional Operations Health Check. Review requests are limited and assessed for operational fit — it isn’t an automatic booking, but it’s a direct way to get a second set of eyes on where your specific refund cycle is losing time. |
About CX Ops Lab
CX Ops Lab publishes operational frameworks, SOP templates, and case-study content built from real DTC ecommerce operations — not theory. Every framework was pressure-tested during live operational conditions across Shopify, Shopee, and Lazada at $610,000+ USD GMV scale.
Website: cxopslab.io │ Products: payhip.com/CXOpsLab