Take real payments in your app

For subscriptions, and for knowing that someone really paid, there is more to do than its doc says. We link the doc for where to click and cover the gaps here. Labels below are the doc's own words ("its docs call it"), and we haven't seen them in the product, so check them in FlutterFlow before you go live. Paying other sellers is a different job: see Stripe Connect in the questions below.

1. 1

   The doc's route, for one-off payments. Its docs call the place Settings and Integrations, then In App Purchases & Subscriptions, then Stripe. Turn on "Enable Stripe Payments". Put your test keys under Test Credentials with "Is Production" off, and your live keys under Production Credentials. Then Deploy. The route needs Firebase, Firebase Authentication and the Blaze plan, and a Firebase Cloud Function processes the transaction. The amount goes in the smallest currency unit, which means cents. The payment needs a signed-in user. If you see a CORS error, the troubleshooting page points to the function's allUsers permission. We give no Merchant Country Code format, because the doc gives two different ones. Read the doc itself: FlutterFlow, Stripe and Fixing Stripe deployment & payment errors.

2. 2

   The gap page one asks about. The doc has no subscriptions and no webhooks. For web subscriptions, Stripe says a webhook is required, and FlutterFlow's troubleshooting page points web to direct API calls. We explain both in Why did they pay but nothing unlocked? and in what happens when a subscription renews.

3. 3

   The doc doesn't say what writes "paid". Here is the check. The doc sets the amount in the app's action and stores the payment ID in an app variable you name. It doesn't say what records "paid" in your database, or whether the price is checked on the server. That is a gap in the doc, not a verdict on any app. Ask three questions:

   1. 1.Where does the price come from? The app screen, or a lookup on the server from a fixed price?
   2. 2.What writes "paid"? The Cloud Function after Stripe confirms, or an app action after the payment ID comes back?
   3. 3.Who can change it? Can a signed-in user edit their own "paid" or plan field in Firestore?

   If you can't answer them, run the hand test below, then ask for the Free Build Audit.

4. 4

   A phone app. Subscriptions in a phone app go through RevenueCat, which is FlutterFlow's own advice, and RevenueCat has no web support. The detail is in Can I use Stripe in my iPhone or Android app?

Read Add payments to your app and Connect your own Stripe account first. Facts read 23 October 2026.

Lovable's built-in payments. Lovable recommends these first. They run on Paddle or Stripe, and Lovable creates and manages the provider account. You need a Pro plan or higher, and only admins and owners can set it up. A database is needed only if the app stores payment data such as subscriptions or orders, but older React + Vite apps always need Lovable's built-in backend. Sign-in is recommended, so each purchase links to a user. Test mode runs in the preview with test cards. Live runs on the published app. Products and prices sync from test to live when you publish, and discounts don't. Going live needs a readiness check (privacy policy, terms, refund policy, genuine content) and provider verification. Lovable registers two webhook endpoints per environment, and its doc says: "Do not delete or disable either Lovable-registered endpoint." If the app's endpoint is deleted, purchases succeed but subscriptions never activate. So leave them in place, and do hand test step 8 on the published app.

Your own Stripe account. Paste a restricted (rk_) or secret (sk_) key into the Connect Stripe form, never into the chat, as Lovable says. Publishable keys don't work. Webhooks are off by default. A test key means test mode. To go live, submit a live key and have Lovable switch to the live price IDs, because they differ. There is no separate test environment: with a live key, payments in the preview are real. Subscriptions are checked with Stripe directly.

Lovable's doc says the app checks payment status with Stripe directly by default, and suggests webhooks for fulfilment. Its one-time section doesn't say the unlock waits for that check. The check: hand test steps 4 and 5.

Gotchas. Disconnecting doesn't cancel subscriptions or refund anyone. On your own Supabase, the secret key stays there, so payment functions keep charging until you delete it there. The customer portal doesn't work in the preview panel.

Digital content and features unlocked inside the app go through the store's own billing. Physical goods and services use Stripe in the phone app too. Each rule below carries its date and link, and none of it promises that any route will pass review. Check the current guideline before you build.

Apple (App Review Guidelines, Last Updated: October 16, 2026, read 23 October 2026).

