Backend coding interview

Subscription Billing Coding Interview Problem

Money & state machinesProration mathHard

What this interview round tests

Recurring billing is where fintech interviews go when they want to test money handling and state machines at the same time. A subscription sounds like a monthly charge; in practice it is a lifecycle — trial, active, past-due, cancelled — plus the single most bug-prone computation in SaaS: proration, the credit-and-charge math of a customer changing plans mid-cycle.

Interviewers like this problem because every bug in it has a real-world invoice attached. Proration that rounds the wrong way overcharges by a rupee at scale; an invoice generated twice for the same period is a double charge and a support ticket; a dunning flow with a wrong transition cancels paying customers or keeps deadbeats active forever. The Stripe-style billing round tests whether you can make time-based money arithmetic exact and keep a lifecycle honest under retries.

The scenario

You are handed a billing engine: subscriptions move through their lifecycle, invoices are generated per period, mid-cycle upgrades and downgrades prorate, and failed payments walk a dunning path with retries and grace. The engine produces numbers — and the test suite disagrees with nearly all of them.

Upgrades charge full price instead of the prorated difference, downgrades mint negative invoices, regenerating a period bills the customer twice, cancelled subscriptions keep invoicing, and payment failures jump straight to cancelled with no dunning. Your job is to fix the math, the lifecycle, and the idempotency until the suite goes green.

What you’ll practice

  • Proration: unused-time credit and new-plan charge, exact to the minor unit
  • Rounding discipline: integer money math with defined rounding points
  • Idempotent invoicing: one invoice per subscription-period, retries included
  • Lifecycle state machine: trial, active, past-due, cancelled — legal moves only
  • Dunning transitions: retries and grace windows before any cancellation
  • Anchor dates: billing cycles that stay aligned across plan changes

How to approach it

Do proration in integer minor units against day counts of the actual cycle: value the unused remainder of the old plan, value the same window on the new plan, and charge the difference — with rounding applied at defined points, once. Most wrong answers compute in floating point or round intermediates, and the tests check totals to the exact paisa.

Treat invoicing as an idempotent job keyed by subscription and period: generation checks for the key first and returns the existing invoice on a retry. The lifecycle is a transition table like any state machine, but the moves that matter are the money-adjacent ones — a payment failure enters dunning rather than cancelling, and only exhausted retries plus an expired grace window may terminate. Wire the clock in as a dependency; billing logic that reads wall time inline cannot be tested and will not pass.

The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.

Try it in a real repository

LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Open the brief and read the full problem — no signup required.

FAQ

What exactly is proration and why is it hard?

When a customer switches plans mid-cycle, you credit the unused portion of the old plan and charge the remaining portion of the new one. The hardness is precision: day-count conventions, rounding rules, and cycle anchors all have to be pinned down, or two implementations of the same spec produce invoices that differ by a rupee.

Why does invoicing need idempotency?

Because invoice generation runs on schedules and retries — a crashed job reruns, a webhook redelivers. Keying invoices by subscription and billing period makes regeneration return the existing invoice instead of charging the customer twice, which is the difference between a robust billing system and a refund queue.

What is dunning, and how do the tests cover it?

Dunning is the managed path after a failed payment: retries on a schedule, a grace period, then suspension or cancellation. The tests drive payment failures through the lifecycle and check that every transition is legal, retries are counted, grace is honoured, and recovery mid-dunning restores the subscription cleanly.

Related