CodeCanyon WooNotify - WordPress Plugin

How to Configure CodeCanyon WooNotify for WooCommerce WhatsApp Notifications

CodeCanyon WooNotify is best viewed not as a standard "message us on WhatsApp" button, but as a transactional messaging layer for a WooCommerce store. In this guide, we will walk through how to prepare your site, connect the Meta WhatsApp Cloud API, configure message templates, enable order triggers, verify the sending queue, and make sure customer consent for messaging is not lost.

This guide is written for a store owner, WordPress administrator, or technical specialist who already understands the basics of WooCommerce and wants to implement automated WhatsApp notifications carefully, without manually forwarding order details. It does not cover how to purchase the product or obtain a license - only installation, configuration, a practical use case, result validation, and troubleshooting for an existing plugin setup.

The main focus is the chain of "order status - Meta template - WooNotify queue - customer message." If that chain is assembled correctly, notifications do not slow down checkout, failed sends can be retried, and the administrator gets a clear log. If any part is configured carelessly, messages may remain queued, use the wrong template, or fail to deliver entirely because of WhatsApp policy rules.

What Problem the Plugin Solves in a WooCommerce Store

A standard WooCommerce store already sends emails about orders, status updates, and payments. The problem is that email often gets buried in the inbox, lands in the Promotions tab, or is read too late. WooNotify adds a different channel - WhatsApp - and sends the customer a short notification when an important order event occurs. This is especially useful for stores where customers expect fast updates about payment confirmation, shipping, delivery, or cancellation.

It is important not to lump all WhatsApp plugins together. Some solutions add a floating chat button, others turn the order flow into a direct conversation, and others function as marketing platforms. CodeCanyon WooNotify is closer to transactional automation: it connects to the official Meta WhatsApp Cloud API, uses approved message templates, queues outgoing messages, and keeps a log. That makes it useful for post-purchase order updates, not just pre-sales questions.

When WooNotify Is Actually Useful

The plugin is a good fit for stores where WhatsApp is already a familiar customer communication channel. Typical examples include clothing, electronics, cosmetics, grocery, local delivery, or stores with manual order processing. Customers want to quickly understand that the order was received, the payment was confirmed, the package was shipped, the courier is on the way, or the refund has been processed.

Another use case is abandoned cart recovery. According to the WooNotify documentation, it stores incomplete checkout data if the customer entered a phone number and checked the box consenting to WhatsApp updates. Later, the plugin can queue a message with a cart recovery link. This is not a magic replacement for email marketing, but it is a strong additional channel for stores where WhatsApp really gets read faster.

Who Should Be More Careful

The plugin may not be a good fit for a site that simply wants to show a contact button without a Meta Business Account, without templates, without a token, and without consent rules. In that case, a click-to-chat solution is easier. WooNotify is also not something you should roll out casually in a store that does not have a clear order status workflow. If managers change statuses inconsistently or fail to enter the tracking number before marking an order as shipped, automated messaging will only expose the mistake to the customer faster.

Finally, this is not a full-scale support hub. WooNotify documentation focuses on notifications, queuing, retries, abandoned cart recovery, and logging. If you need team inboxes, segmentation, bulk campaigns, operator roles, and CRM-style workflows, compare WooNotify with larger platforms in the related solutions section.

Practical takeaway: WooNotify works best when orders are already being processed in WooCommerce and WhatsApp is needed as a fast, verifiable channel for transactional updates.

What to Check Before Installation and First Launch

Before installing the plugin, do not start by uploading the ZIP file to WordPress. First, verify that the store has the minimum infrastructure required for official message delivery through the WhatsApp Cloud API. WooNotify is not a workaround gateway and should not be treated as a way to send any text to any buyer. It operates within Meta's rules: a business account, a WhatsApp Business number, a token, a Phone Number ID, approved templates, and customer consent.

WordPress and WooCommerce Technical Baseline

According to the plugin author's documentation, WooNotify requires current versions of WordPress, WooCommerce, and PHP, and WooCommerce must already be active before the plugin is activated. That makes sense: the plugin creates its own tables, registers WP-Cron jobs, and hooks into order events. If WooCommerce is disabled, the notification layer has no event source and cannot function correctly.

Before installation, check three things on a staging copy of the site. First, test orders should be created successfully. Second, order statuses should change predictably: payment moves the order to processing, the manager moves a shipped order to the correct status, and cancellations and refunds appear in the standard order history. Third, third-party shipping, payment, and order status plugins should not break the order edit screen.

