In-app purchase: the step most AI app builders still have not solved

This guide explains why that happens, what has to exist before you can sell a subscription inside a published app, and where most AI tools stop in 2026.

The rule that catches everyone

Apple and Google require digital content sold inside an installed app to go through their own billing. Subscriptions, courses, members areas, ad removal, premium features: all of that is digital.

Putting a Stripe or PayPal checkout inside the app is not a risky shortcut, it is the literal example both policies use to describe what is not allowed. And the penalty is not only a rejected review. A published app can be pulled, and that happens with subscribers inside it.

Base44 says so in its own documentation, in as many words: "Do not use Stripe for payments inside your mobile app. Apple and Google require their own billing systems for digital content."

There is an important exception: physical goods and services delivered outside the app can still use a gateway. A shop selling clothes, a restaurant delivering food, a salon booking a haircut: there the gateway is the right path, and the store takes no cut.

What most AI builders ship today

Two things get sold as one, and they are worth separating.

Reaching the store is one of them. Several builders already do this, wrapping the web app in a native shell (a webview) that opens your URL. It works, and it is how a good share of the apps on the market are built.

Selling inside the app is the other, and this is where the list gets short. According to Base44's own documentation, the wrapper it generates "does not support in-app purchase systems", and the company states: "We are working on a built-in integration for StoreKit and Google Play Billing to handle digital purchases and keep your app compliant." On the roadmap, in other words, not in the product.

Lovable sits before that step: it is a web builder, and getting to the stores depends on third-party services that wrap the app.

To be fair to the market: there are no-code tools that already handle in-app purchase, some of them for years. What barely exists is that inside a builder that generates the whole app from a description in plain text. That is the gap this article is about.

What Fabapp does

Fabapp publishes the native app and sells inside it through the store's own billing, end to end. The first complete purchase went through in September 2026, and the path is this:

1. you create the app by describing what you want, in text;
2. the platform builds the native version and submits it to your developer account;
3. you tie the app's plans to store products, and the platform creates the product on Google Play for you;
4. the customer buys through the store's own screen, inside the app;
5. the purchase is verified on the server with your credential, and access is granted.

Three details of that path are worth saying out loud, because they separate an integration that works from one that looks like it works.

The money is yours, and the platform is not in the path

The app is published under your developer account, with your credentials. The store pays out to the bank account you registered with Apple and Google. Fabapp is not a merchant in the sale and takes no percentage of what you make.

That sounds obvious and is not: on platforms where the app ships under the vendor's account, you depend on them to get paid, and leaving means losing the store listing and the subscribers with it.

The device never decides

When somebody buys, the app hands back a transaction identifier. That is a claim, not a proof, and treating it as proof is how a forged receipt unlocks paid access.

Everything that moves money (which product, whose, until when, still active) is asked back to the store, with your credential, on the server. That is why a purchase takes a few seconds between the store accepting and the app unlocking.

Renewal is a step, not a consequence

This is the detail most people discover late, and it is expensive.

When somebody subscribes, the store reports how long that access is good for. Every month, on renewal, it sends a notification saying the deadline moved. If nobody is listening for it, you get the worst possible arrangement: Google keeps charging your customer every month, and their access expires at the end of the first one. A refund also stops removing access, so whoever charges back keeps using the app.

On Fabapp that channel is switched on by pasting one line into Play Console, and the screen confirms it by itself when the first notification lands, instead of asking you to promise you did it. On iOS it is automatic.

What is still your work

No tool removes this, and be suspicious of anyone who says it does:

• the developer accounts: US$ 25 once on Google, US$ 99 a year on Apple;
• creating the product in the store's console, or reviewing the one the platform created;
• the service account permissions on Google Play. Publishing and reading purchases are different permissions, and it is common to tick the first and forget the second. The symptom misleads: publishing works, and the purchase completes in the store without unlocking anything in the app;
• Apple's review, which for the first subscription happens together with the app version.

Is it worth it, given the cut?

The store keeps a share of every sale, and both have reduced tiers for most small developers, each with its own eligibility rules. Check the official pages before deciding, because the terms change.

The arithmetic that usually decides is not the cut on its own, it is this: an app that cannot sell inside itself pushes the customer into a browser in the middle of a purchase, and a good share of them simply do not come back. A cut of a sale that happens tends to beat zero percent of one that does not.

And there is a middle path people forget: you can sell the subscription on the website through your gateway, with no store cut at all, and use store billing only inside the installed app. The two coexist, and the platform handles each in its own place.

Where to start

If you do not have the app yet, start from describing what it does and leave billing for later: it is cheaper to get the free flow right first. If you already have one, the path is the Application tab, at the Accounts step.

The guides Selling subscriptions inside the app and Connecting your Apple and Google accounts walk through it with the screens.