Tech
Your Base44 App Is Finished. So Why Can't You Charge for It?
September 28, 2026
"Definitely got all the way to the finish line with my app just for this to be a roadblock." That's a Base44 builder on the platform's own feedback board in July, and it's far from the only one. Another founder, who'd already launched on the App Store a month earlier, wrote: "I want to start earning from it and just came to know that we cannot do that natively on the App Store." A third called it "tantamount to false advertising."
If your Base44 app sells anything digital on iPhone (a subscription, premium features, credits, a course), Apple requires that sale to go through its own in-app purchase system, and Base44 can't connect to it yet. Stripe is fine for physical goods. For digital goods inside the app, Base44's own documentation says it plainly: "If your app uses Stripe for digital content, your app is rejected."
What you do next depends on where your customers are and what you're selling.
Because Apple's Guideline 3.1.1 says so for anything digital. The exact wording is: "If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase."
Physical goods work the other way. Guideline 3.1.3(e) covers physical goods and services "consumed outside of the app", and for those you must use something other than in-app purchase, "such as Apple Pay or traditional credit card entry." So a Base44 app that sells cakes, gym sessions or plumbing call-outs can use Stripe. So can one selling live one-to-one services between two people, such as coaching, tutoring or fitness training: Guideline 3.1.3(d) allows other payment methods for "real-time person-to-person services". A Base44 app that sells a monthly membership to its own content can't.
The two names get confused. One builder on Reddit said they "can't add Apple Pay" when they meant in-app purchase (StoreKit, on the developer side). In apps, Apple Pay is a way to pay for physical things. In-app purchase is what Apple requires for digital ones.
The grey area is anything that mixes the two. In our experience a plan that bundles real-world deliveries with extra features in the app needs looking at case by case, because the membership part can pull the whole thing towards in-app purchase. We worked through exactly that with a pharmacy client recently.
Base44's own iOS app, the one you build with on your phone, charges through Apple too. Its docs warn that "the price shown in the iOS app may differ from the price on base44.com, as Apple applies its own fees."
Because a Base44 mobile app is your web app inside a wrapper, and that wrapper has no connection to Apple's purchase system. Base44's documentation describes the store build as "a lightweight native wrapper around your web app that opens only your app's URL."
In-app purchase needs native code that talks to StoreKit. RevenueCat, a widely used subscription platform, explained the gap in its community forum in June: "Because Base44 apps run inside a WebView, and Base44 does not currently provide a native bridge to StoreKit or RevenueCat's iOS SDK, there currently is not a way to directly connect a Base44 mobile app to App Store subscriptions in the same way you would with a native iOS app." One builder on Base44's board found this out the expensive way: "I had already configured RevenueCat and was surprised to learn that native SDK integrations aren't currently possible."
Base44 says it's coming. Its docs say: "We are working on a built-in integration for StoreKit and Google Play Billing." There's no date. On Base44's public roadmap, read on 28 September 2026, nothing about StoreKit or in-app purchase appears under Planned, In progress or Shipped, and the most-voted request for it has sat at "Under review" since 2 July. Google Play billing has the same gap.
If your launch date matters (one builder on the board has a seasonal app that must be live before Christmas), I wouldn't plan around it.
This month we reviewed the exported code of a Base44 app for a wellness founder who wanted to sell memberships in their iPhone app. The App Store question turned out to be the second problem. The app had three Stripe functions, and the webhook (the part that tells your app a payment succeeded) would have recorded new subscribers as free users, so people who'd paid would have been treated as if they hadn't.
Nobody had noticed, because the demo worked and nobody had followed a real payment all the way through. That's the pattern we see with AI-built payment code: the checkout page looks finished, and the code that runs after the money moves is where it goes wrong.
It depends which App Store your customers use. In the US, you can put a button to your own checkout in the app. In the UK and most other countries you can't, not from inside the app.
Base44's troubleshooting page gives this recovery for a Stripe rejection: move the purchase to the web version of your app, "keep the paywall in your mobile app, but have it tell people to go to your website," and have the app show or hide content according to who's paid. The link part fits the US storefront. Since a 2025 court ruling, Apple's Guideline 3.1.1(a) says entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps." Whether Apple also expects you to offer in-app purchase for the same thing isn't settled: Guideline 3.1.3(b) still says so, with no US exception. A B2B SaaS founder on r/iOSProgramming, stuck in a loop titled "Keep getting flagged for 3.1.1" in March, was rejected because even a link to a web sign-up page counted (the post didn't say which storefronts the app was on).
Apple grants that exception per storefront, though, and one app build goes to every storefront. Because Base44's wrapper can't tell which country's App Store the app came from, my advice is to use the US button only if the app is listed on the US store alone.
Everywhere else the same guideline says the opposite: apps "may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase," unless the developer holds a regional entitlement. Apple's StoreKit documentation covers regions including the EU, South Korea, Japan and Brazil, each with its own terms and fees. The UK isn't on the list. (Reader apps, such as video or audio libraries, can apply for a separate link entitlement.) The Competition and Markets Authority consulted in June 2026 on rules that would let UK developers steer users out of the app, and published the responses in August, but until Apple's guidelines change, a UK paywall that says "go to our website to pay" is what the guideline prohibits.
Paying on the web and logging in on the app has one more problem. Guideline 3.1.3(b) lets people use in your app what they bought on your website, "provided those items are also available as in-app purchases within the app." My reading of the text is that a login-only app fits only if it also offers in-app purchase or falls into one of the other exceptions: for example a reader app (magazines, music, video), an app sold directly to organisations for their staff or students (3.1.3(c)), or a free companion to a paid web tool with no purchasing or calls to action in it. The list in 3.1.3 is longer than this.
Keep the app on Base44, take payment on your website with Stripe, and make sure the iPhone app follows the rules for the storefronts you're in. In the US that can include a button to your checkout. In the UK it means the app can't point people there, so you rely on email, your website and marketing outside the app to make the sale. It's the cheapest and quickest route, and the worst for sales, because the app can't tell people where to pay at the point they decide to. One Base44 founder shipped without a paywall because they couldn't add one on iOS. Months later they wrote: "I haven't made a single dollar from the app itself."
Replace Base44's store build with a wrapper you control that has a native purchase bridge (Median, Natively and Despia all offer this), wired to RevenueCat so purchases go through StoreKit and Google Play Billing. This isn't a plugin inside Base44's build, which Base44 says won't work; it replaces that build. Your web app keeps running on Base44. It's quicker than a rebuild and it gives you proper in-app purchase. The costs are a second vendor in the chain and Apple's commission (15% if you enrol in the App Store Small Business Program, for developers under $1 million in annual proceeds). The hard part is keeping purchases, restores and people who subscribed on the web in agreement across three systems. A builder who went this way put it mildly: it "took way more time than expected."
Use your Base44 app as the blueprint and rebuild the mobile app natively, in React Native or Flutter, with in-app purchase built in. Base44 lets you export the web code (base44 eject in its CLI), but the backend is Base44's own, so moving off it means replacing that too. It costs more up front. In return you own the whole app, there's no wrapper between your customer and the payment sheet, and features Base44's wrapper can't reach, such as HealthKit and offline use, become possible. For the wellness founder above, once HealthKit, Health Connect and the other native features were on the list, our estimate put a native rebuild at about the same cost as wrapping their app properly and moving it off Base44's backend.
Our Base44 to production service delivers routes 2 and 3 and sets out the trade-offs for your app.
Of the rejection letters builders paste online, one of the most common has nothing to do with payments: Guideline 4.8, Login Services. If your app lets people sign in with Google, Apple requires an equivalent option that limits data collection to name and email, lets people keep their email private, and doesn't track them for advertising without consent. Sign in with Apple meets that. One founder, rejected on exactly this in March, came back to say: "It literally is as easy as the commenters said. I just added Sign in with Apple."
Check for the badge too. A builder was rejected in April "for sending users to another site outside of the app to pay," when every purchase already went through Apple. The cause was a small "Edit with Base44" button in the corner of the screen. Base44 calls it the platform badge, and removing it is available on the Starter plan and above.
List everything someone can pay for in your app. Anything used in the real world can stay on Stripe. Anything they get inside the app needs in-app purchase, or has to move to your website with no button pointing at it (outside the US). Check sign-in offers an Apple-compatible option, and that nothing on screen links out to Base44. Then buy your own product with a real card and confirm your app records you as a paying customer.
If you'd rather someone else looked, our £95 code review gives an engineer a fixed amount of time in your Base44 project. You get a written report covering architecture, security, stability, whether it can be saved and what you own, and the £95 is credited in full against any paid work that follows.
Yes, for physical goods, real-world services and live person-to-person services such as coaching, and on the web version of your app for anything. Not for digital goods sold inside your iPhone or Android app: Base44's documentation says an app that uses Stripe for digital content is rejected, and Apple's Guideline 3.1.1 requires in-app purchase for subscriptions, premium features and credits.
No. Apple Pay is a payment method, and Apple's guidelines name it as one you can use in apps for physical goods and services. In-app purchase is Apple's billing system for digital goods, and it's what Guideline 3.1.1 requires for subscriptions and premium features.
Not from inside the app, as of September 2026. Apple's guidelines allow buttons and links to other payment methods on the US storefront, and through regional entitlements in the EU, South Korea, Japan and Brazil. The UK has no such exception yet, though the CMA has consulted on rules that would allow it. Reader apps are an exception: they can apply for a separate link entitlement.
Not as of 28 September 2026. Its store build has no bridge to Apple's StoreKit, and its docs say an integration is being worked on, with no date. Today you need a wrapper with a purchase bridge or a rebuilt native app.
