Can you safely accept payments in a vibe-coded app?

The direct answer: yes, a vibe-coded app can take payments safely—but only when a reputable payment provider handles card details and your own app verifies payment, fulfils orders once, and makes failures visible. A checkout screen that looks finished is not enough.

Let the payment provider handle card data

Do not build your own card form, store card numbers, or ask an AI assistant to “just add payments” without choosing a recognised provider. A service such as Stripe provides hosted or embedded checkout designed to handle card data. Your job is smaller but still important: create the payment session on the server, keep secret keys private, and decide what happens after the provider confirms payment.

You do not need to become a payments engineer. You do need to trace the real journey from a customer clicking Buy to them receiving the thing they paid for.

Why the thank-you page is not proof of payment

A customer can reach a browser success page and lose their connection before your app records the order. Someone can also type a success-page URL directly. The trusted confirmation comes from the payment provider sending a server-to-server event, usually called a webhook.

Your server should check the webhook signature. That proves the event came from the provider rather than a random request from the internet. Only after a verified event says payment succeeded should your app issue access, create a download link, send an order email or mark an order as paid.

The payment checks that matter before launch

1. Keep both types of key in the right place

A publishable key may be used in the browser where the provider expects it. A secret key must never reach browser JavaScript, screenshots, GitHub or a public prompt. Keep it in your host's protected environment settings. If you are unsure whether a value is secret, treat it as secret. If one leaked, rotate it with the provider; deleting the old line is not enough.

2. Create the checkout session on the server

The server should decide the price, currency, product and customer reference. Do not trust a price sent by the browser: people can alter browser requests. Use a server-side product or price identifier from the payment provider, then attach your own order reference as metadata if you need to match the event back to a customer.

3. Verify and record the webhook event

Check the provider's signature using the webhook secret. Record a stable event ID or payment ID before fulfilment. Providers can retry an event, and network interruptions happen. Your system must be able to see “we have already processed this exact payment” and stop there.

4. Make fulfilment safe to repeat

Idempotent is a useful word for a simple idea: doing the same thing twice should have the same result as doing it once. If the provider delivers the same success event twice, do not email two licences, create two bookings or ship two products. Store the completed order state, then perform the one-time action only when it has not already happened.

5. Decide what happens when fulfilment fails

Payment can succeed while your email provider, database or file-delivery service is temporarily down. Do not silently lose the order. Record the paid order first, show an honest confirmation, alert yourself to the failed next step and make delivery safe to retry. A manual recovery route is far better than discovering a customer paid and received nothing.

6. Test unsuccessful and awkward paths

Use test mode to try a declined card, cancellation, a browser refresh during checkout and duplicate webhook delivery. Then, before a public launch, make a small genuine purchase where practical and trace the whole path. Confirm the money appears in the provider dashboard, the server records it, fulfilment happens once and the customer gets the right receipt or access.

Refunds, chargebacks and support

Put a plain refund policy where customers can find it before purchase. Know which account can issue a refund and who will answer support messages. A chargeback can happen when a person does not recognise the charge, cannot get help or never receives what they bought. Keep clear order records and make the description match the actual delivery.

For subscriptions, cancelled, failed and renewed payments all need verified provider events and clear access rules. If you are launching your first digital product, a one-off payment is often easier to understand and test.

A five-minute founder check

Ask these questions and do not accept “probably” as an answer:

• Which provider takes the payment, and do they handle card details?
• Where is the server-side price defined?
• What verified event proves payment succeeded?
• What stops the same order being fulfilled twice?
• How would we notice and recover a paid order whose email or delivery failed?

If any answer is missing, it is a launch task. It does not mean the product is doomed; it means you found the part to fix before asking customers to trust you with money.

How Ship Doctor helps

KHDS Ship Doctor gives vibe coders an evidence-led way to examine an actual project inside their coding workspace. The free builder makes a starter instruction. The £49 one-off toolkit adds reusable workflows for payments, webhooks, fulfilment, secrets and recovery, with evidence templates and a remediation plan. See a real redacted payment and delivery review in the public Ship Doctor sample report. For the wider launch picture, read the vibe coding security checklist and the guide on production readiness.

Frequently asked questions

Can I safely accept payments in an AI-built app?

Yes, when a reputable provider handles card data and your app verifies payment on the server before fulfilling the order.

Should I put payment secret keys in my app?

No. Keep them in protected server-side settings. Rotate any key that is exposed.

Why do webhooks matter?

They give your server a provider-verified payment confirmation and can be safely retried if you handle duplicate events correctly.

What should I test before charging customers?

Test checkout, confirmation, fulfilment, failed payments, cancellations and duplicate events from end to end.