Paid WooCommerce order without email: check triggering and sending

First check which message is missing

The order is paid, but the customer received no store email. Or the merchant awaits an alert while the customer has their summary. These messages do not necessarily share a trigger or recipient. The desired result is the correct document sent to the correct address without artificially changing payment.

Distinguish the post-purchase confirmation page, any provider receipt and WooCommerce emails. One may work while another fails. If only the final page is missing, examine payment return and the checkout request; changing email settings will not repair that redirect.

This guide concerns a WordPress store already using WooCommerce. Authorized access to orders, email settings and logs is required. A manager may examine an order while global configuration may require the administrator. In multisite, check the selected store. Mail-transport access belongs to hosting or the provider. On WordPress.com, open WP Admin to find these screens if WooCommerce is installed; this does not grant server-configuration access.

The examined version is WooCommerce 11.2.1, a free Automattic plugin. It declares minimum requirements of WordPress 7.0 and PHP 7.4, with testing through WordPress 7.1.4. Built-in transactional logs let you begin without installing another tool. An older version may show less information: do not search for a new screen as though it always existed. These compatibility minimums do not recommend an old PHP version.

Connect the expected email to the actual order status

Under WooCommerce, Orders, open the affected order. Check status, payment and notes. If confirmed collection still leaves Pending payment, first reconcile with the gateway. The event announcing payment may never have run; this is not necessarily a mail-transport fault.

New order goes to configured merchant recipients. Processing order concerns the customer after the corresponding transition into fulfillment. Completed order accompanies completion. Depending on products, an order may go directly to completed; do not necessarily expect two identical emails.

An on-hold order message, customer note and manually sent summary serve other purposes. Record the exact expected name before intervening. A provider receipt does not prove WooCommerce generated its message, and a received merchant notification does not prove the customer address is correct.

Do not move an order from a paid state to Pending and back to Processing to provoke email. Transitions may trigger stock, automation and additional messages. Keep status faithful to the commercial situation and use appropriate email settings or actions.

• Status inconsistent with collection: reconcile payment before email diagnosis.
• Message disabled or address incorrect: use the first route.
• Expected message but no visible attempt: examine event, queue and log.
• Locally successful attempt but email absent: examine transport and mailbox classification.

Route 1: correct activation and the right address

Open WooCommerce, Settings, Emails, then Manage for the relevant type. For an automatic notification, check Enable this email notification and save if disabled by mistake. Preserve the initial value. Activation governs future events; it does not automatically send every past missing confirmation.

For New order or another merchant alert, check Recipient(s). It may contain several comma-separated addresses. Verify the monitored mailbox matches this setting without assuming the logged-in account email or general administration address always replaces it. Do not copy every customer on an internal notification.

For customer confirmation, open the order and examine its stored billing email. Usual customer emails use this address, which may differ from the current user profile. A guest order needs no account to have a recipient. Changing a customer profile does not necessarily correct the address already stored on this order.

If a typo is confirmed through a trusted channel, use the pencil in Billing to correct only email, then Update under Order actions. Do not reload the entire address from the profile to fix one letter: other data could be replaced. Under Order notes, choose Private note, enter the correction reason and Add without unnecessarily repeating personal data.

The expected result is an enabled notification and exact recipient for the intended document. To undo an unsuitable setting correction, restore its initial value. Do not restore an erroneous address merely for convenient rollback; instead document the confirmed value. Before the targeted send described later, check no deferred attempt will already produce the same message.

Route 2: read the built-in transactional log

In WooCommerce 10.9 and the later examined versions, open WooCommerce > Status > Logs. Under Browse log files, select source transactional-emails and the relevant date. Open the file and search for order number and email type. With database storage, use the corresponding log view. Start with existing data without sending several messages to populate the log. Private order notes may also indicate a successful or failed attempt.

Read the exact result. Sent means the message was handed to the sending system without a detected local error; it does not prove inbox arrival. Failed indicates this attempt failed. Disabled means the type was disabled. Skipped means a condition, such as recipient, was missing. These distinctions prevent changing the sender for a message never attempted.

If expected lines are absent, open the logs’ Settings tab. Check activation, retention and Level threshold. To see INFO successes, NOTICE non-sends and WARNING failures, temporarily choose Info if the current threshold hides them and save. None means every level, not no logging. If WC_LOG_THRESHOLD enforces the field, have its administrator check configuration. Preserve and restore the original setting after diagnosis; this change does not recreate past events.

