DEV Community: Kaibalya Kar

Debugging Stripe Webhooks in Node.js: The “Payload Must Be a String or Buffer” Error

Kaibalya Kar — Fri, 22 Aug 2025 09:08:40 +0000

When integrating Stripe into a Node.js application, webhooks play a critical role in handling real-time events like payments, subscriptions, and invoices. However, I recently ran into a tricky issue while verifying Stripe webhooks in my backend. The error looked something like this:

❌ Webhook signature verification failed: Webhook payload must be provided as a string or a Buffer instance representing the _raw_ request body. Payload was provided as a parsed JavaScript object instead.

At first glance, it seemed like a simple mismatch, but the root cause was a little deeper. Here’s how I solved it step by step.

The Problem

Stripe verifies webhooks by checking a signature against the raw request body. However, most Express apps use body parsers (express.json() or body-parser) which automatically parse the incoming JSON request into a JavaScript object.

This means that by the time the request reaches Stripe’s constructEvent method, the raw body is no longer available, leading to the above error.

The Fix

The fix is to tell Express not to parse the body for Stripe webhook routes. Instead, we need the raw body as a Buffer.

Here’s the corrected setup:

import express from "express";
import Stripe from "stripe";
import bodyParser from "body-parser";

const app = express();
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY_TEST);

// ✅ Use raw body only for the webhook endpoint
app.post(
  "/webhook",
  bodyParser.raw({ type: "application/json" }),
  (req, res) => {
    const sig = req.headers["stripe-signature"];
    let event;

    try {
      event = stripe.webhooks.constructEvent(
        req.body, // raw body (Buffer)
        sig,
        process.env.STRIPE_WEBHOOK_SECRET
      );
      console.log("✅ Webhook verified:", event.type);
    } catch (err) {
      console.error("❌ Webhook signature verification failed:", err.message);
      return res.sendStatus(400);
    }

    // Handle event
    if (event.type === "payment_intent.succeeded") {
      console.log("💰 Payment received!");
    }

    res.json({ received: true });
  }
);

// Normal JSON parsing for other routes
app.use(express.json());

app.listen(5000, () => console.log("Server running on port 5000"));

Key Takeaways

Don’t parse Stripe webhook requests with express.json() or body-- parser.json().
Use bodyParser.raw({ type: "application/json" }) for the webhook route.
Always test your webhook integration using the Stripe CLI:

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

If you see this error, it almost always means the body was already parsed into an object before reaching Stripe’s verifier.

Conclusion

Debugging this issue was a great reminder that not all requests should be parsed the same way. Stripe needs the original, untouched request body to verify signatures properly. Once I separated the raw body parsing logic only for the webhook endpoint, everything worked flawlessly.

If you’re integrating Stripe into your Node.js backend and run into this error, just remember: webhooks need raw body, not JSON!

🚀 How to Install Chromium for Puppeteer on AWS (EC2 or Lambda)

Kaibalya Kar — Mon, 21 Jul 2025 20:43:04 +0000

🧠 Why This Happens

AWS environments (like Amazon Linux 2 on EC2 or Lambda) don’t come with Chromium installed by default. Also, the headless version Puppeteer tries to download is often incompatible with AWS's OS.

To make Puppeteer work, you need:

A compatible headless Chromium binary.
Proper dependencies installed (fonts, sandbox libs, etc.).
The right launch options.

🧠 Why This Happens

AWS environments (like Amazon Linux 2 on EC2 or Lambda) don’t come with Chromium installed by default. Also, the headless version Puppeteer tries to download is often incompatible with AWS's OS.

To make Puppeteer work, you need:

A compatible headless Chromium binary.
Proper dependencies installed (fonts, sandbox libs, etc.).
The right launch options.

sudo yum update -y

# Install missing libraries
sudo yum install -y \
  atk.x86_64 \
  cups-libs.x86_64 \
  gtk3.x86_64 \
  libXcomposite.x86_64 \
  libXcursor.x86_64 \
  libXdamage.x86_64 \
  libXext.x86_64 \
  libXi.x86_64 \
  libXrandr.x86_64 \
  libXss.x86_64 \
  libXtst.x86_64 \
  pango.x86_64 \
  alsa-lib.x86_64 \
  ipa-gothic-fonts \
  xorg-x11-fonts-100dpi \
  xorg-x11-fonts-75dpi \
  xorg-x11-utils \
  xorg-x11-fonts-cyrillic \
  xorg-x11-fonts-Type1 \
  xorg-x11-fonts-misc \
  wget

✅ Step 2: Download a Compatible Chromium Binary

