How to add in-app purchases to your Base44 mobile app

Your app works. You built it on Base44, maybe it's already in the App Store or on Google Play with the store build Base44 makes, and now you want it to make money: a monthly subscription, a one-time payment for the premium features, a pack of credits, or ads in a free app. Then Apple rejects the build under guideline 3.1.1, its rule that digital purchases go through Apple, or Play Console won't let you create a single in-app product, and that's how you find out that Base44's mobile app can't sell anything digital.

Why Base44's mobile app can't sell anything digital

On the web you can charge on Base44, as long as you pay for the Builder plan ($50/month) or above: you connect Stripe and people pay on a checkout page. The stores work differently. Apple and Google don't allow Stripe, PayPal or any other checkout for digital things inside an app: a subscription, premium features, credits, a course. Those have to be paid through Apple or Google, on their own payment screen inside the app, and an app that sells them any other way is rejected.

For an app to sell through Apple or Google, three things have to work together. The app opens the store's payment screen. A server checks the purchase with Apple or Google. And the person's account gets what they paid for. On Base44, all of that belongs to Base44.

Start with the app itself. The mobile app Base44 builds for you is your website inside a wrapper: a small native app, made by Base44, that opens your site. Only that native app can open the payment screen, and Base44 doesn't let you change it. That's also why the usual advice, “just add RevenueCat”, doesn't work on Base44. RevenueCat is a service many apps use to run their in-app purchases, but it has to be built into that same native app, so on Base44 there's nowhere to add it. The server that would check the purchase is Base44's too: your app's backend runs on Base44's servers, and your users' accounts sit in Base44's database.

So there's no setting or prompt that fixes it, and no plugin that adds it. Base44 has been saying it's working on in-app purchases for almost a year. The request is still “under review” on their feedback board, there's still no date, and their own support has told owners it's not coming anytime soon. Ads have the same problem. In a phone app, ads come from AdMob, Google's ad network for apps, and AdMob has to be built into that native app as well. Google doesn't allow the AdSense ads from your website to run inside an app without it.

None of the ways to stay on Base44 gets you real in-app purchases

Nobody wants to give up an app that works, so the first thing people try is selling without leaving Base44. Base44 itself suggests two ways, the community has a third, and none of them puts real in-app purchases in an app you own.

1. Sell on your website and let the app unlock it

Base44's own docs suggest this one, and on paper it makes sense: keep Stripe on the web, take every price and every Upgrade button out of the mobile app, and have the app unlock what people bought on your site. Netflix does exactly that, so why not your app?

The problem is that Apple allows that only for video, music, book and news apps like Netflix. Any other app can unlock what people bought on your website only if it also sells the same things inside, as in-app purchases, and yours can't. If the app still shows a price or points at your website, Apple rejects it with a letter saying so. What gets through is the app with every price and every mention of your website stripped out: a free app with a login box, where a new user never sees a price. On Google Play, the Android app may unlock what people bought on your website, but a button or a link that sends them there to pay isn't allowed. One owner put it this way: “My app is already on the iOS store and picking up downloads. I just cannot monetize it.” So the app stops selling, and every sale depends on people finding your website by themselves.

2. Release on the US App Store only and link to your checkout

Base44's second suggestion is to release the iPhone app only on the US App Store and put a button in it that sends people to pay on your website. A US court made Apple allow that link on the US store, so it looks like a way around Apple's rule.

The problem is that Apple can still reject the app for it, even on the US store. Base44 says so itself, in its own instructions for this exact route. You can pull the app from every country but the US, add the link, and still get the rejection letter.

And when it does get through, it cuts out most of the people who would pay you. The link is allowed only on the US App Store, so nobody outside the US can buy: not in the UK, not in Canada, not in Europe or Australia. Google Play doesn't allow the link at all, unless you join Google's own program, which needs changes to the app that Base44 doesn't let you make, so your Android app still sells nothing. The people who can pay get sent out of the app to a checkout page in their browser and asked for their card, instead of paying with Face ID in a second, and many of them never finish. And it all rests on a court ruling that the Supreme Court agreed in June to review, so it can be taken away.

What you're left with, if Apple lets it through at all, is an iPhone app that sells only in the US, by sending people out of the app, for as long as the court allows it.