Recipients may appear as a username or guest instead of a full address. That label does not establish a missing recipient; check the order address. A readable error may also require correlation with transport logs to confirm its exact cause. In this version, Disabled and Skipped are logged but do not create the same attempt notes as Sent or Failed. Absence of a note therefore does not prove the type was enabled.

The expected result is locating the fault: activation, condition, event or sending. An empty log does not authorize claiming the customer received, deleted or blocked the message. Also inspect fatal errors at the same time if generation seems to stop. No logging tool installed afterward can reconstruct an unrecorded event.

Compare the recorded transition with the email attempt

Under WooCommerce > Orders, open a fictional order or reread the reported one without changing state. Record time, previous state, resulting state and exact expected notification. A Processing-to-Completed order calls for Completed order email. An administration email, manually sent summary and template preview have different triggers.

Under WooCommerce > Settings > Emails, check the corresponding type is enabled. Correlate the status-change note with source transactional-emails under WooCommerce > Status > Logs. Search the same order number and message type. A note proving the new state was recorded does not prove email was prepared or handed to transport.

On a copy without outbound sending, create a different order for each control. Keep the same transition and change only one parameter. Compare a disabled notification, absent billing address and transport returning an error. Record whether WordPress was called in each case. An order remaining Completed after failure must not be artificially returned to Processing on the live store to attempt resending.

Read the six controls in the native log

The following protocol proposes six controls prepared separately on an isolated copy with fictional orders and a private email receiver. It does not describe measurements already performed. For each case, record before-and-after state, email type, immediate or deferred mode, log and actual transport response. Do not use a customer order to provoke an SMTP error.

These results are interpretation criteria to confirm in your version and configuration. Preserve observed differences instead of replacing them with the expected result.

• Disabled notification: look for disabled and verify no attempt for that type.
• Absent billing address: look for skipped and its reason, such as no_recipient, without concluding from commercial status alone.
• Controlled SMTP rejection: record the complete code and check failed and any generated attempt note.
• Test receiver acceptance: look for sent, then distinguish acceptance from receipt in an external mailbox.
• Saving without a new transition: verify it does not constitute an explicit email resend request.
• Rendering error: correlate PHP log and trigger; an exception may prevent transport from being reached.

Choose the next check from the control that differs

If you see the transition but no result for the expected type, compare time, trigger, logging threshold and any pending action. A critical entry may name the hook where the error surfaces, here woocommerce_mail_content, without an order number. Correlate with test time and PHP log. If the error names a template, theme or customization plugin, restore the native template on the copy for one new control. Keep the same email type and route. If the attempt reappears, check the identified customization before restoring it.

If WooCommerce reports failed, use the transport error to identify the rejected stage. SMTP code 550 must be interpreted with its full text and exchange stage: the number alone does not attribute the cause to the recipient. Compare time and test recipient in the private transport log. If the system accepts the message but the mailbox does not show it, continue on the receiving side. Commercial state and transport result are separate evidence.

To verify correction, prepare a new fictional order of the same type and record one transition. The expected result is an attempt for the correct notification and the intended result at the test receiver. Then restore the setting or template changed for testing. On the live store, separately handle any document needing resending for a specific order and deferred actions that could still send. Check history to avoid duplicate email.

Examine a deferred email queue without replaying everything

Under WooCommerce, Settings, Advanced, Features, check whether Deferred emails is enabled. This shifts processing of some notifications to a queue. Customization may also influence its state. Disabling it is not a general recovery method for already pending messages.

Open WooCommerce > Status > Scheduled Actions. The examined version uses group woocommerce-emails and action woocommerce_send_queued_transactional_email for this queue. Use search, then Pending or Failed views as needed. Correlate hook, group, time and arguments with the order. Another scheduled action in the list may be unrelated to its email.

Inspect the identified action’s state and log. A pending action still needs execution; a failed action needs its error corrected before retrying. If the entire queue stops progressing, examine background tasks with the site administrator. Do not delete every action to remove alerts.

Manual execution can actually send email. On an isolated copy with a separate database and all recipients redirected to a test mailbox, open the identified action’s details. After correction, use Run only for that action if available and authorized, then inspect its log. Do not use bulk Run. On the live store, choose one recovery method: retry this notification or send a targeted document after checking duplication risk.

The expected result is a completed action and visible email attempt in the log. Do not confuse action completion with inbox receipt: transport still needs checking. Rollback concerns the corrected task setting or component; it does not retract already sent messages. Retain actions useful for history instead of emptying the list.

Route 3: test transport without using a customer order

