Metadata

Goal

So you’ve put your app behind a subscription paywall — but a few people still need to get in for free: you as the owner, your staff, a handful of comp accounts, press contacts, partners, or beta testers. Here’s how to let them in without issuing a real App Store / Google Play purchase or faking a WooCommerce order.

You’ve got three levers to choose from, from least to most effort:

1. Administrators are already exempt — automatically, with nothing to configure.
2. Exempt one named person by ticking a box on their WordPress profile (once a one-time reader snippet is in place).
3. Exempt everyone in a role (for example, all editors or all shop managers) with a small code rule.

Pick whichever one matches the size and shape of your exemption list.

Before you start

• This article assumes your paywall is already turned on — if it isn’t, there’s nothing yet to exempt anyone from. See Recipe: Configure IAP settings for the Require IAP after login? setting that drives it.
• You’ll need WP Admin access. The per-user step requires the ability to edit the target user’s profile (the edit_user capability); the role-wide rule needs you (or your developer) to add a small PHP snippet to the site.
• The paywall itself is delivered by the mam-inapp-purchase-manager plugin. The mobile app reads two flags from the app’s data feed: whether the paywall exists at all (inapp_has_iap) and whether a purchase is required to proceed (inapp_is_required). Exempting someone just means forcing both of those to “no” for that person.

Lever 1: Administrators are exempt automatically

Any WordPress user with the administrator role gets a free pass from the paywall — no setup required. When an admin signs into the app, the data feed sets both inapp_has_iap and inapp_is_required to 'no', so they see everything as if they’d already subscribed.

Here’s where that lives: in the plugin’s phone-data pipeline (includes/phone-manager.php), in a block that runs near the end of building the payload — the bundle of data your app downloads from your site — after the paywall filters have already run:

if ( $mam_user && in_array( 'administrator', $mam_user->roles ) ) {
    $data_array['inapp_is_required'] = 'no';
    $data_array['inapp_has_iap']     = 'no';
}

Here’s what that means in practice:

• If you’re the owner, you’re probably already in. Sign into the app with your administrator account and the paywall won’t even appear — nothing to configure.
• This exemption always wins. Even custom code that tries to force the paywall on for an admin won’t succeed — the admin check runs last. If you want to see the paywall yourself to test it, sign in with a non-admin test account instead.
• It’s tied to the role, not the person. Promote anyone to administrator and they get free app access as a side effect — fine for an owner, but too blunt a tool for staff. Lever 2 and Lever 3 give you finer control.

Making someone an administrator just to give them free app access also hands them full control of your WordPress site. Don’t do that for staff or testers — use the per-user flag (Lever 2) or a role rule (Lever 3) instead.

Lever 2: Exempt one named person

Reach for this when your list is short and specific — an owner who isn’t an admin, a couple of staff members, a press contact, a comp account, or one beta tester.

How it works

The plugin adds an IAP information section to the WordPress user profile screen, with a single checkbox: IAP not required. Tick it and the plugin writes a piece of user data — the iap_not_required user meta, set to 'yes'. Untick it and save, and that data is removed entirely.

Here’s the one thing to know before you rely on it: the checkbox only stores a flag — the plugin never reads it back itself. That flag only becomes a real exemption once a mam_iap_require_iap filter callback reads the iap_not_required meta and turns the paywall off. MAM Suite doesn’t ship that reader by default, so for the checkbox to do anything, you (or your developer) need to add a one-time snippet first — the canonical example lives in Hook: mam_iap_require_iap. Add it once and every future tick of the box just works; skip it and the checkbox is silently inert. If ticking the box doesn’t seem to change anything, this missing reader is almost always why — see “If the paywall still appears” below.

Steps

1. Open the person’s profile. Go to Users → All Users and click the user you want to exempt. To exempt your own account, use Users → Profile instead.

2. Scroll to the IAP information section. It’s near the bottom of the profile page — you’ll see a single field labeled IAP not required.

3. Tick IAP not required, then click Update User (or Update Profile for your own account). The save is protected by WordPress’s standard profile security check and the edit_user capability for that user.

