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.