DEV Community: pk2502

Verifying Razorpay payments: the order ID you shouldn't trust

pk2502 — Fri, 09 Oct 2026 10:48:45 +0000

Razorpay's checkout flow ends with your server checking a signature. Most tutorials show that check in a few lines, and the check itself is correct. But I recently reviewed a store backend before launch where the check passed and still let one payment mark a different order as paid. The bug wasn't in the cryptography. It was in where one input came from.

How the flow works

Your server creates a Razorpay order for the amount and stores its ID (order_xyz) on your own order.
The browser opens Razorpay Checkout with that order ID.
On success, Checkout hands the browser three values: razorpay_order_id, razorpay_payment_id and razorpay_signature.
The browser sends them to your server, which checks that the signature is HMAC-SHA256(order_id + "|" + payment_id, key_secret).

Only Razorpay and your server know key_secret, so a valid signature proves that Razorpay processed that payment for that Razorpay order.

The bug

The endpoint looked roughly like this:

def verify_payment(request):
    order = Order.objects.get(id=request.data["order_id"], user=request.user)
    rzp_order_id = request.data["razorpay_order_id"]      # from the client
    rzp_payment_id = request.data["razorpay_payment_id"]
    signature = request.data["razorpay_signature"]

    expected = hmac.new(secret, f"{rzp_order_id}|{rzp_payment_id}".encode(),
                        hashlib.sha256).hexdigest()
    if expected != signature:
        return error("Payment verification failed")

    order.payment_status = "paid"
    order.save()

Every Razorpay value is checked, but nothing ties them to this order. The internal order_id and the Razorpay order ID both come from the client, and nothing checks that they belong together.

So a buyer can:

Create a cheap order A and pay ₹99 for it.
Create an expensive order B and close the checkout without paying.
Send A's genuine razorpay_order_id, razorpay_payment_id and razorpay_signature with B's internal order_id.

The signature is genuine, so it verifies, and order B is marked as paid.

The fix

Verify against the Razorpay order ID you stored when you created the order, not one the client sends. Compare in constant time, and make the update idempotent:

import hashlib
import hmac

def verify_payment(request):
    order = Order.objects.select_for_update().get(
        id=request.data["order_id"], user=request.user
    )
    if order.payment_status == "paid":
        return ok(order)  # idempotent: retries and double-clicks are fine

    payment_id = request.data.get("razorpay_payment_id", "")
    signature = request.data.get("razorpay_signature", "")
    expected = hmac.new(
        settings.RAZORPAY_KEY_SECRET.encode(),
        f"{order.razorpay_order_id}|{payment_id}".encode(),  # stored, not sent
        hashlib.sha256,
    ).hexdigest()

    if not order.razorpay_order_id or not hmac.compare_digest(expected, signature):
        return error("Payment verification failed")

    order.payment_status = "paid"
    order.razorpay_payment_id = payment_id
    order.save(update_fields=["payment_status", "razorpay_payment_id"])
    return ok(order)

(Run this inside transaction.atomic() so select_for_update() actually holds the row lock.)

If you use the official SDK, client.utility.verify_payment_signature(...) does the HMAC for you. Just pass it your stored razorpay_order_id.

Don't rely on the browser at all: add the webhook

Even a correct verify endpoint depends on the buyer's browser getting back to your site. People close tabs, networks drop, and phones lock mid-redirect. The money arrives, but the order stays "pending".

Razorpay webhooks fix that. Subscribe to payment.captured (or order.paid) and treat the webhook as the source of truth:

def razorpay_webhook(request):
    body = request.body  # raw bytes, before any JSON parsing
    received = request.headers.get("X-Razorpay-Signature", "")
    expected = hmac.new(settings.RAZORPAY_WEBHOOK_SECRET.encode(), body,
                        hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, received):
        return HttpResponse(status=400)

    event = json.loads(body)
    if event["event"] == "payment.captured":
        payment = event["payload"]["payment"]["entity"]
        Order.objects.filter(
            razorpay_order_id=payment["order_id"], payment_status="pending"
        ).update(payment_status="paid", razorpay_payment_id=payment["id"])
    return HttpResponse(status=200)

Note three things:

The signature is computed over the raw body with the webhook secret, which is a different secret from your API key secret.
The update is keyed by the Razorpay order ID that Razorpay itself sent, and it only moves pending to paid, so duplicate deliveries do nothing.
The browser flow and the webhook can now race safely. Whichever arrives first marks the order paid, and the other is a no-op.

