DEV Community: Pavel

Testing Stripe Webhooks Locally Without Deploying Your App

Pavel — Mon, 26 Jan 2026 13:16:15 +0000

At some point, every Stripe integration hits the same wall.

You add webhook handling, everything works in theory — and then you realize that Stripe requires a public HTTPS endpoint.

Your backend is running locally. Behind NAT. Probably behind a firewall.

Suddenly, every small change turns into:
deploy → wait → trigger event → read logs → repeat.

I wanted to keep my backend local, receive real Stripe events, and avoid turning webhook development into a deployment ritual.

This article shows how I do that.

The problem with local Stripe development

Stripe webhooks have a few non-negotiable requirements:

public URL
HTTPS
stable endpoint
real event delivery (with signatures)

That makes sense for production.

It’s much less convenient during development.

In practice, this often leads to:

pushing half-baked code just to test a webhook
debugging logic in staging instead of locally
slowing down iteration for no good reason

A real use case: `payment_intent.succeeded`

Let’s use a concrete example.

A typical flow looks like this:

Customer completes a payment
Stripe emits payment_intent.succeeded
Backend:
- verifies the webhook signature
- updates internal state
- triggers business logic

This logic is often:

stateful
timing-sensitive
annoying to debug without real events

Mocks help, but they don’t fully replace real Stripe payloads.

A minimal NestJS webhook handler

Here’s a stripped-down NestJS example that handles a Stripe webhook properly.

Stripe requires access to the raw request body, so this matters.

@Post('webhooks/stripe')
async handleStripeWebhook(
  @Req() req: Request,
  @Headers('stripe-signature') signature: string,
) {
  const payload = req.rawBody;

  const event = this.stripe.webhooks.constructEvent(
    payload,
    signature,
    this.configService.get('STRIPE_WEBHOOK_SECRET'),
  );

  if (event.type === 'payment_intent.succeeded') {
    // handle successful payment
  }

  return { received: true };
}

At this point, everything works — except Stripe can’t reach your machine.

Why localhost is not enough

Stripe sends webhooks from their servers.

Your local server:

lives behind NAT
has no public IP
often can’t accept inbound connections at all

Port forwarding might work at home, but:

it’s not always possible
it’s rarely acceptable on corporate networks
it’s not something you want to rely on daily

Common workarounds (and why they fall short)

Deploying to staging

Works, but:

slow feedback loop
noisy logs
unnecessary infrastructure work

`stripe listen`

Stripe provides an official CLI command:

stripe listen --forward-to localhost:3000/webhooks/stripe

It’s useful, but:

it does not use a real public HTTPS endpoint
it relies on an outbound tunnel initiated by the CLI
it doesn’t reflect how webhooks behave in production
it doesn’t help with other services that require HTTPS callbacks

Good for quick tests, not great for realistic debugging.

ngrok

Also works, but:

URLs change
requires extra setup
can be blocked or restricted in some regions or networks

What we actually want

For local webhook development, the requirements are simple:

real HTTPS endpoint
stable public URL
no DNS configuration
no certificate management
no redeploys
backend keeps running locally

In other words:
Stripe should think it’s talking to a production server — while everything stays local.

Exposing a local NestJS server via HTTPS

The approach is straightforward:

Run your NestJS app locally
Expose it through a secure HTTPS tunnel
Forward requests to localhost

With a tunnel service, this can be done in one command:

npx start-pnode --port 3000

This gives you:

a public HTTPS URL
automatic TLS
stable endpoint
traffic forwarded to your local server

Your application code doesn’t change.

Connecting Stripe to the local endpoint

Now the fun part.

Open the Stripe Dashboard
Go to Developers → Webhooks
Add a new endpoint
Paste your public HTTPS URL:

   https://your-subdomain.pnode.site/webhooks/stripe

Select events (e.g. payment_intent.succeeded)
Copy the signing secret

That’s it. Stripe is now talking directly to your local machine.

End-to-end test

Trigger a test event from the Stripe dashboard.

On your local machine, you’ll see:

a real HTTPS request
a real Stripe payload
a valid signature
your NestJS handler executing normally

No staging environment.
No redeploy.
No guessing.

This is the point where webhook development stops being painful.

Security notes

A few important reminders:

Always verify the webhook signature
Don’t rely on IP allowlists alone
Treat exposed endpoints as temporary
Don’t use this setup as-is for production traffic

This approach is about local development speed, not replacing production infrastructure.

When this approach works best

Webhook-heavy backends
Early-stage products
Rapid iteration on payment logic
Debugging real Stripe edge cases locally

If your workflow involves frequent webhook changes, keeping everything local is a big win.

Closing thoughts

Stripe webhooks don’t require you to deploy on every change — they just require HTTPS.

Once you remove the friction around that, local development becomes fast again.

And debugging payments where your code actually runs turns out to be much more pleasant.

Stripe documentation
PNode documentation

