Stripe payments and webhooks in AI-built apps
A “payment successful” redirect improves the experience, but it is not accounting evidence: orders change only after a verified authoritative event.
The essential Stripe architecture for an AI-built app: server-side checkout, signed webhooks, idempotency, traceable orders and controlled refunds.
Step-by-step procedure
Treat payment as a sequence of states, not as one button. The app prepares an order, Stripe handles payment, the webhook confirms the outcome and the database records what happened.
- 01
Model order states
Define at least draft, pending, paid, failed, refunded and cancelled. Decide which authoritative event allows each transition and which transitions are forbidden.
- 02
Create checkout on the server
The server reads product, price, currency, customer and metadata from trusted data, creates the local order and only then opens the Stripe session.
- 03
Handle the webhook
Verify the signature against the original body, store the event identifier and update order and request idempotently, including retries and out-of-order events.
- 04
Test refunds and reconciliation
Run separate tests for success, abandonment, failure, duplicate events and refunds. Compare local state with Stripe periodically.
Never send passwords, tokens, .env files or private API keys through public forms, chats or screenshots.
The server creates the payment
Price, currency, customer and order metadata must come from backend-controlled data. The browser receives only what it needs to open checkout.
What to check
- Never accept an amount chosen by the client.
- Link sessions and orders with stable identifiers.
- Keep test and live environments separate.
The webhook confirms the outcome
Stripe signs events sent to the backend. Verify the signature against the original body and process each event idempotently so retries cannot create duplicates.
What to check
- Store the event identifier.
- Handle retries and out-of-order events.
- Never trust the browser return alone.
Orders, refunds and reconciliation
Your local state must be comparable with the provider state. Confirmations, refunds and failures need an access-controlled, readable history.
What to check
- Keep a status timeline.
- Protect administrative actions.
- Define a reconciliation procedure.
How to decide the next step
The flow is reliable when the browser cannot decide amounts or states, every event can be repeated without duplicates and orders, refunds and failures can be reconstructed days later.
Do you have an app that stops at the demo stage?
Describe what works, what is missing and the outcome you need. The request is reviewed personally by Giambattista.