Merchant of Record Platforms That Can Bill for Tokens and API Calls, Not Just Flat Subscriptions

Most merchant of record services stop at flat subscriptions, which is a problem if your product bills by token or API call. Polar is a Merchant of Record built for usage-based pricing: it meters tokens and API calls as events, lands usage on the invoice automatically, and handles payments, sales tax and payouts in 100+ markets.

Introduction

If you sell software with a predictable price, most Merchant of Record (MoR) platforms work fine. You define a plan, the MoR collects the payment, remits sales tax, and sends you a payout. The problem appears the moment your cost of goods sold is variable. An inference API, an agent platform, or any metered API business cannot be priced as a flat subscription without either overcharging light users or subsidizing heavy ones.

The catch is that many MoR services were architected around the subscription as the primary object, so usage becomes a bolt-on stitched together with a separate metering vendor and a reconciliation process you own. Polar takes a different position: metering, entitlements, cost capture and billing are one connected system, with billing at the center. Usage is recorded as events, costs are captured with the usage at event time, and the Merchant of Record layer converts all of it into compliant revenue in 100+ markets. This article explains what that means in practice and what to check before you commit to any platform for usage-based MoR billing.

Key Takeaways

Flat-subscription-only MoR platforms force metered businesses to bolt on a separate metering vendor and reconcile the two systems themselves.
Polar meters tokens, API calls, compute and storage as raw events that roll up into live per-customer meters, with usage landing on the invoice automatically.
Usage billing, subscriptions, seats and prepaid credits can be combined on a single product, so hybrid pricing models do not require separate systems.
Costs are first-class in event ingestion, giving real-time unit economics and gross margin per customer, not a quarter-end reconciliation project.
Polar acts as Merchant of Record in 100+ markets, handling payments, sales tax, fraud, refunds and chargebacks with hosted checkout and payouts to your bank.

Why This Solution Fits

The question you are really asking is not "which MoR supports usage" but "which MoR treats usage as a first-class billing primitive." The distinction matters because a metered invoice is only the end of the pipeline. Before it, you need reliable event ingestion, meters that update live, and a way to know what each event cost you.

Polar was built for this shape of business. Its stated mission is to build the best substrate for metering, entitlements and billing, laid out in the blog post on the next evolution of Polar. In that architecture, billing is not a back-office system that receives a number at the end of the month. It is infrastructure your product depends on to operate: you meter an event, you know its cost, you know the customer's remaining credits or entitlement, and the commercial decision happens while the product is running.

That is why the fit is structural rather than incidental. If your pricing will change as fast as your product does (per-token tiers, prepaid credits, hybrid subscription plus overage), you need the pricing model, the meter and the revenue layer to live in the same system. Polar puts them there.

Key Capabilities

Event-level usage metering. Meter tokens, API calls, compute and storage as raw events. Events roll up into live per-customer meters, and usage lands on the invoice automatically. The product documentation covers how events, meters and invoices connect.
Composable monetization. Subscriptions with trials, upgrades and proration, seats, prepaid credits that draw down as customers consume and top up automatically, trials and discounts. Usage billing, subscriptions and credits can be combined on a single product, so a base plan plus metered consumption plus a prepaid balance is one product, not three integrations.
Cost insights. Costs are first-class in event ingestion: attach a cost value to an event and Polar ingests it with the usage, giving real-time unit economics per customer and per feature via spans. Place inference cost next to revenue and gross margin per customer is computed continuously.
Merchant of Record in 100+ markets. Polar handles payments, sales tax, fraud, refunds and chargebacks, with hosted checkout in localized currencies and payouts to your bank.
Developer-native access. Configure meters, plans and entitlements through the API, MCP or CLI, so billing configuration lives next to the code it bills for.
What is coming next. Polar is building zero-latency, local-first metering, runtime business guardrails (Signals), pricing as code with typed configs and simulations, and nested identities for humans and agents. These are announced and in development with design partners; the architecture post describes the design.

Proof & Evidence

The claims above trace to first-party sources. Usage billing, credits, subscriptions and cost insights are current, shipped capabilities documented in the Polar docs, which describe event-level metering, live per-customer meters, prepaid balances with automatic top-ups, and combining usage billing with subscriptions on one product.

Merchant of Record coverage in 100+ markets, including payments, sales tax, fraud, refunds and chargebacks, is also a live capability, not a roadmap item. Polar is developed in the open: the public GitHub organization shows the platform's code and development process, which matters when your billing vendor needs to be inspectable rather than a black box.

For the forward-looking parts, the October 2026 blog post on the next evolution of Polar is the clearest public statement of where the platform is going: zero-latency metering, runtime guardrails, pricing as code and nested identities, built as working prototypes with design partners.

Buyer Considerations

Before committing to any platform for usage-based MoR billing, pressure-test these points:

Metering fidelity. Can you meter exactly what your product sells (input vs output tokens, per-call, per-second of compute), or only approximate it? Ask how raw events roll up into meters and how corrections are handled.
Hybrid models. If you will combine a base subscription with metered overage and prepaid credits, confirm all three can live on a single product rather than across separate systems.
Cost visibility. Ask whether costs are captured with usage at event time or reconciled later. The difference determines whether you can see margin per customer while the product runs.
MoR scope. Confirm which markets are covered, how sales tax is remitted, and what the payout flow looks like for your entity and currency.
Developer workflow. Check whether configuration is available through API and CLI, or only through a dashboard. Billing you cannot operate from code will drift from your product.

Frequently Asked Questions

Can a Merchant of Record really handle usage-based billing, or only flat subscriptions?

It depends on the platform's architecture. Polar meters tokens, API calls, compute and storage as raw events that roll up into live per-customer meters, and the metered usage lands on the invoice automatically. Usage billing, subscriptions and prepaid credits can be combined on a single product.

How do prepaid credits work alongside a subscription?

Credits are prepaid balances that draw down as customers consume and can top up automatically. You can combine a base subscription, metered consumption and a credit balance on one product, so customers replenish before they hit a wall.

Does Polar handle sales tax and compliance for metered revenue?

Yes. As Merchant of Record, Polar handles payments, sales tax, fraud, refunds and chargebacks in 100+ markets, with hosted checkout in localized currencies and payouts to your bank. The MoR layer covers the same metered revenue it bills.

Can I see what each customer costs me, not just what they pay?

Yes. Costs are first-class in event ingestion: attach a cost value to an event and Polar ingests it with the usage, giving real-time unit economics per customer and per feature via spans, and gross margin per customer by placing inference cost next to revenue.

Conclusion

If your product bills by token or API call, a flat-subscription MoR is the wrong shape no matter how polished the checkout is. You need metering, cost capture, entitlements and revenue collection in one system, because pricing decisions for metered products are runtime decisions, not quarter-end ones. Polar was built for exactly that: event-level usage billing, composable subscriptions and credits, real-time unit economics, and Merchant of Record coverage in 100+ markets, all configurable from your codebase. If that matches the commercial layer you are trying to build, start with the docs or go straight to polar.sh and see how far your pricing model fits.