How changes reach WordPress
A change travels in five steps: Flow or an app changes the account in Shopify; Shopify sends a webhook; RedeemID checks the signature and queues it; a background job processes it and reads the full tag list back; the next page view uses the new copy. It can wait where Shopify retries or drops a subscription, where WP-Cron waits for a visitor or a failed job retries, and where a page cache ignores DONOTCACHEPAGE. A sign-in reads the account at once.
WordPress never decides who is a member. It keeps a copy of each linked customer account (name, email, status and tags) and reads that copy on every page. This page covers how the copy is kept up to date. There’s no promised time. Most changes land within seconds to a minute, but every step below can be slower on a given store or host.
Signing in
Each sign-in reads the customer’s account from Shopify’s Customer Account API, so a member who signs in gets their current tags straight away. A member who is already signed in waits for one of the paths below.
The webhook path
When something changes a customer in Shopify, the update travels like this:
- Shopify Flow or an app changes the account. Flow runs a workflow when its trigger fires. A subscription app tags on its own schedule, for example after a billing attempt. Nothing reaches WordPress until the tag is on the customer in Shopify.
- Shopify sends a webhook. RedeemID subscribes to customer updates, tag changes, enable and disable, merges and deletions. Shopify usually sends a webhook within seconds, but it doesn’t guarantee a time or an order.
- RedeemID checks it and queues it. The webhook’s signature is checked, the delivery is saved in the inbox, and Shopify gets its answer at once.
- A background job processes it. Action Scheduler handles the queue if it’s installed, and WP-Cron if not. For a tag change, RedeemID reads the customer’s full tag list back from the Admin API rather than trusting the change alone.
- The next page view uses the new copy. Access, features and the member’s account block all read it.
What slows it down
- WP-Cron only runs when someone visits. On a quiet site, step 4 waits for the next page view. A real cron job hitting
wp-cron.phpevery minute removes that wait. - A failed job is retried. If processing fails, for example because the Admin API is down, the delivery is retried four more times over about half an hour. After that it’s dead-lettered, and you can retry it from RedeemID → Webhooks.
- Shopify can stop sending. If your site doesn’t answer, Shopify retries a delivery for several hours and then removes the subscription. RedeemID checks its subscriptions once a day, puts back any that are missing, and warns you on the admin screens (and by email, if you turn that on). Register webhooks with Shopify puts them back at once.
- Page caches. Pages showing members-only content send
DONOTCACHEPAGE, so a cache that honours it never stores them. A cache that ignores it can serve a stale page until it’s purged. See Works with.
While a change is on its way
The copy stays as it was until Shopify sends something new. A member whose renewal is late reaching WordPress keeps their access, and a cancelled member keeps it until the removed tag arrives. RedeemID never locks a member out because their copy is old. In return, a revoked tag only takes effect once it lands.
Right after a checkout that started on the site, the locked panel tells the buyer their membership is being set up and offers to check again.
Pushing a change through
- A member can use the Refresh Membership block, once a minute.
- Staff can resync a customer from their row on RedeemID → Customers.
- After an outage, Resync all customers on the same screen re-reads everyone. It runs only when started, paced to the store’s API budget, and can be paused and resumed. From the command line:
wp redeemid resync all.
To see the copy RedeemID holds for one customer, open them on RedeemID → Customers. If it doesn’t match Shopify, see Troubleshooting.