Merchant of Record for Usage-Based Billing: What Breaks When You Sell AI by the Token
Most merchant of record services were built for flat subscriptions. Here are the five places that model breaks when you sell prepaid credits and metered AI usage — and what to require from a provider.
On this page
Merchant of record services matured around flat subscriptions, where the amount is known before the charge. Usage-based billing inverts that, and the model breaks in five specific places: revenue timing on prepaid credits, partial refunds against a drawn-down balance, place of supply, chargeback exposure that scales with top-up size, and invoices a finance team cannot approve.
- A merchant of record can answer cleanly what was sold, to whom, where and for how much — but only when the amount is fixed before the charge.
- Credits sold and credits consumed are two separate events; a provider that records only the purchase takes your revenue-recognition choice away.
- Partial refunds are structurally harder under a merchant of record, because the invoice was issued by the provider as legal seller.
- Dispute exposure scales with ticket size, and a dispute can arrive after the credits are already consumed.
- A hybrid invoice must show subscription, allowance and overage as separate lines, or every business customer slows down at renewal.
Most billing infrastructure carries an assumption it never states out loud: a customer agrees to a price, the amount is known before the charge is made, and that charge repeats on a schedule. Subscriptions work this way. So does nearly every merchant of record service built in the last decade.
AI products do not work this way. Three shapes dominate, and the rest of this article refers back to them:
- Prepaid credit packs. An image or video generation product sells $20 for 1,000 credits. Customers buy a balance and draw it down unevenly — or stop halfway and never return.
- Subscription plus overage. A $99/month plan includes 1,000,000 tokens. A busy team exhausts the allowance by the eleventh and runs on metered overage for the rest of the cycle.
- Pure per-run. An agent product charges $0.30 per run. One enterprise account produces more variance in a week than a SaaS seat produces in a year.
If you sell this way and you are evaluating a merchant of record, the question is not whether the provider supports usage-based billing. Most will say yes. The question is where their model breaks, because the breaks are predictable and they are expensive.
Why the merchant of record model was built for flat subscriptions
A merchant of record becomes the legal seller of your product. It takes the order, issues the invoice in its own name, collects the money, and carries the tax obligation on that sale. That arrangement is what lets a small team sell globally without registering for VAT in a dozen jurisdictions.
The whole structure depends on being able to answer one question cleanly: what was sold, to whom, where, and for how much. With a flat subscription, every one of those is known at the moment of the charge. The invoice can be issued immediately and it will still be correct next month.
Usage-based billing breaks that cleanliness in five specific places.
Break 1: the sale and the delivery happen at different times
When a customer buys $500 of credits, money moves. But nothing has been delivered yet. The delivery happens later, in fragments, possibly over months, possibly never.
For a flat subscription this gap does not exist in any way that matters. For credits it is the entire problem. You now have two distinct events — credits sold and credits consumed — and your accounting, your tax position, and your understanding of your own business all depend on being able to see them separately.
This is not a question a billing vendor can settle for you; the right treatment depends on your jurisdiction, your terms, and your auditor. What a provider can do is make the treatment possible. So the requirement is concrete: can it report credits sold and credits consumed as separate series, per customer, per period, and can it tell you what the outstanding unconsumed balance is at any date?
A provider that only records the cash event at purchase has quietly taken that choice away from you.
Concretely. A customer buys the $20 credit pack in March. By June they have used 150 of 1,000 credits and stopped opening the product. At your fiscal year end, 850 credits sit on the balance. Is that revenue? Is it a liability? Is it breakage you can recognise? Whatever your answer, you can only reach it if your provider can tell you — per customer, per period — how many credits were sold and how many were actually consumed.
Break 2: refunds against a balance that is partly gone
A customer buys $500 of credits, uses $120, and asks for their money back.
Under a normal payment processor this is awkward. Under a merchant of record it is structurally harder, because the invoice was issued by the provider as legal seller. Someone has to compute the residual, someone has to amend a document issued in the provider's name, and the tax already remitted on the original sale has to be adjusted on the refunded portion.
The failure mode is that the provider can only refund in full or not at all, so you end up handling partial refunds manually and off-system — which means your records and the legal seller's records diverge. That divergence is exactly what you adopted a merchant of record to avoid.
Before you sign, get a straight answer on three things: can it process a partial refund against a drawn-down balance, does it recompute tax on only the refunded portion, and does the customer receive a corrected document rather than just an unexplained bank reversal.
Concretely. The same customer asks for their money back. The merchant of record already issued a $20 invoice in its own name, and 15% of the pack is gone. Someone has to compute the $17 residual, amend a document issued by the legal seller, and adjust the tax already remitted on the refunded portion only. If your provider can refund in full or not at all, you will do this by hand — and your records and the legal seller's records will diverge.
Break 3: where the supply happened is no longer obvious
We are deliberately not giving you the answer here. The correct treatment of credit sales and place of supply depends on your jurisdiction, your terms and your auditor. What a provider can do is make the right treatment possible — and whether it has a documented position is itself a useful signal.
Tax on a digital sale generally turns on where the customer is. With a subscription that is settled once and stays settled.
With credits, the sale and the consumption can happen in different places. A customer buys a balance in one country and spends it over six months, part of it while living somewhere else. Which event determines the place of supply, and what evidence supports that determination?
We are deliberately not going to tell you the answer, because it depends on the jurisdictions involved and it changes. What we will say is that this is a question your provider should have a documented position on, and the absence of a position is itself informative. If a provider has genuinely handled credit-based products across borders, it has been forced to think about this. If it has not, you will be the one who finds out.
Concretely. A customer buys $500 of credits while living in Singapore, then relocates to Germany and consumes the remaining 60% over the following six months. Which event fixes the place of supply — the purchase, or each act of consumption? What evidence supports that position? Your provider should be able to say, and an inability to answer tells you how much credit-based cross-border volume it has actually handled.
Break 4: dispute exposure scales with the top-up
A $49 monthly subscription creates a $49 disputable charge. A customer who tops up a $2,000 API balance in one transaction creates a $2,000 one.
That alone would be manageable. What makes it worse is the timing. A card dispute can arrive sixty days or more after the charge, by which point the credits may be fully consumed. The compute was delivered and paid for on your side. If the dispute succeeds, the money leaves anyway.
So the questions are: who absorbs that loss under the contract, what evidence does the provider actually submit on your behalf, and — the one most people forget to ask — are consumption logs accepted as proof of delivery for a digital service? A provider whose dispute response is tuned for subscriptions will submit a signup record and a charge receipt. For a drawn-down balance, that is the wrong evidence.
Concretely. An enterprise account tops up $2,000 to run an agent workflow and burns through 40,000 runs in three weeks. On day 58 the cardholder disputes the charge. The compute was delivered, your inference costs were paid, and the credits are gone. If the dispute succeeds, the money leaves anyway — so ask who absorbs it, and whether consumption logs are accepted as proof of delivery.
Break 5: the invoice has to survive a finance department
This one sounds cosmetic and is not. It is where deals stall.
A hybrid invoice has to show a base subscription, metered usage with the unit and quantity that produced the charge, any included allowance that was consumed before metering began, the tax treatment of each line, and the legal seller's details. A buyer's finance team has to be able to approve it without emailing you to ask what a number means.
If your provider can only emit a single total, every business customer you have will slow down at the exact moment you want them to expand. For self-serve consumer purchases nobody reads the invoice. For the accounts that actually grow your revenue, someone reads every line.
Concretely. A buyer's finance team receives an invoice for $3,247.80 with a single line reading "API usage." Procurement cannot approve a number it cannot reconstruct, so the invoice goes back to your champion, who emails you, and the payment slips a cycle. The fix is structural, not cosmetic: unit, quantity and rate on every metered line.
What to require from a merchant of record
If you sell on consumption, put these in front of any merchant of record before you integrate.
On measurement and reporting
- Credits sold and credits consumed reported as separate series, per customer, per period
- Outstanding unconsumed balance queryable at an arbitrary date
- Usage records retrievable through an API, not only visible in a dashboard
On money movement
- Partial refunds against a drawn-down balance, with tax recomputed on the refunded portion only
- A corrected document issued to the customer, not just a bank reversal
- A documented position on place of supply for prepaid credits consumed across borders
On risk
- Written allocation of chargeback liability
- Consumption logs accepted as delivery evidence in dispute responses
- Dispute-response templates that exist for metered products specifically
On the invoice
- Subscription, allowance, and overage as separate lines
- Unit and quantity shown for every metered line
- Per-line tax treatment and the legal seller's details
Any provider can say it supports usage-based billing. These are the questions that separate the ones that have actually run it from the ones that have only configured it.
If you price on consumption, these are the questions worth putting to any provider — including us.
Where Waffo Pancake fits
Waffo Pancake operates as a merchant of record whose billing covers subscription, usage-quota and on-demand (dynamic price-snapshot) models. To be precise about the boundary: Pancake does not provide built-in usage metering — you measure consumption in your own system or with an external metering service, and Pancake turns that number into an order, a payment, an invoice and a remitted tax. If you are pricing an AI product on consumption and want to walk through the specifics above against your own model, see how billing and subscriptions work, read about the AI integration, or start with what a merchant of record actually does.
This article is general information, not tax, legal, or financial advice. Tax rates and rules change; verify current requirements with the relevant authority or a qualified advisor before acting.
Frequently Asked Questions
Can a merchant of record handle usage-based billing?
Some can, many cannot do it well. The merchant of record model matured around flat-rate SaaS subscriptions, where the amount is known before the charge. Usage-based billing inverts that: the amount is only known after consumption. Ask a provider specifically how it handles prepaid credit balances, mid-period overage, partial refunds against consumed usage, and hybrid invoices that combine a subscription line with metered lines.
When is revenue earned on prepaid AI credits — at purchase or at consumption?
This is the central accounting question for credit-based products, and it is not one a billing vendor can answer for you. What matters operationally is that your merchant of record can report both events separately: credits sold and credits consumed, per customer, per period. If your provider only reports the cash event at purchase, you lose the data needed to recognize revenue on consumption and to quantify unused balances.
What happens when a customer wants a refund on partially consumed credits?
Someone has to compute the residual value and someone has to amend an invoice that a legal seller already issued. Under a merchant of record, that seller is the provider, not you. Confirm before you sign: can it process a partial refund against a credit balance, does it recompute tax on the refunded portion, and does the customer receive a corrected document rather than just a bank reversal.
Why do chargebacks hurt more with usage-based billing?
Dispute exposure scales with ticket size. A customer who tops up a large API balance in one transaction creates a single disputable charge far larger than a monthly subscription, and the dispute may arrive after the credits have been consumed — meaning the service was delivered and the money leaves anyway. Ask who absorbs that loss, what evidence the provider submits on your behalf, and whether consumption logs are accepted as delivery proof.
What should a hybrid subscription-plus-usage invoice show?
Enough for a finance team to approve it without emailing you. That means the base subscription as its own line, metered usage with the unit and quantity that produced the charge, any included allowance that was consumed before metering started, the tax treatment of each line, and the legal seller's details. If your provider can only emit a single total, expect payment delays on every business account.
What is the difference between usage-based billing and metered billing?
They are used interchangeably in practice. Both mean the charge is computed from measured consumption rather than a fixed price agreed in advance. The distinction that actually matters commercially is prepaid versus postpaid: whether the customer buys a credit balance up front and draws it down, or consumes first and is invoiced in arrears. Those two models create different tax, refund, and credit-risk problems.
Waffo Pancake is a Merchant of Record platform for developers and solo founders — we handle global payments, tax, and compliance across 173 countries so you can focus on building. Our team writes these guides from hands-on payments and billing experience.
About Waffo Pancake →
