Case Study

Subscription media platform: from manual signups to automatic delivery

Every new subscriber used to mean manual work. Confirm payment by hand, create the account by hand, send access details by hand, remember to chase the renewal. We automated the whole chain.

Public catalogue with the subscription checkout panel.

The problem

The business worked, but only because someone was manually holding it together:

• Card payments were fine. Stripe handled checkout and sent a webhook. Everything after that was manual.
• Bank transfer and QR payments were worse. A customer paid, then messaged a screenshot. Someone had to match the payment to an order, then create the account, then reply with access details.
• Renewals were tracked in a spreadsheet. If nobody checked the sheet, customers either lost access without warning or kept it for free.

The bottleneck was not traffic. It was that every single subscriber required a human to finish the job.

What we built

Catalogue and checkout

• Browsable catalogue with plan tiers and pricing
• Stripe checkout for card payments, with webhook confirmation
• FPX and DuitNow QR through a Malaysian gateway for customers without cards
• Order record created at checkout with a reference number the customer can quote

Fulfilment chain

Both payment rails converge on the same fulfilment path. Once payment is confirmed, by webhook or by the payment poller, the system provisions access, records the expiry date, and notifies the customer automatically. Nobody touches it.

Customer side

• Order status page keyed by reference number
• Receipt access without needing an account
• Customer portal showing current plan, expiry, and renewal options
• Self service cancellation

Operations side

• Payment poller reconciling bank transfers that the gateway does not webhook
• Notification delivery over both email and messaging, with retry on failure
• Manual override for the cases that always exist: partial payments, disputes, refunds

The parts that were actually hard

Two payment rails, one truth. Stripe confirms instantly by webhook. Bank transfers confirm minutes or hours later, and sometimes not at all. The system had to treat a single order as potentially pending across two different confirmation mechanisms without ever double provisioning. The fix was an idempotent fulfilment step keyed on the order reference: it does not matter which rail fires first, or whether both fire, the customer is provisioned exactly once.

Expiry without a cron dependency. Access has to end on a date. Rather than trusting a scheduled job to run, access checks compare the current time against the stored expiry on every request. Renewal extends the expiry. This means the system stays correct even if a scheduled task is late or missed, which it will be eventually.

Notifications that actually arrive. Customers were paying and then waiting for a message that silently failed. Delivery is now retried, and failures are logged rather than swallowed. A payment that succeeds but never gets delivered is the worst possible outcome, so it gets the most defensive code.

Architecture choices

Cloudflare Pages for the front end, Workers for the API and webhooks, KV for state. The same reasoning as the ordering system: no server to patch, no database to administer, and a hosting cost that rounds to zero at this scale. Payment secrets live as Worker environment bindings, never in the client bundle.

The public pages carry a strict content security policy. Card data never touches our code at any point, Stripe hosts the payment fields directly, which keeps the compliance scope small.

What I would do differently

The customer portal started as a read only status page and grew features over time. If I rebuilt it, I would design the portal as the primary interface from day one and treat the status page as a lightweight view of it, rather than maintaining two surfaces that show overlapping information.