Processing time limits must be stated
Aliases: refund timeline · time to refund · refund SLA
What it is
When a refund is requested, people must see time limits: how long merchant review takes, when money leaves the merchant, when the rail credits the account. Stated means a checkable window (X business days, a latest date), not “as soon as possible” or “usually quick.” This is not whether the entry is findable, and not how a stage bar is drawn—a bar with no clock is comfort animation.
Why it happens
A refund stretches a loss already taken. Uncertain waits cost more than known long waits because people cannot plan: statement close, the next purchase, whether to dispute with the bank. Merchant review, finance payout, and rail credit are three clocks; one “seven days to arrive” explodes on day eight—the payout may have left while the scheme has not posted. A limit is also a promise: overrun entitles a chase; unwritten, support can only say “wait more.” Holidays, cross-border, and different tenders move at different speeds; one vague phrase makes the slowest path everyone’s expectation.
Studying it
On the request page compare no limit, a single “7 days,” and staged limits (review / payout / credit). Ask inside and outside the window whether people think it is late.
Independent variables: granularity, whether the rail stage is included, calendar date vs duration. Dependent variables: nudges inside the window, overdue complaints, restating the latest credit day.
Do not substitute CSAT for limit comprehension. Labs need a stated “today is weekday N” to test business-day math. Live credit also depends on banks; split “did the merchant say it” from “did the bank keep it.”
Where it stops holding
When the rail will not promise a credit day, the merchant can only stamp “refund initiated” and say the issuer or wallet governs after that. Inspection returns start the clock at warehouse receipt; say so. Instant credit to a store balance can be minutes and still must be written, or people wait on a card. Regulatory caps are a floor; the UI may promise faster, but must not pass the cap off as its own speed.
Applying it
- Before submit, show three times: review, merchant payout, rail credit; prefer dates, and name business-day and holiday rules.
- Original-rail vs store-balance refunds get their own limits, not one sentence.
- On overrun, automatically switch to an overdue explanation that can be queried, not endless “processing.”
- Verify after submit, page closed: “latest day the money should appear, and where.” Failure: “soon,” or no rail stage.