The refund happened but the customer received no confirmation

Anchor the message to the refund that exists

Open the original payment and its refund in the authorized provider account. Match the refund amount and date to the store order, including whether this was a partial or full refund. Keep the provider status separate from the store status. This prevents a search for the full-order notification when only part of the order was refunded.

WooCommerce documents that a manual refund record and an order-status change do not themselves return money. Its automatic refund path requires a supporting gateway. If the only evidence is the store label, the financial result still needs checking; the case is not yet just a missing confirmation. Conversely, when the provider record establishes the refund, an absent message is not a reason to repeat the money movement.

Assign the expected message to its own sender

For a WooCommerce message, inspect the refund notification in the store email settings and whether it is enabled. The refund documentation distinguishes partial-refund wording from full-refund wording; a partial refund need not put the order into Refunded status. Compare the refund event with the intended message rather than changing the order status to make the subject line look right.

Sender identity is another setting. WooCommerce separates the From name and address from the optional Reply-to. A correct Reply-to does not establish that the original message was generated or delivered. Record the notification type and the responsible sending system before investigating the address the customer expected to see.

For a Stripe-processed payment, Stripe creates receipts for successful payments and refunds. Receipt creation and email sending are separate facts. Its receipts documentation describes successful-payment email settings and manual sending; the successful-payment setting alone does not establish whether this refund notification was sent. Look for the refund's own notification or message record in the actual provider account. If that record is unavailable, leave provider sending unconfirmed and continue tracing the store message separately.

Distinguish a message record from a delivery result

Look for the available message history for the expected sender at the refund time. Record what the system actually reports and when: no matching record found, an attempted send, an error, or a delivery outcome. If no history is available, record that limit. A current enabled setting does not prove it was enabled when this refund occurred.

Compare the intended recipient inside the authorized store or provider account without copying their email address into the worksheet. If a message was generated, the next evidence comes from the service that sent it and the customer’s reported receipt or non-receipt. Do not rename an attempted send as an inbox confirmation. A provider receipt and a store email can have different histories for the same refund.

An old Stripe receipt link can also be a different problem: Stripe documents that receipt links expire after 30 days. A link that no longer opens does not show that the refund failed or that no original message was sent. Keep link access separate from the send trace.

Close the communication gap without another money action

Prepare the customer update from the records you verified: the refunded amount, whether it was partial or full, the provider’s reported state and the date your team checked it. Describe the missing notification separately. If the provider still shows an unresolved state, do not write that the customer has received the funds.

If an authorized resend or a direct support update is appropriate in the existing system, first verify its recipient and wording against that refund. Record the communication action separately from the refund action. For a recurring gap, bring a non-sensitive summary of the store, gateway and missing notification to a Prism checkout-review consultation. Confirm investigation scope, responsibilities, fees and terms before work; the consultation does not establish delivery or authorize another refund.

For a consultation request, describe the website, research-only products and the notification gap without attaching customer records. Prism follows up by email; scope, fees and terms are discussed before work. The request does not book an appointment, buy a service or submit a processing application.

Refund-message trace

Use one actual refund and complete a separate trace for each expected sender. Keep customer contact details and message contents in their authorized systems. An unknown delivery outcome remains unknown even when the refund is confirmed.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.