Anatomy of a B2B payment
“How hard could charging money be?” is a quote paraphrased by teams across the globe, perhaps with the occasional expletive.
Getting customers to pay is hard enough as is; it would be nice if charging customers was a cakewalk. Sadly it’s not. It’s frankly downright confusing. Between metering, billing, invoicing, and payments, there are various overlapping components that confuse developers and product managers alike.
Part of the trouble is inconsistent terminology, where marketing-speak is conflated with actual object names in code. Another issue is that none of these major components of pricing are trivial problems.
Today, we’re going to attempt something that’ll spark some disagreement—establish hard definitions of each term, particularly in context of one another. We’re basing these definitions on how third-party software has organized the various sub-problems of charging customers money.
In short, we’re going to explore the differences between metering, billing, invoicing, and payments.
While metering, billing, invoicing, and payments are four of the most common charging sub-problems, they don’t apply to all products. For instance, take a product like Font Awesome—it sells a flat annual subscription, with no concept of metering. Or consider a marketplace like Flip—there is no strong concept of invoicing.
Where all four concepts apply is any usage-based pricing model. Which is, to the surprise of some, a majority of companies. “Usage-based” pricing might connote to a product that bills customers based on API requests or infrastructure hours. However, the most common usage-based billing model is seat-based pricing, where companies charge customers based on the number of registered employees using the platform.
Knowing our typical readers, there’s a fair change you are working on that exact type of company.
In a nutshell, usage-based pricing models have to monitor usage, invoice customers, and charge them appropriately. It is this entire process that’s broken down into those four subcategories (metering, billing, invoicing, and payments).
Metering is the process of collecting events tied to billable units. For instance, metering for an API company would be counting date-stamped API requests. Or, for a seats-based SaaS businesses, metering is accounting for the number of seats added or released.
There are various sub-problems when it comes to scaling metering. Some products might have millions of events to ingest, which need to be efficiently queried to play well with the billing engine (more on that later). These queries often involve date ranges, so timezones also need to be accounted for.
//sample event
{
"event": {
"transaction_id": "1234_5678_90123_4567",
"external_customer_id": "hooli_1234",
"code": "storage",
"timestamp": 1699971014,
"properties": {
"gb": 12,
"provider: "aws",
"region": "us-east-1"
}
}
}At times, even the events are complicated. For a storage product, events might report the maximum storage for a period, or an incremental delta, or a weighted average. It’s up a metering engine to come up with a fair estimate of usage.
For some products, the source of data isn’t in an internal database, but a log source (like LogStash) or server-less agents (like CloudWatch) — all of which needs to be accounted for by the metering solution. Today, Lago handles by using ClickHouse, an event-driven OLAP database that’s deployed via Altinity Operator on K8s.
Additionally, events cannot be double counted other the customer will be over-billed. And, in pricing schemes, usage has to be gated depending whatever is allowed by the tier.
Billing is the process of calculating how much a customer owes and knowing when they should be charged for it. The former is often conflated with metering—but billing is more holistic, accounting for the total amount owed, including any flat recurring subscription fees or any one-off fees.
Billing is also often confused with a payments solution like Stripe. Billing is not process of charging a customer, just determine how much and when a customer should be charged. Billing is agnostic to how a customer pays, just that they owe money.
Billing is often the cornerstone piece of the puzzle. In other words, other products often integrate into a billing solution, not the other way around. For instance, metering is one of many inputs into a billing engine.
Another input into billing is pricing. Pricing determines how much metered units actually cost.
Where pricing gets complicated is due to legacy pricing. As products evolve, so does pricing. Given that many products grandfather in pricing for earlier clients (e.g. let them keep an older rate), pricing can often grow difficult to maintain. Additionally, some companies prorate (charge only for the remainder of a month if a user joins mid-month). And, sometimes pricing drops with bulk usage (graduated pricing), which just adds to the pricing complexity.
//sample pricing object
{
"charges": [
{
"billable_metric_code": "storage",
"charge_model": "graduated",
"invoiceable": true,
"pay_in_advance": false,
"prorated": false,
"min_amount_cents": 0,
"invoice_display_name": "Storage",
"properties": {
"graduated_ranges": [
{
"from_value": 0,
"to_value": 10,
"per_unit_amount": "0.00",
"flat_amount": ""
},
{
"from_value": 11,
"to_value": null,
"per_unit_amount": "0.05"
}
]
}
}
]
}Overall, pricing needs to account for multiple historical pricing models and any complexity that deviates from a flat rate.
Invoicing is the process of issuing a legal document of a balance owed. Invoicing and billing are often confused, but they actually have very different sub-problems.
Whereas billing is focused on how accurately determining how much people owe on any arbitrary pay date, invoicing is about giving the customer something that they could pass through their procurement system. In that sense, invoices are an output of billing.
// A sample invoice object
{
"fees": [
{
"external_customer_id": "hooli_1234",
"external_subscription_id": "repository_A",
"taxes_amount_cents": 0,
"taxes_rate": "0.00",
"units": "10",
"total_amount_cents": 12000,
"total_amount_currency": "USD",
"events_count": 23,
"pay_in_advance": false,
"invoiceable": true,
"prorated": false,
"from_date": "2022-04-29T08:59:51Z",
"to_date": "2022-05-29T08:59:51Z",
"payment_status": "paid",
"created_at": "2022-08-24T14:58:59Z",
"succeeded_at": "2022-08-24T14:58:59Z",
"failed_at": "",
"refunded_at": "",
"item": {
"type": "charge",
"code": "storage",
"name": "Storage"
}
}
]
}Invoices are documents that can be voided or marked as paid. They are also often something that needs to be exportable into something like a PDF.
Payments is the actual process of charging a customer money, either through a credit/debit card transaction, an ACH withdrawal, or another method of payment (including virtual credits). Payments should be considered an input into the billing system as it fulfills a billing object.
Payments are almost always handled by a third-party as there are ample subprocesses involved with billing methods. These include interfacing with card issuers (e.g. VISA) and banking provider (e.g. JPMorgan Chase). This shouldn’t be conflated with banking data providers like Plaid but instead payment handlers like Stripe.
At Lago, we see a lot of our customers use Stripe for Payments while using Lago for Billing, Metering, and Invoicing.
The cornerstone piece of all this should be a billing engine. Billing is, fundamentally, knowing when and how much to charge customers. Everything else either an input or output of billing. The alternative approach is to treat payments are the core, but that bundles billing, invoicing, and metering together, making for a less systematic process.
Between billing, pricing, metering, invoicing, and payments, charging customers money is hard work. It’s important that companies gauge, based on their business model, where the pain-points will be to ensure a strong implementation. Regardless, putting a billing engine at the center is typically the correct model to ensure that systems are centered around a single source of truth.