Forget Router Configs and VPNs: How to Show a Local Site to a Client in 5 Minutes

Pavel — Sun, 05 Oct 2025 09:31:05 +0000

Forget Router Configs and VPNs: How to Show a Local Site to a Client in 5 Minutes

Familiar situation?

You’ve been developing a web application locally for weeks.
Demo time comes - and suddenly you hit a wall:

How do you quickly and safely show a localhost app to someone outside your network?

The usual options are rarely pleasant:

“Just connect to my VPN” - essentially inviting someone into your private network.
“I’ll forward a port on my router” - 40 minutes lost to NAT, firewalls, and ISP quirks.
“Let me spin up a VPS real quick” - extra cost, deployment time, and configuration overhead.

And if your ISP doesn’t provide a static IP address, the situation gets even worse.

For a long time, I used tools like ngrok or localtunnel.
They helped, but speed, stability, and availability were inconsistent.

In this article, I want to show how PNode solves this problem with a much simpler model:
a secure public URL that forwards traffic directly to your local service - no network setup, no servers, no certificates.

Let’s walk through a real-world example.

The Scenario

You’re a freelancer.
A client asks to see a working prototype right now.

The app already runs locally. You just need to expose it to the Internet.

Option 1: Instant Demo with Anonymous Mode

PNode supports an Anonymous mode that requires no registration.

You don’t create an account, don’t generate tokens, don’t configure anything.

You simply run:

npx start-pnode@latest --port 3000

That’s it.

PNode will assign a temporary public domain in the form:

tmp-xxxxx.pnode.site

What you get

A public HTTPS URL
Traffic forwarded to your local port
No credentials, no setup
The domain is valid for 12 hours
After expiration, a new temporary domain is issued automatically

This mode is ideal for:

quick client demos
webhook testing
temporary previews

The only limitation is that anonymous mode does not support frontend / backend separation.

Option 2: Fixed Domain with Authorized Mode

If you need a stable URL or more control, PNode offers Authorized mode.

Step 1: Create an Account and Project

Go to pnode.site and sign up.

After logging in, create a project.
Each project corresponds to one fixed public domain, for example:

pahatrop.pnode.site

The project page gives you a single credential:

AGENT_TOKEN

This token uniquely identifies your project.

Step 2: Prepare a Local Application

In my case, I’m running a simple NestJS API locally:

npx nest new my-demo-server
cd my-demo-server
npm run start

The server listens on:

http://localhost:3000

At this point, it’s still completely inaccessible from the outside.

Step 3: Run the Agent

Set the environment variables (on Windows, use set instead of export):

export AGENT_TOKEN=your-agent-token
export LOCAL_PORT=3000

Then start the agent:

npx start-pnode@latest

Alternatively, you can pass everything via CLI flags:

npx start-pnode@latest --token your-agent-token --port 3000

Done

Once the agent connects, your local service becomes publicly accessible.

You send the link:

pahatrop.pnode.site

The client opens it and immediately sees the application running on your machine.

You can keep coding, refreshing, and changing things in real time - no redeployments required.

Frontend and Backend Separation (Authorized Mode)

Authorized projects can optionally enable domain separation:

pahatrop.pnode.site - static frontend
api-pahatrop.pnode.site - backend proxied to your local server

Frontend builds can be uploaded as a ZIP archive or deployed from a connected Git repository.

This setup works well for SPA + API projects where the backend is still under active development.

Why PNode?

Fast setup - from zero to public URL in minutes
No network configuration - no NAT, no firewall rules
Secure by default - encrypted traffic between agent and PNode
No static IP required
Two clear modes - anonymous for speed, authorized for stability

PNode is not just another tunneling tool.
It solves a very practical problem: sharing local work quickly and professionally, without infrastructure overhead.

If you regularly demo prototypes, test integrations, or expose local services, this tool fits naturally into that workflow.

What tools do you use to expose local services?
Feel free to share your experience in the comments.

DEV Community: Pavel

Testing Stripe Webhooks Locally Without Deploying Your App

The problem with local Stripe development

A real use case: payment_intent.succeeded

A minimal NestJS webhook handler

Why localhost is not enough

Common workarounds (and why they fall short)

Deploying to staging

stripe listen

ngrok

What we actually want

Exposing a local NestJS server via HTTPS

Connecting Stripe to the local endpoint

End-to-end test

Security notes

When this approach works best

Closing thoughts

Forget Router Configs and VPNs: How to Show a Local Site to a Client in 5 Minutes

Forget Router Configs and VPNs: How to Show a Local Site to a Client in 5 Minutes

The Scenario

Option 1: Instant Demo with Anonymous Mode

What you get

Option 2: Fixed Domain with Authorized Mode

Step 1: Create an Account and Project

Step 2: Prepare a Local Application

Step 3: Run the Agent

Done

Frontend and Backend Separation (Authorized Mode)

Why PNode?

A real use case: `payment_intent.succeeded`

`stripe listen`