Store Setup

In-app purchases can’t be tested until both stores know about your app and products. This page covers the store-side configuration for the client and for the server.

Step-by-step walkthrough

The sample app’s readme covers the whole setup for testing and production on both platforms: sandbox controls, license tester test cards, accelerated renewal tables, building and uploading with dotnet publish, backend configuration, and a test plan to run before you ship.

Apple — App Store Connect

Products

1. Agreements, Tax, and Banking — the Paid Apps agreement must be active. Until it is, product requests silently return nothing.
2. Your app → Monetization → In-App Purchases — create consumables and non-consumables.
3. Your app → Monetization → Subscriptions — create a subscription group, then the subscriptions in it. Levels within a group decide what counts as an upgrade or downgrade.
4. The bundle id in your MAUI project (ApplicationId) must match the App Store Connect app.

Testing

• Sandbox Apple Account — create one under Users and Access → Sandbox, then sign in on the device under Settings → Developer → Sandbox Apple Account. Sandbox subscriptions renew on an accelerated schedule (a monthly subscription renews every few minutes).
• TestFlight builds always use the sandbox.
• StoreKit configuration files (.storekit) are an Xcode scheme feature, so they aren’t available to dotnet build. Use a sandbox account instead.

Server notifications

• App Information → App Store Server Notifications — set the Production and Sandbox URLs to your /pay/apple endpoint and choose Version 2.
• App Information → Apple ID — this numeric id is AppAppleId, which is required to validate production notifications.
• Users and Access → Integrations → In-App Purchase — generate a key for the App Store Server API. You’ll need the Issuer ID, Key ID and the downloaded .p8 file (it can only be downloaded once).

Google Play Console

Products

1. Set up a payments profile (merchant account) for the developer account.
2. Upload a build that references the Play Billing Library to a testing track (internal testing is fine). The console won’t let you create products until it has seen an APK/AAB with the com.android.vending.BILLING permission, which the library merges in automatically.
3. Monetize → Products → One-time products — create one-time products. Whether they’re consumable is decided in code by FinishPurchaseAsync(purchase, consume).
4. Monetize → Products → Subscriptions — create subscriptions, each with one or more base plans and optional offers (free trials, intro pricing).

Testing

• Settings → License testing — add tester Google accounts so purchases use test cards and are never charged. Test subscriptions renew on an accelerated schedule.
• The app must be installed from Google Play (join the internal testing track). Sideloaded builds can load products only if their package name and signing key match the uploaded build.

Real-time developer notifications

1. In Google Cloud, create a Pub/Sub topic (for example play-billing).
2. Grant google-play-developer-notifications@system.gserviceaccount.com the Pub/Sub Publisher role on the topic.
3. In the Play Console under Monetize → Monetization setup, enter the full topic name (projects/<project>/topics/play-billing) and use Send test notification.
4. Create a push subscription on the topic pointing at your /pay/google endpoint and enable authentication. Choose a service account and an audience; configure the same values on the server so it can validate the OIDC token Pub/Sub sends.

Google Play Developer API

RTDN messages only say that something changed. The server then looks up the full purchase with the Play Developer API:

1. In Google Cloud, enable the Google Play Android Developer API and create a service account with a JSON key.
2. In the Play Console under Users and permissions, invite the service account’s email and grant View financial data and Manage orders and subscriptions. Permissions can take some time to take effect.