Metered and seat-based SaaS billing in USDC — what actually changes

SaaS billing has two dominant shapes — seat-based subscriptions and metered usage — and a stablecoin rail changes them differently. Seat-based billing gets a cleaner settlement mechanic and loses the card network's built-in retry infrastructure for failed payments. Metered billing gets something closer to real-time settlement per usage event — a genuinely new capability, not just a faster old one. As of 2 Sep 2026, none of this is live — Arc mainnet launches 16 September 2026.

Seat-based billing: what's lost is the card network's retry machinery

A typical SaaS subscription charges a card on a recurring schedule. When a charge fails — expired card, insufficient funds, a fraud filter — the card ecosystem has built substantial recovery infrastructure: retry logic timed against likely balance refreshes, card-updater services that silently refresh an expired number, and issuer signals informing how to retry.

A USDC-on-Arc charge doesn't fail the same way. There's no issuer declining for insufficient funds — a wallet either holds enough USDC (plus gas) or it doesn't, and the provider finds out by checking the balance, not a decline code with a reason. A SaaS company billing in USDC has no equivalent to lean on for automatic revenue recovery; dunning becomes "detect an insufficient balance, notify the customer, re-attempt on a schedule you design" rather than a managed retry product — a real gap in ecosystem maturity, not a wash.

Metered billing: a genuine upgrade

Usage-based billing — per API call, per compute-hour — has always fought against payment rails built for periodic, batched charges. Most metered products bill in arrears because charging a card per usage event is operationally absurd (fees alone could exceed many individual charges). Arc's dollar-denominated, sub-second-finality settlement opens a different design space: settling usage closer to consumption, in smaller increments, without the same batching-arrears risk. That's not automatically right for every product — batching still reduces transaction overhead and gives customers a predictable bill — but it's a capability card rails genuinely can't offer at any reasonable cost.

Dunning without card retries

With no card-network retry machinery to inherit, a SaaS company needs its own explicit design: how often to check a wallet balance against what's owed, how many notification attempts before treating an account as delinquent, and what enforcement actually looks like (suspending access, after how long) since there's no equivalent to a card simply being declined at the next charge attempt. None of this is technically hard to build, but none of it is bundled the way Stripe's dunning product is bundled today — budget the engineering time.

Proration: the math doesn't change, settlement timing might

Proration — crediting or charging the partial-period difference on a mid-cycle plan change — is pure arithmetic, identical whether the charge lands via card or USDC. What can change is settlement timing: a card-based proration credit typically nets against the next statement or refunds over several business days, while a USDC adjustment can settle immediately in either direction, with no multi-day reversal process to wait on. A minor operational convenience, not a structural change.

Revenue recognition timing: an open question, not a solved one

This is one place this guide won't hand a controller an answer. Revenue recognition under US GAAP (ASC 606) and IFRS (IFRS 15) turns on when performance obligations are satisfied and price is measurable — questions about service delivery, not the payment rail. Whether receiving payment in USDC changes *when* revenue is recognized (as opposed to how a receivable is subsequently measured, a separate accounting question tied to how the entity classifies its USDC holdings) is for a company's own accountant against its specific facts. Built on Arc's guide to accounting questions for USDC on Arc lays out the shape of that broader question without answering it — this is not accounting or tax advice.

What's confirmed for Arc specifically

Arc's EVM execution layer means billing integrations — smart contracts triggering on usage events, subscription logic settled on-chain — can be built with familiar Solidity tooling. Gas paid in USDC with an EIP-1559-style base fee makes per-transaction cost dollar-denominated, though actual per-transaction cost at mainnet volume isn't yet confirmed as of 2 Sep 2026. No named SaaS billing product built specifically on Arc was confirmed in Built on Arc's research; this describes what the rail's mechanics make possible, not a live product.

Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.

Sources: - Circle: Introducing Arc - Circle Announces Founding Validator Cohort and Major Integrations for Arc