Checklist

[ ] The amount is set on the server when the Razorpay order is created, never taken from the client.
[ ] The stored razorpay_order_id is used for verification, not the one in the request.
[ ] Signatures are compared with hmac.compare_digest.
[ ] Marking an order as paid is idempotent.
[ ] A payment.captured webhook with its own secret is the source of truth.
[ ] There's a reconciliation job for orders stuck in "pending".

Payment bugs rarely come from broken crypto. They come from trusting an input that looked like it was already verified.

Originally published on my site. I'm Paritosh, a lead full-stack engineer; more of my work is at paritosh-dev.vercel.app.

Nearby search with PostGIS and GeoDjango: let the database do the geometry

pk2502 — Fri, 09 Oct 2026 10:48:39 +0000

IceCreamGo connects customers with nearby ice cream trucks. The query behind its main screen is "which active trucks are within a few kilometres of me, nearest first?", and it runs every time someone opens the app or moves the map. Get it wrong and the core feature is slow.

The tempting version

The first version you'd write stores latitude and longitude as two floats, loads every active truck, and computes Haversine distance in Python:

trucks = [t for t in Truck.objects.filter(status="ACTIVE")
          if haversine(user_lat, user_lng, t.lat, t.lng) <= radius_km]

It works with twenty trucks. But it reads every row on every request, the cost grows with the fleet rather than with the answer, and pagination is wrong because filtering happens after the database has already returned the rows.

The database can do this itself, with an index.

Make location a real spatial column

With PostGIS and GeoDjango, a location is a PointField:

from django.contrib.gis.db import models

class IceCreamTruck(models.Model):
    status = models.CharField(max_length=10)
    # Denormalized: the latest position, kept on the truck row so the
    # nearby query stays a single indexed lookup.
    current_location = models.PointField(geography=True, null=True)

class TruckLocation(models.Model):
    truck = models.ForeignKey(IceCreamTruck, on_delete=models.CASCADE)
    point = models.PointField(geography=True)
    recorded_at = models.DateTimeField(auto_now_add=True)

Two decisions are worth explaining:

The current position is denormalized onto the truck. The history table is for tracking and replay. The nearby query only ever needs the latest point, and putting it on the truck row avoids a "latest location per truck" subquery on the hottest path.
GeoDjango creates a spatial (GiST) index by default (spatial_index=True). That index is what lets Postgres skip trucks that are nowhere near you.

The query

from django.contrib.gis.db.models.functions import Distance
from django.contrib.gis.geos import Point
from django.contrib.gis.measure import D

def nearby_trucks(lat: float, lng: float, radius_km: float):
    here = Point(lng, lat, srid=4326)  # x = longitude, y = latitude
    return (
        IceCreamTruck.objects
        .filter(status="ACTIVE", current_location__dwithin=(here, D(km=radius_km)))
        .annotate(distance=Distance("current_location", here))
        .order_by("distance")
    )

dwithin uses the index to throw out far-away trucks, Distance computes the exact distance for the ones left, and ordering and pagination happen in SQL. Serialize truck.distance.km and the client gets "1.2 km away" for free.

Three gotchas

1. Point takes longitude first. Point(x, y) means Point(lng, lat). Swap them and every truck in Mumbai appears to be in the Indian Ocean, or the query quietly returns nothing.

2. Geography or geometry decides your units. With a plain geometry column in SRID 4326, distances are in degrees, and Django refuses D(km=…) in a dwithin lookup on it. A degree of longitude is also a different length at different latitudes. geography=True makes PostGIS work in metres on the spheroid, which is what "within 3 km" actually means. For city-scale search, the extra precision cost is negligible.

3. Your test database needs PostGIS too. SQLite won't run these lookups. Run tests against the same postgis/postgis image you deploy with, so the spatial SQL is actually exercised.

Writing locations without melting the database

Reads are only half of it. Drivers report their position while they're on a route:

The app posts a location every few seconds, only while the route is active. There are no GPS calls when the truck is paused or offline.
The backend updates current_location for search, appends a TruckLocation row for history, and publishes to a Django Channels group so customers watching that truck see it move without polling.
A Celery beat task prunes old history rows, so the table doesn't grow forever.

WebSockets are used only for the three things that genuinely need push: truck location, order status and new-order alerts. Menus and order history are plain REST with client-side caching. A menu that changes twice a day doesn't need a socket.

Takeaways

