Lovable and Stripe: Built-In Payments, Your Own Account, and the Webhook Behind Our Own Checkout

Which two paths does Lovable offer, and who qualifies for each?

Built-in payments and your own Stripe account. Both are in Lovable's docs, read on 26 September 2026, and they differ on plan, on who holds the keys, and on webhooks. The payments page says “built-in payments require a paid Lovable plan”, and offers Paddle and Stripe with “no API keys to handle”. The own-account page says the integration “does not require a paid Lovable plan”, and that “The form accepts restricted keys (rk_...) or secret keys (sk_...), test or live mode”.

The security line is the one to copy into your habits: “Never paste your Stripe key into chat messages.” The form is the only place for it, and “The key is stored as a backend secret, and Lovable does not read stored secret values back.” Lovable then “Lovable builds your payment flow with edge functions: small pieces of backend code that call Stripe using your stored key, so the key is never exposed in your app.”

What does a sale cost on each path?

Stripe's fees, from its US pricing page on 26 September 2026: “2.9% + 30¢ per successful transaction for domestic cards”, “+ 1.5% for international cards”, “+ 1% if currency conversion is required”. Checkout is “Included with Payments”; Billing is 0.7% of Billing volume (pay as you go); Tax Basic is 0.5% per transaction, where you're registered to collect taxes (no-code integration); a dispute is $15.00 for each dispute you receive. Paddle through Lovable's built-in path is “5.0% + 50¢ per transaction, no monthly fee”, with a “flat 10% under $10”. Lovable's own framing: “Using Stripe or Paddle through Lovable costs the same as setting up the provider directly.”

Paddle is a merchant of record, so its higher rate buys tax handling that Stripe sells separately; whether that is worth 2.1 points plus 20 cents on a $29 sale depends on where your buyers are. What the chart cannot show is the international share of your sales, which on this site is the majority, so the middle bars are our bars.

Why is the success page not proof of payment?

Because Stripe says so, in its "Fulfill orders" guide: “You can't rely on triggering fulfillment only from your checkout landing page, because it's not guaranteed customers visit that page. For example, a customer can pay successfully and then lose their internet connection before your landing page loads.” And: “Perform fulfillment only once per payment. Because of how this integration and the internet work, your fulfill_checkout function might be called multiple times, possibly concurrently, for the same Checkout Session.” The events to handle are checkout.session.completed and, for delayed payment methods, checkout.session.async_payment_succeeded. The detail that surprises people: “Checkout waits up to 10 seconds for your server to respond to the webhook event delivery before redirecting your customer.”

Put next to Lovable's line that on your own key “By default, the integration does not use webhooks: your app checks payment and subscription status directly with Stripe”, this is the decision the page exists for. A one-time purchase that grants access at the moment of return works until a buyer's connection drops between paying and returning. Subscriptions and delayed methods do not work that way at all. Ask Lovable for the webhook, verify its signature, and make it the only writer.

The webhook and the claim route both call the same idempotent write, keyed on the Checkout Session id, because the browser redirect regularly arrives before the webhook and a buyer looking at a page that says they own nothing is worse than a duplicate no-op. The webhook adds a second layer on the Stripe event id so a retry cannot send a second receipt:

// Layer 1. Insert-and-check: if we did not insert, someone already handled this event.
const { data: claimed, error: claimError } = await supabase
  .from("stripe_webhook_events")
  .insert({ id: event.id, type: event.type })
  .select("id")
  .maybeSingle();

if (claimError?.code === "23505") {
  return NextResponse.json({ received: true, duplicate: true });
}

try {
  switch (event.type) {
    case "checkout.session.completed":
    case "checkout.session.async_payment_succeeded":
      await handleCheckoutSession(event.data.object);
      break;
    case "charge.refunded":
      await markPurchaseRefunded(charge.payment_intent);
      break;
    case "charge.dispute.created":
      await markPurchaseDisputed(dispute.payment_intent);
      break;
  }
} catch (error) {
  // 500 so Stripe retries. Release the claim first, or the retry short-circuits as a duplicate.
  await supabase.from("stripe_webhook_events").delete().eq("id", event.id);
  return NextResponse.json({ error: "Handler failed" }, { status: 500 });
}

Two rules in there are cheap to state and expensive to skip. A bad signature returns 400, never 500, because a 500 makes Stripe retry a forgery. A handler failure releases the claim before returning 500, because otherwise the retry short-circuits as a duplicate and the purchase is lost.

What broke on our own checkout, and how was each fixed?

The path above is the fixed version. The git log of this repository, read 26 September 2026, shows how it got here.

The last commit fixed four defects that had shipped that morning. The first one was the default path, not an edge case: checkout is guest-first by design, so every guest who paid hit it.

The common thread is the same as on the security page: a swallowed error looks like success. The fix that outlasts the others is that the member page now writes nothing and a gate script runs a guest purchase on every deploy. The vibe coding tips page carries the rest of that list.

Which prompts on this site encode these rules?

Four, across three categories. Subscription Checkout Flow and Payment History & Billing Pages sit in the SaaS prompts; Payment Provider Webhook Integration in the API prompts; Pricing Page with Tier Comparison in the landing page prompts. The lines they share, as they appear in the prompt bodies:

## Build Order
Server-side session creation first, then the webhook with signature verification, then the return pages, then the status UI. The webhook is the source of truth; build it before the celebration screen.

## Safe-Guard Instructions
- Verify webhook signatures; reject unsigned payloads
- Make webhook handlers idempotent: Stripe retries, and double-processing a payment event is a money-losing bug
- On Lovable, built-in payments (Paddle or Stripe) need a paid plan and run in test mode in the preview until the app is published; on the free plan connect your own Stripe account. Either way the webhook stays the source of truth
- Never grant entitlements from the success redirect alone; a user can bookmark that URL
- All Stripe calls server-side; the browser never sees the secret key
- Amounts and currency stored as provided, in minor units; no floating-point money anywhere

Every one of those lines is a defect we have either shipped or read about in the CVE record. The Pro variants add the distribution step each payment feature should carry, which is what the bundle sells at $199 USD, one time, through the exact checkout described above.

What do the top results for this term leave out?

• Lovable docs, Connect your own Stripe account. The primary source. Setup, how payments work, limitations, FAQ.
• No Code MBA, Lovable Stripe Tutorial 2026. About 2,100 words, updated 19 May 2026. No webhooks, no live-mode step, no fees, no restricted keys, no screenshots.
• RapidDev, Lovable Stripe Connect. About 4,500 words on Stripe Connect (marketplace payouts), not checkout. States the integration only works on a deployed URL; Lovable's FAQ says the full checkout runs from the preview.

What we did not publish

• A run of the Connect Stripe form on a Lovable test project. It would mean pasting a key from a live Stripe account into a throwaway project, and we decided the screenshot was not worth that.
• Our sales count. The webhook table and the purchases table were both read today; their sizes stay ours.
• A Paddle comparison from experience. We have only ever run Stripe.

Sources

All read on 26 September 2026. Quotes and rates in src/data/lovableStripe.ts.

• Lovable docs: Add payments to your app
• Lovable docs: Connect your own Stripe account
• Stripe: Pricing and fees (United States)
• Stripe docs: Fulfill orders
• No Code MBA: Lovable Stripe Tutorial 2026
• RapidDev: Lovable Stripe Connect integration