HPOS and Plugins That Read Orders

WooNotify is advertised as compatible with High-Performance Order Storage. That matters for modern WooCommerce stores because orders may be stored in dedicated WooCommerce tables instead of only in WordPress post tables. In practice, this means you should review the site's plugin list before rollout and check whether any extensions are marked as incompatible with HPOS.

If the store already uses HPOS, do not disable it just to install WooNotify. Test the plugin on a staging copy first, create several orders, and confirm that WooNotify writes an entry to its log when the order status changes. If the store has not migrated to HPOS yet, do not combine order storage migration and WhatsApp notification rollout on the same day. It is safer to stabilize order storage first and then add a new messaging channel.

Meta Business Account, Templates, and Customer Consent

The most common mistake with this kind of setup is assuming that a regular WhatsApp number is enough. Automated outbound notifications require the Meta business context: a WhatsApp Business Account, a Phone Number ID, and a permanent system user token. In addition, messages initiated by the business usually require approved templates. If the store tries to send free-form text without an incoming customer message first, delivery may fail.

Prepare the consent text on the checkout page separately. WooNotify adds an opt-in checkbox that, according to the documentation, is unchecked by default. That is the right behavior: the customer must explicitly agree to receive WhatsApp updates. Do not turn the checkbox into hidden consent, and do not use vague wording. It is better to clearly explain that the customer will receive order, delivery, and cart recovery messages, if that feature is enabled.

What Not to Do on a Live Store

Do not enter a temporary token from the Meta panel if the documentation requires a permanent system token. Do not test abandoned cart recovery on real customers before the template and consent flow are configured. Do not enable every trigger at once if you do not yet have approved templates for each use case. And do not change cron settings on your hosting account unless you understand what other tasks WordPress is already using.

A good rollout plan is simpler: a staging copy, one template to validate the API, one test order, a message log review, then status-based triggers, then abandoned cart recovery, then validation on a small group of real orders.

Installation and Initial Post-Activation Checks

Installing the WordPress plugin is technically standard: upload the archive through Plugins - Add New - Upload Plugin, then activate it from the installed plugins list. What matters more is what happens next: after activation, WooNotify should create its internal tables, add WP-Cron jobs, and expose the WA Notify settings area. If those elements are missing, configuring the API will not produce a complete working setup.

After activation, do not rush to paste in every key. First, open the admin panel and make sure WooCommerce is active, the orders screen opens without errors, and a WA Notify section or equivalent settings item has appeared in the menu. If the top of the admin screen shows a notice that WooCommerce is missing, restore WooCommerce first instead of trying to configure the plugin separately.

Initial Validation Without a Real Customer

The first test is best done using an admin-owned number. In the API Setup settings, enter the Phone Number ID, permanent token, template language, and test phone number. WooNotify documentation suggests using the hello_world test template if it fits your connection check. This kind of test is useful because it separates API access issues from problems with a specific order template.

If the test message does not arrive, do not move on to creating an order. First, run the connection validation if that option is available in the interface. A successful check should show that Meta accepted the Phone Number ID and token. An error at this stage usually means the ID is incorrect, the token is temporary or revoked, the app is still in development mode, or the system user lacks the required permissions.

Checking Internal Tables and the Queue Without Direct Database Access

It is easy for a typical guide to recommend opening the database and searching for tables manually, but that is not the best first step for a store owner. In WooNotify, the main operational screen should be the Message Log. If a test order creates a log row with the status Queued, that means the plugin reached at least the message queueing stage. If the row later changes to Sent, Meta accepted the message for delivery.

Database access is only needed when diagnosing abandoned cart recovery or disputed edge cases on a staging copy. The article below explains which states matter, but for day-to-day work, use the log as your primary reference: it is safer, clearer, and does not require risky manual table edits.

Meta API, Templates, and Variables: How to Configure Them Without the Usual Mistakes

The most important part of WooNotify is not the list of triggers but the connection between the Meta API and Message Templates. That is what determines whether WhatsApp will accept automated outbound notifications. The documentation emphasizes that a Phone Number ID is not the same thing as an App ID, a WABA ID, or a regular phone number. This mix-up is common because all of the values look like long numbers, but they are used in different places.

Phone Number ID and Permanent System Token

