In-app purchases without writing StoreKit or Play Billing: selling subscriptions inside your app

Selling a subscription inside a mobile app is one of the most demanding things you can build: StoreKit on iOS, Google Play Billing on Android, server-side receipt validation, renewals, refunds. Or, on our platform, one toggle. This post explains what that toggle actually hides, and the honest trade-off that comes with it, because there is one and it is not small.

Quick context: GoodBarber is a no-code app builder running since 2011; the platform compiles native iOS and Android apps for people who will never open Xcode. Some of those people live from their content. This is the machinery that lets them charge for it.

What in-app purchases are for (and not for)

In-app purchases sell access to digital content inside the app: premium articles, videos, podcasts, courses, members-only sections. On our platform that takes the form of subscriptions, monthly or annual, and it exists for Content Apps published as native iOS and Android builds.

What in-app purchases are not for: selling physical goods. That distinction is not a product choice, it is store law. Apple and Google require in-app purchase for digital content sold inside an app, and forbid it for physical goods and real-world services, which must go through a regular payment gateway. So an app that sells t-shirts checks out through Stripe or PayPal, and an app that sells premium podcasts checks out through the App Store and Google Play. Two different rails, two different cost structures, and no way to swap them.

Keep that in mind for the rest of this post: everything below is about the digital-content rail. The e-commerce rail is a separate module with separate economics (no store cut, standard processor fees). Mixing the two up is the single most common confusion in this topic.

When is the in-app rail the right call? When your audience is mobile-first, your product is content, and your growth depends on people subscribing at the exact moment they hit your paywall. Which is precisely the moment a payment form kills.

Why this is the hardest checkout in mobile

Here is what "selling a subscription in your app" means when you build it yourself:

• Two APIs, two lifecycles. StoreKit on iOS and Play Billing on Android are separate systems with separate product models, separate testing sandboxes and separate failure modes. You implement everything twice.
• A server you now operate. Purchases must be validated server-side: the store issues a receipt or purchase token, and your backend has to verify it, or your paywall can be bypassed. That means running a service, storing entitlements, and keeping it up for as long as you have subscribers.
• A state machine that runs for years. A subscription is not one transaction. It renews, fails to renew (card expired), enters grace periods, gets cancelled, gets refunded, gets restored on a new phone. Every one of those events must reach your server and flip content access accordingly, or you have paying users locked out and free riders let in.
• Store-specific edge cases. Restore purchases is mandatory on iOS. Refund handling differs per store. Review teams check your subscription UX against their guidelines.

None of this is exotic for a payments team. All of it is a wall for a creator, and a serious multi-week project for a developer doing it once. It is the hardest checkout in mobile because it is not a checkout: it is a long-running billing system with two masters.

What happens behind the toggle

On our side, the creator's job is to define the offer in the back office: the subscription products, monthly or annual, and the price for each store, because the App Store and Google Play each have their own pricing grids and currencies. Then they turn the feature on.

To be precise about what "we handle the rest" means: it is not one big automation. Behind the toggle there is software and there is a team, splitting the list from the previous section:

• The billing machinery is software. Server-side receipt and purchase-token validation runs on infrastructure we already operate. Renewals, grace periods, cancellations, refunds and restores are processed and wired to content access: a subscriber sees the premium content, a lapsed one stops seeing it, with no code written by the creator.
• The store side is our app-store experts. The creator's configuration drives the product setup with Apple and Google and the submission work around it, carried by the same team that publishes and maintains apps in the stores all day. Store-specific edge cases, and the drift of StoreKit and Play Billing over time, land on their desk, not the creator's.

One toggle on the creator's side does not mean one script on ours; it means the complexity moved to people and systems whose job it is.

For the end user, the entire experience is one tap on the store's native payment sheet. No form, no card number, no new account. The store already has their payment method on file.

The fine print

Because a toggle this clean has some:

• It is for Content Apps published as native builds, not PWA-only plans, and not eCommerce Apps (different rail, as covered above).
• It sells subscriptions, monthly or annual, not one-time unlocks or consumable credits.
• Subscription access is binary: subscribers see the premium content, everyone else sees the public content.
• It also replaces the standard login flow; an app uses one or the other, and the back office makes you switch deliberately.

Very few no-code builders ship native in-app purchases at all; the usual answer is a plugin, a third-party billing service, and a validation server that becomes your problem. Shipping it as one toggle is rare, and it is one of the features we consider a signature.

The honest trade-off: the store cut

Apple and Google take 15% to 30% of every in-app subscription. Where you land in that range depends on their programs and your history: the small-business tiers, subscription retention past the first year. That cut is real money, and any article that shows you the toggle without the cut is selling you something.

GoodBarber adds no commission on subscriber revenue: the platform is flat-rate subscription pricing, and what your subscribers pay is yours, minus the store's share. But the store's share is structural. It is not our fee to waive; it is the cost of being on the rail.

So why accept it? Because of what the rail buys: the highest-converting checkout that exists on mobile. The user is already authenticated with the store, their card is on file, and the purchase completes in one tap at the exact moment of intent. Compare that with sending a mobile user to a web page to type a card number: conversion drops sharply, and the drop routinely costs more than the cut. The store cut is not a tax on the feature; it is the price of the smoothest checkout in mobile.

In-app or web checkout: how to choose

The alternative is legitimate: sell the subscription on your website, keep your full margin minus processing fees, and let subscribers sign in inside the app. Regulators and courts have also started forcing the stores to loosen their rules on external purchase links in some regions, so the legal ground is moving. The physics, so far, are not: a web checkout still asks a mobile user to leave the app and fill a form.

A short decision grid:

• In-app wins on volume. Mobile-first audience, impulse subscriptions at the paywall moment, price points where 15-30% is absorbable: the conversion uplift usually outweighs the cut.
• Web wins on margin. High-ticket subscriptions, an audience you already convert on the web, thin margins where the cut genuinely hurts.

Most creators are not choosing a religion. They are choosing a default for where their audience actually subscribes, and for a content app, that is usually inside the app.

If you are evaluating no-code platforms for premium content, here is the one question that sorts the field: who validates the receipts? If the answer involves you, a plugin and a server, you now know what you are signing up for.

Questions in the comments - happy to go deeper on the billing lifecycle or the store-specific quirks.