• 3.1.1: unlocking features or content in the app, such as subscriptions, premium content or a full version, "must use in-app purchase." How much the stores take is in What it costs to publish an app.
• 3.1.3(e): physical goods or services consumed outside the app must use purchase methods other than in-app purchase. So a booking, delivery or physical-product app uses Stripe in its iPhone app.
• The US storefront exception (3.1.1(a) and the 3.1.3 intro): apps on the United States storefront can include buttons, links or calls to action to other purchase methods without an entitlement. All other storefronts may not. This US rule follows a court case, Epic v. Apple, that is still going, so check the current guideline.
• 3.1.3(b): an app may let users access content or subscriptions bought elsewhere "provided those items are also available as in-app purchases within the app". One founder reported that Apple classed a Lovable-built coaching app as multiplatform, so its content also had to be sold by in-app purchase. That is one founder's report of one review, not a rule for every coaching app.
• 3.1.3(d): real-time person-to-person services (Apple's examples: tutoring, medical consultations, real estate tours, fitness training) may use other purchase methods. One-to-few and one-to-many real-time services must use in-app purchase.
• Other 3.1.3 exceptions exist for reader apps, company-internal apps, free stand-alone apps and advertising management. Read them in the guideline.

An app that sells digital content outside in-app purchase can be rejected under 3.1.1: see Why apps get rejected.

Google Play (Payments policy, read 23 October 2026; the page carries no policy date). Paid downloads and in-app purchases of digital items must use Google Play's billing system unless an exception applies. Physical goods, physical services and bill payments must not use Play billing.

Google's US page (read 23 October 2026) adds this. From 29 October 2025, for mobile and tablet apps serving US users, Google will not require Play Billing and won't block links to outside purchases. Developers who offer external links or alternative billing enrol in Google's programs, which launched on 9 December 2025. On 17 September 2026, Google told developers enrolled in external content links they have until 1 December 2026 to report successful downloads and pay the relevant service fees. That is the external-links reporting date, not an end date for the US changes, and the page gives no end date.

RevenueCat, the route Replit and FlutterFlow name for phone-app subscriptions. In Replit, Agent creates the RevenueCat project, product and entitlement. FlutterFlow has Paywall, Purchase and Restore Purchases actions, and no web support. Setup needs the store accounts and agreements: for Apple, the Apple Developer Program, a TestFlight build and the Paid Apps Agreement; for Google, an active subscription and a closed testing track. In previews and Expo Go, purchases are simulated. We can't say that RevenueCat, an external link or alternative billing will pass review. Read Replit, Add payments with RevenueCat and FlutterFlow, RevenueCat.

Two builders' own lines, set beside Apple's, not merged. Replit's docs (read 23 October 2026) say: "You can't route around it with an external payment link." That is simpler than Apple's current US storefront rule above. Base44's docs (read 23 October 2026) say: "If you plan to publish your app to the App Store or Google Play, don't sell digital content in the mobile app." Base44 apps don't support store in-app purchases yet.

If you wrap a web app. If you wrap a web app from Lovable or Base44 for the stores, you still need the store's own billing for digital content outside the US storefront. On the US storefront, Apple's 3.1.1(a) and the 3.1.3 intro allow links. For Google, US users don't need Play Billing from 29 October 2025, with enrolment. Check the current guidelines before you build. The whole route to the stores is in Publish your app to the app stores.

• Two Checkout modes. One-time purchases and recurring ones are different Stripe Checkout modes (payment and subscription). Subscription mode saves the payment method by default (How Checkout works).
• Webhooks are required for subscriptions, says Stripe. Events can arrive more than once and out of order, so the unlock must still work correctly if it runs twice. Renewals, cancellations and failed renewals reach your app the same way. If the endpoint is missing or deleted, the first payment can succeed while the subscription never activates, as Lovable's doc says.
• Bubble. With "End of billing period" cancellation, Bubble's manual says the web app doesn't update unless you process the webhook event.
• FlutterFlow. The doc has no subscriptions. Web subscriptions need the server-side confirmation, and phone apps go through RevenueCat (see the FlutterFlow and store sections above).
• Subscriptions need sign-in. Lovable, Bolt and FlutterFlow say so in their docs. How to set that up: "How do I set up login and user roles?" is a planned guide.

Hand test step 7 is the check. We don't describe Stripe's retry behaviour or the customer portal beyond what the vendors' pages say.

The signs:

• Subscriptions unlock access.
• A phone app sells anything.
• Credits are going on one payment bug that keeps coming back. See AI builder credits.

Either of those, or any one of these, is a reason to ask for the Free Build Audit first.