The problem

When you add paid plans to an MVP, three things have to agree:

• The payment provider knows who paid and whether their subscription is active.
• Your database needs to know what each customer is allowed to use.
• Your app has to check that before serving anything paid.

If each part keeps its own idea of "paid", they drift. A cancelled customer keeps access, or a new customer pays and gets nothing. Both cost you trust.

The pattern in one picture

• The payment provider sends a webhook when something changes (a purchase, a renewal, a cancellation, a failed payment).
• Your webhook handler verifies the request and updates one entitlements row.
• Every paid route asks one function, hasAccess(), which reads that row.
• For developer tools that have no login, a licence key maps to the same entitlement.

That way there's one source of truth on your side, and one place to look when something goes wrong.

1. Store entitlements, not payment events

Keep the table small. It records what a customer may use now, not the whole payment history (your provider already keeps that).

Example code, not from a shipped product.

CREATE TABLE IF NOT EXISTS entitlements (
  customer_id  TEXT PRIMARY KEY,
  plan         TEXT NOT NULL,      -- e.g. 'free', 'pro'
  status       TEXT NOT NULL,      -- e.g. 'active', 'past_due', 'cancelled'
  current_until TEXT,              -- end of the paid period, ISO date
  updated_at   INTEGER NOT NULL
);

2. Verify every webhook before trusting it

Anyone can POST to your webhook URL, so check the signature first. Most providers sign the raw request body with a shared secret. The exact header and format differ by provider, so follow their docs. The general shape looks like this:

Example code, not from a shipped product. Check your provider's docs for the real header name and signing scheme.

async function verifySignature(rawBody: string, signature: string, secret: string) {
  const key = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(secret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["verify"],
  );
  const sig = Uint8Array.from(signature.match(/../g)!.map((h) => parseInt(h, 16)));
  return crypto.subtle.verify("HMAC", key, sig, new TextEncoder().encode(rawBody));
}

Two habits help here:

• Read the raw body before parsing it. Re-serialised JSON won't match the signature.
• Make the handler idempotent. Providers retry, so the same event can arrive more than once. Writing "the current state" (an upsert) rather than "add one month" makes repeats harmless.

3. Turn events into one upsert

Example code, not from a shipped product. Event names are placeholders; map your provider's real event types.

type BillingEvent = {
  type: "subscription.active" | "subscription.past_due" | "subscription.cancelled";
  customerId: string;
  plan: string;
  currentUntil: string | null;
};

async function applyEvent(db: D1Database, e: BillingEvent) {
  const status = e.type.split(".")[1];
  await db
    .prepare(
      `INSERT INTO entitlements (customer_id, plan, status, current_until, updated_at)
       VALUES (?1, ?2, ?3, ?4, ?5)
       ON CONFLICT(customer_id) DO UPDATE SET
         plan = excluded.plan, status = excluded.status,
         current_until = excluded.current_until, updated_at = excluded.updated_at`,
    )
    .bind(e.customerId, e.plan, status, e.currentUntil, Date.now())
    .run();
}

4. One access check for every paid feature

Don't scatter if (user.plan === "pro") across the codebase. Put the rule in one function so changing it later is a one-file change.

Example code, not from a shipped product.

async function hasAccess(db: D1Database, customerId: string, plan = "pro") {
  const row = await db
    .prepare("SELECT plan, status, current_until FROM entitlements WHERE customer_id = ?1")
    .bind(customerId)
    .first<{ plan: string; status: string; current_until: string | null }>();
  if (!row || row.plan !== plan) return false;
  if (row.status === "active") return true;
  // Decide on purpose what past_due means for you. Here: keep access until the paid period ends.
  return row.status === "past_due" && !!row.current_until && new Date(row.current_until) > new Date();
}

The past_due line is a product decision, not a technical one. Write it down before launch, along with who can refund or comp a seat.

5. Licence keys: an entitlement without a login

If you sell to developers who install things from a CLI or an AI coding assistant, a full sign-up and login flow can be more than they want. A licence key in an environment variable fits the way they already work.

The key then becomes a lookup into the same entitlements data. Two rules keep it safe:

• Never store raw keys. Store a hash, so a database leak doesn't leak working keys.
• Reject obvious junk early. An empty value, or a literal ${MY_LICENSE_KEY} from an unset variable, should get a helpful message, not a confusing "invalid key".

Example code, not from a shipped product.

async function sha256Hex(s: string) {
  const buf = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(s));
  return [...new Uint8Array(buf)].map((b) => b.toString(16).padStart(2, "0")).join("");
}

async function customerForKey(db: D1Database, rawKey: string | null) {
  const key = rawKey?.trim();
  if (!key || key.startsWith("${")) return { error: "No licence key found. Check your environment variable." };
  const keyHash = await sha256Hex(key);
  const row = await db
    .prepare("SELECT customer_id FROM licence_keys WHERE key_hash = ?1")
    .bind(keyHash)
    .first<{ customer_id: string }>();
  return row ? { customerId: row.customer_id } : { error: "That licence key wasn't recognised." };
}

From there, hasAccess() does the rest. The webhook still decides who's paid, and the key is just a way of saying who's asking.

Tradeoffs to decide on purpose

Lessons

• Billing is mostly about state, not checkout. The checkout page is the easy part.
• Trust the webhook, verified. Don't unlock access from a client-side "success" redirect alone.
• Write the edge cases down before launch. Failed payments, refunds and cancellations need an owner and a rule.
• Buy the commodity parts. Payments and keys can come from a provider, which leaves more of an MVP budget for the product itself.

Where this fits in an MVP budget

Billing and edge cases deserve their own slot in the schedule, not the last afternoon before launch. I wrote more about where SaaS MVP money actually goes in this guide to SaaS MVP costs. If you'd rather have it built, my 30-day SaaS MVP sprint starts from $2,500 and includes billing and its edge cases.

Shaheer Malik designs and builds products at Ship It Live.