# Refund not received: reconcile the payment before issuing another

[By Evidenz](https://evidenz.dev/)  5 min read

When a customer cannot see a refund, trace the promise to an actual refund record and its current status. Then check how the return of funds should appear and whether a dispute is also open. A second support ticket is not evidence of a second payout, and a processor success status does not show exactly what appears on the customer’s statement.

## Start with the original payment and the promise

Find the payment the customer wants refunded. Record the charge identifier, amount, currency, invoice, and relevant account. Then read what support promised: a full refund, a partial amount, a credit against a later invoice, or simply a review of the request.

Those promises require different follow-up. A credit note in the business’s records should not be presented as a card refund unless money was actually sent through the refund process. Nor does a closed support ticket establish that the finance step completed.

Search for refund records linked to this payment. If none exists, that is the immediate finding: support made a promise that has not yet been connected to a payment action. Assign an owner to resolve it instead of telling the customer that their bank is slow.

## Keep the stages of a refund distinct

[Stripe’s Refund object exposes a refund’s amount, currency, original payment relationship, and status.](https://docs.stripe.com/api/refunds/object) Use the current record, not a screenshot taken when the request was first submitted.

A missing-refund review: distinguish internal progress from payment status

| What you find | What it means for the review | Next question |
| --- | --- | --- |
| Support promise, no refund record | An intention or commitment exists; payment execution is unverified. | Who owns creating or reconciling the refund? |
| Pending refund | The refund has not reached a final successful state. | What does the processor say is preventing progress? |
| Failed or canceled refund | Do not describe this attempt as money successfully returned. | Why did it fail, and what safe resolution does the processor support? |
| Refund requiring action | Some payment methods need another step before processing can continue. | What action is requested in the processor’s current record? |
| Successful refund record | The processor records success for that amount. | How should the customer locate or trace it with their bank? |

The first row is an internal investigation state, not a processor status. Exact status names and actions depend on the provider and payment method. [Stripe documents failures and refunds that require action separately.](https://docs.stripe.com/refunds) Do not apply the behavior of one payment method to every card refund.

## Reconcile the amount, not just the number of attempts

List every refund for the original charge, including unsuccessful attempts. Separate successful amounts from pending or failed amounts and keep currencies explicit. Several records may represent retries or partial refunds rather than several completed reimbursements.

For example, a €90 charge may have a successful €30 refund and a failed €60 attempt. “Refunded” is too broad a description of that history. The review needs to show the successful portion and the unresolved portion without counting the failed attempt as money returned.

Check whether the customer is referring to a different invoice or a later renewal. Reconcile account credit separately from funds returned to the payment method. Where the billing system contains several balances, document which balance each action changed.

[Polar’s refund form takes an amount excluding tax and calculates the corresponding tax refund automatically.](https://polar.sh/docs/features/refunds) Its maximum refundable amount also accounts for earlier refunds and customer balance applied to the order. For a Polar order, distinguish the entered net amount from the customer’s total refund, including tax. Reconcile those components before calling a difference an underpayment or creating another refund.

## A reversal may not look like a separate credit

[Stripe explains that some early refunds appear as reversals: the original charge drops off the statement rather than a separate credit appearing.](https://docs.stripe.com/refunds) Verify the recorded type before asking the customer to search for an incoming transaction that may not exist.

When a bank trace is appropriate, use the reference supplied for that refund. Stripe describes card references such as an Acquirer Reference Number, System Trace Audit Number, or Retrieval Reference Number. Availability and type vary. Give the customer only the relevant reference through an appropriate support channel, together with the amount, currency, and date.

Avoid promising that every bank will display the money within one fixed period. Use the processor’s current guidance for the payment method, check the status, and provide a concrete next update if the case remains unresolved.

## An open dispute changes the next action

Check for an inquiry or dispute on the original charge before attempting another refund. It may explain a status change and can create a risk of conflicting reimbursements if separate teams act independently.

[Stripe identifies a pending refund being disputed as a possible failure reason and advises handling the dispute rather than issuing another refund to avoid duplicate reimbursement.](https://docs.stripe.com/refunds) That is a Stripe-specific instruction; follow the live case and the rules of the processor you use.

The [dispute response documentation](https://docs.stripe.com/disputes/responding) describes how to inspect and act on the case. A customer saying they asked their bank to withdraw a dispute is not, by itself, confirmation that your processor has closed it. Keep the case owner, support reviewer, and finance operator working from the same current status.

## A worked reconciliation with a partial refund

**Fictional example.** A customer pays €90 for a SaaS subscription. Support promises a full refund on October 12. A €30 refund succeeds, while a €60 attempt fails. The customer asks again on October 16, and a card dispute is now open for the original payment.

There are two support requests and two refund attempts. Neither count answers how much was successfully returned or what should happen next. The useful finding identifies the €30 successful record, the €60 failed attempt, the full-refund promise, and the open dispute.

Do not automatically issue €90 again. Confirm the current processor balances and available case actions, account for the existing successful refund, and have one owner choose the next step. Retain the status checks and the action confirmation so a later reviewer can understand how the case was resolved.

## Give the customer an answer that matches the records

A helpful reply says what has been verified, what remains unresolved, and who will follow up. If the refund failed, say that the attempt failed. If it succeeded but is not visible, explain the verified transaction type and available trace route. Avoid implying the customer is making a duplicate claim simply because they have contacted support twice.

The [refund-abuse article](https://evidenz.dev/articles/refund-abuse) explains why request patterns need context. Here, the immediate job is payment reconciliation. Fix the missing or unclear refund first, then examine any broader pattern separately.

Evidenz’s customer-timeline approach is designed for refund investigations in B2B and B2C SaaS, where support promises and payment outcomes live in different systems. Relating the conversation, invoice, refund attempts, and any dispute to the same account makes a more precise handoff possible. In the example above, the useful message is “€30 succeeded; €60 remains unresolved,” with the records behind both statements. Teams receiving repeated refund questions need that shared explanation: what happened, and what still needs an owner before another financial action is considered.

## Sources and scope

Sources checked October 2026

Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.

- [Stripe: Refund and cancel payments](https://docs.stripe.com/refunds)
- [Stripe: The Refund object](https://docs.stripe.com/api/refunds/object)
- [Stripe: Respond to disputes](https://docs.stripe.com/disputes/responding)
- [Polar: Manage Refunds](https://polar.sh/docs/features/refunds)

Customer context is our starting point.

Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news.

[Join the waitlist](https://evidenz.dev/#hero)

## Keep reading

[4 min read

### Review refund abuse without penalizing legitimate customers](https://evidenz.dev/articles/refund-abuse)[4 min read

### The customer withdrew the chargeback. Why is the dispute still open?](https://evidenz.dev/articles/withdrawn-chargeback)[5 min read

### Refund vs. chargeback costs: compare the next action, not just the fee](https://evidenz.dev/articles/refund-vs-chargeback-costs)

Canonical page: https://evidenz.dev/articles/refund-not-received