If a query is "near me", store a spatial type and let PostGIS do the work. dwithin plus Distance plus the default GiST index covers most location features.
Use geography=True when users think in kilometres.
Keep the hot path to one indexed lookup. Denormalize the latest position and keep history separate.
Real-time updates are a separate concern. Push them only for the screens that need them.

Originally published on my site. I'm Paritosh, a lead full-stack engineer; more of my work is at paritosh-dev.vercel.app.

SEO for a Vite + React SPA without SSR: prerender the head, not the app

pk2502 — Fri, 09 Oct 2026 10:48:35 +0000

My portfolio is a Vite + React Router single-page app on Vercel. When I audited it for SEO, the problems were the classic ones for a client-rendered app:

Every route shared one <head>. /services, /services/ai-development and /blog all served the same index.html, with the homepage's title, description and a canonical pointing at /. To Google, every page announced itself as a duplicate of the homepage.
Every URL returned 200. The usual SPA rewrite (/(.*) → /index.html) meant /totally-fake was a perfectly healthy page as far as crawlers could tell. That's a soft 404, and an endless supply of them.
Link previews were wrong everywhere. LinkedIn, WhatsApp and Slack don't run JavaScript, so every shared link showed the homepage card.

Three ways out

Move to an SSR framework like Next.js. The right answer for a large site, but a rewrite for a small one.
Prerender the whole app with a headless browser at build time. Works, but it's slow, flaky in CI and adds a browser to your build.
Prerender only the <head>. Google renders JavaScript fine, so the body can stay client-rendered. What crawlers and link previews need first is the title, description, canonical, robots and social tags, and those are just strings.

I went with the third.

One source of truth for metadata

Every route's metadata lives in one module. It has no import.meta.env and uses relative imports only, so both the React app and the Vite config can import it:

export type PageMeta = {
  /** Canonical path. Omit for pages that should not declare one (e.g. 404). */
  path?: string;
  title: string;
  description: string;
  noindex?: boolean;
};

export const staticPages = (): RoutedPageMeta[] => [
  homeMeta,
  servicesMeta,
  ...services.map(serviceMeta),
  ...caseStudies.map(caseStudyMeta),
  blogMeta,
  ...blogPosts.map(blogPostMeta),
];

Routes come from the same data that renders the pages, so a new service or case study gets its own prerendered page and sitemap entry without anyone remembering to add them.

A Vite plugin that writes one HTML file per route

index.html marks the page-specific block:

<!-- seo:start -->
<title>…</title>
<meta name="description" content="…" />
<link rel="canonical" href="…" />
<!-- seo:end -->

After the build, a small plugin swaps that block for each route and writes the files:

closeBundle() {
  const template = fs.readFileSync(path.join(outDir, "index.html"), "utf8");
  const write = (file: string, meta: PageMeta) =>
    fs.writeFileSync(path.join(outDir, file), template.replace(SEO_BLOCK, renderHead(meta)));

  for (const page of staticPages()) {
    write(page.path === "/" ? "index.html" : `${page.path.slice(1)}.html`, page);
  }
  write("404.html", notFoundMeta);
  fs.writeFileSync(path.join(outDir, "sitemap.xml"), sitemapXml());
}

renderHead turns a PageMeta into the title, description, robots, canonical, Open Graph and Twitter tags, plus per-route JSON-LD. Every value is HTML-escaped, and < is escaped inside the JSON so it can never close the script tag early.

Real 404s on Vercel

With a file per route, the catch-all rewrite can go:

{ "cleanUrls": true, "trailingSlash": false }

cleanUrls serves services.html at /services. Anything without a file falls through to 404.html, which Vercel serves with a real 404 status. That page still loads the app, so visitors see a styled not-found page, while crawlers see the status code and a noindex.

Keeping the head right during client-side navigation

The prerendered head covers the first load. After that, React Router navigates without reloading, so a small hook updates the same tags from the same metadata:

export const usePageMeta = (meta: PageMeta) => {
  useEffect(() => {
    document.title = meta.title;
    for (const tag of headTags(meta)) {
      // upsert <meta>/<link> by name, property or rel; remove when undefined
    }
  }, [meta.path, meta.title, meta.description, meta.noindex]);
};

Because the hook and the build plugin share headTags(), they can't drift apart.

Guarding the CSP

