Webshop plugins

Ready-made plugins that give a webshop Sign in with allme, one-time checkout autofill, and customer records that keep themselves up to date — with no code at all. You create an OAuth app in the portal, paste the credentials into the shop, and the flows from Sign in with allme are wired up for you.

Available now: allme for WooCommerce (v1.0.0). It is the reference implementation and the fully zero-knowledge one — the private key lives on your server. The hosted allme for Shopify app is built (guest checkout fill, stay-connected, live customer sync, embedded admin, and Plus OIDC login) and is pending Shopify App Store submission — its key custody differs from the plugin, and we say exactly how below. Magento, PrestaShop and Shopware are ports of the same blueprint, as demand dictates.

What the plugin does

Four features. Each one can be switched on independently, and every one of them is additive — a shopper who has never heard of allme sees one extra button and ignores it. No form on your shop is replaced, and no manual path is removed.

Feature	What the shopper sees	Underlying mode
Sign in with allme	A button on the WordPress and WooCommerce My Account login forms. A returning shopper is in with one tap. An unknown shopper gets an account created for them — progressive, passwordless sign-up: a single email claim, no registration form.	`signin`, then `one_time` for the sign-up hop
Checkout autofill	A “Fill in with allme” button above the checkout form. The shopper approves in the app; name, email, phone and address land in the form. Every field stays editable and nothing is submitted on their behalf.	`one_time`
Stay connected	An optional checkbox at checkout and a nudge on the thank-you page, turning a one-off share into a lasting connection.	`connect`
Live customer sync	Nothing, which is the point. When a connected shopper changes their address or phone in allme, the shop's customer record follows within seconds.	service webhook / change feed

Both checkout types are supported — the block checkout is filled through the block's own data store, so validation and shipping recalculation behave exactly as they normally do.

Sync is one-way, always

The shop reads; the shop never writes. There is no code path that pushes a customer's details back into their allme profile. Because a synced field would be overwritten on the next change anyway, fields allme keeps current are locked read-only in the customer's account area (a toggle, if you prefer editable fields and accept the drift). Per-order delivery addresses are never locked — a shopper can always ship one order somewhere else.

Which features need what

This is the single most useful thing to know before you start, because it decides whether an OAuth app alone is enough or you also need a service:

Feature	OAuth app	Service
Sign in with allme	Required	—
Checkout autofill	Required	—
Stay connected	Required	Required
Live customer sync	Required	Required + a `svc_…` data client and its key

In short: an OAuth app alone gets you login and checkout autofill, and for most shops that is the whole integration. Stay-connected and live sync additionally need a service bound to that OAuth app. Login and checkout autofill need no paid level. Stay-connected and live sync run on a live service, which needs your company on the Basic level or above; below that the service answers as if it did not exist, so a connect fails and nothing syncs. The plugin itself holds no plan logic.

Requirements

WordPress 6.4+, PHP 8.1+, and WooCommerce active (the plugin stays inert without it) — the plugin pins no minimum WooCommerce version; it is developed and tested against the version in the project's own dev fixture, currently 10.9.4.
HTTPS in production. A live shop's registered redirect URIs must be absolute https — a public http:// shop cannot complete a flow. Local development is the exception: plain http is accepted on localhost, 127.0.0.1 and the private IP ranges 10.x.x.x, 172.16–31.x.x and 192.168.x.x (IP literal, not a hostname), so you can run the plugin against a shop on your own machine or LAN. Those registrations send the authorization code unencrypted across your network — keep them to development apps.
For live sync over webhooks, a site the platform can reach inbound. If yours is not reachable, use the change-feed fallback (below) instead — nothing is lost, it is just slower.
The allus company-data PHP SDK is bundled with the plugin. There is nothing to install with composer.

Setting it up

Two halves: install the plugin, then walk the portal. Steps 1–6 give you login and checkout autofill; steps 7–10 add stay-connected and live sync.

1 · Install the plugin

Not on the wordpress.org directory yet. Until it is listed, install a release zip yourself — Plugins → Add New → Upload Plugin in your WordPress admin — rather than searching for it. Once it is published, this becomes an ordinary in-dashboard search-and-install.

Install and activate allme for WooCommerce. WooCommerce must be active first.
Go to WooCommerce → allme. At the top of the OAuth app section the screen shows a Redirect URI with a Copy button. It is your site's REST route:
```
https://your-shop.example/wp-json/allme/v1/callback
```

