Revenue-critical code
Revenue-critical code is the part of a product where a bug is not a slow page, it is a customer who cannot pay, or who paid and cannot use what they bought. Payments, refunds, subscriptions, licensing. The distinguishing feature of this layer is not difficulty, it is the shape of the failure: it is quiet, it compounds, and you usually discover it at settlement rather than in a test suite.
That changes how you build. Every operation has to survive being run twice, because webhooks retry and queues redeliver. Amounts have to be exact, which means integer minor units rather than binary floats. Refunds and proration have to be derived rather than divided, or you lose a cent per split and nobody notices for a year. And every state change needs an append-only trail, because six months from now a customer will dispute a charge and "we are not sure" is an expensive answer.
These essays cover that layer as I actually build it, in Laravel apps and in WordPress plugins that handle licensing and subscriptions. They are opinionated on purpose. Where there is a defensible counterargument I say so, and where the honest answer is "it depends on your provider", I say that too.
- You are about to write billing code and want the decisions that are painful to retrofit.
- Your refunds, proration, or reconciliation have started disagreeing with your provider.
- You are inheriting a payments codebase and need to know where to read first.
The foundational one: why a binary float cannot hold $2.78, and why you allocate a total instead of dividing it.
A practical method for auditing an unfamiliar payments codebase by reading the path most teams write last.
The failures that never appear in the happy path: retries, duplicate webhooks, partial refunds, and chargeback deadlines.
Why proration and dunning are where recurring revenue quietly leaks, and how to model the billing clock honestly.
Something in your billing not adding up?
Reconciliation drift, double charges, or a refund path nobody wants to touch. If you are staring at one of these, tell me what you are seeing.
Get in touchOther people's writing that shaped it
- brandur.org · Brandur Leach
Implementing Stripe-like Idempotency Keys in Postgres
The implementation piece that most idempotency writing skips. Not the concept, but the schema, the state transitions, and what happens when a request dies halfway through a multi-step operation. If you have ever written a webhook handler that calls a payment provider and then updates two tables, this is the piece that explains why that is harder than it looks.
- martinfowler.com · Martin Fowler
Circuit Breaker
A short, clear description of the pattern that stops one failing dependency taking your whole application with it. Useful well beyond microservices: any plugin that calls a licence server, a payment gateway or an external API on a page load has this problem, and usually solves it with a timeout and hope.
- docs.stripe.com · Stripe
Webhooks
Vendor documentation rather than an essay, and worth reading even if you never touch Stripe. It is the clearest statement of what at-least-once delivery obliges the receiver to do: verify signatures, acknowledge fast, do the slow work elsewhere, and expect the same event more than once. Most webhook bugs are one of those four ignored.
Building something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch