Goal

Get the In-App Purchase Manager into a working state for your app: store keys plumbed in, legal URLs set, paywall styled to match your brand, and the on/off behavior dialed in. After this recipe, the app will be ready to display IAP products (which you create in Recipe: Create an IAP product).

Prerequisites

• WordPress admin access with manage_options capability
• WooCommerce active
• MAM Suite with mam-inapp-purchase-manager activated under Mobile App Mgr → Software
• iOS App Store Connect access if you want to populate the iOS shared secret
• Google Play Console access if you want to populate the Android billing key

If mam-inapp-purchase-manager isn’t installed, see Plugin overview: mam-inapp-purchase-manager first.

Where the settings live

Go to Mobile App Mgr → In-App Purchase Manager. The page opens on General Settings by default. A second tab, Screen Settings, only appears when single-screen UI is enabled — see Recipe: Use the single-screen IAP UI.

All values save to the WordPress options table under keys prefixed tsl-setting-. They become part of the mobile JSON payload on the next request from the app.

Steps

1. Add the iOS shared secret

In iOS Shared Secret Key (tsl-setting-inapp_shared_sec), paste the shared secret from App Store Connect (App-Specific Shared Secret, not the Master Shared Secret).

This value goes to the app as inapp_shared_sec and is used by iOS receipt validation logic on the device. Leave it blank only if your iOS build has its own bundled secret.

2. Add the Android billing key

In Android Key (tsl-setting-inapp_purchase_and_key), paste the Base64 RSA public key from the Google Play Console (Monetization setup → Licensing).

This is the key the Android client uses to verify Play purchases locally. It is sent to the app as inapp_and_key.

3. Set the Android product group ID

In Android Product Group ID (tsl-setting-iap_sub_product), enter the subscription group identifier you set up in Google Play Console.

This is sent as iap_sub_product. Leave blank to omit the key from the payload.

4. Set the legal URLs

Three fields:

• iOS Terms of Service URL (tsl-setting-terms_of_service_url) → mobile key inapp_ios_terms_of_service
• Android Terms of Service URL (tsl-setting-android-terms_of_service_url) → mobile key inapp_terms_of_service
• Privacy Policy URL (tsl-setting-privacy_policy_url) → mobile key inapp_privacy_policy

iOS and Android keep separate ToS URLs because Apple and Google sometimes require slightly different wording. If your policy is the same on both platforms, just paste the same URL in both fields.

5. Upload the paywall logo

In Logo for Top of Purchase Screen (tsl-setting-inapp_logo), upload or pick a logo from the media library.

The plugin computes the aspect ratio at request time (inapp_logo_aspect) so the app can size the image correctly. If no logo is set, the aspect defaults to 0.5.

6. Set the paywall colors

Four color pickers, all hex values:

The plugin converts each hex value to RGB components and writes them as three separate keys. Pure-black components (0) are coerced to 1 before sending — a quirk of older app builds that treated 0 as “unset.” Don’t try to send a true 0 channel; use 1 if you need near-black.

7. Decide whether IAP is required

Require IAP after login? (tsl-setting-iap_show_on_login) is the master switch:

• yes → inapp_has_iap is 'yes' in the mobile payload, the app shows the paywall
• no → inapp_has_iap is 'no', the paywall is suppressed

The same value also flows into inapp_is_required (the app’s “block content until purchase” flag), unless something subscribed to Hook: mam_iap_require_iap changes it.

Administrators always receive 'no' for both keys regardless of this setting — so admins don’t get blocked while testing.

8. Decide what happens in sandbox

Turn off IAP in Sandbox? (tsl-setting-iap_off_in_sandbox) sets iap_off_in_sandbox in the mobile payload. The app reads it and skips the paywall in sandbox/TestFlight builds. Set to yes if you want a smoother QA flow; no if you specifically need to test the purchase pipeline.

9. Save

Click Save Changes at the bottom of the form. The save handler verifies the mam_iap_save nonce, writes each value with update_option(), then redirects back to the same tab.

10. Verify

Open the mobile app (or hit the phone-data endpoint directly) and confirm:

• inapp_has_iap matches what you set
• inapp_is_required matches (admins should always see 'no')
• The colors render correctly on the paywall screen
• The legal links open the URLs you configured
• iap_off_in_sandbox is honored in sandbox builds

If inapp_has_iap is 'no' when you expected 'yes', the most likely cause is signing in as an administrator. Try a non-admin account.

Variations

Override the on/off flag in code

If you need IAP on or off for reasons the admin UI can’t express (a feature flag, a per-role toggle, time-of-day rules), use Hook: mam_iap_require_iap. The filter runs after the role check and is the last word on the value the app sees.

Use the single-screen UI

If you want the paywall presentation to be a feature list with a single CTA rather than the multi-product carousel, see Recipe: Use the single-screen IAP UI.

Verification

This article was last verified against:

• Plugin: mam-inapp-purchase-manager v2.0
• Source: includes/admin-settings.php
• Source: includes/phone-manager.php

Re-verify whenever the option keys named in this recipe change, a new field is added to the General Settings tab, or the hex-to-RGB coercion logic in phone-manager.php changes.

Related articles

• Plugin overview: mam-inapp-purchase-manager
• Recipe: Create an IAP product
• Recipe: Use the single-screen IAP UI
• Recipe: Bypass IAP for a specific user
• Hook: mam_iap_require_iap

Metadata