The site has one inline script, which applies the saved light or dark theme before first paint to avoid a flash of the wrong theme. A strict Content-Security-Policy only allows it by hash, and a hash goes stale as soon as someone edits the script. So the same plugin hashes every inline script and fails the build if that hash isn't in the CSP in vercel.json. A broken theme toggle becomes a build error instead of a production bug.

Checking it

Every route now answers with its own status and title:

URL	Status	Title
`/services`	200	Services \| Paritosh Khubchandani
`/services/ai-development`	200	AI Development \| …
`/totally-fake`	404	Page not found \| …
`/services/`	308 → `/services`

LinkedIn's Post Inspector picks up the right title and the new 1200×630 preview image.

Trade-offs

The body is still client-rendered. Google indexes it, but crawlers that don't run JavaScript only see the head. For blog posts I also inject the article HTML into the prerendered page, so the text is there without JavaScript.
Routes must be known at build time. That's fine when routes come from data, as they do here. It's not fine for user-generated pages; at that point, use a real SSR framework.
No new dependencies. The whole thing is one metadata module, a hook and a plugin of about forty lines.

For a portfolio, marketing site or docs site built as a SPA, prerendering just the head gets you most of what SSR gives you for SEO, without changing frameworks.

Originally published on my site. I'm Paritosh, a lead full-stack engineer; more of my work is at paritosh-dev.vercel.app.

One Next.js app, every school website: subdomains, custom domains and automatic HTTPS

pk2502 — Fri, 09 Oct 2026 10:48:30 +0000

The GungunERP Website Builder gives every school its own website, which it edits itself. The dashboard lives on gungunerp.org. Each school's site is served on school.gungunerp.org or on a domain the school already owns. All of it is one Next.js app, one Postgres database and one server.

That setup raises four questions: how a request finds the right school, how a domain we've never seen gets HTTPS, how one school's data stays out of another's, and how non-developers build pages. Here's how we answered each.

1. Route by the Host header

Every request carries the hostname it was sent to. Next.js middleware (renamed proxy.ts in Next 16) reads it before any page renders and rewrites the URL to an internal route:

// proxy.ts (simplified)
export function proxy(request: NextRequest) {
  const host = (request.headers.get("host") ?? "").split(":")[0].toLowerCase();
  const { pathname, search } = request.nextUrl;

  // school.gungunerp.org -> /sites/school/...
  const slug = tenantSlug(host);            // null for the platform itself
  if (slug) return rewriteTo(`/sites/${slug}${pathname}`, request);

  // Anything that isn't the platform is a school's custom domain.
  if (host !== PLATFORM_DOMAIN) {
    if (host.startsWith("www.")) {
      return NextResponse.redirect(`https://${host.slice(4)}${pathname}${search}`, 308);
    }
    return rewriteTo(`/sites/${host}${pathname}`, request);
  }

  return authenticatePlatformRequest(request); // dashboard, admin, APIs
}

The visitor's address bar never changes; the rewrite is internal. All school sites are rendered by one route tree, app/(public)/sites/[domain]/…, which looks the school up by slug or by custom domain and renders its pages. Because a slug never contains a dot and a domain always does, the two lookups can't collide.

Two details that matter in practice:

Normalize domains once, on the way in. People paste https://www.School.co.in/about. Store the bare, lowercase form (school.co.in), reject the platform's own domain and its subdomains, and accept multi-part suffixes like .co.in and .edu.in that a naive "one dot" regex rejects. The same function is used everywhere a domain is compared.
Pick one canonical host. www. gets a 308 to the bare domain, so search engines see one URL per page instead of two.

2. HTTPS for domains you don't know in advance

The platform's own subdomains are easy: they sit behind Cloudflare, which presents its own certificate to visitors.

Custom domains are harder. A school adds its domain in the dashboard, points an A record at our server, and expects https:// to work within minutes, without anyone from our team touching the server.

Caddy's on-demand TLS does exactly this. The first HTTPS request for an unknown hostname triggers a Let's Encrypt certificate, issued on the spot. The catch is that "any hostname" includes hostnames you don't serve. Anyone could point a thousand domains at your IP and burn through your Let's Encrypt rate limits. So Caddy asks first:

{
  on_demand_tls {
    ask http://127.0.0.1:3000/api/domains/check
  }
}

https:// {
  tls {
    on_demand
  }
  reverse_proxy 127.0.0.1:3000
}

And the app answers only for domains an active school has saved:

