lovable-stripe-billinglisted

# Stripe billing in a Lovable app Payments are the part of an app where a silent bug costs real money and looks perfectly correct on screen. Most of what follows exists because something failed quietly first. ## The rule that matters most **A successful charge and a delivered entitlement are two separate events, and the gap between them is where money disappears.** Stripe charges the card. Something in your app then has to grant the hours, extend the subscription or unlock the feature. If that second step fails, the customer has paid and has nothing, and **nobody finds out until they complain**. So: never treat the checkout return page as proof of delivery, and never rely on a single mechanism to close the gap. ## The delivery pattern: webhook plus reconcile Use both, keyed on the same idempotency token. 1. **Webhook** on the payment event writes the entitlement. This is the primary path. 2. **A reconcile fallback on the return page.** When the buyer lands back in the app, look up the entitlement by the checkout session id. If it is not there yet, ask Stripe directly whether the session was paid, and if so write the entitlement yourself. Key the write on `stripe_checkout_session_id` with a unique constraint. Then both paths can run and the second one is a no-op. Without that key you have built a double-credit bug. A status lookup by session id is safe to expose publicly: **the session id is the capability token.** Only the buyer knows it, because Stripe substitutes