How to Send a Stripe Test Webhook in Under 5 Minutes

You've added a webhook endpoint to your Stripe account. Now you need to confirm it actually works before a real customer triggers it for you. Stripe gives you two good ways to fire off test events: the Dashboard UI and the CLI. Both take about a minute to set up.

This guide walks through each approach step by step, then covers what to look for in the test payload and how to fix the most common issues.

What you'll need

Before you start, you'll need a publicly accessible URL that can receive POST requests. If you're running your app locally, you'll need a tunnel or a tool like Payloader's webhook testing tool to give you a public endpoint. If your app is already deployed to a staging server, you can use that URL directly.

Option 1: Send a test webhook from the Stripe Dashboard

This is the quickest way to send a single test event without installing anything.

1. Open the Webhooks page. In your Stripe Dashboard, go to Developers > Webhooks. Make sure you're in test mode (the toggle in the top-right corner).
2. Add your endpoint. If you haven't already, click "Add endpoint" and enter your URL. You can subscribe to all events or just the ones you care about, like payment_intent.succeeded or checkout.session.completed.
3. Send a test webhook. Click on your endpoint, then click "Send test webhook" in the top-right area. Pick the event type you want to test from the dropdown and hit "Send test webhook."
4. Check the response. Stripe shows you the response status code from your endpoint right in the UI. A 200 means your server received it and responded correctly.

That's really it. Stripe fires a synthetic event with realistic (but fake) data to your endpoint. You can repeat this as many times as you need while building out your handler.

Option 2: Send test webhooks with the Stripe CLI

The CLI is better for local development. It creates a tunnel between Stripe and your machine, so you can test webhooks without deploying your code anywhere.

Install the CLI

On macOS with Homebrew:

brew install stripe/stripe-cli/stripe

For other platforms, check Stripe's install docs. There are binaries for Linux, Windows, and Docker.

Log in

stripe login

This opens your browser and asks you to authorize the CLI with your Stripe account. You only need to do this once per machine.

Start listening

stripe listen --forward-to localhost:4242/webhook

Replace localhost:4242/webhook with whatever host and path your app uses. The CLI prints a webhook signing secret when it starts up. Copy that, because you'll need it for signature verification.

Keep this terminal open. It stays connected and forwards events in real time.

Trigger a test event

Open a second terminal and run:

stripe trigger payment_intent.succeeded

The CLI creates a real PaymentIntent in test mode, then fires the corresponding webhook event to your local server through the listener. You'll see the event show up in the first terminal along with your endpoint's response code.

Some other useful triggers:

stripe trigger checkout.session.completed
stripe trigger customer.subscription.created
stripe trigger invoice.payment_failed

You can see the full list of supported triggers with stripe trigger --help.

What to look for in the test payload

Every Stripe webhook event follows the same top-level structure. Here's what matters:

{
  "id": "evt_1234567890",
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_1234567890",
      "amount": 2000,
      "currency": "usd",
      "status": "succeeded"
    }
  },
  "livemode": false
}

• type tells you which event fired. Your handler should switch on this field.
• data.object contains the actual resource (PaymentIntent, Subscription, Invoice, etc.) at the time the event occurred.
• livemode should be false for test webhooks. If your handler checks this field, make sure you're not accidentally rejecting test events.

If you want a clearer view of what Stripe is sending, Payloader's Stripe webhook inspector parses these payloads automatically and translates them into plain-English summaries. Point your test endpoint to hook.payloader.dev, trigger some events, and you'll see exactly what arrived, which fields changed, and whether the payload structure matches what you expect. It's useful when you're building a handler for an event type you haven't worked with before.

Common issues and fixes

Endpoint not receiving events

First, check whether your URL is actually reachable from the internet. If you're developing locally without the Stripe CLI, Stripe can't reach localhost. You need a tunnel or a public URL. Also confirm you don't have a firewall or security group blocking incoming POST requests.

Getting the wrong event types

When you add an endpoint in the Dashboard, you choose which events to subscribe to. If you're only listening for payment_intent.succeeded but triggering checkout.session.completed, you won't see anything. Check your endpoint's event filter.

Test mode vs. live mode

Stripe keeps test and live webhooks completely separate. An endpoint registered in test mode won't receive live events, and vice versa. Make sure you're triggering test events from test mode (check that the Dashboard toggle says "Test mode" and your API keys start with sk_test_).

Signature verification failing

If you're using the CLI, the signing secret is different from the one in your Dashboard. The CLI prints its own whsec_ secret when you run stripe listen. Use that one for local development, and the Dashboard secret for your deployed endpoint. See our full guide on Stripe webhook signature verification for more detail.

What's next

Once your test webhooks are flowing, there are a couple of things worth doing before you go to production. Set up proper signature verification so you know every incoming event is actually from Stripe. Write handler logic that's idempotent, because Stripe will retry failed deliveries and you might process the same event twice.

For a broader look at webhook testing beyond just Stripe, our general webhook testing guide covers strategies that work across any provider.