What it means
A customer refund is approved on Monday, but the payment processor still shows pending a week later. This metric measures the time from a valid internal approval to a verified refund outcome, while keeping initiation and bank posting separate.
Define approval as the authorised decision covering customer, payment, currency and amount, because a support agent's promise to look into a refund is not approval. Stripe documents that a refund request may remain pending if funds are unavailable and that customer bank posting can depend on networks and banks.
Choose the endpoint carefully, whether processor status succeeded, return of funds confirmed by the customer or a defined settlement record, since these are not the same timestamp. Distinguish a cancelled authorisation from refunding a completed payment, as there may be no settled original charge to return.
For partial refunds, link the amount to the original charge and check that cumulative refunds do not exceed the amount paid. If a credit note adjusts an invoice but no cash refund is issued, do not count the credit note as a settled payment refund.
For a refund to the original payment method, explain the expected customer statement behaviour without guaranteeing a universal bank posting date, and for another payment method check its supported refund path rather than assuming card behaviour. If the original card is expired, follow processor and issuer rules rather than sending money to a newly supplied account without authorisation.
Where a processor shows pending, investigate the stated cause and next action, and do not close the task merely because the API accepted the request. If fraud or a formal dispute is involved, coordinate with the approved team before issuing a duplicate refund, and if the customer reports nonreceipt after the processor marks success use available trace references before issuing a second refund.
For cross-border transactions, currency conversion can make the amount on the customer's statement differ, so show the original refund currency and any known limits. If a fee was charged, verify the policy and processor rules before promising it will also be returned.
Keep customer communication factual, so that refund approved, submitted, pending or completed matches the current state, and if settlement cannot be verified directly mark it as unknown and state the available processor status. Define the cohort as approvals whose outcome is due for review, including refunds still pending beyond target, and report median and high-percentile lag for completed cases plus the age and count of pending approved refunds.
Segment by payment rail and reason, because a pending processor balance is a different fix from an internal approval queue, and audit the source request, authority, processor refund ID, status history and customer communication. If a refund fails record the failure and the authorised recovery route instead of resetting the approval clock, pair lag with accuracy, keep service and refund statuses separate for cancellations, and protect payment information by keeping a reference ID and controlled link rather than card details.
In practice
Real-world examples.
Example
A $50 refund is approved Monday and processor status succeeds Wednesday. Under a processor-success endpoint, the lag is two days, and the customer is told the bank may take longer to show it.
Example
A refund request is accepted but remains pending for lack of processor balance. It is not counted settled, and finance is asked to fund the balance.
Example
A credit note reduces an open invoice without returning cash. It is not treated as a completed refund of a paid charge, and the customer is told the credit reduces the amount due.
Formula
Calculation
Illustrative lag = verified refund-outcome timestamp - authorised approval timestamp. Show pending and failed approvals separately.
Worked example: a $50 refund is approved on Monday and the processor status succeeds on Wednesday, so under a processor-success endpoint the lag is 2 days. Across eight completed refunds, an invented team records lags of 1, 2, 2, 3, 3, 4, 5 and 12 days. The median is (3 + 3) / 2 = 3 days and the mean is (1 + 2 + 2 + 3 + 3 + 4 + 5 + 12) / 8 = 32 / 8 = 4 days. Two further approved refunds totalling $400 are still pending at ages of 8 and 14 days, and are reported separately.Case study
Seen in the real world.
This fictional case follows Greenbay Billing, an invented online retailer. A customer received notice of an approved refund, but the processor record stayed pending. The team tracked the status, corrected the funding issue and updated the customer without claiming the bank had already posted the money.
The team then listed every approved refund still pending beyond its target and found two more waiting on the same balance problem. It added a daily check of pending refunds and a processor balance alert. The case is invented.
Watch out
Common mistakes.
- Calling a pending processor request settled.
- Confusing a credit note on an open invoice with cash returned.
- Promising an exact bank posting date without evidence.
Questions
People also ask.
Does processor success prove the customer sees funds?
Not always. State the chosen endpoint and any bank-posting uncertainty.
What if the refund fails?
Keep the approval history and use the authorised recovery path.
Can the refund be partial?
Yes, if the approved amount matches the original payment and applicable policy.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%Related