Refund timing depends on the payment method and the stage already reached. A merchant approving a return, submitting a credit and your bank displaying the money are different events. Start with the actual refund submission date and the provider’s estimate for that payment route, then investigate the specific stage that has exceeded its expected time.
There is no single number that reliably covers cash, debit cards, credit cards, wallets, bank transfers and failed payments. A retailer’s estimate should also be separated from any statutory deadline that applies to the transaction. This guide explains how to read an estimate and what to do when the expected credit remains missing.
Guides to specific timing questions
Use the supporting explanations for debit and credit card refund timing, bank-transfer refunds, weekends and bank holidays, approval and processing statuses and refunds involving an unsettled purchase.
If your question is what “pending” means, retain the existing explanation of a pending refund. If an expected time has passed and the credit cannot be located, the missing refund investigation guide provides the tracing sequence.
Identify the starting event
Return requested
The date you asked to return an item may establish compliance with a policy or legal notice deadline. It does not necessarily identify when the merchant submitted money into the payment system. Keep the request because it may matter to eligibility, but ask which event the retailer’s payment estimate begins from.
Return received or inspection completed
A retailer may describe its estimate by reference to delivery of the parcel or completion of inspection. Ask which of these it means and whether any action is still required. A tracking record can establish delivery without establishing that the payment team has submitted a refund.
Refund actually submitted
Request the amount, currency, submission date and available payment reference. This gives the issuer or provider a specific record to investigate. Where there are several partial refunds, keep separate dates for each one rather than assuming the earliest return event starts a single timetable for the whole order.
Read the estimate in context
An estimate should identify the payment route, the relevant starting point and whether the period uses business or calendar days. Ask what happens if the expected time passes. A support message that simply says “allow several days” does not tell you whether the merchant is describing its own internal queue or the receiving bank’s posting stage.
For a simple example, a store takes three days to approve a return and then gives an estimate for the submitted card refund. Do not combine the approval date and submission date without checking the wording. Equally, do not allow an explanation of bank processing to conceal that the merchant has not yet identified a payment transaction.
Card refunds need account-level checking
For debit cards, check the linked account activity. For credit cards, examine the credit entries and balance, not only whether cash reached a current account. A merchant credit may reduce debt. The absence of a separate deposit does not establish that a credit-card refund failed.
Square’s US refund guidance provides a provider-specific processing estimate and describes issuer handling. Treat such estimates as belonging to that provider and route. They should not be presented as a universal legal deadline or a promise that every issuer displays a refund identically.
If the card changed, tell the issuer about the original purchase relationship. Waiting longer solely because a card number is old may not resolve the problem. The existing old-card refund guide helps distinguish replacement from account closure and confirmed failure.
Bank transfers and wallet refunds
For a bank-transfer reimbursement, ask whether the merchant has actually sent the transfer and which payment route it used. An internal payout queue can precede the bank’s execution time. Cross-border currency or recipient-information issues need transaction-specific investigation rather than an assumption that every transfer follows a domestic timetable.
For wallets, check both the wallet’s refund activity and the underlying funding component. A payment funded partly from a balance and partly from a card may generate more than one destination. Keep the components separate so that a received balance credit does not obscure a missing card credit.
Cash and collection arrangements
A cash refund handed to you has no later card-network posting stage. The relevant questions concern when the retailer approves the return, where the cash can be collected and whether it actually paid the agreed amount. Obtain a receipt when money is handed over and check any conditions before attending a different branch.
If a store says a cash refund is “processing,” ask whether it means an internal approval or an agreed collection arrangement. Do not assume an estimate for card credits explains a delay in handing over cash. A check offered instead is a different method with its own receipt and clearance considerations.
Why weekends and holidays matter differently
Some parts of a payment process can be automated while others depend on staffing, provider operating calendars or banking business days. Avoid the blanket assumption that every refund stops over a weekend, or that a Sunday approval means the issuer has already received a credit.
Confirm the provider’s business-day definition and any relevant cut-off. A local public holiday may differ from the calendar observed by a provider or receiving institution elsewhere. Keep a calendar showing the dates you excluded and the estimate’s starting event, rather than repeatedly restarting the count whenever support replies.
Why an estimate can be exceeded
Ask which step is delayed. The merchant may still be checking the return, the provider may need action from the merchant, or the issuer may be investigating posting. Incorrect details, an unavailable account or a failed refund may require a correction rather than more waiting.
For a provider example, Stripe’s refund reference distinguishes status and pending-reason fields within its system. A retailer should investigate the actual record rather than infer the cause from a generic customer-facing message. One provider’s labels are not a complete explanation for every merchant’s delay.
Estimates and statutory deadlines are different
An estimate describes expected processing. A statutory deadline comes from the applicable law and transaction context. Identify the jurisdiction, reason for refund and relevant starting event before relying on a legal time limit. Rules for a qualifying cancellation, defective goods or a payment error should not be treated as interchangeable.
Keep the retailer’s policy and refund agreement alongside any evidence of the right you are asserting. A provider’s estimate does not by itself establish whether the merchant complied with a legal duty, and a merchant’s promise to investigate should not be assumed to extend a complaint or dispute deadline.
When to contact the merchant or bank
If the merchant cannot identify a submitted refund, ask its return or payments team to resolve that step. If it provides a payment record and its stated estimate has passed, contact the relevant receiving institution with the amount, date and reference. An urgent suspected mistake or fraud concern should be reported promptly rather than left until an ordinary estimate expires.
Ask for a result: located and posted, still being investigated, confirmed failure or no match found. Keep the actual wording. If the issuer cannot locate the credit, take that result to the merchant and request its provider’s latest status. A failed search and a confirmed rejection require different next steps.
Frequently asked questions
Should I wait for my next credit-card statement?
Ask whether the issuer can identify the credit in current account activity before the next statement is produced. The statement cycle and the date a transaction posts are different concepts. Check required account payments separately while a refund remains unresolved.
Does another support reply restart the estimate?
Not automatically. Record the actual payment events and ask why any revised date is necessary. A useful update identifies the outstanding action and responsible team instead of simply replacing the earlier estimate with another unexplained waiting period.
What if only part of the refund arrived?
Match the received amount to the merchant’s allocation and separate refund records. Keep the unresolved component open with its own reference and dates. The arrival of one credit does not establish that the entire agreed amount has been received.
Keep a timeline that separates the events
Consider a return requested on a Friday, delivered the following Tuesday and approved after inspection on Thursday. If the merchant submits the refund on Friday, those are four separate dates. Record all four instead of reporting that the bank has held the refund since the first Friday. The first date can matter to return eligibility while the last identifies the payment record being traced.
A second customer may cancel an order before the merchant captures the payment. Their app shows a pending purchase and later releases the hold. That case should not automatically use an estimate for a settled purchase’s refund. Ask what happened to the original authorization and whether any separate credit was actually created.
For either case, keep the estimated period and the provider’s explanation together. If support revises the estimate, ask which event changed: a new submission, correction of recipient information or a continuing investigation. This gives the next adviser a coherent timeline and makes it easier to identify a missed action, without treating every delay as evidence that the money has permanently disappeared.