4. Verify. Now see it in action: sign in to the app as that person (or have them do it) — the paywall shouldn’t appear, and subscription-gated content should be right there. If they were already signed in, have them sign out and back in first, so the cached data feed refreshes.

Removing the exemption

Uncheck IAP not required and save — the plugin deletes the flag rather than storing a “no,” so a user who never ticked it and a user who ticked it and later unticked it end up in exactly the same state.

Good to know

• The box shows up on every profile, including admins. Admins are already exempt under Lever 1, so ticking it there is harmless — just redundant.
• There’s no bulk tool. You can only flip this switch one user at a time in the UI — if your exemption list is getting long, that’s your cue to switch to a role-wide rule (Lever 3).
• The person has to be signed in. This exemption only kicks in once the app has authenticated the user — anonymous, signed-out traffic is governed by the global Require IAP after login? setting, not by anyone’s personal flag.

Lever 3: Exempt everyone in a role

If your rule is really “all staff get in free,” and “staff” maps cleanly to a WordPress role — say Editor or Shop Manager, or a custom MAM role — skip ticking a box on every profile and add one small rule instead. It’s cleaner, it scales to any number of people, and it automatically covers anyone you add to that role down the road.

This one’s code, so it’s typically handed to a developer (or pasted into a site-specific snippets plugin). It uses the mam_iap_require_iap filter, which gets the last word on the paywall flags before they head out to the app.

add_filter( 'mam_iap_require_iap', 'my_app_exempt_staff' );

function my_app_exempt_staff( $has_iap ) {
    do_action( 'mam_update_current_user' );
    global $mam_user;
    if ( $mam_user && in_array( 'editor', (array) $mam_user->roles, true ) ) {
        return 'no'; // no paywall for editors
    }
    return $has_iap;
}

Swap 'editor' for whatever role represents your staff. You can check several roles at once, or combine this with other conditions — a promotional free week, a partner allow-list, whatever you need. For the full contract, including the fact that this filter runs twice and how administrators stay exempt regardless, see Hook: mam_iap_require_iap.

The administrator exemption from Lever 1 kicks in after this filter runs, so a role rule can grant access but can never take it away from an admin. That’s by design.

Choosing the right lever

If the paywall still appears

Still seeing the paywall? Work down this list:

• Double-check you saved the right account. It’s easy to end up editing your own profile when you meant to edit someone else’s.
• Have the person sign out and back in. The app caches the data feed, so a stale session won’t reflect an exemption you just saved.
• Confirm the paywall is actually on. If Require IAP after login? is off, everyone already has access — there’s nothing to exempt, and what you’re seeing is probably something else entirely.
• Confirm the per-user flag has a reader. The profile checkbox only stores the flag — a mam_iap_require_iap callback still has to read it and act on it, and MAM Suite doesn’t ship one by default. If Lever 2 doesn’t seem to be doing anything, this missing reader is almost always the piece you need to add — see Hook: mam_iap_require_iap for the canonical snippet.

Verification

This article was last verified against:

• Plugin: mam-inapp-purchase-manager v2.0
• Source: mam-inapp-purchase-manager.php — profile field render (mam_admin_manage_user_iap) and save (save_user_iap_fields), hooked on show_user_profile / edit_user_profile and personal_options_update / edit_user_profile_update
• Source: includes/phone-manager.php — the mam_iap_require_iap filter calls and the administrator-exemption block in manage_phone_data()
• User meta key: iap_not_required
• Mobile feed keys: inapp_has_iap, inapp_is_required

Re-verify whenever the user meta key changes, the IAP information profile section is renamed or moved, the nonce/capability check in save_user_iap_fields() changes, or the administrator-exemption block in manage_phone_data() is moved or removed.

Related articles

• Plugin overview: mam-inapp-purchase-manager
• Recipe: Configure IAP settings — turning the paywall on and off
• Recipe: Bypass IAP for a specific user — the per-user step in more depth
• Hook: mam_iap_require_iap — the filter behind Lever 3