Title: StoreToNative Author: storetonative Published: September 6, 2026 Last modified: September 6, 2026 --- Search plugins ![](https://ps.w.org/storetonative/assets/banner-772x250.png?rev=3683660) ![](https://ps.w.org/storetonative/assets/icon.svg?rev=3683669) # StoreToNative By [storetonative](https://profiles.wordpress.org/storetonative/) [Download](https://downloads.wordpress.org/plugin/storetonative.1.5.2.zip) * [Details](https://wordpress.org/plugins/storetonative/#description) * [Reviews](https://wordpress.org/plugins/storetonative/#reviews) * [Installation](https://wordpress.org/plugins/storetonative/#installation) * [Development](https://wordpress.org/plugins/storetonative/#developers) [Support](https://wordpress.org/support/plugin/storetonative/) ## Description StoreToNative connects your WooCommerce store to the StoreToNative platform so it can power a native iOS and Android app built from your catalog. This companion plugin runs entirely on your own site and only does five things: * **1-click connect.** Paste a short pairing code from your StoreToNative console into this plugin. No OAuth redirect, no “approve this application” screen to trip over on security-hardened sites. * **Deep-link hosting.** Serves `.well-known/apple-app-site-association` and `. well-known/assetlinks.json` from your store’s own domain, which is what iOS Universal Links and Android App Links require. These files must be served from your domain— a plugin is the only way to do that without touching your host’s file system by hand. * **Smart app-install banner.** Once your app exists, shows a lightweight, bundled- JS install banner to shoppers browsing your storefront in a mobile browser, plus an `apple-itunes-app` meta tag so Safari’s own native banner takes over on iOS. * **Store readiness checks.** Looks over your own WooCommerce settings for the dozen things that quietly break a mobile app — “Coming soon” mode still switched on, no payment method enabled, Plain permalinks, no shipping zone, a stale product price index — and tells you what each one costs you and exactly which screen to fix it on. The checks read only your own site and run entirely inside WordPress. * **Shopper sign-in.** Lets a shopper sign in to your native app with their existing WooCommerce account (email + password). This runs entirely between your site and its own app over REST routes this plugin registers — it never involves the StoreToNative platform at all, and your shoppers’ passwords are checked by WordPress itself, exactly as they are on your website’s own login form. No network requests of any kind are made until you explicitly pair your store — see “External services” below for exactly what is sent, and when. #### Requirements * WooCommerce must be installed and active. This plugin does nothing without it. * A StoreToNative account with a store already set up in the console (to generate a pairing code). #### WooCommerce HPOS This plugin declares compatibility with WooCommerce’s High-Performance Order Storage( HPOS / “Custom Order Tables”) feature. It does not read or write order data itself. ### External services This plugin connects to the StoreToNative platform (**api.storetonative.com**) to power your store’s native app. There is **zero network activity before you explicitly pair your store** — installing or activating this plugin alone sends nothing anywhere. **Pairing requires https.** This plugin refuses to pair (and refuses to talk to the StoreToNative API at all) unless your store is served over https — see the FAQ below. **When you pair** (entering a pairing code from your StoreToNative console into this plugin’s connect screen), the plugin sends, once: * Your store’s URL. * A WooCommerce REST API key/secret pair that this plugin generates for itself at that moment. It is a **read/write** key (a standard WooCommerce REST API key): the app needs to read your product catalog and to create and read orders that shoppers place through the app, on your behalf. You can revoke it at any time from the plugin’s Disconnect button or under WooCommerce Settings Advanced REST API. * This plugin’s version number and a short list of its own feature names (currently` status`, `deep-links`, `smart-banner`, `readiness`, `shopper-auth`, `checkout- fields`, `pair-challenge` — which parts of the plugin are active, not any data those features touch). **While that pairing request is in flight, the StoreToNative platform makes one request BACK to your site** to confirm the pairing really came from it and not from someone who merely learned your code: it asks a public read-only route this plugin registers (`storetonative/v1/pair-challenge`) to sign a random value with the pairing code you just typed. The answer is a single one-way HMAC digest — the `pair-challenge` feature sends nothing anywhere itself (the code is sent to StoreToNative only inside your own pairing request above, never in this answer), and the route answers “nothing in progress” at every other moment. This is what stops a stranger with a StoreToNative account from attaching their own app to your store’s address. **After pairing**, the plugin sends a small heartbeat so your StoreToNative console can show the connection is healthy — roughly once a day, once immediately after pairing, at most once every 12 hours while you work in wp-admin, at most once a minute while you have this plugin’s own screen open, and once each time you press** Check connection** on it. Every one of those carries the same thing: * This plugin’s version, its feature-name list (the same seven names above), your WordPress version, and your WooCommerce version. * Whether your store’s WooCommerce customer account registration setting is switched on (true/false only) — this is what lets the app decide whether to offer shoppers a sign-up option alongside sign-in. * The result of the store readiness checks, as a short list of check names paired with a one-word verdict — for example `payment_gateway: fail`, `guest_checkout: warn`, `permalinks: pass`. **Names and verdicts only**: no counts, no product names, no URLs, no settings values, and no text of any kind that you or anyone else typed into this site. The wording you read on the readiness card is stored in the plugin and in the console, never sent between them. This is what lets your console show you the same warnings without anyone having to log in to your store. It is only ever sent after you have paired, and only the thirteen fixed check names this plugin ships with can appear. **The `checkout-fields` feature sends nothing anywhere.** Like the `shopper-auth` name above, it is only ever REPORTED to the console so it knows this plugin build supports it. What it does is serve a read-only route on your own site that describes** the shape of your checkout form** — your field labels, which fields you have marked required, which countries you sell to, and the state/governorate lists WooCommerce already has for them. The app reads it so its native checkout screen asks for exactly what your own checkout page asks for. It contains no orders, no customers, no prices, no settings values and no secrets; every value in it is already visible to any visitor who opens your checkout page. It is a read-only route: nothing about it writes to your store, and it never sends anything to api.storetonative.com. **Shopper sign-in never reaches the StoreToNative platform.** The `shopper-auth` feature name above is only ever REPORTED to the console (so it knows this plugin build supports sign-in); the sign-in requests themselves — a shopper’s email and password — go directly from the app to your own site’s REST API and nowhere else. This plugin checks them the same way your website’s own login form does (WordPress’s own `wp_authenticate()`), and issues the app a signed token it can use to prove who’s asking on later requests. A shopper’s password and that token never leave your site — neither is ever sent to api.storetonative.com. Signing in, signing out and resetting a password send nothing about the shopper there at all; there is exactly one moment when anything identifying a shopper is sent, and it is the next paragraph. **When a shopper deletes their own account** — the “Delete account” option in the app, which asks for their password again before it will proceed — this plugin erases that account here on your site: it runs WooCommerce’s own personal-data erasers ( honouring the retention settings you’ve configured), then deletes the WordPress user. It then sends **one** signed notification to api.storetonative.com so StoreToNative can delete its own copy of that shopper’s sign-in record, which it keeps to know which app installs belong to which account. That notification carries exactly three things: * A one-time id for the notification itself (so a repeat of the same notice can be recognised and ignored). * The numeric WordPress user id of the account that was just deleted. * A one-way SHA-256 hash of that account’s email address — **not the address itself**. No password and no token are included, and nothing else about the shopper is. It is sent only after the shopper themselves asks for the deletion, and it is the only notification this plugin ever sends that refers to an individual shopper. Disconnecting from the StoreToNative menu (without uninstalling) sends one more signed notification so the console can mark the store as disconnected — it carries no data beyond that notice. Separately, the plugin periodically _fetches_ (never sends) a small public configuration document — your app’s name, theme color and icon, install-banner text — used to keep the deep-link files and install banner up to date; that request carries no store or site data at all. Apart from the account-deletion notification described above, no other data — no order data, no content, and nothing else about any customer — is ever sent by this plugin. This use of an external service is governed by StoreToNative’s [Terms of Service](https://storetonative.com/terms) and [Privacy Policy](https://storetonative.com/privacy). ## Installation 1. Upload the plugin to `/wp-content/plugins/`, or install it directly from the WordPress plugin directory. 2. Activate the plugin through the “Plugins” screen in WordPress. WooCommerce must already be installed and active. 3. Go to the new “StoreToNative” menu in your wp-admin sidebar. 4. Open your StoreToNative console, generate a pairing code for this store, and enter it on the connect screen. 5. Read the Store readiness card and fix anything it flags — it works before you pair, too. 6. Once paired, the dashboard shows your app’s connection status, deep-link readiness, and the smart banner toggle. ## FAQ ### Do I need a StoreToNative account? Yes. This plugin pairs your store with a StoreToNative account and console — it isn’t a standalone app builder. ### Does this send data before I connect? No. Installing or activating this plugin makes zero network requests. The very first request it ever makes is the pairing request, and only after you’ve pasted a pairing code into the connect screen yourself. See “External services” above for exactly what that first request contains. ### Does it work without HTTPS? No. This plugin refuses to pair — and therefore never talks to the StoreToNative API at all — unless your store itself is served over https. That check happens locally, before any network request is made, so a plain-http site can’t even attempt it. ### Pairing fails with “could not confirm this site” (site_unverified) — what does that mean? During pairing, the StoreToNative platform makes one request back to your site —` https://your-store/wp-json/storetonative/v1/pair-challenge` — and your site has to answer it while the pairing request is still running. That fails on four kinds of setups: a security plugin, firewall or WAF that blocks anonymous requests to the WordPress REST API (allow that one route, or the StoreToNative platform’s requests); a host that runs a single PHP worker, which cannot answer a second request while the first is waiting (the built-in `php -S` development server is the usual case— production hosts run several); an object cache that is private to each PHP process, so the worker answering the call cannot see what the pairing worker stored; and a host so slow that a fresh request takes more than ten seconds to answer. The code you typed is spent either way — generate a fresh one after fixing the cause. ### What happens if I deactivate WooCommerce? The plugin shows an admin notice explaining that WooCommerce is required and does not register any of its other functionality until WooCommerce is active again. ### What happens if I uninstall the plugin? Uninstalling removes all of this plugin’s local data (pairing, settings, cache, and the WooCommerce API key it created for itself) and stops your store from syncing with your native app. It does not make any remote request — your StoreToNative console will simply notice the store has gone quiet the next time it checks in. Reconnecting later starts a fresh pairing. ### Does this work on WordPress multisite? This has not been tested on a multisite installation. Use on multisite at your own risk until this is verified. ### Is this compatible with WooCommerce’s High-Performance Order Storage (HPOS)? Yes, compatibility is explicitly declared. The plugin does not read or write order data. ## Reviews ![](https://secure.gravatar.com/avatar/35fd6df3a1a2257f3806f738764f3e0113d2ab5e5f5c4a0946959694e3a6298c? s=60&d=retro&r=g) ### 󠀁[Amazing tool to have mobile app](https://wordpress.org/support/topic/amazing-tool-to-have-mobile-app/)󠁿 [abdallaaddict](https://profiles.wordpress.org/abdallaaddict/) September 6, 2026 Honestly, this plugin saved me hours of head-scratching. Setting up deep links and API permissions usually makes me want to pull my hair out, but pasting the pair code literally took five seconds. The readiness check caught a misconfigured permalink setting that would’ve definitely broken my mobile catalog before launch. Highly recommend it if you’re building an app with StoreToNative—it just works without messing up your store. [ Read all 1 review ](https://wordpress.org/support/plugin/storetonative/reviews/) ## Contributors & Developers “StoreToNative” is open source software. The following people have contributed to this plugin. Contributors * [ storetonative ](https://profiles.wordpress.org/storetonative/) [Translate “StoreToNative” into your language.](https://translate.wordpress.org/projects/wp-plugins/storetonative) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/storetonative/), check out the [SVN repository](https://plugins.svn.wordpress.org/storetonative/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/storetonative/) by [RSS](https://plugins.trac.wordpress.org/log/storetonative/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 1.5.2 * New: once your store is connected and checking in, the dashboard shows a small card asking for a wordpress.org review, with a “No thanks” that hides it for good. It appears only while the connection is healthy, sends nothing anywhere, and offers nothing in return. #### 1.5.1 * This is the first directory release after 1.4.1 and carries everything in 1.5.0 below. It also keeps both 1.4.1 fixes (the account-deletion re-authentication check and the dismissible deep-link notice), which the 1.5.0 build served from the StoreToNative console did not include. #### 1.5.0 * Security: **Pairing now proves it came from your site.** While your pairing request is in flight, the StoreToNative platform makes one request back to a new read- only route on your site (`storetonative/v1/pair-challenge`) and your site answers with a one-way digest computed from the code you typed. Before this, anyone with a StoreToNative account who learned — or guessed at — your store’s address could attach their own app to it; now only the site itself can complete a pairing ( older plugin versions, until this plugin’s 1.6 release, are instead checked by proving that the WooCommerce key they created can write to the store). Nothing new is sent to StoreToNative; see “External services”. * New: `pair-challenge` added to the plugin’s reported feature list. * Changed: the pairing request’s timeout is now 25 seconds (it has to wait for the round trip above); every other request keeps its 10 seconds. * New: a clearer error on the connect screen when that round trip fails, naming the things that usually block it; and a second Connect pressed while one is still running is refused without spending your code. #### 1.4.1 * Security: **account deletion now re-checks who was actually re-authenticated.** The “Delete account” flow asks for the shopper’s password again before it will proceed. It previously accepted any successful re-authentication; on a site running a plugin that filters WordPress’s authentication (single sign-on, social login), that could be a _different_ account than the one the request was for. It now requires the re-authentication to come back as the same account the request is deleting, and refuses otherwise. Sign-in was hardened the same way. * Fix: the notice warning that a file on your server is shadowing a deep-link file can now be dismissed, like the plugin’s other admin notices. #### 1.4.0 * New: **Downloadable-product check.** The readiness card now warns when your catalogue contains products marked Downloadable — including the variations of a variable product. Apple and Google both require digital content to be sold through their own in-app purchase systems rather than your website checkout, and an app that sells it through the web checkout is rejected by both stores. The check deliberately ignores the Virtual box: in WooCommerce that means “no shipping required”, not“ digital”, so appointments, bookings, classes, repairs and deliveries tick it — and both stores exempt real-world services. A service business is never flagged here. Setting a product’s Catalog visibility to Hidden clears it from this check, though note that also hides it from your own website shop. This is a warning, not a blocker. #### 1.3.0 * New: **Checkout fields.** The plugin now serves a read-only route describing the shape of your own checkout form — your field labels, which fields you have marked required, which countries you sell to, and the state/governorate lists WooCommerce already has for them — so the app’s native checkout screen asks for exactly what your own checkout page asks for, instead of a generic address form. It sends nothing anywhere; see “External services”. * New: `checkout-fields` added to the plugin’s reported feature list. #### 1.2.1 * Fixed: after re-connecting this store to a different StoreToNative app, the deep- link files (`apple-app-site-association` / `assetlinks.json`) could keep serving the previous app’s identity for up to 12 hours from cache. The cache is now cleared whenever the connection changes, so a fresh connection always serves fresh files. #### 1.2.0 * New: **Shopper sign-in.** The native app can now sign a shopper in with their existing WooCommerce account (email + password), entirely through REST routes this plugin registers on your own site — no sign-in request, password or token ever reaches the StoreToNative platform. See “External services” for exactly what that involves. * New: **Shoppers can delete their own account** from the app. The plugin re-checks their password, runs WooCommerce’s own personal-data erasers (honouring your retention settings), deletes the WordPress user, and then sends StoreToNative a single signed notification so it can delete its own sign-in record for that shopper. That notification carries a one-time id, the deleted WordPress user id, and a one-way hash of the email address — never the address itself, never a password or token. It is the only thing this plugin ever sends that refers to an individual shopper; see “External services”. * New: `shopper-auth` added to the plugin’s reported feature list. * New: whether your store allows customer account registration is now included in the existing heartbeat (true/false only — see “External services”), so the app knows whether to offer sign-up. #### 1.1.0 * New: a **Store readiness** card on the StoreToNative screen. Twelve checks over your own WooCommerce configuration — “Coming soon” mode, HTTPS, published products, payment methods, permalinks, the product price index, shipping zones, guest checkout, the checkout page, your site icon, conflicting swatch plugins, and WordPress/ WooCommerce/PHP versions — each explained in plain language with what it costs you and which screen to fix it on. Blocking problems come first, warnings next, everything that passed is tucked away. * New: the card also renders before you connect, so you can fix your store first. * New: a one-click **Rebuild price index** button for a stale product lookup table, which asks WooCommerce’s own tool to do the work in the background. * New: your store’s readiness results (check names and one-word verdicts only — see “External services”) are included in the existing daily heartbeat, so your console shows the same warnings. * New: `readiness` added to the plugin’s reported feature list. * Fix: the StoreToNative screen could keep showing “Connected” for up to half a day after the app was deleted or unpaired in your console. Opening this plugin’s own screen now re-checks the connection (at most once a minute, and only there— no other wp-admin page checks any more often than before), and a new **Check connection** button on the connection card checks on the spot. Nothing new is sent: it is the same check-in the plugin already made, just sooner. #### 1.0.0 * Initial release: 1-click pairing with the StoreToNative console, `.well-known` deep-link hosting for iOS Universal Links and Android App Links, a smart mobile install banner, and a periodic heartbeat that reports connection health back to your console. ## Meta * Version **1.5.2** * Last updated **11 hours ago** * Active installations **Fewer than 10** * WordPress version ** 6.5 or higher ** * Tested up to **7.1** * PHP version ** 8.0 or higher ** * Tags * [app banner](https://wordpress.org/plugins/tags/app-banner/)[deep links](https://wordpress.org/plugins/tags/deep-links/) [Mobile App](https://wordpress.org/plugins/tags/mobile-app/)[native app](https://wordpress.org/plugins/tags/native-app/) [woocommerce](https://wordpress.org/plugins/tags/woocommerce/) * [Advanced View](https://wordpress.org/plugins/storetonative/advanced/) ## Ratings 5 out of 5 stars. * [ 1 5-star review ](https://wordpress.org/support/plugin/storetonative/reviews/?filter=5) * [ 0 4-star reviews ](https://wordpress.org/support/plugin/storetonative/reviews/?filter=4) * [ 0 3-star reviews ](https://wordpress.org/support/plugin/storetonative/reviews/?filter=3) * [ 0 2-star reviews ](https://wordpress.org/support/plugin/storetonative/reviews/?filter=2) * [ 0 1-star reviews ](https://wordpress.org/support/plugin/storetonative/reviews/?filter=1) [Your review](https://wordpress.org/support/plugin/storetonative/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/storetonative/reviews/) ## Contributors * [ storetonative ](https://profiles.wordpress.org/storetonative/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/storetonative/)