Lovable Stripe integration: set it up safely

As of 30 September 2026, Lovable offers two ways to take payments with Stripe. Built-in payments create a Stripe sandbox account for you to claim later. The Stripe integration connects a Stripe account you already own, using an API key, and Lovable builds the checkout, subscriptions and a customer portal through chat. Either gets a working checkout in front of customers quickly. What neither sets up by default is the part that keeps money and access in step: Lovable's documentation says its Stripe integration does not use webhooks by default, and Stripe says webhooks are required to fulfil subscriptions reliably.

This guide explains both options, what Lovable builds and what it leaves to you, and the checks a paying app needs before launch. Every fact about Lovable and Stripe comes from their own documentation, listed under Sources at the end.

How does the Lovable Stripe integration work?

You ask for payments in the project chat and describe what you sell. Lovable then asks for a restricted Stripe API key through a Connect Stripe form, stores it as a backend secret named STRIPE_SECRET_KEY and builds the rest. On Lovable Cloud the key appears in the project's Secrets; on your own Supabase project it is synced to your edge function secrets.

What Lovable builds, according to its documentation:

• Edge functions that call Stripe from the server, so the secret key never reaches the browser.
• A checkout that opens in a new tab, for one-time payments and subscriptions.
• A Manage subscription button that sends customers to Stripe's hosted customer portal.
• Products and prices in your Stripe account, created with your approval.

There are three requirements. The project needs a backend, either Lovable Cloud or your own Supabase project. Subscriptions need sign-in, so Lovable can match each subscription to a user; one-time payments work without accounts. And the Stripe connector must be enabled in your workspace settings.

Built-in payments or your own Stripe account: which should you use?

Built-in payments hand the whole setup to Lovable. Connecting your own account keeps Stripe in your hands and asks more of you. You cannot run both in one project.

Choose built-in payments for a simple digital subscription you want live this week. Choose your own Stripe account if you already sell through Stripe, need more than one subscription per customer, or expect engineers to take the app beyond Lovable later, because the account, its customers and its history should sit in your company's name from day one.

Do you need Stripe webhooks in a Lovable app?

Yes, as soon as you sell subscriptions. A webhook is a message Stripe sends your server when something happens, such as a renewal succeeding or a card being declined. Lovable's integration instead checks payment status directly with Stripe, which works while the customer is on the page. Most of what happens to a subscription happens when nobody is.

Stripe is explicit about this. Its fulfilment guide says you cannot rely on the checkout's landing page alone, because a customer can pay and lose their connection before that page loads, and that webhooks are required if you sell subscriptions. Its billing guide adds that a subscription integration needs a webhook handler because most subscription activity happens asynchronously. Our glossary entry on webhooks covers how they work and how they fail.

At a minimum, a subscription app should handle these events:

• checkout.session.completed and checkout.session.async_payment_succeeded: a checkout was paid, now or later.
• invoice.paid: a renewal was paid; confirm the subscription is active before extending access.
• invoice.payment_failed: a renewal failed; tell the customer and ask for new card details.
• customer.subscription.updated and customer.subscription.deleted: a plan changed or ended.
• charge.refunded and charge.dispute.created: money went back, or a customer's bank is disputing a charge.

How do you handle Stripe webhooks safely?

A webhook endpoint is a public address that can change who has paid, so it needs the same care as a sign-in form. Stripe's documentation sets out the rules:

1. 01Verify every signatureCheck the Stripe-Signature header against the endpoint's signing secret, which starts with whsec_, using the raw request body. Stripe's libraries reject events older than five minutes by default, which blocks replayed messages.
2. 02Answer first, work secondReturn a 2xx response straight away and do slow work afterwards, ideally from a queue. Slow endpoints time out and get retried.
3. 03Process each event onceStripe may deliver the same event more than once. Record the event IDs you have handled and skip repeats, so a renewal never extends access twice.
4. 04Never depend on orderStripe does not guarantee events arrive in the order they happened. When one arrives early, fetch the current object from the API rather than guessing.
5. 05Plan for your own outagesIn live mode Stripe retries a failed delivery for up to three days with exponential back-off; in a sandbox, three times over a few hours. Anything down for longer needs a reconciliation job that asks Stripe what changed.
6. 06Keep keys on the serverOnly the publishable key, starting with pk_, is safe in the browser. Stripe recommends restricted keys, starting with rk_, over unrestricted secret keys.

Doing something exactly once when messages can repeat is called idempotency. It is the difference between a customer being charged once and a support ticket about being charged twice.

How should a Lovable app decide who has paid?

From a record in your database that only your server writes. The browser should never decide whether someone has paid, because anyone can edit what runs in their own browser. When a webhook arrives, your server updates the customer's plan and access date; every screen and function reads that record; and your database's row-level security stops one customer reading another's billing details.

Stripe's subscription guide gives the rules for that record. After invoice.paid, retrieve the subscription and confirm its status is active before extending access. When a subscription moves to past_due, ask the customer to update their card. When it moves to canceled or unpaid, revoke access. Then test it the hard way: call your checkout function directly with a changed price or plan and expect a refusal. That test, and the rest of a payments review, is in our Lovable security checklist.

How do you test Stripe payments in a Lovable app?

• Use sandbox keys, which start with pk_test_, rk_test_ and sk_test_. No card network processes a sandbox payment.
• Pay with Stripe's test card 4242 4242 4242 4242, any future expiry date and any three-digit code.
• Forward events to a local copy with the Stripe CLI (stripe listen --forward-to) and fire them on demand with stripe trigger.
• Walk every path, not only the happy one: a failed renewal, a cancellation from the customer portal, a refund issued in the Stripe dashboard and a dispute. Check that access changes each time.
• Before launch, switch to live keys and copy each endpoint's live signing secret. Stripe issues a different signing secret for sandbox and live mode.

Stripe's go-live checklist covers the account side. The app side, from access rules to monitoring, is what our guide to taking a Lovable app to production walks through.

What does payment engineering look like in a real product?

Two of our case studies show it. Inkwave is a newsletter platform where publishers sell paid subscriptions through Stripe Connect while the platform bills the publishers. Every Stripe webhook is signature-checked, failed payments are stored rather than logged and dropped, and refunds and subscription history are written from webhooks, so both sides keep an invoice trail. Inkwave is pre-launch; the details are on the Inkwave case study.

Ekko, a waitlist platform whose rewards are worth real money, was designed in Lovable. Its engineering pushed 25,000 users through the queue under load, with four locks in a row on anything worth money, and not one reward went out twice. Ekko is also pre-launch, and its case study is on our work pages.

Starter costs $2,999 a month paid annually or $3,999 month to month, and Growth is priced per product; both are on our pricing page. Not sure how close your app is? The free production-readiness check scores it in a few minutes.

Sources

Each fact above comes from one of these pages, checked on 30 September 2026.

• Lovable documentation: Connect your own Stripe account (docs.lovable.dev/integrations/stripe); Add payments to your app (docs.lovable.dev/features/payments).
• Stripe documentation: Receive Stripe events in your webhook endpoint (docs.stripe.com/webhooks); Fulfill orders (docs.stripe.com/checkout/fulfillment); Using webhooks with subscriptions (docs.stripe.com/billing/subscriptions/webhooks); API keys (docs.stripe.com/keys); Idempotent requests (docs.stripe.com/api/idempotent_requests).
• Case-study facts: our Inkwave and Ekko case studies, as published on this site.