Stripe Test Webhook: Test Payments Locally With the CLI

The fastest way to run a stripe test webhook is the Stripe CLI. You log in, run stripe listen to forward events from your Stripe test mode to a local URL, then run stripe trigger to fire sample events. Your app receives real signed requests without any deploy.

This matters most for apps built with AI tools such as Lovable, Bolt or Base44, where the payment path often looks fine in a demo but has never faced a failed card, a retry or a duplicate event. I am a Brazilian engineer, and this is the routine I use before any real money flows through an app.

How do I send a test webhook in Stripe?

You have three options, and they test different things.

• Stripe CLI: best for local development. It forwards events to localhost and lets you trigger them from the terminal.
• Dashboard event destinations: in test mode you can point Stripe at a public URL and send a test event from the dashboard. Useful for a staging deployment.
• Real test-mode actions: completing a Checkout with a test card produces the exact event sequence your app will see in production.

For daily work I combine the first and third. The CLI gives fast feedback, and a real test checkout confirms the whole chain: your frontend, your server, Stripe and back to your database.

How do I use stripe listen to forward events to localhost?

Install the Stripe CLI, then authenticate with stripe login. It opens a browser to link the CLI to your account. Make sure you are working in test mode.

Start your app locally, then run:

1. stripe listen –forward-to localhost:3000/api/stripe/webhook (use your own port and path).
2. Copy the signing secret the CLI prints. It starts with whsec_.
3. Put that value in your local environment variable for the webhook secret.
4. Restart your app so it reads the new value.

The most common mistake I see is using the dashboard endpoint secret locally. The CLI session has its own secret, so signature verification fails with a confusing error. If your handler returns 400 on every event, check this first.

Also confirm your handler verifies the signature against the raw request body. Frameworks that parse JSON before your code sees it will break verification. That is a code issue, not a Stripe issue.

How do I trigger specific events with the Stripe CLI?

With the listener running, open a second terminal and run stripe trigger followed by an event name. Common ones for a payment app:

• checkout.session.completed
• payment_intent.succeeded
• payment_intent.payment_failed
• invoice.paid and invoice.payment_failed
• customer.subscription.deleted

Watch the listener output. Each line shows the event and the HTTP status your endpoint returned. You want 200 for handled events, and you want to see your own logs and database changes too.

One caveat: triggered events use generated fixture data. They will not contain your customer ID, your order ID or your metadata. So a trigger proves your endpoint receives and verifies events, but it may not prove your order logic works. For that, run a real test checkout with card number 4242 4242 4242 4242 and let the CLI forward the resulting events.

Which failure cases should I test before launch?

AI-built apps usually handle the success case. The failures are where money and data get lost. Here is the list I run through.

The key rule: your app should grant access or mark an order paid only after a verified webhook confirms payment, not because the browser landed on a success page. Anyone can open a success URL manually. A generic security scanner will not catch this, because it is business logic, not a known vulnerability pattern.

Also check that errors return a non-2xx status. If your handler swallows an exception and returns 200, Stripe believes the event was handled and will not retry, and you silently lose the payment record.

How do I test duplicate and out-of-order events?

Stripe can deliver the same event more than once, and it does not guarantee order. Your handler must survive both.

Duplicates

Use stripe events resend with an event ID from your test dashboard to deliver the same event again. Your app should not create a second order, send a second email or extend a subscription twice. The usual fix is to store processed event IDs in a table with a unique constraint and skip any you have seen. Better still, make the underlying update idempotent, for example setting an order status to paid rather than incrementing a counter.

Out of order

You might receive invoice.paid before checkout.session.completed, or a subscription update before the record exists. Test by resending events in a different order, or by temporarily deleting the related row and replaying. A robust handler either fetches the current object from the Stripe API or fails with a 500 so Stripe retries later.

Concurrency

If two copies arrive at nearly the same moment, a check-then-insert pattern can still create duplicates. The unique constraint in the database is what actually protects you, so rely on it rather than on application code alone.

How do I test after moving off the builder?

Code built in Lovable can be moved to GitHub and to your own hosting. When you do that, the webhook setup changes, and this is a common place for payments to break quietly.

1. Register a new endpoint in Stripe for the new public URL, in test mode first.
2. Use the new endpoint secret in the new host’s environment variables. Do not reuse the CLI secret or an old one.
3. Check the server location. If webhooks used to run in a builder-managed function, confirm the same logic now exists in your own backend.
4. Run a full test checkout against the deployed staging URL and confirm the database row changes.
5. Repeat in live mode with a small real payment you refund afterward, once everything passes.

Remove the old endpoint in Stripe when you are done so events are not sent to two places. Staying on the builder is sometimes the better call, especially for a simple app with little traffic. But if you move, treat the webhook as the first thing to retest, because the app owner is responsible for payment confirmation even when the platform runs the infrastructure.

Fix the existing code before considering a rewrite. When I review a payment path, I start by looking for targeted fixes in the existing code before anything bigger.

Want a second pair of eyes?

If you want a second opinion on your webhook handler or payment flow, email me@filipeeduardo.dev with a description of your setup and I will tell you what I would check first.