I Watched a Senior Engineer Design a Payment System — Here's What Indie Founders Should Actually Take Away

I watched Hayk Simonyan's video on designing a payment system like a senior engineer. It's a 25+ minute deep dive into building a payment backend with 99.999% availability, card network authorization flows, and distributed architecture patterns.

It's excellent engineering content. It's also wildly overkill for 95% of indie founders reading this.

So here's what I pulled out that actually matters if you're monetizing something like ResistGate or Amethyst — free in the Web Store, Pro via subscription — without pretending you're building Stripe.

The 3 Approaches (And Which One Is Yours)

The video lays out three ways to accept payments:

1. No-code checkout (Stripe Checkout links, PayPal.me). You generate a link, customer clicks, pays, done. No backend code. Fine for validating that someone will pay once. Not enough for recurring Pro access inside a Chrome extension.

2. Build your own payment processor. The video covers this as an option, then essentially says: don't. You'd need PCI DSS compliance, bank partnerships, licensing in every market you operate in. This is for companies like Stripe itself, not for you.

3. Integrate a Payment Service Provider (PSP). This is the sweet spot for most real products. You use Stripe, PayPal's API, Paddle, or Freemius as your PSP. They handle card networks, fraud basics, and compliance layers. You handle product logic — when Pro unlocks, what happens on cancel.

The takeaway: ship free first, move from approach 1 to approach 3 when manual fulfillment breaks, never touch approach 2.

Idempotency Keys — The Concept That'll Save You From Angry Customers

Here's the problem: a customer clicks "Subscribe" and their internet hiccups. The request gets sent twice. Without protection, you charge them twice — or grant Pro twice with conflicting state. They email you furious.

Idempotency keys solve this. Every payment request gets a unique key. If the same key hits your server twice, the second request returns the result of the first instead of processing again.

Stripe exposes this as an Idempotency-Key header. With PayPal webhooks, the equivalent discipline is idempotent webhook handlers — same subscription_id + event type should not double-write entitlements. Most beginner tutorials skip this. Don't.

Authorization vs. Capture — Why It Matters for Refunds

Payment happens in phases:

Authorization: "Does this card have funds? Hold them."
Capture: "Actually take the money now."
Clearing/Settlement: Money moves between banks behind the scenes.

If you authorize but delay capture, you can cancel the hold without charging — no refund fees, no dispute for money that never left.

For extension subscriptions, PayPal and most PSPs bundle authorize + capture on renewal. The lesson still matters when you add one-time upgrades or annual plans with fulfillment delays.

Webhooks — The Thing That'll Break at 3 AM

For indie founders, the practical version is: webhook handling is where your payment integration will break.

When a customer subscribes, your PSP sends a webhook confirming the event. You use that to flip Pro on in your database and let the extension verify access.

Three things go wrong constantly:

Your server is down when the webhook fires. Customer paid but Pro didn't unlock.
You don't verify the webhook signature. Someone fakes a POST and gets free Pro.
You process the webhook but crash before saving. The retry runs; without idempotency, state diverges.

The fix: verify signatures, store events before processing, handle retries idempotently. Every PSP documents this — including PayPal for ResistGate and Amethyst on my stack.

What You Can Safely Ignore (For Now)

Critical at scale, irrelevant below ~$50K MRR on two extensions:

Multi-region failover for 99.999% uptime — your PSP's uptime is probably better than your side project.
Card network clearing flows — abstracted away completely.
Distributed ledger architecture — you need an entitlements table in Postgres, not a ledger cluster.
Load balancing payment endpoints — if you need this, you've already won.

The Meta-Lesson

Senior engineers design payment systems for millions of transactions. Indie founders spend weeks on billing before the Web Store listing has reviews.

The correct order for browser extensions:

Ship free and earn trust in the Chrome Web Store.
Make money with the smallest stack — checkout link or simple subscription.
Automate unlock — webhooks, entitlements, extension API when manual confirmation hurts.
Harden — idempotency, refunds, tax/MoR (often via Paddle or Freemius) when edge cases become weekly.
Scale the architecture — that's when the full video becomes your playbook.

For ResistGate and Amethyst I'm between steps 3 and 4: PayPal subscriptions, webhooks, signed tokens — not step 5. If you're reading this after the revenue-stage breakdown, stay in the band you're actually in.

Watch the full video: Design a Payment System Like a Senior Engineer by Hayk Simonyan. Worth your time even if you only apply 20% of it now.

I'm Orlando. I build ResistGate and Amethyst from Venezuela and write about shipping extensions and the billing that comes after. orlandoascanio.com