Billing correctness monitoring for Stripe
Murphy is for billing and monetization engineers, and for whoever has to answer for a number that turns out to have been wrong all year. It re-derives what an invoice should have said from the objects it was built out of, then holds that against what you charged.
Revenue leakage does not throw. It looks like a plausible invoice and it gets paid.
Two weeks free. The first report covers the invoices you already have.
A customer added seats and was refunded for it.
What the objects say
What it comes to
What went quiet
All three of these happened. None of them threw an error. A billing engineer found each one by hand, long after it started.
A Stripe coupon carries a list of the products it is allowed to reduce. The list on this one matched no product on the invoice.
It was attached and valid the whole time, and the dashboard showed it sitting there. The invoice generated with no discount on it at all. Attached is a different fact from applied, and only one of the two shows up on the invoice.
A coupon went onto a back-dated subscription during a migration. The initial payment was worked out without the discount and the prorations were worked out with it.
The customer expanded their seat count and the delta came out negative, so they were refunded for buying more. Every invoice in the sequence added up on its own.
A payment failed and the retry sequence that should have followed it did not run. The invoice sat open for five weeks. The card had worked the whole time.
Nothing errored, because what went wrong was an absence. The only evidence was next_payment_attempt sitting null on one invoice, a field no handler has a reason to re-read.
Why nothing caught it
Every layer that could have caught it was right to report success.
Error rate and latency say nothing about whether a number is correct.
It asserted that the coupon was attached. The coupon was attached.
There is no error to catch and no event to handle. A step that never ran emits nothing, so an integration built on incoming events waits for a message that is not coming.
How it works
It checks what you charged. It never checks what you were charged. The only account it reads is your own Stripe account.
Which means it flags the gaps that run in your favour and the gaps that run against you. An overcharge has a customer who will eventually report it. An undercharge has nobody.
A restricted read key and one webhook endpoint.
Murphy reads your existing invoices, subscriptions and discounts on the day you connect, then keeps up from the webhook. It holds its own copy, so a check reads that rather than your account, and it never issues a write back to Stripe.
The number, derived again from the objects the invoice was built out of.
Not read off the invoice and not compared against last month. Given the same objects the recomputed number comes out the same every run, so a finding is a fact about the objects rather than about when it was looked at.
The gap between what you charged and what the objects say.
It arrives with the objects it was derived from, so the first question after the alert has an answer already attached.
The first run is the interesting one. Murphy re-derives every invoice you already have, so the first thing it tells you is what has been wrong for a while, not what breaks next Tuesday.
Living with it
The person who installs billing monitoring is the person who gets woken up by it, so the noise question is the whole question.
The first run alerts nobody. It produces a report, you read it, and you decide what is worth hearing about before anything is turned on.
The failure catalog
You can write a check for the bug that already bit you. The rest of them you would have to know about first, and nothing in your week suggests you go looking. Murphy keeps a catalog of the ways billing goes wrong quietly, grouped by what breaks.
Every category here runs on the day you connect. Nothing in the catalog is held back for a higher tier and nothing in it is a plan.
What this is built on
The catalog started with billing systems I ran and broke, at companies between three and two hundred and fifty million in revenue. Engineers who hit their own version filled in more of it, and the rest comes from behavior Stripe documents in public.
Nothing in it is a failure somebody imagined might be possible. That is the whole difference between a catalog and a feature list.
The working notes go up one failure at a time, with the Stripe behaviour underneath each one written down. Who is behind this.
Connect a read key and the first report tells you which of your invoices already disagree with the objects they were built from. Two weeks free, and no call to book.