Selling subscriptions inside the app

Why inside the app is different

On the published website, a subscription goes through the gateway you connected (Stripe, Mercado Pago, Pagar.me). Inside the app installed from a store, that is a policy violation on both stores for digital content, and the penalty is removal.

So the platform never falls back to the gateway inside the app. Either store billing exists, configured and ready, or the app shows the mute state. A button that opens the store and fails is worse than no button.

The store keeps a commission on every sale, and both programmes have different tiers depending on revenue and how long someone has subscribed. Check the official pages from Apple and Google Play before setting your price.

What has to be ready

1. the native app published, or at least configured in the Mobile app tab;
2. in-app purchase turned on in the Features step;
3. your app's plans already registered (what the Data tab calls plans, and what the app sells);
4. the verification credentials: on iOS the In-App Purchase key, on Android the Play service account;
5. each plan tied to a store product, which is what the rest of this guide is about.

Tying each plan to a store product

In the Mobile app tab, the subscriptions section shows your app's plans side by side with what the store really has, one store at a time (Google Play and the App Store are separate catalogues: being linked on one says nothing about the other). Each plan carries a state:

Only sellable allows a purchase. That distinction matters: on Google, the API answers success while the base plan is still a draft, and the purchase then fails on the device with "item unavailable".

On Google Play

Two actions, and which one you use depends on where you started:

• Create in the store: the platform creates the product and activates the base plan for you. Before confirming, check the identifier shown under "Will be created as";
• Link to an existing product: if you already built the catalogue in the Play Console, give it the product id and the base plan id. The platform checks and shows the differences between your plan and what the store has (price, period), without deciding for you.

On the App Store

Here the platform does not create the subscription, and that is not our limitation: Apple requires the first subscription to be submitted together with an app version, inside a subscription group, with per-territory pricing and review.

The path is to create it in App Store Connect and then link it here:

1. in App Store Connect, open the app and go to Monetization → Subscriptions;
2. create a subscription group (the group is what lets a customer switch plans inside it);
3. create the subscription, with its identifier, duration and price;
4. fill everything in until the status reads Ready to Submit;
5. on the app version page, in the in-app purchases section, select the subscription and submit both together for review;
6. once approved, come back to the Mobile app tab and link the plan to the identifier.

This applies to the first subscription. Once one is approved in the group, later ones can be submitted on their own.

Identifiers are permanent

On both stores a product identifier cannot be renamed or reused once created. On Google Play you cannot even delete a subscription, base plan or offer: they stay forever, for reporting.

That is why the screen warns before creating, and why it refuses to invent a variant when the identifier is already taken: the right action there is to link, not to create another.

The In-App Purchase key (iOS)

Verifying a purchase on iOS uses a different key from the one that submits builds. It is generated under Users and Access → Integrations → In-App Purchase and connected in the subscriptions section itself.

Without it the store would charge on the device and the verification would then refuse: money moved, nothing granted, and the customer holding a receipt. That is why, with no such key, the app stays mute instead of selling.

The subscribe button does not appear: why

The server decides that in one place, and always to narrow, never to widen. Every reason is a missing piece of configuration, and all of them have a fix:

Cancellation and refunds

A store subscription is cancelled by the customer, at the store, not in your app: that is how both work and it cannot be changed. Renewals, cancellations and refunds reach us through the store's own notifications, and the customer's access is adjusted from that.

One practical consequence on Android: a purchase the app does not acknowledge is refunded automatically by Google in three days. The platform acknowledges it as soon as verification passes, so the normal path already handles it; if a customer reports a refund out of nowhere, that is the first thing to look at.

The device never decides

Worth knowing, because it explains several of the system's answers: the transaction identifier the app hands back is a claim, not proof. Everything that moves money (which product, whose, until when, still active) is asked of the store with the app owner's own credential.

It is what stops a forged receipt from unlocking paid access, and also the reason a purchase takes a few seconds between the store accepting it and the app granting it.

Official links

• Google Play: create and manage subscriptions
• Google Play: understanding subscriptions, base plans and offers
• Apple: submit an in-app purchase for review
• Apple: generate keys for In-App Purchases