Setting up in-app purchases

This is the setup for Sell them through the App Store and Google Play. Read Selling digital products in your app first for what that option does; this page is the checklist for making it work.

Almost all of the work happens in Apple’s and Google’s consoles, under your own developer accounts. Memberside never holds your store credentials — they live on your WordPress site, under Memberside → API Keys.

Do this before your first submission

Both stores review your in-app products alongside your app. Creating them after you submit means a second review round. Create them, then submit.

What you need before you start

• An Apple Developer Program membership ($99/year) and/or a Google Play Developer account ($25 once), in your own name or your organisation’s. Memberside cannot submit on your behalf — see iOS builds for why.
• Your paid applications agreement accepted and your bank and tax details complete. Neither store will show your products to the app until they are, and the symptom is products that do not load, with no error.
• The digital products already existing in WooCommerce, and classified as digital.

Apple

1. Create the app record in App Store Connect and note its bundle ID (com.yourcompany.yourapp). It has to match the app identifier in your Memberside build exactly — a receipt from a different app verifies perfectly and means nothing, so a mismatch fails every purchase with an error naming neither.

2. Create your in-app purchases. Under the app → Monetization → In-App Purchases (or Subscriptions), add one per thing you sell.

   • A membership that renews → an auto-renewable subscription, inside a subscription group. Everything in one group is mutually exclusive, which is what makes upgrading and downgrading work; put your tiers in one group and rank them.
   • A one-off that never expires — lifetime access, a downloadable — → a non-consumable.

   Give each a Product ID you can recognise later. It is permanent and cannot be reused once created, even if you delete it.

   Fill in the localisation, price and review screenshot. A subscription also needs its Subscription Display Name and duration.

3. Create an App Store Connect API key. Go to Users and Access → Integrations → App Store Connect API, choose the In-App Purchase key type, and download the .p8. Apple lets you download it exactly once.

   Note the Key ID beside it and the Issuer ID at the top of the page.

4. Save all three on your site under Memberside → API Keys → In-app purchases: the .p8 file, the key ID and the issuer ID.

5. Point Apple’s notifications at your site. In App Store Connect, under the app → General → App Information → App Store Server Notifications, set the Production Server URL and the Sandbox Server URL to the Apple URL shown on Memberside → In-App Purchases, and choose Version 2.

   Without this your site never hears about renewals, cancellations or refunds, and members keep access they stopped paying for.

Google

1. Create the app in Play Console and note its package name (com.yourcompany.yourapp). Unlike Apple’s, this can never be changed after the first upload — for any app, ever.

2. Upload a build to a testing track first. Play will not let you create in-app products for an app that has never had a release with billing in it, and it will not show products to a build that is not on a track. Internal testing is enough.

3. Create your products. Under Monetize → Products:

   • renewing membership → Subscriptions, one subscription with one or more base plans
   • one-off → In-app products

   The Product ID is permanent here too.

4. Create a service account. In the Google Cloud project linked to your Play account: IAM & Admin → Service Accounts → Create, then Keys → Add key → JSON, and download it. Make sure the Google Play Android Developer API is enabled on that project.

5. Grant it access in Play Console. This is a separate step in a different console, and it is the single commonest reason Play refuses a site that looks perfectly configured. Under Users and permissions, invite the service account’s email address and give it access to your app with View financial data and Manage orders and subscriptions.

   Google can take up to 24 hours to apply it.

6. Save the JSON on your site under Memberside → API Keys → In-app purchases.

7. Set up Realtime Developer Notifications. In Google Cloud Pub/Sub, create a topic, then a push subscription on it whose endpoint is the Google URL shown on Memberside → In-App Purchases. Grant [email protected] the Pub/Sub Publisher role on the topic. Then paste the topic name into Play Console under the app → Monetize → Monetization setup.

   That URL contains a secret unique to your site. Treat it like a password: anyone who has it can send your site notifications. Your site re-checks every one of them with Google before acting, so a forged notification achieves nothing — but there is no reason to publish it.

Then, on your site

1. Open Memberside → In-App Purchases and fill in Your app: the bundle ID and the package name from above.

2. Press Test connection on each store card. This makes one real call and reports what came back. Everything else on the screen is a local check — a file exists, a field is filled in — and none of that survives contact with the store.

3. Add an entitlement for each thing you sell. An entitlement is the thing itself; the Apple product ID and the Play product ID are two ways to buy it, which is what lets an iPhone purchase and an Android purchase grant the same membership.

   For each one choose what it grants: a WooCommerce product (an order is placed on your site, so your reporting, emails and role plumbing fire exactly as they do for a card payment) or a role directly.

4. Rebuild your app, then set Global settings → Store to Sell them through the App Store and Google Play.

Some products will be refused

The mapping screen will not let you map a stock-managed product (a membership would go out of stock), a product variation (roles are read from the parent, so per-variation roles are impossible), or a WooCommerce Subscription product (it would try to bill the member a second time). Each refusal names what to change.

Testing before anyone real buys

You cannot test with your own credit card, and you cannot test in the builder preview. Both stores have a sandbox, and both need a build installed on a real device.

Apple. In App Store Connect, Users and Access → Sandbox → Test Accounts, create a tester with an email address that is not an existing Apple ID. On the device, sign out of the App Store, install a TestFlight build, and the first purchase prompts for the sandbox account. Sandbox subscriptions renew on a compressed clock — a month is about five minutes — so a renewal, a lapse and a revocation are all testable in one sitting. This is the only practical way to see renewal work before it happens to a real member.

Google. In Play Console, Setup → License testing, add the tester’s Google account. Install from the internal testing track with that account. Purchases are free and marked as test; subscriptions renew every few minutes.

Worth walking through once each:

• buy, and confirm the role arrives on your site
• force-close the app mid-purchase and reopen it — the purchase should resolve on its own
• Restore purchases on a fresh install with the same store account
• let a sandbox subscription lapse and confirm the role is removed

Restore Purchases is a review requirement

Apple rejects apps that sell non-consumables without a visible way to restore them. Your app has one; do not remove the row, and do point the reviewer at it in your review notes.

When something does not work

“Products unavailable” / an empty purchase sheet. Almost always the store, not your site: the product is not Ready to Submit or Active, the build is not on a track the tester’s account can see, or your paid applications agreement is unsigned. Give a newly created product an hour.

Every purchase fails verification. Check the bundle ID and package name on Memberside → In-App Purchases against what the app was actually built with. This is what that screen’s warning is for.

Test connection fails on Google with a permissions error. The service account exists but has not been granted access in Play Console, or the grant has not propagated yet. Wait, then try again.

Test connection fails on Apple with an authorisation error. The key, key ID and issuer ID have to come from the same App Store Connect account, and the key has to be an In-App Purchase key.

Renewals never arrive. The notification URL is wrong, or Apple’s is set to Version 1. Your app also re-checks entitlements when it launches, so members are not stranded — but refunds and cancellations will lag until this is fixed.