Web Development & Booking Systems

A Booking Engine Built Around PSD2-Grade Payment Verification

Cowork.lk

Sri Lanka — included as architecture evidence, not an EU engagement

Knovik built a coworking space's booking engine from spec: real-time availability across six space types, checkout with a local payment gateway, automatic invoice creation in the client's accounting system, and a front-desk admin dashboard — verified end-to-end against a real running instance, not just a passing build.

Overview

Cowork.lk runs a coworking space with six bookable space types, each with its own pricing and inventory. The engineering problem — availability, payments, and accounting all having to agree with each other in real time — is identical to what any EU reservation business faces. The payment integration is the part most relevant to EU compliance teams: a booking is only marked paid after a server-side signature verification of the payment provider's webhook, the same verify-before-trust pattern PSD2's Strong Customer Authentication rules require. Nothing here was EU-specific by client, but the architecture transfers directly.

Approach

Real-Time Availability, Not a Shared Calendar

A half-day booking and a full-day booking on the same resource have to correctly block each other; a multi-unit pool needs a live count, not a yes/no. Built as a single database function both the customer-facing site and the admin dashboard call, so the two can never disagree about what's actually free.

Signature-Verified Payments, Not Trust-the-Redirect

Payment confirmation arrives via a server-to-server webhook carrying a cryptographic signature; a booking is only marked paid after independently recomputing and matching that signature server-side. A request with a valid-looking but incorrect signature is rejected before it can touch booking state — verified by simulating both a correctly signed and a tampered webhook against the running system.

Three Database Permission Bugs Found by Testing, Not Reading

Row-level security is easy to get subtly wrong in ways that only surface under real queries. This build found and fixed three: a function using the caller's own role instead of an elevated one, a missing table grant on the service-role key, and a self-referencing admin policy Postgres correctly rejects as infinite recursion — all caught by running real queries against a real database.

Technologies

Next.js 14TypeScriptSupabase (PostgreSQL, Auth, Row-Level Security)Payment gateway webhooksAccounting API integration

Verified Results

As of 13 July 2026

  • Full booking-to-payment-to-invoice flow verified end-to-end
    A real booking, a real simulated payment webhook with a correctly computed signature, and a real invoice attempt, confirmed working together.
  • Three production-grade database security bugs found and fixed
    Each found by running real queries against a real database under real conditions, not by reading the schema.

Related Industry

Want something built and verified the same way?

Book a Strategy Call