If the log reports Sent or Failed, verify the system actually sending email. WooCommerce normally uses WordPress’s wp_mail function; an existing tool may connect it to SMTP or an API. A locally successful result means that stage accepted the message, not that the recipient’s mailbox displayed it.

Under WooCommerce > Settings > Emails, find Email Preview when available. Select the type, then Send a test email. Enter a mailbox you control and confirm once. These controls also exist on the individual screen with Email improvements enabled. If your interface lacks them, use the existing transport’s documented test. Do not change email editing systems solely for this test. The test email is real but requires neither purchase nor status change.

Compare the attempt with the already configured provider’s log. Search time, recipient and message ID when available. Distinguish acceptance, queuing, rejection and returned error. If authentication or sender is rejected, correct that parameter for the account used before another limited attempt; do not add a second competing sending tool.

The expected result is a received test and understood sending route. A received preview demonstrates that route at that moment; it does not prove the order event triggered its own email. If preview works but no transactional attempt appears, return to generation and queue instead of recreating the connection.

Keep initial settings before correcting transport and restore parameters unrelated to the failure. Revoked or expired secrets do not become valid through merely restoring their value. No password or token should be copied into the command, console or public report.

Check sender and receipt without rebuilding all configuration

Under WooCommerce, Settings, Emails, examine sender name and address. They must match an identity your sending service is authorized to use. A transport tool may enforce its own address: compare the actually received message instead of concluding from one administration field.

Do not put the customer’s address in From to fix missing email. The recipient receives it; the sender represents the store or authorized domain. A reply address may differ but does not replace sender authentication. Correct the responsible value, save and repeat only the useful test.

If the provider accepts the message but the mailbox does not show it, check spam, quarantine and receiving rules. For spam-delivered mail, read authentication headers with the domain administrator: SPF, DKIM and DMARC concern specific identities. A successful result alone does not guarantee primary-inbox placement.

This stage requires neither replacing DNS servers, receiving records nor the entire email system. Use provider-requested values for the domain actually controlled. If the fault is limited to deliverability, address it in the corresponding diagnosis instead of modifying commercial statuses.

The expected result is an authorized sender and verifiable receipt. Retain the validated value and test-message evidence. Rollback of a bad change concerns only that setting; no command retracts email already accepted by an external mailbox.

Send a targeted summary after correction

When the customer needs information again and payment state is accurate, open their order. Verify billing address, status and absence of an equivalent scheduled notification. The available manual action is not necessarily an exact replay of automatic Processing order email.

Under Order actions, choose Send order details to customer, then Apply once. This produces Order Details email, historically associated with technical name customer_invoice. It sends a summary based on current order state; it is neither a new payment nor proof of collection.

If the order is still considered unpaid, this document may contain a payment request or link. That is why reconciliation precedes sending for an already collected purchase. Do not use it to announce everything is paid while WooCommerce retains an incorrect state. Also check a custom template if its text asserts payment unconditionally.

For a missing merchant alert, Resend new order notification targets another recipient and message type. Do not choose it expecting to contact the customer. Check configured recipients before triggering and avoid both actions when one meets the need.

The expected result is one attempt for the intended document in transactional-emails and verified receipt. A note saying details were manually sent is not alone proof of delivery. Wait for the result before another click. Sent email cannot be undone; if content was incorrect, have communication corrected separately without status oscillation.

1. Open only the affected order and reconcile payment, billing address and still-pending notifications.
2. Under Order actions, select Send order details to customer for the customer or Resend new order notification for the merchant, according to the established need.
3. Click Apply once, then check transactional-emails and the authorized mailbox before another attempt.

Validate future events without multiplying sends

To verify automatic triggering, use an isolated copy with a separate database, test-mode payments and all email directed to safe destinations. Disable real commercial integrations while retaining the incoming test-payment notification if it triggers the transition studied. One test order verifies that scenario: status, generation, possible queue, log and receipt. It does not validate every message type or payment method.

A template preview does not replace event checking. Conversely, ten orders are unnecessary to test an already identified address typo. Choose verification matching the corrected layer and retain its result.

On the live site, then track affected orders without bulk resending. An activation or transport correction may leave old cases to address individually. For each, verify the document still needed and attempts already executed; queue resumption may produce a message after your manual intervention.

Keep a note of corrected settings, expected message and final result. Resolution is complete when commercial state remains accurate, the correct event produces the correct email and routing is verified. Recent orders and history must be preserved; a global store restoration is not a way to resend confirmation.