// GET /api/domains/check?domain=<host>
export async function GET(request: Request) {
  const domain = normalizeCustomDomain(new URL(request.url).searchParams.get("domain") ?? "");
  if (!domain) return new Response(null, { status: 400 });

  const org = await prisma.org.findUnique({ where: { customDomain: domain } });
  return new Response(null, { status: org?.isActive ? 200 : 404 });
}

Because normalization strips www., the www variant is approved too, so the redirect to the bare domain is itself served over a valid certificate. Adding a school is now a database row, not a server change.

3. Keep every query inside one school

All schools share the same tables. Each tenant-owned row has an orgId, and unique constraints are per tenant (@@unique([orgId, slug])), so two schools can both have an /admissions page.

The risk is a route that forgets where: { orgId }. Rather than rely on every developer remembering, dashboard routes use a Prisma client extension that adds it for them:

const GLOBAL_MODELS = new Set(["User", "Org", "RefreshToken"]);
const FILTERED = new Set([
  "findMany", "findFirst", "findFirstOrThrow", "findUnique", "findUniqueOrThrow",
  "count", "aggregate", "groupBy", "update", "updateMany", "delete", "deleteMany",
]);

export const tenantDb = (orgId: string) =>
  prisma.$extends({
    query: {
      $allOperations({ model, operation, args, query }) {
        if (!model || GLOBAL_MODELS.has(model)) return query(args);
        if (FILTERED.has(operation)) args.where = { ...args.where, orgId };
        if (operation === "create") args.data = { ...args.data, orgId };
        if (operation === "createMany") args.data = args.data.map((row) => ({ ...row, orgId }));
        if (operation === "upsert") {
          args.where = { ...args.where, orgId };
          args.create = { ...args.create, orgId };
        }
        return query(args);
      },
    },
  });

A route then does const db = tenantDb(user.orgId) and queries normally. Know where this kind of guard stops, though:

List operations explicitly and review the list when you upgrade Prisma. The …OrThrow variants and newer operations like createManyAndReturn are separate operation names. If they aren't in the list, they go through unfiltered.
It only guards the top-level query. Nested writes and included relations aren't rewritten. Raw SQL isn't either.
The orgId must come from the verified session, never from the request body or a header the client can set.

It's a safety net, not a substitute for thinking about tenancy in each route. But it turns the most common mistake into a non-event.

4. Pages are data, blocks are code

Schools edit pages in Puck, a visual editor for React. Puck saves a page as JSON: an ordered list of blocks and their props. Each block is a normal React component with a field schema:

const config: Config = {
  components: {
    HeroBanner: {
      fields: {
        heading: { type: "text" },
        image: { type: "custom", render: MediaUrlField },
      },
      render: (props) => <HeroBanner {...props} />,
    },
    // …admissions, courses with fee concessions, faculty, galleries, disclosure tables, blog feed…
  },
};

The same config renders the editor and the live site, so what a school sees while editing is what visitors get. The library has grown to more than 70 blocks. When a new kind of page is needed, it ships as reusable blocks instead of a one-off template.

Each page row stores two JSON columns: draftContent for what the editor autosaves, and content for what's live. Publishing copies draft to live and records a revision, keeping the last 20 per page, so a school can roll back a bad publish. Revisions are taken on publish, not on every autosave, because publish is the checkpoint anyone would want to return to.

5. SEO per school, not per platform

Each school's site is its own website to Google, so it needs its own sitemap.xml, robots.txt, canonical URLs and per-page titles and descriptions. They all hang off the [domain] route and build absolute URLs from one helper:

const baseUrl = (org) =>
  org.customDomain ? `https://${org.customDomain}` : `https://${org.slug}.${PLATFORM_DOMAIN}`;

One gotcha: a sitemap.ts under a dynamic segment has no params at build time, and next build tries to prerender it anyway and crashes. export const dynamic = "force-dynamic" makes Next generate it per request, for the right school.

What I'd tell someone building one

Route on Host in middleware, and render all tenants from one route tree. Subdomains and custom domains are just two ways of finding the same tenant.
Use on-demand TLS with an ask endpoint. Without the ask, your server issues certificates for anyone. With it, adding a domain is a database write.
Normalize domains in exactly one function and use it for storage, the TLS check and routing.
Scope queries by tenant in one place, and know what that one place doesn't cover.
Store pages as data and ship blocks as code. Non-developers get freedom inside a design system, and developers keep control of the components.

The builder is live at gungunerp.org, and there's more about the project in the case study.

Originally published on my site. I'm Paritosh, a lead full-stack engineer; more of my work is at paritosh-dev.vercel.app.