A withdrawal request can exist even when its customer acknowledgement or merchant alert is missing. In WooCommerce 11.2, check these two configurable messages separately before asking the shopper to submit the request again.
The 11.2 announcement places both email configurations under WooCommerce > Settings > Emails. Their purpose is to acknowledge the request and alert the merchant. Receiving an acknowledgement is not proof that a refund was processed.
Start with one controlled request
Use a test order and addresses controlled by your team. Record the order reference, request timestamp, expected customer mailbox and expected merchant mailbox. Keep the actual identity-verification steps required by your store; do not weaken them to make a test easier.
First establish whether the request was recorded. If it was not, investigate the submission path. Email troubleshooting cannot repair a request the application never accepted. If the request exists, do not create another production request merely to generate another message.
Inspect each email independently
Open the relevant email settings and record whether each message is enabled. Verify the merchant recipient list and the customer identity associated with the request. Check previews for content and presentation, but do not treat a successful preview as evidence that the real request triggered delivery.
| Checkpoint |
Customer acknowledgement |
Merchant alert |
| Enabled configuration |
Confirm this specific email |
Confirm this specific email |
| Intended recipient |
Verified test customer |
Approved operations address |
| Real trigger |
Same controlled request |
Same controlled request |
| Provider evidence |
Message ID and disposition |
Separate ID and disposition |
| Mailbox evidence |
Arrived and readable |
Arrived and actionable |
The WooCommerce email settings reference explains the configuration layer. Mail-provider evidence is another layer: accepted, deferred, rejected and delivered are not interchangeable states.
Request: One controlled request exists. Customer: Acknowledgement received. Merchant: Alert has its own delivery proof. Order: Actual state reconciled. Explanatory checklist, not a customer test result.
Avoid the duplicate-request trap
If the customer message arrives but the merchant message does not, narrow the investigation to the merchant configuration and delivery. Check mailbox aliases, forwarding rules, spam handling and suppression. Do not re-run the entire withdrawal workflow until you understand its effects on the order.
If neither message is created, inspect whether the intended event occurred and whether a customization disabled or replaced it. If both reached the provider but only one mailbox received them, changing the application trigger is unlikely to solve the mailbox problem.
Use the store's supported resend or recovery procedure only after checking whether it sends mail alone or repeats business actions. A test that produces an extra refund or changes fulfillment is not a harmless email test.
Close with an order-state check
Confirm the request exists once, the acknowledgement describes its actual status and the merchant can locate it. Reconcile any separate cancellation or refund workflow before telling the customer it is complete. This is a technical delivery guide, not advice about legal eligibility or deadlines.
Our withdrawal identity and order-state guide covers the wider workflow. HandL WP can trace missing transactional messages using the request timestamp and redacted provider records.
References reviewed October 8, 2026. Examples are explanatory, not customer test results.