The Phone Number ID is taken from the Meta Developers panel in the WhatsApp API Setup section. In WooNotify, you must enter the sender number's identifier, not the actual phone number in international format. The actual number matters to the business and the customer, but the API talks to the numeric ID. If you enter the wrong value, Meta may return an error such as "Object with ID does not exist".

The permanent token is created through a system user in Meta Business settings. Do not use the temporary token from the quick API Setup panel, because it is only intended for short-term testing. In a store setup, the token must remain valid long enough, have the correct permissions for the WhatsApp Business Account, and be stored securely in the WordPress database. WooNotify documentation explicitly states that the token is stored in site settings, so database security and admin access matter here.

Do not expose the token in task descriptions, articles, support tickets, or public screenshots without masking it. If you need to show a problem to a developer, hide most of the value and leave only the error context.

Why Free-Form Text Is Unreliable for Order Notifications

The WhatsApp Business Platform distinguishes between messages a business sends within an active conversation and messages initiated by the business. An order, shipping, or abandoned cart notification is typically business-initiated. That requires an approved template. WooNotify may show a text preview, but the actual delivery must use a template message if the customer did not contact the business first within the allowed conversation window.

That is why you should not fill in only the preview field and assume it is enough. Configure the Meta template name, template language, and variable mapping. If the template is called order_confirmed in Meta, but WooNotify is configured with order-confirmed or a different language code, delivery can fail even if the message text itself looks correct.

Template Variable Mapping

Meta uses positional variables such as {{1}}, {{2}}, and {{3}}. WooNotify maps those to its own variables, such as {{customer_name}}, {{order_id}}, {{order_total}}, {{tracking_number}}, {{site_name}}, and {{cart_link}}. The order is critical. If the template expects three variables but the configuration provides two or four, Meta will return a parameter count error.

For a shipping notification, the mapping might work like this: the first value is the customer name, the second is the order number, the third is the tracking number, and the fourth is the store name. In WooNotify, that would be mapped as {{customer_name}},{{order_id}},{{tracking_number}},{{site_name}}. If the tracking number is not filled in before the status changes, the message may contain an empty value or a fallback. That is why your order handling workflow must account for the proper sequence.

A Quick Checklist for Each Template

• The template name in WooNotify matches the name in WhatsApp Manager character for character.
• The language code in WooNotify matches the language code of the approved template.
• The number of Meta variables matches the number of variables in Parameter Mapping.
• The variables are arranged in the order the customer should see the data.
• The preview in WooNotify is used as a reference, not as a replacement for the approved template.

Safe Message Localization

If the store serves a Russian-speaking audience, the templates in Meta must be created in the correct language, or in the specific language version you actually use. Do not try to work around a language mismatch by translating only inside WooNotify. Meta validates the language code of the approved template. If the template was created in English but the plugin uses a different code, the error may look like a missing translated template.

For transactional notifications, keep the wording short and specific: order received, payment confirmed, order shipped, package handed off for delivery, order completed, order canceled, refund processed. Marketing copy, promo codes, and sales calls to action can change the template category and affect delivery rules. If the purpose is order notification, keep the message tied to the order event.

Order Triggers, New Statuses, and the Tracking Number

What makes CodeCanyon WooNotify different from simple WhatsApp buttons is that it listens to WooCommerce order events. The documentation lists triggers for payment confirmation, shipping, out-for-delivery, completion, cancellation, refund, and abandoned cart. Each trigger can be enabled separately, and each use case can be assigned its own Meta template. That way, you do not have to send one generic message for every situation.

Payment Confirmed and Processing

The first message a customer usually expects is the payment confirmation. In WooNotify, the Payment Confirmed trigger is tied to the Processing status, which is when WooCommerce treats the payment as received and the order as ready to be handled. For digital goods or stores with instant payment capture, this may be the primary trigger. For orders that require manual payment review, make sure the payment gateway does not move the order to Processing before the team is ready to confirm payment to the customer.

The template for this event should be as calm and clear as possible: customer name, order number, total amount or a brief confirmation, and the store name. Do not add extra promotions to the first transactional message. The customer should immediately understand that the order has been received and acknowledged by the store.

Shipped and Out for Delivery as Custom Statuses

By default, WooCommerce does not provide a full logistics chain of "shipped" and "out for delivery" for every store. WooNotify adds custom statuses: Shipped and Out for Delivery. This helps you avoid using Completed too early. If the store physically ships products, it is better to separate the stages: order paid, order shipped, order with the courier or in final-mile delivery, order completed.

