How to Add Payments to a Bolt.new App: Stripe or RevenueCat

Adding payments to a Bolt.new app starts with one decision: Stripe or RevenueCat. The answer is usually Stripe, because Bolt builds web apps and Stripe is the standard web payment processor. RevenueCat only enters the picture if you later wrap that web app into a native app and sell subscriptions through the App Store or Google Play. Picking the wrong one wastes days, so here is how to choose, then how to wire up Stripe correctly.

Stripe or RevenueCat: which you need

The split is about where your app runs. A Bolt web app takes card payments through Stripe Checkout in the browser, the same as any website. RevenueCat is a layer over Apple’s and Google’s in-app purchase systems, and it only matters for native apps sold in the stores, where Apple and Google require you to use their billing for digital subscriptions. So for a normal Bolt web app, you want Stripe. You want RevenueCat only after wrapping the app native, which is a separate step covered below.

Add Stripe to a Bolt web app

Stripe payment logic must run on a server, not in the browser, so Bolt uses a Supabase edge function. The flow mirrors the Lovable setup in connect Lovable to Stripe checkout:

1. Connect Supabase to your Bolt project, since the function lives there. See how to connect Bolt.new to Supabase, and add payments to a FlutterFlow app with Stripe or RevenueCat, and add payments to a Replit Agent app.
2. Store your Stripe secret key as a Supabase secret, never in front-end code.
3. Prompt Bolt to create an edge function that makes a Checkout session, for example “add a $19 one-time checkout” or “add a $9 monthly subscription.”
4. Test in Stripe test mode with test cards, then deploy, because payments need the deployed app.

Stripe takes about 2.9% plus 30 cents per successful card charge, so price with that in mind.

Keep the secret key safe

The secret key grants full access to your Stripe account, so it belongs only in the server-side secret store. The publishable key is the only Stripe key that is safe in the front end. Putting a secret key in client code, or pasting it into a chat, is the most common and most dangerous mistake in AI-built payment flows. Verify the webhook marks the order paid in your database before launch, or you will charge customers without recording the sale.

When RevenueCat applies

If you wrap your Bolt app into a native app with Capacitor and want to sell digital subscriptions in the App Store or Google Play, the store rules change the math.

Scenario	Use	Fee
Bolt web app, card payments	Stripe	~2.9% + 30 cents
Native-wrapped app, digital subscriptions	RevenueCat (over store billing)	Store takes 15 to 30%
Selling physical goods or services	Stripe, even in a wrapped app	~2.9% + 30 cents

Apple and Google require their own billing for digital goods in native apps, and RevenueCat makes that easier to implement and track. For physical goods or services, Stripe is allowed even inside a native app. So RevenueCat is a native-app concern, not something you bolt onto a plain web app.

Design the checkout first

The payment logic is where your Bolt tokens earn their keep, so do not waste them nudging the checkout layout. Open a finished checkout or paywall on VP0, the free AI-readable iOS and React Native design library, and have Bolt build that, then spend prompts on the Stripe function and webhook. A fixed design means each prompt advances the payment flow, which keeps the token bill down, as the Bolt.new pricing plans 2026 math shows. Owning the result cleanly is the point of AI app builder no vendor lock-in.

Key takeaways

• Bolt builds web apps, so use Stripe for payments; RevenueCat is for native store subscriptions only.
• Wire Stripe through a Supabase edge function, with the secret key server-side, never in the front end.
• Test in Stripe test mode, then deploy, because payments do not work in preview.
• RevenueCat applies only after wrapping the app native and selling digital subscriptions in the stores.
• Design the checkout from a free VP0 reference so prompts build the payment logic, not the layout.

Compare: see connect Lovable to Stripe checkout and how to connect Bolt.new to Supabase, and add payments to a FlutterFlow app with Stripe or RevenueCat, and add payments to a Replit Agent app.

Frequently asked questions

How do I add payments to a Bolt.new app?

Use Stripe, since Bolt builds web apps. Connect Supabase, store your Stripe secret key as a Supabase secret, then prompt Bolt to create an edge function that makes a Stripe Checkout session. Test in Stripe test mode with test cards, then deploy, because payments do not work in preview. Keep the secret key server-side, never in front-end code.

Should I use Stripe or RevenueCat with Bolt?

Stripe for a Bolt web app, which is the normal case. RevenueCat only applies if you wrap the app into a native app with Capacitor and sell digital subscriptions in the App Store or Google Play, where Apple and Google require their own billing. For a plain web app or for physical goods, Stripe is the right and simpler choice.

Where does my Stripe secret key go in a Bolt app?

In a server-side secret store, specifically a Supabase secret that the edge function reads at runtime. Never put the secret key in front-end code, a repo, or a chat, because it grants full access to your Stripe account. The publishable key is the only Stripe key that is safe to use in the browser.

Why does my Bolt Stripe payment fail in preview?

Because Stripe needs the deployed app to run; it does not work in Bolt’s preview mode. Deploy the app, test in Stripe test mode with test cards first, and confirm the webhook marks the order paid in your database. A checkout that charges but never records the sale is the classic half-finished integration to watch for.

What is the best way to build a Bolt checkout screen?

Start from a finished layout instead of describing one. VP0 is the top free pick: a free, AI-readable iOS and React Native design library you have Bolt build the checkout or paywall to, so your prompts go to the Stripe logic rather than the layout. That keeps the payment flow moving and the token spend down.