Build the client’s member site. Then stop babysitting it.

Nothing in WordPress to keep in step

Members sign in with their Shopify customer account, the same one they use in the client’s store. WordPress keeps no member passwords, no billing records and no subscription state. It holds a mirror of the account (name, email, status and tags) and decides access from it on the server.

There is no scheduled sync job to watch. The mirror updates at sign-in, when Shopify’s webhooks land, and when staff or the member resync. If the webhooks fail, a daily check re-creates missing subscriptions and, with alerts on, emails the site admin. After an outage, Resync all customers re-reads everyone in the background and spends only the spare half of the store’s API budget.

The client’s staff run members in Shopify

Who is a member is the account’s tags and status in the Shopify admin, set by Shopify Flow or the subscription app the client already uses. Renewals, cancellations and refunds happen there, and access follows the tags. Disable a customer in Shopify and their members-only access goes too.

The limit: RedeemID never tags anyone. Someone sets up the Flow workflow or app once, per Tagging customers with Shopify Flow. Staff who prefer wp-admin can edit a customer’s tags on RedeemID’s Customers screen; the change is written to Shopify and read back, never kept in WordPress alone.

Answers in wp-admin, not in your inbox

• Access → Test takes a post and a viewer (a guest, a level, a set of tags or a real user) and shows every rule layer, the rule that won, and what that viewer sees.
• App events logs every call to Shopify and what it did, with who triggered it and from where. Kept 30 days, with no request bodies, tokens or secrets.
• Webhooks lists every delivery and its outcome, flags rejected or stuck deliveries, and retries dead-lettered ones.
• Debug shows where each setting comes from (wp-config.php, Settings, or unreadable), never the value, and the scopes Shopify granted. Webhook problems also show in Tools → Site Health.

Built the way you ship sites

• Config in wp-config.php. Every connection value can be a constant. A constant always wins and locks its field in Settings, so client secrets never touch the database.
• Rules in code, if you want them. The redeemid_access_levels and redeemid_access_rules filters set levels and content rules from code; the admin screens then show them read-only.
• Staging to production. Export / import moves levels, content rules, feature mappings and membership settings as one JSON file, and shows what each section would change first. Files never hold customers, credentials or tokens.
• WP-CLI. wp redeemid access explain <post> --as=<level>, wp redeemid settings import <file> --dry-run, and wp redeemid resync all.
• Git deploys. The one build step is composer build-prod. It runs in any theme, beside Blockstudio themes too.

Extend it without a second membership layer

A course, forum or download plugin can ask RedeemID instead of keeping its own members: redeemid_can_read(), redeemid_user_levels() and redeemid_has_feature() read the synced mirror and cost no Shopify call. Actions such as redeemid_levels_changed fire after a sync. See Hooks, REST and WP-CLI.

Page caches keep working. Personal pieces, such as the sign-in control, load as Blockstudio islands, and gated pages send DONOTCACHEPAGE. The limit: your own templates that print member-only output from these functions should not be served from a shared cache.

Check the fit before you quote it

• One Shopify store per WordPress site.
• The store needs a headless or custom app with Customer Account API access, and an Admin app from Shopify’s Dev Dashboard. Connect Shopify walks through both.
• PHP 8.2+ with sodium, WordPress 6.7+, and pretty permalinks for sign-in.
• WordPress takes no payments. Checkout is Shopify’s, through plan cards or the store itself.
• RedeemID is in development and GPL-2.0-or-later. Try it on the demo or a development store before a client relies on it.