Yes, you can enable push for WooCommerce: use the Woo Mobile App for staff order alerts and a web push or native App Clip approach for customer engagement. Which path you follow depends on whether you need internal order alerts or customer-facing marketing and cart recovery. Either way, you will want a current WooCommerce version, HTTPS on your storefront, and service-worker support (or an active Jetpack connection) before you start.
TL;DR:
- Web push for customer engagement requires HTTPS, service-worker support, and user opt-in prompts, with limited reach on iOS Safari due to platform restrictions.
- Woo Mobile App push notifications for staff alerts are quick to set up, do not require user consent, and work reliably across Android and iOS devices.
- Testing push notifications involves confirming device tokens, triggering events like orders or cart abandonment, and checking real-time delivery within seconds.
- Native iOS App Clips provide a more consistent reach for cart recovery notifications on iOS devices where web push cannot deliver, without requiring email or app installation.
- Early priorities should include staff order alerts and monitoring key metrics like opt-in rate, click-through, and opt-out rates to optimize push performance and user engagement.
Table of Contents
- Which approach should you pick: Woo Mobile App or web push?
- Set up Woo Mobile App push notifications for order alerts
- Add web push for customer-facing order and marketing alerts
- Design opt-in prompts and messages that actually convert
- Run a testing checklist before you trust the delivery path
- Fix the most common reasons push notifications don't arrive
- Why App Clips solve the iOS reach problem web push can't
- What I'd prioritize in the first two weeks
- When native reach matters more than plugin settings
- Where to verify these setup details yourself
- Sources
- FAQ
Which approach should you pick: Woo Mobile App or web push?
The two paths solve different problems, and most stores end up running both once they see how little they overlap.
The Woo Mobile App handles internal alerts. It tells your staff when an order lands, when stock runs low, or when a review comes in, and setup takes minutes because you are just connecting your own store to your own phone. There is no customer opt-in flow to design and no consent language to write, because nobody outside your team ever sees these notifications.
Web push (through a plugin or a hosted service) targets your shoppers. It re-engages people who abandoned a cart, announces a flash sale, or nudges someone back to a product page they viewed twice. This path takes more setup: opt-in prompts, message templates, segmentation, and testing across browsers. It also carries a real limitation on iOS, where Apple's rules around web push and Safari mean a meaningful share of your mobile visitors may never see a prompt at all.
Here is the practical breakdown:
- Woo Mobile App: fast setup, staff-only, no consent requirements, works reliably across Android and iOS for the merchant's own device.
- Web push plugin or service: customer-facing, needs opt-in and HTTPS, strong on desktop and Android Chrome, weaker reach on iOS Safari.
- Running both: common and low-conflict, since one serves your team and the other serves your shoppers, with no overlap in permissions or triggers.
If you sell primarily to iOS-heavy audiences, the web push gap matters enough that it is worth planning around before you invest in an opt-in campaign, a point we will come back to later.
Set up Woo Mobile App push notifications for order alerts
This is the fastest win in this guide, and it is the one every store should do first regardless of what you decide about customer push later.
Before you start, confirm your version numbers. As of WooCommerce 10.9.2 and Woo Mobile App 25.0.1, the app can configure push notifications directly using the Jetpack Connection Package that ships with WooCommerce, so you no longer need the full Jetpack plugin installed just to get order alerts working. If you are on an older version, you will need Jetpack connected in the traditional way.
Follow these steps in order:
- Update WooCommerce to at least 10.9.2 and install the current Woo Mobile App from your device's app store.
- Log into the app with your store credentials and let it complete the connection handshake.
- From the My Store dashboard, open the Menu, go to Settings, and select push notifications.
- Toggle on the notification types you want: new orders, low stock, and product reviews are the common three.
- Grant notification permissions when your phone's operating system prompts you, since a denied permission at this stage silently blocks every alert type.
- Repeat the device-level permission step for every staff phone that needs alerts, since permissions are per-device, not per-account.
Once that is done, place a test order (even a $0 or draft one works) and confirm the notification lands on your device within a few seconds. If it does not, check the app's own activity log before assuming the whole setup failed, since most misses trace back to a single denied permission rather than a broken connection.
Pro Tip: On Android, check your battery optimization settings for the Woo Mobile App specifically. Aggressive battery savers can delay or silently drop notifications even when permissions look correct.
If test orders never arrive, work through this shortlist: confirm notification permissions are still granted (they can get revoked during OS updates), check that the app isn't restricted by battery settings, and look at the app's log for a failed handshake with your site. Most failures resolve with a permission reset or a fresh app login.
Add web push for customer-facing order and marketing alerts
This section covers the generic workflow that applies whether you pick a WooCommerce push plugin or a hosted push service, since the underlying mechanics are the same across vendors.
Prerequisites first. Your site needs HTTPS everywhere (not just on checkout), a browser environment that supports service workers, and a clear plan for cookie or consent banners if you serve visitors covered by GDPR. You also need to confirm the scope your service worker registers at, since a script registered at a subfolder will not catch traffic on your root domain, a mistake that quietly breaks delivery for half your site.
The setup itself follows a predictable sequence:
- Sign up for your chosen plugin or hosted service and generate your site's push credentials or API keys.
- Install the plugin (or add the service's script tag) and confirm the service worker registers correctly at your site's root scope.
- Configure your opt-in prompt, starting with a soft, on-page ask before the native browser permission dialog appears.
- Map your triggers: add-to-cart events, abandoned checkout, order status changes, and back-in-stock alerts are the most common.
- Build your message templates for each trigger and, where your tool supports it, segment by cart value, product category, or customer tag.
- Run a full test cycle before turning triggers on for real traffic.
That last step deserves its own checklist, because skipping it is how stores end up sending broken links to hundreds of subscribers:
- Register a test browser or device and confirm it shows up in your plugin's subscriber list.
- Simulate each trigger (abandon a cart, change an order status) and confirm the notification fires within the expected window.
- Click through from the notification and confirm the landing page loads correctly, with UTM parameters intact if you are tracking attribution.
- Check that unsubscribe or opt-out actions actually remove the device from future sends.
On the performance side, service worker registration and push scripts add a small amount of overhead to every page load, so it is worth pairing this setup with solid caching. A rundown of caching plugins for WooCommerce is a reasonable place to check that your site can absorb the extra script weight without slowing down checkout.
On privacy, treat push subscription the same way you would treat an email list: disclose what you are collecting (device tokens, not personal identifiers, in most cases), make opt-out obvious, and avoid triggers that reveal more about a customer's behavior than they would expect from a store they just started browsing.
Design opt-in prompts and messages that actually convert
The single biggest lever in customer-facing push is the opt-in flow, and most stores get it backward by asking too early.
A two-step prompt beats a native-only prompt almost every time. Show a soft, on-page ask first (a banner or modal explaining what the customer gets), and only trigger the native browser permission dialog after they click "yes" on your own prompt. Jumping straight to the native dialog on page load is the fastest way to train visitors to click "block" out of reflex, and a two-step opt-in flow tends to raise acceptance meaningfully compared to a cold ask.
Remember the iOS caveat from earlier: even a well-designed opt-in flow only reaches shoppers on platforms where web push works reliably. For iOS Safari traffic, that gap is structural, not a copy problem, and it is why some stores pair web push with an App Clip or native approach for that slice of their audience.
For message copy, keep two templates distinct:
- Order alerts: status update, order ID, and a direct link back to the relevant admin or account page, kept short enough to read at a glance.
- Abandoned cart: product name, any discount you are offering, and a clear call to action back to checkout, not the homepage.
Pro Tip: Cap marketing push frequency at a level you would tolerate as a customer. One or two messages a week for cart recovery outperforms daily nudges, which tend to spike opt-outs within the first two weeks.
Segment where you can (cart value, category, repeat versus first-time buyer) and always honor unsubscribe requests immediately. A subscriber who opts out and still receives a push is a subscriber who reports your site, not just your notification.
Run a testing checklist before you trust the delivery path
Before you rely on push for anything customer-facing or operationally important, verify the full delivery path end to end, not just that a message showed up once.
Start with device registration. Confirm the test device or browser actually has a token stored in your plugin's dashboard or your site's push-token endpoint, since a missing token is the most common reason a "sent" notification never arrives.
Next, check the internal send path. WooCommerce's push dispatcher normally authenticates internal requests with an Authorization header, but some hosts strip that header from loopback requests before it reaches your site. To cover that case, WooCommerce added a wcpn_token fallback that appends the credential as a query parameter, so delivery still authenticates even when the header gets stripped.
Then run the real test: place a test order or trigger the event you are validating, and confirm delivery lands on your test device within a few seconds. If it does not land immediately, check Action Scheduler for a safety-net job attempting a delayed retry, since that is the system's built-in fallback for a missed first attempt.
Your acceptance checklist before go-live:
- Device token confirmed present in the dashboard or endpoint.
- Test order triggers an immediate notification, not just a delayed retry.
- Authorization header or wcpn_token fallback both tested where your host is known to strip headers.
- Action Scheduler shows no unexplained duplicate safety-net jobs for the same event.
One useful diagnostic: WooCommerce also exposes a push notification driver status endpoint that reports which drivers are installed, whether they are connected, and which one is currently active, a fast way to confirm the right driver is live before you chase a false alarm elsewhere.
Define your go-live bar clearly: if a test order does not produce an alert on a connected device within seconds, do not flip the feature on for your whole team yet.
Fix the most common reasons push notifications don't arrive
Most delivery failures trace back to one of five causes, and working through them in order saves time.
- iOS delivery gaps: web push on iOS Safari has real platform limitations that no plugin setting can fully work around. If your audience is iOS-heavy, an App Clip or native approach is a more reliable route for that traffic than tuning your existing web push setup further.
- Stripped Authorization headers: some hosting environments strip headers from internal loopback requests. Test for this directly, and rely on the wcpn_token query parameter fallback that WooCommerce added specifically for hosts that do this.
- Android battery restrictions: aggressive battery optimization can delay or drop notifications even with permissions granted. Check both app-level permissions and device battery settings, and review the Woo Mobile App's activity log for dropped sends.
- Jetpack or connection issues: if your driver status shows disconnected or no active driver, check your Jetpack connection status first, then confirm the correct driver shows as active in your driver status endpoint.
- Duplicate safety-net scheduling: if the same notification seems to fire twice, check Action Scheduler for duplicate safety-net jobs scheduled for the same event, since the safety net is designed to check for an existing scheduled action before adding another.
Work through these in sequence rather than jumping to the most dramatic fix first. Nine times out of ten, the culprit is a permission setting or a header, not a broken integration.
Why App Clips solve the iOS reach problem web push can't
Web push was never built to reach every shopper, and iOS is where that shows up hardest. Apple's restrictions on web push in Safari mean a real share of your mobile traffic, often the most valuable share on a lot of storefronts, never even sees a permission prompt.
App Clips work differently. Instead of asking a shopper to install an app or hand over an email address, an App Clip-based flow lets a store re-engage someone who added a product to cart and left, sending a native-level push straight to their lock screen. StorePush documents this approach specifically for recovering anonymous carts without collecting email addresses, which sidesteps the opt-in-then-hope-they-accept problem entirely.
The practical rules are straightforward:
- Triggers fire on real shopper behavior (add-to-cart, checkout abandonment), not on a marketing schedule.
- No email or phone number is required to re-engage the shopper, which also simplifies your consent posture.
- Integration points connect through standard Shopify or WooCommerce hooks, so it layers onto an existing store rather than replacing your checkout flow.
Merchants can go live with App Clip-based cart recovery in about 8 hours, according to StorePush's own integration case notes. StorePush, merchant integration case notes
Track the same core numbers you would for any push channel: opt-in or engagement rate, click-through rate, and recovered revenue attributed back to the notification.
What I'd prioritize in the first two weeks
Get staff order alerts working before you touch anything customer-facing. It is the lower-effort win, it has zero consent complexity, and it gives your team immediate value while you take your time getting the customer-facing setup right.
Once that is live, track four numbers from day one: opt-in rate, push click-through rate, revenue recovered through push-attributed orders, and your opt-out rate. If opt-outs climb past what you would tolerate as a customer, your frequency or targeting is off before your copy is.
The most common early mistake is turning on every trigger at once. Start with one or two (new order status changes, abandoned checkout) and expand once you have two weeks of clean data. Rushing the opt-in flow is the second mistake. A soft prompt before the native ask consistently outperforms a cold native prompt, and it costs you nothing but a few extra minutes of setup.
— Lucas
When native reach matters more than plugin settings
If your store's traffic leans iOS and web push keeps hitting the same wall no matter how you tune the opt-in flow, that is not a configuration problem you can fix with another setting. It is a platform limitation, and StorePush was built specifically around it.
StorePush uses native iOS App Clips to send push notifications straight to a shopper's lock screen, without requiring an email address, a phone number, or an app install. It targets the same abandoned cart and browse abandonment moments a web push plugin would, but reaches the iOS share of your traffic that traditional web push structurally cannot.
If you are already running a web push plugin for desktop and Android, StorePush is not a replacement, it is the missing piece for the traffic your current setup was never going to reach. Store owners can start on a free plan, upgrade to a paid plan as volume grows, and pay a usage commission based on recovered revenue. Check current plan details and get started at StorePush.
Where to verify these setup details yourself
For the technical specifics behind this guide, the primary sources are worth bookmarking. WooCommerce's own pull requests document the wcpn_token authentication fallback, the driver status endpoint, and the notification safety-net scheduling logic. For the App Clip approach to iOS reach, StorePush's own blog covers anonymous cart recovery and integration timelines in more depth.
Sources
- Accept the push notification send credential from the URL when hosts strip the Authorization header
- Add push notification driver status REST endpoint.
- Add notification processor, send controller ... and safety net.
FAQ
Do I need Jetpack to use Woo Mobile App push notifications?
Not anymore in every case. As of WooCommerce 10.9.2 and Woo Mobile App 25.0.1, the app can set up push notifications directly using the Jetpack Connection Package bundled with WooCommerce, so the full Jetpack plugin is no longer a strict requirement for basic order alerts.
Why aren't my WooCommerce push notifications arriving on iOS?
Web push on iOS Safari carries real platform restrictions that limit reach compared to Android or desktop browsers. For stores with heavy iOS traffic, a native approach like App Clip-based push, such as the one StorePush uses, tends to close that gap more reliably than adjusting plugin settings alone.
What causes push notifications to fail silently on WooCommerce?
The most common causes are a stripped Authorization header on hosts that filter loopback requests, denied device permissions, or Android battery optimization delaying delivery. WooCommerce's wcpn_token fallback specifically addresses the header-stripping case so internal dispatch still authenticates.
How do I test that WooCommerce push notifications are actually working?
Place a test order or trigger the relevant event, then confirm the notification lands on a registered test device within a few seconds. If it doesn't arrive immediately, check Action Scheduler for a delayed safety-net retry and confirm your driver status endpoint shows an active driver.
What's the difference between order alert push and marketing push?
Order alert push notifies your staff internally about new orders, low stock, or reviews through the Woo Mobile App, with no customer opt-in involved. Marketing or cart recovery push targets customers directly and requires an opt-in flow, consent handling, and message templates built around triggers like abandoned checkout.