Copy it from the screen — do not type it. Redirect URIs are exact-match, and on a site with plain permalinks WordPress renders the same route as ?rest_route=/allme/v1/callback instead. The value shown on the settings screen is always the right one for your site. A single character of drift and sign-in fails.

2 · Create the OAuth app in the portal

In the allus portal, open the Configuration group in the sidebar → OAuth apps → New app:

Create a confidential app (the shop has a server, so it can keep a secret).
Register the Redirect URI you just copied, exactly as shown.
The portal generates the app's keypair in your browser and shows you its passphrase, once, in a dismissible card. Write it down before you close it. There is no ordinary way to see it again afterwards — the one exception is the portal's Recovery feature (Settings → Recovery), which can retrieve it later only if your company has set one up and a copy was saved at the moment of creation. Don't rely on that being available.
Note the client_id (an idw_… id) and the client secret, also shown once in the same way — and recoverable the same way, under the same condition. If it's gone, Regenerate secret issues a working replacement.

The passphrase and the client secret are each shown exactly once, with no guaranteed way to see them again. Unless your company's Recovery feature happens to have a saved copy, losing the private key's passphrase makes that key permanently unusable — there is no in-place way to swap in a new keypair for an existing app, so the only route forward is deleting the app and registering a new one. That is what zero-knowledge means in practice. Back the key file up with your site regardless: unlike the passphrase and secret, the encrypted PEM itself stays downloadable at any time from a Download button next to the app in your apps list — it just still needs the passphrase to open.

3 · Paste the credentials into the shop

Back in WooCommerce → allme, section OAuth app:

Field	What goes in it
Client ID	The `idw_…` identifier.
Client secret	The secret shown once at creation. Leave blank on later saves to keep the stored one.
App private key (PEM)	Paste the PEM or upload the downloaded `.pem`. It is written to a protected directory under `wp-content/uploads/` — mode `0600`, never in the database.
Key passphrase	The passphrase from the creation dialog.
Sign-in button	Show “Sign in with allme” on the login and My Account forms.
Checkout autofill	Show “Fill in with allme” above the checkout form.

Save, then press Test connection in the Status section. Green means the API answered and accepted the credentials.

Prefer secrets out of the database? Every credential can be pinned by a PHP constant in wp-config.php — ALLME_OAUTH_CLIENT_ID, ALLME_OAUTH_CLIENT_SECRET, ALLME_OAUTH_KEY_PASSPHRASE, ALLME_SERVICE_HANDLE, ALLME_SERVICE_CLIENT_ID, ALLME_SERVICE_CLIENT_SECRET, ALLME_SERVICE_KEY_PASSPHRASE, ALLME_WEBHOOK_SECRET, plus ALLME_API_URL / ALLME_AUTHORIZE_URL for testing against another environment. A pinned field renders disabled on the settings screen. Anything stored in the database instead is encrypted at rest with a key derived from your site's own WordPress salts.

Sign-in and checkout autofill work from here. Stop now if that is all you need.

4 · Add a service, for stay-connected and live sync

In the portal, create a service (Configuration → Services in the sidebar) and define the request fields it asks for. The plugin's defaults map to name, lastname, an email, a mobile phone and a home/postal address. Creating the service also generates its own zero-knowledge keypair in your browser — note the once-shown passphrase the same way as the OAuth app's, and note the service's COMPANY/SERVICE share code (auto-generated from the name; editable on the service's own page).
Attach that service to the OAuth app — pick it in the app's own Service this app is attached to field (Configuration → OAuth apps → edit the app); connect mode requires it.
On the service's API access tab, create a company-data client to get the svc_… client ID and its client secret — a different credential from the service keypair above, used to authenticate the calls that fetch the change feed rather than to decrypt what they return. The service's private key PEM stays downloadable at any time from the service's Overview tab.
Fill in the plugin's Live sync section: Service handle (COMPANY/SERVICE), Data client ID, Data client secret, Service private key (PEM) and its Key passphrase. Switch on Offer stay-connected and Apply live updates.

The service keypair is a second, separate key from the OAuth app's. The app key decrypts one-time checkout claims; the service key decrypts the live values arriving over the change feed and webhooks. The company-data client's svc_… id/secret is separate again — it authenticates fetching the feed, and carries no decryption capability of its own.