This level of detail is only useful if the process is disciplined. If a manager forgets to change the status or does it after the fact, the customer will receive messages at the wrong time. Before enabling these triggers, define a simple rule for the team: once the order is handed over to the shipping service, enter the tracking number first, save the order, and only then change the status to Shipped. For local courier delivery, use Out for Delivery when the order is already on route.

Tracking Number and the Sequence of Actions

WooNotify adds a WhatsApp Tracking Number field to the order edit screen. The value of that field becomes available as the {{tracking_number}} variable. If the shipping template includes a tracking number, the sequence matters: fill in the field, save the order, confirm that the value remains in place, and only then change the status to shipped.

If the status is changed first, the message may go out without the tracking number or with a technical fallback. The customer will receive the notification but miss the most useful part of it. Internally, it is best to establish one simple rule: do not change the shipping status until the tracking number or tracking link has been added to the order.

Cancellation, Refunds, and Message Tone

The Cancelled and Refunded triggers may look secondary, but they are the ones that can reduce customer anxiety. If an order has been canceled or a refund has already been processed, a WhatsApp message can save support from repetitive follow-up questions. The tone still needs to be careful: state the fact, include the order number, and suggest contacting support if the customer did not expect that status.

Do not send aggressive marketing messages in a cancellation or refund notification. The event itself is sensitive. A good formula is: "Your order #... has been canceled. If this is a mistake, reply to this message or contact support." For refunds: "The refund for order #... has been processed. The posting time depends on your payment method." If the exact timing is not confirmed by the payment gateway, do not promise a specific timeframe.

Abandoned Cart: Recovering the Cart Through Consent and a Link

Abandoned cart handling in WooNotify is not designed as a generic broadcast to every visitor. According to the plugin documentation, it records an incomplete checkout only when certain conditions are met: the customer entered a phone number, checked the WhatsApp opt-in, the cart was saved through a background AJAX request, and the order was not completed afterward. Once the waiting threshold passes, a cron task looks for active records and places a recovery message in the queue.

What Data Is Needed for Recovery

For abandoned cart recovery, the important pieces are the phone number, cart contents, total amount, recovery token, and session status. The template usually needs the customer name, cart total, a recovery link via {{cart_link}}, and the store name. If the template does not include the link, the message may remind the customer about the cart but will not take them back to the restored contents directly. If the link is present, clicking it should restore the cart in WooCommerce and return the customer to the checkout flow.

Do not enable this trigger until you have tested both the opt-in and the template. A recovery message without consent is bad practice. A message without a working link is frustrating. A message with the wrong total or outdated products creates disputes. That is why abandoned cart recovery should be tested on its own, not turned on together with every status notification at once.

How to Test Abandoned Cart Recovery

The test is best run in a private browser window. Add a product to the cart, go to checkout, enter a phone number, check the WhatsApp updates consent box, and wait long enough for the background handler to save the data. Then leave the page without completing the order. WooNotify documentation notes that during testing you can use forced queue processing through the Message Log so you do not have to wait for the natural cron cycle.

The test is successful if an active abandoned cart record appears, then after threshold processing a message for the abandoned trigger shows up in the log, and the WhatsApp link restores the cart. On a live store, also verify that the restored cart does not conflict with coupons, product variations, or shipping rules.

When It Is Better to Disable Abandoned Cart Recovery

If the store operates in a sensitive niche where a WhatsApp message could reveal a purchase to other people, the feature should be enabled only after legal and UX review. If the average order requires manual agreement on product mix, discounts, or delivery details, an automated recovery link may be less useful than a personal manager. If WP-Cron is unstable on the site, abandoned cart recovery will trigger unpredictably and create confusion for the team.

A safe strategy is to enable abandoned cart recovery first for a test group or a low-risk product segment, review the log, confirm the links behave correctly, and only then expand usage.

The Queue, Message Log, and WP-Cron

One of WooNotify's most practical mechanisms is its sending queue. The plugin does not try to send a WhatsApp message synchronously at the exact moment the order is saved. Instead, it creates a record in the log table, marks it as Queued, and a WP-Cron handler calls the Meta API later. This reduces the risk of slowing down checkout and allows retries when the API is temporarily unavailable.

Queued, Sent, and Failed Statuses

Queued means WooNotify has built the message and is waiting for the queue processor to run. That is normal as long as cron is working and the record does not stay pending for too long. Sent means the Meta API accepted the message. That does not always mean "read by the customer," but for the administrator it confirms that the request left WordPress successfully. Failed means Meta returned an error or retries did not resolve the issue.

