A WooCommerce manual refund does not return the payment
If the action was a WooCommerce manual refund, that action recorded the refund in the store without returning money through the gateway. Changing an order's status alone also does not move funds. A separate authorized provider action may already have occurred, so reconcile the original payment and every existing refund reference before initiating another action. The store row establishes what WooCommerce recorded; the provider record establishes whether a gateway refund exists and what status it has. Do not promise completion from the order label alone.
For: A research-only WooCommerce merchant whose order shows a refund but whose team has not confirmed a matching gateway refund.
Open the real order, its refund entries and its order history. Identify whether someone recorded a manual refund, requested an automatic refund through the gateway or changed the order status. If the action cannot be established from the available history, retain that uncertainty. A current Refunded label does not reconstruct the action that produced it.
WooCommerce documents that automatic refunds require gateway support. A manual refund records the store adjustment but does not itself return the money, and changing a status does not initiate the financial action. These are different operations even when the order screen later uses similar wording.
Keep the action time, amount and any gateway reference linked to the order. The key question is whether a provider refund was created for the original payment, not whether the store total now looks right. An email describing a refund remains a store communication to compare with that financial record.
Match the original payment before looking for the refund
Use the payment reference and gateway recorded for the actual order to locate the original provider payment in the correct account. Then inspect the refunds associated with that payment. Compare the intended refund amount and currency, existing refund references, action dates and current provider status with the store entry. Keep multiple partial refunds separate instead of treating their combined store total as one provider action.
If a matching provider refund exists, the manual store record may have been entered to reflect that separately initiated action. Its existence changes the next decision: you need to reconcile and follow the existing refund, not create another one just because WooCommerce's action was manual.
If you cannot find a provider refund, record the extent of the search. An unavailable account, an uncertain original payment reference or unchecked history means the refund remains unconfirmed. Only after the correct payment and its relevant history have been examined can your team distinguish a store-only record from incomplete access. Do not convert an access gap into an instruction to send funds again.
Read the provider status without inventing a cause
Where the provider is Stripe, its Refund object can have a status of pending, requires_action, succeeded, failed or canceled. Preserve the actual status and any documented request attached to the refund. Pending and requires_action do not establish completion; failed and canceled do not establish a successful refund. If Stripe reports succeeded, describe that as the provider's reported outcome, rather than claiming to have inspected the buyer's bank statement.
Those status names alone do not establish why this refund is pending or why another failed. Do not infer insufficient funds, a bank problem or a missing customer action unless the relevant provider record supports it. Another gateway requires its own documented status meanings. Neither a store entry nor this status list supplies a guaranteed receipt date.
Amount allocation and inventory are separate checks. WooCommerce can retain an order status after a partial refund; absence of Refunded is not proof that no partial refund exists. Its refund controls also distinguish item quantities, typed amounts and explicit restocking. A stock adjustment does not prove money moved, and a refund does not establish that returned goods are fit for resale.
Assign one next action and correct the support message
For a confirmed store-only entry, name the person authorized to determine and perform the outstanding provider action under the actual gateway's procedure. For an existing provider refund, name the person who will follow its status or requested action. For an unresolved match, assign retrieval of the missing account or payment evidence first. Record the responsible person and a follow-up date so two staff members do not independently treat the same store row as a fresh refund request.
Before another financial action, the authorized owner should check existing refunds and the gateway's current payment state, balance requirements and any restrictions relevant to that action. A manual store entry is not permission to use an alternate payment route. Preserve the history rather than deleting the store entry to make the mismatch disappear.
Tell support exactly which conclusion the records support: recorded only in the store, provider refund located with its current status, or gateway outcome still unconfirmed. If an earlier message overstated completion, correct it using those checked facts. A date your team will investigate again is a follow-up commitment, not a promised date funds will arrive.
For a PRISM checkout-review consultation about this mismatch, provide the website, research-only products, gateway name and a non-sensitive description of the store action and unresolved provider result. Keep order exports, customer records and payment credentials out of the public form. Scope, responsibilities, fees and terms are discussed before work; follow-up is by email. The request does not book an appointment, purchase work or submit a processing application.
Manual-refund reconciliation
Use one real order and its original payment. Enter internal references and observed states in the final column, without customer details or card data. Follow an existing gateway refund if one is found; treat missing access as unresolved; assign a financial action only after the store-only condition is established and the responsible owner checks the gateway requirements.
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.
Manual-refund reconciliation. The last column is for temporary notes.
Reconciliation item
Evidence to open
What the evidence establishes
Your finding and next step
Order reference
Evidence to openInternal order reference and its recorded gateway and payment reference.
What the evidence establishesIdentifies the actual order and provider payment to reconcile, without relying on a customer's name.
Store refund entry
Evidence to openRefund amount, currency, date and entries on that order.
What the evidence establishesShows the adjustment recorded in WooCommerce, not necessarily returned funds.
Action type
Evidence to openOrder history and available record of the action performed.
What the evidence establishesDistinguishes a manual refund, automatic gateway request and status-only edit; retain unknown if history does not establish it.
Original provider payment
Evidence to openThe original payment in the correct authorized provider account.
What the evidence establishesConfirms where the refund history must be checked before concluding a refund is missing.
Gateway refund reference
Evidence to openEach existing refund associated with that payment, with amount and currency.
What the evidence establishesMatches a provider action to the store entry and reveals prior partial refunds that must remain separate.
Provider result
Evidence to openCurrent refund status and any documented provider request or reason.
What the evidence establishesSupports the status your team may report; the status alone does not establish an unseen cause or bank receipt date.
Inventory action
Evidence to openThe order's quantity adjustments and any recorded restock choice.
What the evidence establishesKeeps stock handling separate from financial completion and physical condition.
Confirmed next owner
Evidence to openNamed authorized owner, remaining task and internal follow-up date.
What the evidence establishesAssigns reconciliation, existing-refund follow-up or an outstanding provider action without duplicate handling.
Support correction
Evidence to openWhat support last stated and the result now supported by the opened records.
What the evidence establishesCorrects an unsupported completion promise without replacing it with an invented receipt date.
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.
Limits
WooCommerce manual refund entries and order-status changes do not themselves return gateway funds; automatic refund support depends on the gateway.
Stripe's status names apply to Stripe and do not establish another provider's behavior or an undocumented failure reason.
This reconciliation does not authorize a refund, an alternate payment route, a tax treatment or a promise about receipt timing.
Keep card data, bank details, passwords, customer messages and order exports out of this worksheet and the public consultation form.
WooCommerce refunds — checked 2026-09-29. Manual refunds and status changes do not move money; automatic refunds require gateway support. Partial refunds, amount or quantity allocation and explicit restocking are separate controls. Gateway records and current state require separate verification.
Stripe Refund object — checked 2026-09-21. Stripe lists pending, requires_action, succeeded, failed and canceled as refund statuses. The list alone does not establish the reason or buyer receipt timing for a particular refund.
Prism solutions — checked 2026-09-21. PRISM discusses storefront review, processing preparation and provider website questions within an agreed scope, with fees and terms discussed before work. Account terms remain the provider's decision.
Prism contact — checked 2026-09-21. The form asks for the website, products and question, excludes card details, passwords and customer records and leads to email follow-up. A request is not a purchase, appointment or processing application.
Get help with store operations
Need help with the order, email or fulfillment step itself?