5 · Point the webhook at the shop

The plugin's Webhook section shows two copy-ready values:

Value	Goes into
Receiver URL — `https://your-shop.example/wp-json/allme/v1/webhook`	Portal → Configuration → Services → your service → Webhooks → URL
HMAC secret — generated for you at activation, regenerable from the screen	The same tab, with auth type `hmac` selected

The signature is what authenticates each delivery: allus sends X-Allus-Signature, an HMAC-SHA256 of the raw body computed with that secret, and the bundled SDK verifies it before the plugin looks at a byte of the payload. See Authenticating the delivery for the full contract.

Finally, change something on a connected test profile and watch the Last delivery indicator on the settings screen go green.

No inbound reachability? Switch on Poll the change feed instead. A scheduled job drains the pull feed on a timer rather than waiting for deliveries — slower, but nothing is lost. Use one or the other, not both.

Leave encrypt_payload off on the service's webhook. The account-key envelope is not supported by the plugin, and an enveloped delivery will fail to parse.

Key custody: WooCommerce vs. the hosted Shopify app

These two integrations are not equivalent on the one axis that matters most, so here it is plainly.

	allme for WooCommerce (available)	Shopify app (built; App Store submission pending)
Deployment	Self-hosted. The plugin runs on the shop's own server.	Hosted. A multi-tenant app backend run by allus.
Who holds the private key	You do. The keypair is generated in your browser at app creation and the PEM is stored on your server, outside the database. It never leaves the machine.	The app backend does. It generates each shop's keypair server-side at install and stores the private key encrypted at rest under a backend master key.
Who can read the plaintext	Only your server. allme relays and stores ciphertext it cannot read — decryption happens entirely on your side.	The app backend decrypts claim values in plaintext at delivery in order to write them to Shopify. allme has access to the plaintext on that path.
Trust model	End-to-end. The pure zero-knowledge model, unmodified.	The same trust level as any Shopify app that touches customer data — weaker than the WooCommerce plugin. Shopify's platform does not permit the self-hosted arrangement, so the app discloses this at install.

Neither model is wrong; they are different trades, forced by where the code can run. If the zero-knowledge property matters to you and you have a choice of platform, WooCommerce is the one that preserves it. See Encryption & data handling for what the guarantee does and does not cover.

Setting up the Shopify app

The Shopify app is hosted — there is nothing to self-host, and there is nothing to paste. Setup starts in your allus portal and Shopify’s own install proves the store. Once the app is live on the App Store, installation is:

Sign up at portal.allus.fyi and open Configuration › Integrations › Other.
Type your store’s myshopify.com domain, read the key-custody disclosure (the hosted model, stated plainly) and choose Connect. There are no credentials to copy: the portal mints the API client for that shop and hands it over for you.
You land in Shopify’s own install for that store; approve the customer read/write scopes. Finish it in the SAME browser you started in — that is what ties the setup to your allus account.
The app auto-provisions the service, its data client, the sync webhook, the sign-in (idw) app and a storefront token, and drops you in the embedded admin with every status row ticked.
Toggle the features you want (guest fill / stay-connected / live sync) in the embedded admin.

Sign in with allme on Shopify Plus

On a Plus store you can add allme as a customer-accounts OIDC identity provider for a genuine “Sign in with allme,” so shoppers sign in with allme instead of a store password. The store reads sub and email from the id_token and creates or resumes the customer. The embedded admin renders the discovery URL and your shop’s client id to paste into Shopify’s customer-accounts settings, and collects the callback URL Shopify shows you back.

Connect the shop from the portal. Run the steps above from Configuration › Integrations › Other and let the app finish provisioning. It creates the OIDC app for this shop automatically.
Open the embedded admin’s OIDC panel. Copy the discovery URL and client id, then reveal and copy the client secret.
In the Shopify admin, go to Settings → Customer accounts → choose the third-party/custom identity provider option. Fill in the discovery URL, client id and client secret, and request scopes openid email profile.
Register Shopify’s callback. Copy the callback URL Shopify shows you into the embedded admin’s OIDC panel and choose Register callback. The app adds it to the auto-provisioned OIDC app without removing the callback used by checkout fill and stay-connected.
Save and test from the storefront: “Sign in” sends the shopper to the allme consent screen; approving returns them signed in, with the customer record keyed on sub.