3. Put the app in another company's wrapper, with RevenueCat

This is the answer you get on Base44's Discord and in the Facebook groups, from Base44's own moderators too: replace Base44's wrapper with someone else's. That's another small native app that opens your live Base44 app, the way Base44's does, except this one has in-app purchases built in, usually through RevenueCat. Despia, Median and Natively sell these wrappers, Wanilla builds and runs one for you as a service, or you hire a developer to build one with Capacitor, a free toolkit for turning a website into a phone app. And it does work: there are Base44 apps in the App Store right now selling real subscriptions this way.

The problem is that you're now on two platforms instead of one, and you control neither. Base44 still runs the app, its backend and its users, so you keep a Base44 plan with backend functions, for the function that checks who paid. The wrapper belongs to another company, so you pay them too: $249 per store at the cheap end, up to $2,995 plus $199/month. Anything their wrapper doesn't do, your app can't do either. And Base44 calls this setup “not a supported approach”, so when a Base44 change breaks the login inside the wrapper, nobody owes you a fix. An owner with two apps live on both stores through a paid wrapper: “between paying Base44 monthly and the program to wrap the app so I can have it on the app stores, I'm bleeding money.”

How a normal app sells a subscription

A normal app sells a subscription like this: the app opens Apple's payment screen, the person pays with Face ID, the app's own server checks the purchase with Apple and writes “premium” on that user's record. Same on Android with Google Play. The app, the server and the accounts all belong to the same person, so wiring them together is an ordinary piece of work, Apple and Google take their cut, and nothing else stands in the way.

Your Base44 app has the screens, the data and the users. What it doesn't have is a server of its own. Everything your app does, from signing people in to saving a record to the logic behind every button, is done by Base44's backend: server code that Base44 wrote and runs for every app on the platform, and never gives out. That's the whole reason a purchase can't go through: the server that would check it isn't yours, and neither is the native app around your site. To sell inside the app, the app has to become yours, server included, and there are two ways to get there.

You can build it again from scratch as a real native app, with developers or in another app builder that supports in-app purchases. It's a serious development project: it takes months, and development agencies often quote $5,000 and up for it. At the end you have the same app you have now, with your database and your users copied over by hand.

Or you can move the app as it is. That's a lot harder than it sounds. Moving the screens is the easy part, and Base44's export gives you those. The hard part is the backend, because the server code that makes the screens work stays on Base44's servers. To move an app as it is, someone has to rebuild Base44's entire backend.

Move your app off Base44, and in-app purchases come with it

To move my own app off Base44, I rebuilt Base44's backend from scratch, all of it: the sign-in, the database and everything that reads and writes it, the backend functions, the files, the AI, the emails, every piece of Base44's server code an app depends on. It took months. Then I automated the whole move, and that's EscapeBase44.

You log in with your Base44 account and pick your app. It moves to hosting and a database you own, with all its records, its files and its functions, and its users, who keep their passwords. The backend comes with it: you get the full code of the server that runs your app, in your own GitHub, and you can read it, change it and host it anywhere. Your app itself isn't rebuilt or changed. It works exactly as it did, and your Base44 app isn't touched, so it keeps running while you check the new one.

From there your app has all three things a store purchase needs, and all three are yours: the server, the accounts, and its own iPhone and Android apps. You build those with one click after the move. The iPhone build lands in TestFlight, Apple's app for trying a build on your phone before you send it to review, and the Android build comes out signed, ready to upload to Google Play. If Base44 already published your app, the new build uses the same app ID the store knows it by, so your existing listing gets an update instead of a new app.

Now selling works the way it does in any app. On iPhone, your user taps Subscribe, Apple's payment screen pops up, and they pay with Face ID, the same way they pay for anything in the App Store. On Android, Google Play's payment screen does the same. Then your own server checks the payment with Apple or Google and gives the premium features to that user's account, so someone who subscribed on their phone is Premium on the web too, and Stripe keeps taking payments on the web as before.

You can sell subscriptions, a one-time unlock of the premium features, and packs of credits. Someone who switches to a new phone gets back what they bought, and when someone renews, cancels or gets a refund, your server hears about it on its own. And ads work too: a free app can show AdMob ads in the iPhone and Android apps and AdSense ads on the web, like any normal app.

