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:<\/p>\n\n
.well-known\/apple-app-site-association<\/code> and .well-known\/assetlinks.json<\/code> 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 \u2014 a plugin is the only way to do that without touching your host's file system by hand.<\/li>\n- Smart app-install banner.<\/strong> 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<\/code> meta tag so Safari's own native banner takes over on iOS.<\/li>\n- Store readiness checks.<\/strong> Looks over your own WooCommerce settings for the dozen things that quietly break a mobile app \u2014 \"Coming soon\" mode still switched on, no payment method enabled, Plain permalinks, no shipping zone, a stale product price index \u2014 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.<\/li>\n
- Shopper sign-in.<\/strong> 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 \u2014 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.<\/li>\n<\/ul>\n\n
No network requests of any kind are made until you explicitly pair your store \u2014 see \"External services\" below for exactly what is sent, and when.<\/p>\n\n
Requirements<\/h4>\n\n\n- WooCommerce must be installed and active. This plugin does nothing without it.<\/li>\n
- A StoreToNative account with a store already set up in the console (to generate a pairing code).<\/li>\n<\/ul>\n\n
WooCommerce HPOS<\/h4>\n\n
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.<\/p>\n\n
External services<\/h3>\n\n
This plugin connects to the StoreToNative platform (api.storetonative.com<\/strong>) to power your store's native app. There is zero network activity before you explicitly pair your store<\/strong> \u2014 installing or activating this plugin alone sends nothing anywhere.<\/p>\n\nPairing requires https.<\/strong> This plugin refuses to pair (and refuses to talk to the StoreToNative API at all) unless your store is served over https \u2014 see the FAQ below.<\/p>\n\nWhen you pair<\/strong> (entering a pairing code from your StoreToNative console into this plugin's connect screen), the plugin sends, once:<\/p>\n\n\n- Your store's URL.<\/li>\n
- A WooCommerce REST API key\/secret pair that this plugin generates for itself at that moment. It is a read\/write<\/strong> 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 \u2192 Settings \u2192 Advanced \u2192 REST API.<\/li>\n
- This plugin's version number and a short list of its own feature names (currently
status<\/code>, deep-links<\/code>, smart-banner<\/code>, readiness<\/code>, shopper-auth<\/code>, checkout-fields<\/code>, pair-challenge<\/code> \u2014 which parts of the plugin are active, not any data those features touch).<\/li>\n<\/ul>\n\nWhile that pairing request is in flight, the StoreToNative platform makes one request BACK to your site<\/strong> 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<\/code>) to sign a random value with the pairing code you just typed. The answer is a single one-way HMAC digest \u2014 the pair-challenge<\/code> 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.<\/p>\n\nAfter pairing<\/strong>, the plugin sends a small heartbeat so your StoreToNative console can show the connection is healthy \u2014 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<\/strong> on it. Every one of those carries the same thing:<\/p>\n\n\n- This plugin's version, its feature-name list (the same seven names above), your WordPress version, and your WooCommerce version.<\/li>\n
- Whether your store's WooCommerce customer account registration setting is switched on (true\/false only) \u2014 this is what lets the app decide whether to offer shoppers a sign-up option alongside sign-in.<\/li>\n
- The result of the store readiness checks, as a short list of check names paired with a one-word verdict \u2014 for example
payment_gateway: fail<\/code>, guest_checkout: warn<\/code>, permalinks: pass<\/code>. Names and verdicts only<\/strong>: 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.<\/li>\n<\/ul>\n\nThe checkout-fields<\/code> feature sends nothing anywhere.<\/strong> Like the shopper-auth<\/code> 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<\/strong> \u2014 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.<\/p>\n\nShopper sign-in never reaches the StoreToNative platform.<\/strong> The shopper-auth<\/code> feature name above is only ever REPORTED to the console (so it knows this plugin build supports sign-in); the sign-in requests themselves \u2014 a shopper's email and password \u2014 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()<\/code>), 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 \u2014 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.<\/p>\n\nWhen a shopper deletes their own account<\/strong> \u2014 the \"Delete account\" option in the app, which asks for their password again before it will proceed \u2014 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<\/strong> 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:<\/p>\n\n\n- A one-time id for the notification itself (so a repeat of the same notice can be recognised and ignored).<\/li>\n
- The numeric WordPress user id of the account that was just deleted.<\/li>\n
- A one-way SHA-256 hash of that account's email address \u2014 not the address itself<\/strong>.<\/li>\n<\/ul>\n\n
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.<\/p>\n\n
Disconnecting from the StoreToNative menu (without uninstalling) sends one more signed notification so the console can mark the store as disconnected \u2014 it carries no data beyond that notice. Separately, the plugin periodically fetches<\/em> (never sends) a small public configuration document \u2014 your app's name, theme color and icon, install-banner text \u2014 used to keep the deep-link files and install banner up to date; that request carries no store or site data at all.<\/p>\n\nApart from the account-deletion notification described above, no other data \u2014 no order data, no content, and nothing else about any customer \u2014 is ever sent by this plugin. This use of an external service is governed by StoreToNative's Terms of Service<\/a> and Privacy Policy<\/a>.<\/p>\n\n\n\n- Upload the plugin to
\/wp-content\/plugins\/<\/code>, or install it directly from the WordPress plugin directory.<\/li>\n- Activate the plugin through the \"Plugins\" screen in WordPress. WooCommerce must already be installed and active.<\/li>\n
- Go to the new \"StoreToNative\" menu in your wp-admin sidebar.<\/li>\n
- Open your StoreToNative console, generate a pairing code for this store, and enter it on the connect screen.<\/li>\n
- Read the Store readiness card and fix anything it flags \u2014 it works before you pair, too.<\/li>\n
- Once paired, the dashboard shows your app's connection status, deep-link readiness, and the smart banner toggle.<\/li>\n<\/ol>\n\n\n
\nDo I need a StoreToNative account?<\/h3><\/dt>\nYes. This plugin pairs your store with a StoreToNative account and console \u2014 it isn't a standalone app builder.<\/p><\/dd>\n
Does this send data before I connect?<\/h3><\/dt>\nNo. 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.<\/p><\/dd>\n
Does it work without HTTPS?<\/h3><\/dt>\nNo. This plugin refuses to pair \u2014 and therefore never talks to the StoreToNative API at all \u2014 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.<\/p><\/dd>\n
Pairing fails with \"could not confirm this site\" (site_unverified) \u2014 what does that mean?<\/h3><\/dt>\nDuring pairing, the StoreToNative platform makes one request back to your site \u2014 https:\/\/your-store\/wp-json\/storetonative\/v1\/pair-challenge<\/code> \u2014 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<\/code> development server is the usual case \u2014 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 \u2014 generate a fresh one after fixing the cause.<\/p><\/dd>\nWhat happens if I deactivate WooCommerce?<\/h3><\/dt>\nThe plugin shows an admin notice explaining that WooCommerce is required and does not register any of its other functionality until WooCommerce is active again.<\/p><\/dd>\n
What happens if I uninstall the plugin?<\/h3><\/dt>\nUninstalling 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 \u2014 your StoreToNative console will simply notice the store has gone quiet the next time it checks in. Reconnecting later starts a fresh pairing.<\/p><\/dd>\n
Does this work on WordPress multisite?<\/h3><\/dt>\nThis has not been tested on a multisite installation. Use on multisite at your own risk until this is verified.<\/p><\/dd>\n
Is this compatible with WooCommerce's High-Performance Order Storage (HPOS)?<\/h3><\/dt>\nYes, compatibility is explicitly declared. The plugin does not read or write order data.<\/p><\/dd>\n\n<\/dl>\n\n\n
1.5.2<\/h4>\n\n\n- 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.<\/li>\n<\/ul>\n\n
1.5.1<\/h4>\n\n\n- 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.<\/li>\n<\/ul>\n\n
1.5.0<\/h4>\n\n\n- Security: Pairing now proves it came from your site.<\/strong> 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<\/code>) and your site answers with a one-way digest computed from the code you typed. Before this, anyone with a StoreToNative account who learned \u2014 or guessed at \u2014 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\".<\/li>\n- New:
pair-challenge<\/code> added to the plugin's reported feature list.<\/li>\n- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.4.1<\/h4>\n\n\n- Security: account deletion now re-checks who was actually re-authenticated.<\/strong> 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<\/em> 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.4.0<\/h4>\n\n\n- New: Downloadable-product check.<\/strong> The readiness card now warns when your catalogue contains products marked Downloadable \u2014 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 \u2014 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.<\/li>\n<\/ul>\n\n
1.3.0<\/h4>\n\n\n- New: Checkout fields.<\/strong> The plugin now serves a read-only route describing the shape of your own checkout form \u2014 your field labels, which fields you have marked required, which countries you sell to, and the state\/governorate lists WooCommerce already has for them \u2014 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\".<\/li>\n
- New:
checkout-fields<\/code> added to the plugin's reported feature list.<\/li>\n<\/ul>\n\n1.2.1<\/h4>\n\n\n- Fixed: after re-connecting this store to a different StoreToNative app, the deep-link files (
apple-app-site-association<\/code> \/ assetlinks.json<\/code>) 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.<\/li>\n<\/ul>\n\n1.2.0<\/h4>\n\n\n- New: Shopper sign-in.<\/strong> 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 \u2014 no sign-in request, password or token ever reaches the StoreToNative platform. See \"External services\" for exactly what that involves.<\/li>\n
- New: Shoppers can delete their own account<\/strong> 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 \u2014 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\".<\/li>\n
- New:
shopper-auth<\/code> added to the plugin's reported feature list.<\/li>\n- New: whether your store allows customer account registration is now included in the existing heartbeat (true\/false only \u2014 see \"External services\"), so the app knows whether to offer sign-up.<\/li>\n<\/ul>\n\n
1.1.0<\/h4>\n\n\n- New: a Store readiness<\/strong> card on the StoreToNative screen. Twelve checks over your own WooCommerce configuration \u2014 \"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 \u2014 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.<\/li>\n
- New: the card also renders before you connect, so you can fix your store first.<\/li>\n
- New: a one-click Rebuild price index<\/strong> button for a stale product lookup table, which asks WooCommerce's own tool to do the work in the background.<\/li>\n
- New: your store's readiness results (check names and one-word verdicts only \u2014 see \"External services\") are included in the existing daily heartbeat, so your console shows the same warnings.<\/li>\n
- New:
readiness<\/code> added to the plugin's reported feature list.<\/li>\n- 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 \u2014 no other wp-admin page checks any more often than before), and a new Check connection<\/strong> 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.<\/li>\n<\/ul>\n\n
1.0.0<\/h4>\n\n\n- Initial release: 1-click pairing with the StoreToNative console,
.well-known<\/code> 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.<\/li>\n<\/ul>","raw_excerpt":"Turn your WooCommerce store into a native app: 1-click pairing, deep links, and a smart iOS\/Android install banner.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/363619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=363619"}],"author":[{"embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/storetonative"}],"wp:attachment":[{"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=363619"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=363619"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=363619"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=363619"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=363619"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/ca.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=363619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}