Shopify authenticates the token endpoint with credentials in the POST body (client_secret_post), which is what allme advertises and accepts.

Customer-account login gives you identity; a lasting, self-updating record is stay connected plus live customer sync above. The two compose — the same person, the same share code. The discovery document, the id_token claim table and the token-verification checks are on allme as an OIDC provider.

Disconnecting is done in the allme app

Ending a connection, and revoking the sign-in link entirely, are actions in the allme app. The shop shows status and nothing more — there is deliberately no unlink control anywhere in the plugin, for two reasons: a shop should not be able to sever a link the shopper owns, and a shopper should not have to hunt through every shop they have ever used to end them.

When someone disconnects in their app, the shop receives a connection_deleted event: sync stops, the field locks come off, and their account and order history stay exactly where they are. The My Account → allme section is status-only and says where to go.

Accounts are passwordless, not locked-in. An account the plugin created carries the shopper's email address, so WordPress's normal “Lost your password?” flow reaches them and sets one. Revoking the allme link never locks anyone out of your shop.

Troubleshooting

Symptom	Cause & fix
Sign-in bounces back, or the consent screen rejects the request	The redirect URI does not match character for character. Re-copy it from the OAuth app section and re-register it in the portal — remember plain permalinks render the route differently.
“The allme API rejected these credentials” on Test connection	Wrong client ID or secret. The secret is shown once — if it was lost, roll a new one on the app in the portal and paste it in.
“Could not reach the allme API from this server”	Outbound HTTPS is blocked. Allow your server to reach `api.allme.fyi` and the regional hosts it redirects to (for example `api-eu.allme.fyi`).
Sign-in works, but checkout autofill returns nothing	The app private key or its passphrase is wrong. A bad passphrase is not reported on the settings screen — the key status light only checks that a file is readable, so it stays green. Check the plugin log for `oauth client init failed`, then re-paste the PEM and re-enter the passphrase.
“This shop is not set up to keep your details up to date yet”	A shopper hit a connect flow with no service handle configured, or the service is not bound to the OAuth app. Complete step 4.
Shoppers can connect, but no data ever arrives	Stay-connected only needs the service handle, while sync needs the data client ID, secret and the service PEM. A half-filled Live sync section lets connections form that then deliver nothing. Fill in all five fields.
Deliveries fail right after regenerating the secret	Expected — the old secret no longer validates. Paste the new one into the portal's Webhooks tab.
Webhook returns `401`	Signature verification or payload parsing failed: a stale HMAC secret, an auth type other than `hmac`, `encrypt_payload` enabled, or a proxy that rewrites the request body (the signature is over the raw bytes).
Webhook returns `404` or `503`	`404`: Apply live updates is off. `503`: the service data client is not fully configured — see step 4.
Last delivery stays on “Never received”	The platform cannot reach your site inbound. Confirm the Receiver URL is publicly reachable, or switch on Poll the change feed.
A customer's synced field looks wrong and cannot be edited	By design — allme would overwrite the edit on the next change. The shopper corrects it in their app and it lands here. Turn off Lock synced fields if you would rather have editable fields and accept the drift.
“That does not look like a PEM private key”	The pasted text is not a PEM block. Paste the whole file including the `-----BEGIN…-----` line, or use the file upload.
“Not loaded — reinstall the plugin from the packaged zip”	The bundled SDK is missing. You are running a source checkout rather than the built release; install the packaged zip.

What leaves your server

The plugin sends credentials, a request for fields, and a random state value. It receives customer data. Nothing about your shop, catalogue, orders or visitors is ever sent to allme, and there are no analytics, trackers, CDNs, remote fonts or remote images — every asset is served from your own server.

web.allme.fyi — the consent screen. Your server sends nothing here; the shopper's browser is sent there by a link, and only when they press a button. Never on a page load.
api.allme.fyi (and the regional host it routes to) — the token exchange and userinfo call after an approval, the detached result poll during a checkout autofill, the change-feed drain if you enabled polling, and the Test connection probe. Nothing else.

The flows behind the plugin → Open the portal · Webhooks · Encryption & data handling

Start here

Build

CRM integrations

Portal

Reference