The worst Lovable payment bug is the one where the payment works. The customer is charged, Stripe shows the money, and the app never unlocks what they paid for. I went through 52 public reports of payments going wrong in Lovable apps, all from Reddit, and 14 of them were exactly that: a subscription status that never updated, a webhook that was never set up, or a signature check that rejected Stripe's message.
Getting a checkout button on the page is the easy part. Both apps I built this year, Launch Check and Client Approvals, take subscriptions through Stripe, and the work is in everything after the button: test and live mode, webhooks, and the moment the database is told someone has paid.
This guide covers both ways Lovable connects to Stripe, how to take each one live, and the places a successful payment gets lost.
What goes wrong with payments in Lovable apps
I sorted the 52 reports by the cause each thread confirmed. Fourteen were payments that succeeded without the app finding out. Four were test and live mode mixed up, four were checkout redirects and success pages, and three were people burning credits asking the AI to fix payments. The largest group, 25, was a mix, but nine of those were founders who couldn't use Stripe at all because of their country or type of business. I'll come back to that one.
Two ways to add Stripe to a Lovable app
Lovable's payments docs describe two separate paths. Built-in payments, launched in April 2026, have Lovable create and manage the payment account for you, on Stripe or Paddle. The older path connects your own Stripe account with a key.
| Built-in payments | Your own Stripe | |
|---|---|---|
| Lovable plan | Pro or higher | Any plan, including Free |
| Who sets up the account | Lovable, on Stripe or Paddle | You, in your Stripe account |
| Fees | Stripe rates, or Paddle 5% + 50 cents; nothing added by Lovable | Stripe rates |
| Preview | Test mode with test cards | Whatever key you paste; a live key means real payments |
| Webhooks | Set up by Lovable | None by default; you add them yourself |
| Tax and verification | Paddle handles sales tax as merchant of record | You, in Stripe |
My take: if this is your first paid product, use built-in payments, because the webhook work is the part people get wrong and Lovable does it for you. If you already run a business on Stripe, or you're on the Free plan, connect your own account and treat the webhooks as your job.
Built-in payments: setting up and going live
Only project or workspace admins and owners can turn built-in payments on, and Lovable recommends adding login first so purchases link to users. In the preview everything runs in test mode with test cards; the published app runs live, and live checkout doesn't work until the go-live steps are done. Products and prices copy from test to live when you publish, but discount codes don't, so create those in live separately. Don't edit products directly in the Stripe or Paddle dashboard either, which can leave test and live IDs out of step.
Going live on Stripe means claiming the Stripe account Lovable created for you, finishing Stripe's onboarding, then copying your products and the app to live. On Paddle it's a readiness check, identity and business verification, and a review of your domain, which usually takes about a day. The readiness check most often fails on missing privacy, terms or refund pages, or a site that isn't published. Lovable also suggests connecting a custom domain first, because the provider reviews the live address.
Your own Stripe account: setting up and going live
Paste a restricted key (rk_) or secret key (sk_) into the Connect Stripe form, never into the chat. Publishable keys (pk_) don't work. Lovable stores it as a backend secret called STRIPE_SECRET_KEY, and the payment code runs in edge functions. Stripe's key docs recommend restricted keys, which carry only the permissions you grant.
The trap is that this path has no separate test environment: the key you paste decides the mode. If you paste a live key, payments you make while testing in the preview are real. Use a test key until you're ready. To go live, Lovable's Stripe docs list three steps: submit a live key, switch the app to live price IDs (they're different from test ones), and make one real purchase on the published app.
Two more things to know. By default this path uses no webhooks: the app asks Stripe directly whether a signed-in user has an active subscription, and matches subscriptions to users by email address. And the customer portal, where people manage their subscription, has to be switched on once in the Stripe dashboard before it works.
When the payment works but the app does not know
Here is the path a payment takes after the customer clicks pay, and where it breaks:
Anything that breaks after step 2 means the customer paid and got nothing.
- The endpoint is gone or doubled. Built-in payments register two webhook endpoints per environment. Lovable warns that deleting the app's endpoint silently breaks unlocking, and that a duplicate one you added by hand delivers events the app can't verify.
- The wrong signing secret. Every webhook endpoint has its own secret, and test and live secrets differ even for the same address, according to Stripe's webhook docs. Stripe says the wrong secret is the most common reason signature checks fail; the one from the Stripe command line tool differs from the dashboard's too.
- The body was changed. The signature is checked against the raw request. Anything that parses or re-formats the body first breaks the check.
- The function expects a signed-in user. Stripe can't sign in to your app, so a webhook function that requires a logged-in user rejects it. In some threads that was the whole bug. The function has to be public and rely on the signature instead.
- Upgrades and renewals aren't handled. customer.subscription.updated fires on renewals and plan changes, so handling only the first purchase misses them. Stripe also doesn't promise events arrive in order, and can send the same one twice, so record the event IDs you've already processed.
My rule is simple: the success page says thank you, and only a verified webhook unlocks anything. Stripe's own fulfilment guide says not to rely on the success page alone, and requires webhooks for subscriptions.
Test mode and live mode are two separate worlds
In Stripe, test and live objects are completely separate: a product or price created in test mode can't be used for a live payment, and test cards like 4242 4242 4242 4242 only work in test mode. Copying a test product to live creates a new product with new IDs, which is why an app still holding test price IDs fails the moment it goes live. The customer portal has separate settings for each mode too, so switching it on in test doesn't switch it on in live.
Before you take your first real payment
- Publish the app, and connect a custom domain if you can.
- Add privacy, terms and refund pages.
- Check you're on live keys and live price IDs, with the live webhook secret if you use one.
- Switch on the customer portal in live mode.
- Buy your own product with a real card on the live site, and check it unlocks.
- Upgrade, cancel and refund that test purchase, and check the app follows each change.
When Stripe is not an option
Nine of the reports were founders who couldn't use Stripe at all: their country isn't supported, Stripe wanted a registered company, or their kind of business wasn't accepted. Built-in payments can run on Paddle instead, which acts as the merchant of record: it sells to your customer on your behalf and handles VAT and sales tax, for 5% plus 50 cents per transaction (a flat 10% under $10). Stripe has its own merchant of record option, Managed Payments, in fewer countries. PayPal, Razorpay and other providers aren't built in and need custom code.
Disconnecting does not stop billing
One last warning from Lovable's docs. Disconnecting built-in payments is permanent and doesn't cancel subscriptions or refund anyone, so your customers keep being billed. If your app uses its own Supabase project, disconnecting your own Stripe leaves the secret key there, so the payment functions can keep charging. Switching providers doesn't migrate products, prices or subscriptions either. Cancel and clean up in Stripe first, then disconnect.
If your app is breaking in other places too, I wrote up the most common causes in Lovable app not working, and how the database side works in Lovable Supabase integration. And if you'd rather hand it over, I take these on as client projects: send me the app and what's going wrong with payments.
Common questions
How do I add Stripe to a Lovable app?
Either turn on built-in payments, where Lovable creates and manages a Stripe or Paddle account for you (Pro plan and up), or connect your own Stripe account by pasting a restricted or secret key into the Connect Stripe form, which works on any plan. Never paste a key into the chat.
Should I use built-in payments or my own Stripe account?
Lovable recommends built-in payments for most new projects: it handles the webhooks and keeps test and live separate. Connect your own Stripe if you already run a business on Stripe, are on the Free plan, or want to manage keys and webhooks yourself.
Why did the customer pay but my Lovable app did not unlock anything?
The app never got, or never accepted, Stripe's message that the payment succeeded. Common causes are a deleted or duplicated webhook endpoint, the wrong signing secret, a function that rejects Stripe because it is not signed in, and upgrade or renewal events that are not handled.
Does Stripe work in the Lovable preview?
With built-in payments the preview runs in test mode with test cards, and the published app runs live. With your own Stripe there is no separate test environment: the key you paste sets the mode, so with a live key, payments made in the preview are real.
How do I take my Lovable app's payments live?
With your own Stripe: switch to a live key, switch the app to live price IDs (they differ from test ones) and make one real purchase on the published app. With built-in payments: complete the provider's verification and readiness check, which needs privacy, terms and refund pages and a published site.
What if Stripe is not available in my country?
Lovable's built-in payments can run on Paddle instead, which acts as the merchant of record and handles sales tax and VAT, for 5% plus 50 cents per transaction. Other providers such as PayPal or Razorpay are not built in and need custom code.
Does disconnecting Stripe in Lovable cancel subscriptions?
No. Disconnecting built-in payments is permanent and does not cancel subscriptions or refund anyone, so customers keep being billed. With your own Supabase project, disconnecting your own Stripe leaves the secret key in Supabase, so payment functions can keep charging.
This post first appeared on tusharbhendarkar.com. I fix apps built with Lovable, Replit, Bolt and Base44, and I build free checkers for live apps. If something here is broken for you, email me at tusharbhendarkar44@gmail.com.
Top comments (0)