--- title: "The Missing Layer in Your Billing Stack" description: "Every company with usage-based pricing builds enforcement from scratch. It's the highest-leverage infrastructure problem nobody owns yet." date: 2026-03-11 author: Kat Laszlo canonical: https://tansohq.com/blog/missing-layer-billing-stack --- # The Missing Layer in Your Billing Stack By [Kat Laszlo](https://www.linkedin.com/in/katrinalaszlo/) · March 10, 2026 Every company with usage-based pricing builds the same thing from scratch. Not metering. There are tools for that. Not payments. Stripe handles that. The thing everybody ends up building themselves is **enforcement**: deciding in real time whether a request should proceed. Your best engineers are spending weeks, sometimes months, building and maintaining enforcement logic instead of working on the product your customers actually pay for. It's the highest-leverage infrastructure problem that nobody owns yet. Billing tells you what happened. Enforcement decides what's allowed to happen. Billing is the scoreboard. Enforcement is the referee. And right now, every engineering team is building their own referee from scratch. --- ## The problem hiding in plain sight You launch with a simple pricing model. Maybe three tiers with a usage cap. Your backend developer writes a few `if` statements. It works. Then things get complicated: - →A customer on the free tier figures out your API doesn't actually block requests after the limit - →Your biggest customer's invoice doesn't match their usage because enforcement and metering disagree - →Product wants to add credits. Now you need to check subscription tier, usage limits, *and* credit balance on every request - →Someone changes pricing, and three services need to be updated in lockstep, or customers get billed for things they shouldn't have access to What started as a few `if` statements becomes a distributed system spanning your API gateway, your application layer, your billing provider, and a growing pile of database queries that run on every single request. We've heard this from every company we've talked to. The symptoms show up as billing pain, but the root cause is enforcement logic scattered across systems: > "I have whiplash from Stripe. We did so many permutations on the products. I'm looking at a product and there's a thousand different versions of it. I don't know which one's active, which one's inactive, why some have multiple SKUs on their invoice, some aren't getting usage events."Product Lead, Series B SaaS company > "Legal was involved. There were masses of custom communications. You change a price, that's a huge deal all of a sudden."Former GM, Fortune 500 company, on what happens when enforcement logic touches everything --- ## Why metering and billing don't solve this The billing infrastructure landscape has matured. Stripe handles payments. Metronome and Orb handle metering. But there's a fundamental gap: **these systems record what happened. None of them control what happens next.** Metering counts API calls after they occur. Billing generates invoices after the period ends. Neither one sits in the request path, making a real-time decision about whether this specific request, from this specific customer, with this specific plan and usage history, should be allowed to proceed. That's enforcement. And it requires a fundamentally different architecture. One that combines: - →**Entitlement data**: what is this customer allowed to use? - →**Usage data**: how much have they already used? - →**Billing state**: are they paid up? Do they have credits? - →**Business rules**: what happens when they hit a limit? Hard block, soft warning, overage charge, model downgrade? Today, most companies stitch this together themselves. They query Stripe for subscription status, their own database for usage counts, an entitlement service for feature access, and then write custom logic to combine it all. This code is fragile, slow to change, and almost always wrong in edge cases. --- ## AI companies have it worse If enforcement was already painful for traditional SaaS, AI companies are dealing with it at a completely different scale. Why AI economics break traditional billing: The enforcement requirements are different too. You need per-request cost awareness, not just monthly caps. You need to downgrade to a cheaper model when a budget is low instead of hard-blocking. You need to catch a single customer burning through credits before the invoice tells you about it a month later. Traditional billing infrastructure wasn't designed for any of this. **The upside most teams miss:** If you're already in the request path making enforcement decisions, you're sitting on per-customer, per-feature, per-request cost data. You can see margins at the customer level. Which customers are profitable, which are draining you, and what happens to your unit economics if you change pricing. Enforcement isn't just a gate. It's the foundation for revenue optimization. --- ## "We'll solve that later" is the most expensive decision The most common response we hear from engineering teams is: "Yeah, we know enforcement is a mess. We'll clean it up later." They never do. Here's what happens instead: 1. The complexity grows Every new pricing tier, every new feature gate, every new usage dimension adds enforcement logic. After a year, you have a distributed enforcement system that nobody fully understands, spread across multiple services, with no single source of truth. 2. The cost is invisible When enforcement is wrong, you don't get an error. You get revenue leakage. Customers using features they shouldn't have access to. Usage caps that don't actually cap. Free tier users who never convert because they're getting everything for free anyway. These problems are hard to measure and easy to ignore until they show up in your unit economics. 3. The migration cost grows The longer you wait, the more deeply enforcement logic is embedded in your application code. Teams we've spoken with estimate 2 to 6 months of dedicated engineering time to untangle enforcement from their core application. Time they could spend on their actual product. --- ## What enforcement as infrastructure looks like Enforcement shouldn't be something you build. It should be something you call. Here's what it looks like when you build enforcement yourself: ``` # What every team builds from scratch async def handle_api_request(customer_id, feature, units): # Check subscription status (query Stripe) subscription = await stripe.Subscription.retrieve(customer_sub_id) if subscription.status != "active": return deny("Subscription inactive") # Check feature access (query your own database) plan = await db.get_plan(subscription.plan.id) if feature not in plan.features: return deny("Feature not included in plan") # Check usage limits (query your metering system) current_usage = await metering_db.get_usage( customer_id, feature, current_period ) limit = plan.features[feature].limit if current_usage + units > limit: return deny("Usage limit exceeded") # Check credit balance (query yet another table) if plan.uses_credits: balance = await credits_db.get_balance(customer_id) cost = calculate_credit_cost(feature, units) if balance < cost: return deny("Insufficient credits") # If you got here without a bug, proceed result = await do_the_actual_work(customer_id, feature, units) # Now update usage (hope this stays in sync) await metering_db.increment(customer_id, feature, units) if plan.uses_credits: await credits_db.deduct(customer_id, cost) return result ``` Four data sources. Six potential points of failure. Custom logic that has to be duplicated in every service that gates a feature. And when product changes pricing next quarter, you get to update all of it. Compare that to two calls: one to check, one to record. Now here's the same thing with enforcement as infrastructure: ``` # Two API calls. One source of truth. async def handle_api_request(customer_id, feature, units): # 1. Check: can this customer do this? check = await tanso.entitlements.check( customer_reference_id=customer_id, feature_key=feature, usage=units ) if not check["data"]["allowed"]: return deny(check["data"]["meta"]["reason"]["description"]) # Tanso checked subscription, plan, usage, credits, # and simulated whether this request would exceed # limits. One call. No custom logic. result = await do_the_actual_work( customer_id, feature, units ) # 2. Record: track what happened await tanso.events.record( customer_reference_id=customer_id, feature_key=feature, usage_units=units ) return result ``` The response tells you everything. Whether access is allowed, current usage, remaining quota, credit balance, and if the proposed usage would exceed any limit. All before the request proceeds. ``` { "data": { "featureKey": "reports", "allowed": true, "usage": { "used": 45000, "limit": 100000, "remaining": 55000 }, "simulation": { "requestedUsage": 5000, "projectedUsage": 50000, "projectedRemaining": 50000, "wouldExceedLimit": false } }, "success": true } ``` When pricing changes, you update the rules in one place. When you add a new tier, you configure it once. When a customer hits their limit, the enforcement layer handles the response, whether that's a hard block, a grace period, an overage charge, or a model downgrade. ### Where enforcement sits in the stack Your Application API, dashboard, agent runtime Enforcement Layer (Tanso) Entitlements + Usage + Credits + Billing State = **Allow / Deny** Billing Invoicing, subscriptions, charges (Tanso) Payment Provider Stripe, PayPal, Adyen Enforcement sits above everything. It's the coordination point between your application and your billing stack. The runtime that combines entitlement data, live usage, and billing state to make a real-time decision on every request. Your enforcement logic is decoupled from your payment provider, so changing how you bill doesn't mean rewriting how you gate. --- ## Why now, and why the window is closing Right now there are two groups of companies. The first group has already hit the wall. They've got 50 customers, or 500, and enforcement is falling apart. Invoices don't match usage. Free tier users are getting paid features. A pricing change went out last quarter and three services are still enforcing the old limits. These teams know enforcement is broken because they're living it every day. The second group hasn't hit scale yet. They've got a Stripe integration and some `if` statements and it works fine. They think enforcement is a problem for later. The first group is already looking for a solution. Not because they're early adopters, but because the pain forced their hand. And what they're finding is that fixing enforcement after it's embedded in your application takes months of dedicated engineering time. The second group is about to become the first group. Every company shipping AI features is on this path. Usage-based and credit-based pricing is the fastest-growing model in SaaS. Stripe acquired Metronome, proving metering is real infrastructure. The recording layer is solved. But the decision layer, the runtime that combines entitlements, usage, credits, and cost data into a single per-request verdict, is still the part teams build from scratch. The companies feeling this pain today are a small group. Within a year, it'll be everyone. The teams that solve enforcement now will ship faster, price with more confidence, and keep their engineers on product work instead of billing plumbing. The teams that wait will spend months untangling the mess they built in the meantime. Enforcement infrastructure is going to exist as a category. The only question is whether you adopt it before you've spent months building it yourself. --- ## The enforcement layer is forming now This isn't a theoretical problem. It's a category forming in real time. The market has already validated the layers below enforcement. Stripe acquired Metronome, proving metering is real infrastructure, not a feature. Usage-based billing has graduated from experiment to default. But metering and billing are the *recording* layer. They tell you what happened. Nobody has built the *decision* layer: the runtime that sits in the request path and decides what should be allowed to happen next. Entitlement platforms like Stigg manage what customers are *supposed* to have access to. But entitlements are a control plane. They describe the rules. Enforcement is the runtime. It applies the rules on every request, in real time, combining entitlement data with live usage and billing state. The SaaS pricing shift makes this urgent. Seat-based pricing was easy to enforce. You count logins. But as companies move to usage-based, credit-based, and outcome-based models, enforcement complexity explodes. Every company experimenting with new pricing models is discovering that the hard part isn't deciding what to charge. It's building the system that actually controls access based on what was charged. --- ## Why we built Tanso We didn't research this problem. We lived it. Both of us built enforcement systems from scratch at our previous company, a startup where the billing complexity outgrew what Stripe and every other tool could handle. We built the entire billing and enforcement stack ourselves because nothing existed to do it for us. That experience is why Tanso exists: so other engineering teams don't have to spend months building what we already know how to solve. There's also a structural reason why the incumbent billing providers haven't solved enforcement: **it works against their business model.** Stripe makes money when transactions go through. Enforcement, by definition, sometimes stops transactions. The incentives don't align. That's not a criticism of Stripe. They're exceptional at what they do. But it means enforcement will be owned by a company whose entire focus is getting it right, not one that's optimizing for transaction volume. Tanso keeps enforcement and billing state above the payment rail. Today it can sync invoices and payment status through Stripe, or let an operator settle invoices manually. That keeps request-path enforcement in Tanso without claiming payment adapters that the open-source product does not yet ship. --- ### Stop building billing infrastructure. Full enforcement, metering, and margin visibility. More for agents: https://tansohq.com/llms.txt