Real payments in an AI-built app: Stripe, webhooks and idempotency

Published on 2026-10-27 by frfrand

How to complete payments for a Lovable app or vibe coding: server confirmation, signed webhooks, reservations, and secure retries.

Real payments in an AI-built app: Stripe, webhooks and idempotency

The 'Pay' button is the easy part

A demo can show an animation and change the status to 'paid'. With real customers that does not prove the charge occurred. You must confirm the operation in the backend against the payment provider and save a consistent state in your database. The success URL the user sees is not a reliable confirmation source.

Why webhooks change the design

Providers can send repeated events and, depending on the case, in a different order than expected. Verify the webhook signature, keep a unique identifier, and handle the operation idempotently: if the event arrives twice, do not create two orders or charge two reservations. Private keys from Stripe, SumUp, or another provider never go inside the AI-generated frontend.

Example: tour tickets

The customer buys two tickets but closes the browser before returning to the confirmation page. The payment completes and the webhook arrives twice. The backend must record a confirmed charge, assign the slot only once, and send a confirmation. If no slots are available, start a review or refund according to business policy, without inventing a success. Test that flow in sandbox before publishing.

Responsible implementation

1. Define states: pending, confirmed, failed, refunded, and canceled. 2. Create payments from the server with protected keys. 3. Verify signature and origin of each webhook according to the provider. 4. Register unique IDs to avoid duplicate operations. 5. Validate availability in the database using transactions. 6. Test expiration, failures, retries, and revenue reconciliation.

Not every provider works the same

Stripe, SumUp, and others have their own events, APIs, and rules. The general idea of confirmation and idempotency remains, but implementation depends on official documentation and region. Also, do not confuse processing card data on your server with delegating payment to a gateway: they are different obligations.

Frequently asked questions

### Does the thank-you page confirm the charge? No. Verify the payment via backend or authenticated event. ### What is idempotency? That a repeated same request does not have unexpected duplicate effects. ### Where do private keys go? In server configuration, not in browser JavaScript. ### What do I do if the email failed but the payment was successful? Keep the order and retry notification, without charging again.

Sources

Stripe Webhooks · OWASP.

What about ArduMaker?

This work fits the idea of a service that reviews AI-generated code, implements what is necessary, and takes it to operable infrastructure. The future page ardumaker.com/lovable will present this migration and deployment modality. The page does not exist yet, so it should not be announced as an automatic service already available. For products that exist today you can visit ardumaker.com. The actual scope is determined with an audit: permissions, data, integrations, and maintenance.

Editorial review: October 2026. Official references prevail over generic examples; make a backup and staging tests before any intervention in production.

What the photograph shows

Development team validating confirmation and payment flows. Illustrative photograph generated for this article about taking code created with AI to a production application; it is not an official capture of the tool nor does it demonstrate a specific implementation.