cd ~
mkdir chromium && cd chromium

wget https://github.com/Sparticuz/chromium/releases/download/v123.0.0/chromium.br
# OR another known working build for Amazon Linux

# Decompress
brew install brotli # if needed
brotli --decompress chromium.br
chmod +x chromium

✅ Step 3: Point Puppeteer to This Chromium

Now in your Node.js code:

import puppeteer from 'puppeteer-core';

const browser = await puppeteer.launch({
  executablePath: '/home/ec2-user/chromium/chromium',
  headless: true,
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
  ],
});

☁️ Bonus: Using Puppeteer with Chromium in AWS Lambda?

Use chrome-aws-lambda:

npm install puppeteer-core chrome-aws-lambda

Then:

import chromium from 'chrome-aws-lambda';
import puppeteer from 'puppeteer-core';

export const handler = async () => {
  const browser = await puppeteer.launch({
    args: chromium.args,
    defaultViewport: chromium.defaultViewport,
    executablePath: await chromium.executablePath,
    headless: chromium.headless,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  const screenshot = await page.screenshot();

  await browser.close();

  return screenshot;
};

🧪 Test It

After setup:

node yourScript.js

✅ If all goes well, Chromium should launch and Puppeteer will work as expected!

✅ Summary

Task Done

Install system dependencies ✅
Download compatible Chromium ✅
Launch Puppeteer with custom binary ✅

Running Puppeteer on AWS isn’t plug and play and but once Chromium is correctly installed and referenced, everything runs smoothly.

Debugging Stripe Webhook Signature Verification Errors in Production

Kaibalya Kar — Sun, 01 Jun 2025 13:28:51 +0000

If you're integrating Stripe in a Node.js backend, you're likely using webhooks to handle events like checkout.session.completed. One of the common pitfalls during deployment is related to webhook signature verification failures, and recently, I ran into exactly this issue.

In this post, I’ll walk through the problem I faced, how I fixed it, and what best practices you can follow to avoid the same mistake.

app.post(
  "/api/v1/webhook/stripe",
  express.raw({ type: "application/json" }),
  stripeWebhookHandler
);

// JSON body parser for all other routes
app.use((req, res, next) => {
  if (req.originalUrl === "/api/v1/webhook/stripe") {
    next(); // Skip body parsing for Stripe
  } else {
    express.json()(req, res, next);
  }
});

This is required because Stripe needs access to the raw body to verify the signature using the stripe.webhooks.constructEvent() method.

❌ The Problem

**
After deploying to production, Stripe kept returning this error:

❗ "Webhook signature verification failed. No signatures found matching the expected signature for payload."

I was sure my raw body handling was correct, and the endpoint URL was accurate. Locally, everything worked using the Stripe CLI. But in production… webhook requests kept failing.

🔍 The Root Cause

Turns out the issue was very simple but easy to overlook:
👉 I was using the Test Mode webhook signing secret (whsec_...) in production, while Stripe was sending Live Mode events.

Stripe signs test and live events with different secrets, and if you mismatch them, signature verification will always fail — even if your code is perfect.

✅ The Fix: Environment-Based Configuration
To avoid this, I updated my environment variables and Stripe initialization code to handle different modes based on the environment

🧪 Bonus Tip: Use Stripe CLI for Local Testing

To test webhooks locally with the Stripe CLI:

stripe login
stripe listen --forward-to localhost:5000/api/v1/webhook/stripe
stripe trigger checkout.session.completed

Make sure your local environment uses the test mode secrets to match the CLI’s default behavior.

💡 Final Thoughts
Small mistakes like using the wrong webhook secret can cost you hours of debugging. If you're getting a "Webhook signature verification failed" error, double-check your mode (test/live) and environment configuration.

If this helped you, share it with someone struggling with Stripe setup — and happy coding! ⚡

Deploy Your First Node.js App on AWS EC2 Without NGINX (Beginner Friendly) EC2 without using NGINX —💻🔥🚀

Kaibalya Kar — Sun, 01 Jun 2025 13:23:07 +0000

🧠 Prerequisites

AWS account

Basic Node.js knowledge

Terminal and VS Code installed

GitHub account (for code upload)

## 🪄 Step 1: Create EC2 Instance
Go to AWS EC2 Dashboard → Launch Instance

Choose Ubuntu (20.04 preferred)

Instance type: t2.micro (free tier)

Key pair: Create or download .pem file (e.g., my-webserver-kp.pem)

In Security Group, allow inbound rule for:

SSH (22)

HTTP (80)

Custom TCP (3000)

Launch the instance

🌐 Step 2: Allocate Elastic IP

Go to EC2 → Elastic IP → Allocate

Associate Elastic IP with your instance

✅ This gives your server a permanent IP address

## 🔐 Step 3: Connect to EC2 via SSH (Windows)
Open Git Bash or terminal

Go to .pem file location:
cd /Downloads
Set permission (Linux/macOS only):

chmod 400 my-webserver-kp.pem//your key pair name
Connect to EC2:

ssh -i "my-webserver-kp.pem" ubuntu@

## ⚙️ Step 4: Setup Node.js & Git
Inside EC2 terminal:
sudo apt update
sudo apt install nodejs npm git -y
node -v
npm -v

## 📦 Step 5: Clone Your Project

git clone https://github.com//.git
cd
npm install

🚀 Step 6: Run Your App with PM2

Install PM2:

sudo npm install -g pm2
Run your server:

pm2 start index.js

pm2 reload all

pm2 status

🧪 Step 7: Visit Your App

Open browser and visit:

http://:3000
Congrats 🎉 You’ve got your app live on the internet!

Conclusion
You’ve just deployed a backend server to AWS EC2 without needing Docker, NGINX, or complex CI/CD. It’s raw, simple, and effective — perfect for learning and practice.

Next Steps:

Use NGINX to run on port 80/443 (for domain & SSL)

Add MongoDB with Atlas

Deploy frontend (React/Vite) using S3 or EC2 + NGINX

Deploy Your First Node.js App on AWS EC2 Without NGINX (Beginner Friendly) EC2 without using NGINX —💻🔥🚀

Kaibalya Kar — Fri, 11 Apr 2025 13:32:52 +0000

🧠 Prerequisites

AWS account

Basic Node.js knowledge

Terminal and VS Code installed

GitHub account (for code upload)

🪄 Step 1: Create EC2 Instance

Go to AWS EC2 Dashboard → Launch Instance

Choose Ubuntu (20.04 preferred)

Instance type: t2.micro (free tier)

Key pair: Create or download .pem file (e.g., my-webserver-kp.pem)

In Security Group, allow inbound rule for:

SSH (22)

HTTP (80)

Custom TCP (3000)

Launch the instance

🌐 Step 2: Allocate Elastic IP

Go to EC2 → Elastic IP → Allocate

Associate Elastic IP with your instance

✅ This gives your server a permanent IP address

🔐 Step 3: Connect to EC2 via SSH (Windows)

Open Git Bash or terminal

Go to .pem file location:
cd /Downloads
Set permission (Linux/macOS only):

chmod 400 my-webserver-kp.pem//your key pair name
Connect to EC2:

ssh -i "my-webserver-kp.pem" ubuntu@

Step 4: Setup Node.js & Git

Inside EC2 terminal:
sudo apt update
sudo apt install nodejs npm git -y
node -v
npm -v

📦 Step 5: Clone Your Project

git clone https://github.com//.git
cd
npm install

🚀 Step 6: Run Your App with PM2

Install PM2:

sudo npm install -g pm2
Run your server:

pm2 start index.js

pm2 reload all

pm2 status

🧪 Step 7: Visit Your App

Open browser and visit:

http://:3000
Congrats 🎉 You’ve got your app live on the internet!

Conclusion
You’ve just deployed a backend server to AWS EC2 without needing Docker, NGINX, or complex CI/CD. It’s raw, simple, and effective — perfect for learning and practice.

Next Steps:

Use NGINX to run on port 80/443 (for domain & SSL)

Add MongoDB with Atlas

Deploy frontend (React/Vite) using S3 or EC2 + NGINX

Why Developers Should Use Elastic IP on AWS (And How to Do It)🚀

Kaibalya Kar — Wed, 09 Apr 2025 16:16:35 +0000

What is an Elastic IP?

An Elastic IP (EIP) is a static IPv4 address provided by AWS. Once you allocate it and bind it to your EC2 instance, it remains constant — no matter how many times you stop, reboot, or restart the instance.

✅ Why Should Developers Use Elastic IP?

Your IP Never Changes Without Elastic IP:

You get a new public IP every time your EC2 instance restarts.

You have to update your frontend, Postman, or any API integrations over and over.

With Elastic IP:

Your server gets a permanent public IP. Clean and hassle-free.

⚙️ How to Allocate and Use Elastic IP

Here’s a step-by-step guide:

Go to your EC2 Dashboard.

In the left menu, click Elastic IPs.

Click Allocate Elastic IP address.

Choose “Amazon’s pool of IPv4 addresses”, then click Allocate.

After allocation, select the new IP → click Actions > Associate Elastic IP.

Choose your running EC2 instance and confirm.

That’s it! 🎉 Your EC2 instance now has a fixed public IP.

⚠️ Warning: Unused Elastic IPs Can Cost You!

Elastic IPs are free — but only if they’re in use.

If you allocate an Elastic IP and don’t associate it with a running EC2 instance, AWS will charge you a small hourly fee.

💡 Pro Tip:
When you're done using it:

Go to Elastic IPs

Select it

Click Actions → Release Elastic IP

Elastic IP is a small step that makes a huge difference in dev workflows. It's simple, efficient, and keeps your deployments smooth.

Solving the "Could Not Determine Executable to Run" Error When Initializing Tailwind CSS

Kaibalya Kar — Tue, 25 Mar 2025 12:00:28 +0000

If you've recently tried setting up Tailwind CSS in your project using npx tailwindcss init -p and encountered the frustrating "could not determine executable to run" error, you're not alone. This common issue stems from recent changes in Tailwind CSS v4, and I'll walk you through exactly how to resolve it.

Understanding the Problem

**
When you run: npx tailwindcss init -p

You might see: npm ERR! could not determine executable to run

This occurs because:

Tailwind CSS v4 removed the init command from its CLI

The default installation now grabs v4, which doesn't support the traditional initialization

The executable path isn't being properly resolved

The Solution: Use Tailwind CSS v3 (Recommended for Most Projects)
If you want to keep using the familiar initialization command:

Install specific v3 versions

npm install -D tailwindcss@3 postcss autoprefixer

Initialize configuration

npx tailwindcss init -p

Maintain compatibility with existing setups

ThankYou 😉✌️

How to Fix "Failed to Load PDF Document" Error on Cloudinary or

Kaibalya Kar — Sat, 01 Feb 2025 18:26:20 +0000

How to Resolve "PDF Files Can’t Be Shared Externally" in Cloudinary

If you’re using Cloudinary to upload and share PDF files, you may have run into the annoying error: "PDF files can’t be shared externally." This can be particularly frustrating when you’ve uploaded a PDF and expect to share it publicly, but Cloudinary blocks access by default.

In this post, I’ll walk you through why this happens and how to resolve it step-by-step, so you can successfully share PDF files externally without any hiccups.

Why Does This Happen?

Cloudinary, by default, restricts the delivery of certain file types (like PDFs and ZIP files) for security reasons. This means even if you upload a PDF and get a URL, it won’t be accessible unless you explicitly allow PDF file delivery in your Cloudinary settings. Additionally, the file must be marked as public for it to be accessible via its URL.

Let’s dive into the solution.

Step-by-Step Solution

1. Enable PDF File Delivery in Cloudinary

First, let’s make sure that Cloudinary is set to allow PDF file delivery:

Log in to Cloudinary

Go to Cloudinary and log in to your account.
Go to Security Settings

Click on the Settings icon (gear icon) located at the top-right corner of the Cloudinary dashboard.
Scroll to the Security Section

Scroll down until you find the Security section.
Allow PDF and ZIP File Delivery

Look for the option labeled PDF and ZIP files delivery. Toggle the switch to Allow delivery of PDF and ZIP files.
Click Save

After enabling the setting, be sure to click Save to apply the changes.

This will allow Cloudinary to serve PDF files from URLs.

2. Ensure the File is Public

Even after enabling PDF delivery, your file needs to be marked as public to be accessible.

Check the File in Cloudinary Dashboard

Go to the Media Library in your Cloudinary dashboard.
Find the PDF file you uploaded (e.g., resumes/nxx0wzdvdsonnuxgenif.pdf).
Ensure the File is Public

Confirm that the file is set to Public. If it’s not, you won’t be able to access it through its URL.

Update the Access Mode During Upload

If you’re uploading the file programmatically, you need to ensure that it’s set as public. For example, when uploading a file via JavaScript, add the access_mode: "public" parameter:


javascript
const cloudResponse = await cloudinary.uploader.upload(fileUri.content, {
  resource_type: "raw", // Treat PDF as a raw file
  access_mode: "public", // Make the file publicly accessible
  folder: "resumes",
});

#### **Conclusion**
The "PDF files can’t be shared externally" error on Cloudinary is a common but easily solvable issue. By enabling PDF file delivery in your Cloudinary settings and ensuring your files are marked as public, you can quickly resolve this problem. If you’re still facing issues, double-check your frontend code and consider using an embedded PDF viewer.

I hope this guide saves you the two days I spent debugging this issue. Happy coding! 🚀