Do not delete failed rows right away. First, read the error_message and identify the root cause: the template name, language, parameter count, token, Phone Number ID, app mode, or opt-in. Once the issue is fixed, you can use Retry. Deleting the row may clean up the log, but it does not fix the configuration.

Why WP-Cron Affects Delivery

WP-Cron runs off site visits, not always as a true system cron job on the server. On an active store, that often works well enough. On a low-traffic site, a staging copy, or a local environment, tasks may be delayed. WooNotify documentation describes two cron jobs: queue processing and abandoned cart checks. If they do not run, messages will remain pending and abandoned cart notifications will never reach the sending stage.

For a production store with real orders, it is better to configure a proper server-side cron job or use your hosting control panel. But do that with a technical specialist, because a bad cron setup can affect more than WooNotify - including updates, scheduled publishing, subscriptions, newsletters, and tasks from other plugins.

Cron Self-Recovery and Cache Limitations

WooNotify documentation states that the plugin checks for the presence of its cron events and can recreate them on page load. That is a useful safeguard after a cache plugin clears the schedule or after a WordPress update. But self-recovery does not replace a functioning scheduler. If the site receives almost no visits, the lack of requests to WordPress will still delay tasks.

Caching plugins usually should not interfere with server-side cron jobs, but they can indirectly affect the abandoned cart checkout script if they aggressively combine, defer, or exclude JavaScript without testing. If abandoned cart data stopped being saved after a performance optimization change, temporarily disable the questionable optimizations on the checkout page and rerun the test.

Full Post-Installation Setup: The Right Order of Tabs and Decisions

After the first successful test, it is easy to fall into a trap: the administrator sees that the API responds and immediately enables every notification. That is the wrong order for WooNotify. The plugin touches money, orders, personal data, and customer expectations, so the setup should be approached like a small implementation project. First the connection, then checkout consent, then one working template, then the trigger map, then abandoned cart recovery, and only after that ongoing log monitoring.

That order may feel slower, but it reduces the risk of large-scale mistakes. If the language code is wrong, one test template will expose the issue immediately. If the variable order is mixed up, one test order will send one ugly message only to the administrator. If WP-Cron is not working, one record will get stuck in the queue instead of dozens of customer notifications. WooNotify provides control tools, but they need to be used before you send messages into a live order stream.

API Setup: The Minimum Fields for a Trusted Connection

In the API Setup tab, start by filling in only what is needed to validate the connection: the Phone Number ID, the permanent system user token, the language code, and the administrator's phone number. If the interface includes a Test Template Name field, use a template that definitely exists and does not require complex variables. For the initial test, the goal is not polished copy - it is proof that WordPress, WooNotify, and Meta can communicate.

After saving the settings, run two checks. The first is Validate Connection, if that button is available. It confirms that the token and Phone Number ID are not mixed up. The second is Send Test. It confirms that the plugin can assemble the request and send it through Meta. Only after that does it make sense to move on to order templates. If Validate Connection passes but Send Test fails, the issue is usually the template, language, or test variables. If Validate Connection fails, do not waste time on WooCommerce orders - fix the basic access first.

Notifications: Enable Only the Events Your Team Actually Supports

The Notifications tab may look like a simple set of toggles, but each toggle creates an obligation to the customer. If you enable Out for Delivery, the team must actually move the order into that status when it is handed to the courier or reaches final delivery. If you enable Refunded, the refund should already be processed in WooCommerce or the payment gateway, not just under discussion with the customer. If you enable Abandoned Cart, the store should understand how often and to whom it is sending reminders about incomplete orders.

For a standard rollout, enable only Payment Confirmed first. It is the clearest and easiest trigger to validate. Once it works reliably, add Shipped and Completed. Out for Delivery is not necessary for everyone: if the store ships through a postal service and does not control the final courier stage, that status may create a false impression of precision. Cancelled and Refunded are useful, but they require careful templates without putting pressure on the customer.

Templates: Keep Them Short and Verifiable

In the Templates tab, each card should answer three questions: what event happened, what information the customer needs, and what they should understand after reading the message. For Payment Confirmed, the customer name, order number, total amount, and store name are usually enough. For Shipped, you need a tracking number or tracking link. For Abandoned Cart, you need a recovery link. For Refunded, you need confirmation that the refund was processed and a calm note that posting times depend on the payment method.