Logging in shows you the price right away. It depends on your app, you pay it once, and the move runs on its own and is usually done in a few minutes. After that there's nothing to keep paying us, and nothing to keep paying Base44. Your users pay inside the app, and the app is yours.

Base44 in-app purchases FAQ

• Can a Base44 app have in-app purchases?

  Not in the app Base44 builds. That app is your website inside a wrapper: a small native app, made by Base44, that opens your site. It can't open Apple's or Google's payment screen, and Base44 doesn't let you change it. In-app purchases need an app you control, so once you move your app off Base44, it can sell them on both stores.

• Apple rejected my Base44 app under guideline 3.1.1. What does that mean?

  It means the app sells or unlocks something digital (a subscription, premium features, credits) without Apple's in-app purchase. A Stripe checkout inside the app triggers it. So does showing a price or your website in an app that unlocks what people bought there without selling the same things inside.

• Does RevenueCat work with Base44?

  Not in the app Base44 builds. RevenueCat is a service many apps use to run their in-app purchases, and it has to be built into the native app around your site, which Base44 doesn't let you change. It only works if you put your Base44 app inside another company's wrapper, which keeps you on Base44 and adds another company to pay.

• Can I sell on my website and unlock it in the iPhone app?

  Only if the same things are also sold inside the app as in-app purchases, which a Base44 app can't do, or if yours is a video, music, book or news app. For everyone else, an app that shows a price or your website gets rejected, and what gets through is a stripped app where a new user never sees a price. On Google Play, the Android app may unlock what people bought on your website, but a button or a link that sends them there to pay isn't allowed.

• Can my Base44 iPhone app link to my website to pay?

  Only on the US App Store, and even there Apple can still reject the app for it, as Base44's own instructions say. No other country's App Store allows the link, Google Play doesn't allow it at all, and the court ruling it rests on is now before the Supreme Court.

• Can I sell credit packs in a Base44 app?

  On the web, yes, through Stripe. Inside the mobile app, no: Apple and Google require credits to be bought on their own payment screen, and Base44's app can't open it. After the move, a pack bought on the phone adds the credits to the person's account, and a refund takes them back.

• Can I put ads in a Base44 mobile app?

  No. In a phone app, ads come from AdMob, Google's ad network for apps, which has to be built into the native part of the app, and Base44's wrapper gives you no access to it. Google doesn't allow your website's AdSense ads inside an app without it. After the move, AdMob runs inside the iPhone and Android apps and AdSense on the web version.

• Does Google Play allow Stripe in a Base44 app?

  Not for anything digital. Google's policy requires Play billing for digital items sold in the app, and it doesn't allow a button or link to pay somewhere else unless you're enrolled in Google's own programs, which need changes to the app that Base44 doesn't let you make.

• My app sells physical products or bookings. Does any of this apply to me?

  No. Apple and Google require their own billing only for digital things. Physical goods and real-world services can go through Stripe or any other provider inside the app, on Base44 too.

• Can I charge for the download instead?

  Yes, and it's the only way to charge inside the stores that works on Base44, because a paid app is a price you set in App Store Connect or Play Console, with nothing inside the app. You get one price per download and nothing else: no subscription, no free trial, no credits, no upgrade later.

• I use Base44 Payments. Does it move with the app?

  No. Base44 Payments is a merchant account Base44 opened for you at Wix, and it only works inside Base44. After the move you take payments on the web with a Stripe account of your own.

• Do I keep my App Store listing and bundle ID after moving off Base44?

  Yes. The bundle ID is the ID the store knows your app by. Your new build uses the same one Base44 published it under, so your existing listing gets an update instead of a new app. An app that was never published gets a bundle ID of your own.

• Does Stripe keep working on the web after the move?

  Yes. Your Stripe keys and the webhook move with your backend, and the web checkout keeps running as it did. A subscription bought on the phone and one bought on the web land on the same user record.

• What do Apple and Google take on an in-app purchase?

  A cut of every purchase, between 15 and 30 percent depending on your size and the kind of purchase. Every app that sells through the stores pays it, and after the move it's the only cut anyone takes on your purchases.