Do not try to build one universal template for every case. Universal text rarely sounds natural and often requires unnecessary variables. Split templates by event and test each one separately. A good rule is this: if a manager cannot explain where each variable in the message comes from, the template is not ready for production use.

How to Choose Variables for a Typical Store

• For payment confirmation, use {{customer_name}}, {{order_id}}, {{order_total}}, and {{site_name}}.
• For shipping, add {{tracking_number}}, but only if the team always enters it before changing the status.
• For abandoned cart recovery, use {{cart_link}}; otherwise the message will not bring the customer back to the cart.
• For cancellation and refund messages, do not overload the template with amounts if that could create disputes with the payment gateway.
• For internal testing, use Test Variables with the same number of values expected by the Meta template.

Checkout: Consent Should Be Part of the Customer Experience

Configuring the opt-in label affects not only legal compliance but also trust. The customer should understand why they are being asked to check the box. If the text only says "Receive notifications," the meaning is too broad. If it says "Receive WhatsApp notifications about your order and delivery," the person understands that it refers to a specific purchase. If abandoned cart recovery is enabled, the wording should reflect that honestly as well.

Do not make the opt-in the most visually dominant element of checkout, and do not bury it among optional marketing consents. It should be visible but not aggressive. After changing the text, test checkout on a mobile screen, because that is where customers are most likely to enter a phone number and see WhatsApp as a natural communication channel. If the theme or checkout builder changes field placement, make sure the checkbox does not disappear and is saved with the order.

Message Log: Setting Up Ongoing Oversight

After launch, assign someone to review the Message Log regularly. This does not have to be a developer. A store manager can open the log once a day and check for recurring failed messages. If the same template keeps failing, fix it in Templates. If every message is failing, the issue is more likely the token, Phone Number ID, Meta access, or cron. If failures affect only certain phone numbers, check the number format and whether the customer actually has WhatsApp.

CSV export is useful for investigating disputed weeks: you can see which events were sent most often, where errors occurred, and whether an increase in failed messages lines up with a theme update, checkout plugin change, cache tweak, or payment gateway update. Do not treat the log as an archive for the sake of archiving. Its purpose is to help you quickly understand what happened to a specific message.

How to Roll Back a Problematic Setting Safely

If errors start appearing after you enable a new trigger, do not disable WooNotify entirely. First, disable only that trigger in Notifications. Then fix the template or mapping, send a test message, create a test order, and only re-enable the trigger after validation. If the problem is in abandoned cart recovery, temporarily disable only the abandoned cart trigger while leaving order status notifications active. If the problem is API access, stop all sending, because different triggers will fail for the same reason.

A rollback is handled correctly when no new broken messages are being created, old failed rows remain in the log for analysis, and the team knows exactly which setting changed. Deleting failed rows before analysis removes the evidence and forces you to diagnose the issue from scratch again.

Practical Use Case: Notifications from Payment Through Delivery

Imagine a store that sells physical goods and wants to reduce manual WhatsApp messaging. The goal is to send customers three automated notifications: payment confirmed, order shipped with tracking number, and order out for delivery or completed. In addition, the store wants to remind customers about abandoned carts, but only if they explicitly agreed to receive WhatsApp updates.

Goal and Preparation

The goal of this setup is to build a predictable status chain. The customer receives a message only when a real event has occurred in WooCommerce. The store team sees every send in the Message Log and can retry a failed message after fixing the issue. To prepare, you need a working WooCommerce store, a connected Meta Cloud API, approved templates for each event, a test product, a test payment method, and an administrator phone number for validation.

Setup Steps

1. In WA Notify - Settings - API Setup, enter the Phone Number ID, permanent System User token, template language code, and the administrator's phone number for testing.
2. Run the connection check or send a test template. If the test fails, do not move on to orders.
3. Enable only Payment Confirmed in Notifications and assign an approved template name to it.
4. In Templates, map the variables, for example {{customer_name}},{{order_id}},{{order_total}},{{site_name}}.
5. Create a test order and check the opt-in box at checkout, then move the order to Processing.
6. Open the Message Log and confirm that the record appears as Queued, then changes to Sent after queue processing runs.
7. Add the Shipped template, enable the corresponding trigger, enter the WhatsApp Tracking Number in the order, save it, and only then change the status to Shipped.
8. Repeat the log check, then add Out for Delivery, Completed, Cancelled, and Refunded only for the events your store actually uses.

How to Verify the Outcome

The outcome should be visible in three places. In WooCommerce, the order status changes in the correct sequence. In the Message Log, each event creates a separate row with a clear trigger_event, status, and preview. In WhatsApp on the test phone, messages arrive with the correct customer name, order number, total, tracking number, and store name.

If the message arrives but the data is mixed up, the issue is almost always the variable order. If the message stays queued, check WP-Cron. If the row becomes failed, read the Meta error and compare the template, language, and token. If there is no row in the log at all, check the opt-in, trigger activation, and whether the order status actually changed.

A Common Pitfall for Stores with Manual Processing

In stores where a manager manually confirms payment or assembles the order, automation should help the team, not get ahead of it. Do not configure Payment Confirmed as a promise of imminent shipping. Do not use Completed if, in your workflow, it only means "closed by accounting." It is better to write templates around your real internal statuses and train the team to change them only after the underlying action has actually happened.

Post-Launch Validation

After configuring WooNotify, you should evaluate more than just whether one test message was delivered. You need to understand how the plugin behaves across different order types, how it handles Meta rejections, how it responds when no opt-in is present, and whether it interferes with checkout. Validation should be brief but regular.

Test Matrix

What Counts as a Successful Launch

A successful launch is not "the plugin is activated." A successful launch is when the store team can take any test order and explain why a particular message was or was not sent. If the customer checked the opt-in box and the status changed to an enabled trigger, a record appears in the log. If the template is correct and cron is working, the record moves to Sent. If the customer did not check opt-in, no notification is sent, and that is the expected behavior.

After a few days of use, it is helpful to export the log to CSV and see which errors recur most often. If most failed rows are tied to one template, fix the template. If delays affect all messages, inspect cron. If abandoned cart recovery records are rarely created, check the consent checkbox, the checkout scripts, and whether the theme is removing the phone field.

Safe Improvements and Practical Habits

With WooNotify, there is no reason to start by editing code. Process-level improvements are more valuable: clear templates, careful opt-in wording, disciplined status handling, a separate administrator test number, and regular log review. Code-level interventions in checkout or order hooks can easily break the critical checkout path, so without confirmed product documentation, it is better not to add them.

Make the Opt-In Clear Without Making It Pushy

In the Checkout Tab settings, you can change the checkbox label. A good English version would be: "Receive WhatsApp updates about your order and delivery." If abandoned cart recovery is enabled, it is better to expand it: "Receive WhatsApp updates about your order, delivery, and cart recovery." Do not use vague wording such as "receive news" - that changes the meaning and may conflict with the transactional nature of the templates.

Do not enable a pre-checked checkbox without a legal review. WooNotify documentation indicates that the default value is disabled, and that is a sensible setting for most stores. Consent should be the customer's action, not a hidden condition of checkout.

Separate Transactional and Marketing Messages

If Meta classifies the template as a utility message, it should clearly relate to a specific order, payment, delivery, refund, or cart. Mixing an order confirmation with a promotional coupon can change the template category and make moderation more difficult. It is better to keep WooNotify as an order-event channel and handle marketing campaigns in a separate tool, if they are truly needed and legally allowed.

Use the Log as an Operational Tool

The Message Log is not just a technical screen. It is where a manager can see whether a message was sent after a status change. If the team works with orders every day, add a short rule to your operating process: if there is a dispute with a customer, first open the order and the Message Log, then check email, and only after that contact the developer. That will help you separate a template issue from a cron delay or missing consent much faster.

Common WooNotify Issues and Troubleshooting

Most WooNotify issues are not caused by the WordPress plugin itself, but by the junction between WooCommerce, the Meta API, templates, consent, and the task scheduler. Below is a practical symptom-based troubleshooting guide. Start with the most visible sign and work your way toward the settings without changing everything at once.

Error: "Object with ID does not exist"

Symptom: the connection test or message send returns an object error. In the Message Log, the message may end with failed, and the error text references an ID.

Cause: the wrong identifier was entered in the Phone Number ID field. People often paste the App ID, WABA ID, or the phone number itself by mistake.

What to check: open the Meta Developer Console, go to WhatsApp - API Setup, find the Phone Number ID specifically under the sending number, and compare it to the WooNotify setting.

How to fix it: replace the value, save the settings, and run Validate Connection or a test send. If the error is gone, retry the failed message using Retry.

Template Parameter Count Error

Symptom: Meta returns an error about a parameter count mismatch, often with a code that WooNotify documentation associates with template variables.

Cause: the Meta template contains one number of {{1}}, {{2}}, {{3}} placeholders, while Parameter Mapping in WooNotify contains a different number of variables.

What to check: open the template in WhatsApp Manager, count all positional variables, and compare that count with the number of values in the mapping field.

How to fix it: provide exactly as many variables as the template expects, in the correct order. After saving, send a test using the same number of Test Variables.

Template Not Found in the Selected Language

Symptom: the message does not send even though the template name looks correct. The error mentions the template name or translation.

Cause: the template name differs by even one character, or the Template Language Code does not match the language version approved in Meta.

What to check: in WhatsApp Manager, find the exact name and language code. Do not rely on the human-readable language name - check the system code.

How to fix it: correct the template name and language code in WooNotify. If the store uses multiple languages, do not mix templates from different languages under the same trigger.

Messages Stay Stuck in Queued

Symptom: records appear in the Message Log but do not move to Sent or Failed. The customer receives nothing.

Cause: the queue is not being processed. On a local site, a low-traffic staging copy, or when WP-Cron has scheduler issues, tasks may not run on time.

What to check: the cron banner in the Message Log, whether a Process Queue Now button is available, site traffic activity, server cron settings, and plugins that manage scheduled actions.

How to fix it: for testing, click Process Queue Now. For a live site, set up a real server cron job with a technical specialist. If the queue processes immediately afterward, the cause was the scheduler, not the template.

The API Is Connected, but the Customer Does Not Receive the Message

Symptom: the connection test passes, but the order notification never reaches the customer.

Cause: possible reasons include a missing approved template, fallback to free-form text, no opt-in, an invalid customer number, the Meta app still being in development mode, or a phone number that does not use WhatsApp.

What to check: whether there is a row in the Message Log, what status it has, whether the customer checked opt-in, which number was stored in billing phone, and whether a Meta Template Name is configured for the specific trigger.

How to fix it: first make sure you can get a clean Sent status on the administrator's test number, then repeat the flow with a real checkout and opt-in. Do not change the template, language, and token all at once.

Abandoned Cart Recovery Is Not Created or Not Sent

Symptom: the test abandoned cart does not appear in the log and does not lead to a WhatsApp message.

Cause: the abandoned cart trigger is not enabled, no template is assigned, the customer did not check opt-in, the phone was entered after a problematic action, the checkout script did not save the session, or cron did not process the waiting threshold.

What to check: whether the trigger is enabled, the abandoned cart template, the presence of {{cart_link}} in the mapping, whether checkout works without JavaScript errors, and whether the phone number and consent were saved.

How to fix it: repeat the test in a private window: product, checkout, phone number, opt-in, leave without ordering, then run Process Queue Now after the threshold. If the session does not appear, temporarily disable JavaScript optimizations on checkout and test the theme.

Shipped and Out for Delivery Statuses Are Not Visible

Symptom: the order status dropdown does not show the new shipping and delivery stages.

Cause: the status did not register after activation, the admin cache is stale, or an order status plugin conflict is blocking the display.

What to check: whether WooNotify is active, whether the orders screen opens without errors, and whether another plugin is fully replacing WooCommerce statuses.

How to fix it: on a staging copy, deactivate and reactivate WooNotify, clear the cache, and reopen the orders screen. If the statuses appear, investigate a conflict with order status extensions.

When CodeCanyon WooNotify Is the Right Choice

CodeCanyon WooNotify is a strong option if your WooCommerce store wants to send customers clear WhatsApp notifications throughout the order lifecycle and is ready to configure the official Meta Cloud API. The plugin's strengths are its templates, queueing, retries, custom shipping statuses, tracking number support, abandoned cart recovery, and message log. It is not the easiest path for someone who only wants a chat button, but it offers much more control for transactional automation.

Before launch, validate a test order, the opt-in flow, the template language, the number of variables, cron behavior, and the log. Then enable triggers gradually. If the store team understands when to change statuses and where to check the Message Log, WooNotify becomes a useful operational part of the store rather than "just another plugin in the admin area."

If that matches your use case, you can move on to the download section and download the CodeCanyon WooNotify file, then deploy it on a staging copy of the store first. For a live site, the safest order remains the same: staging, API test, one trigger, one test order, the log, then gradual rollout of the remaining messages.