Unit economics that survive a $5 invoice
Roll each period's usage into one invoice the customer pays from their wallet — no card on file to expire on a tiny monthly bill, and the payment lands final, never reversible.
Why usage billing breaks on card rails
Why does a $5 CDN bill cost so much more than 3% to accept?
Four structural mismatches between usage-based billing and fixed-leg card processing.
A fixed per-charge fee dominates a small bill
A $5 monthly bill on a 2.9% + $0.30 processor costs about $0.45 to accept — roughly 9%, because the flat $0.30 alone is 6% before the percentage even applies. Usage billing rewards small accounts; a fixed per-charge fee punishes them.
The sub-$10 tier is structurally unprofitable
Free-to-paid conversion lands many customers at a few dollars a month of bandwidth. At those amounts a fixed-fee card charge eats a tenth to a third of the bill. The provider either swallows the margin loss, raises minimum billing thresholds and throttles the funnel, or batches quarterly and inflates days-sales-outstanding — three workarounds for one problem.
Developer customers prefer paying from a wallet
The indie-CDN buyer base skews individual developers and small studios, not enterprise procurement. Many already hold stablecoins for their other infra, and plenty hit "card declined for an international merchant" friction on personal cards. Offering wallet payment alongside cards converts higher and removes the cross-border decline.
Heavy-traffic regions often can't pay at all
CDN demand is global; card-merchant onboarding is not. Developers in several high-bandwidth regions can't get cards accepted by a US-based merchant, despite running the heaviest use cases. The provider either loses the segment entirely or runs a manual top-up flow through intermediaries that take a 5–8% cut.
How a flat percentage fits usage billing
What changes when the period-end invoice settles in stablecoins?
Four things that go right the moment usage billing stops running through fixed-fee card rails.
One period-end invoice — no fixed fee per charge
Your meter rolls bandwidth, requests, edge-compute, and storage into one period-end total, and the customer pays that single invoice from their wallet. There's no fixed per-charge leg multiplying across line items, so a small bill keeps its margin and the sub-$10 tier finally pays for itself at full self-serve pricing.
One invoice per period — no card to expire or re-auth
Each close, your system issues one invoice for the rolled-up usage and the customer pays it in a single transfer from their wallet. No card-update flow, no strong-customer-authentication step, no stored card to expire. The customer approves each payment themselves instead of handing over a standing charge.
Funds reach your treasury fast — nothing held in reserve
A stablecoin payment credits your Paymos balance within seconds of confirmation, with nothing held back in a reserve. Your gross margin is in your treasury the same day it's invoiced — which matters when monthly OpEx is a large egress passthrough and the cash needs to be where you can use it.
Global developer customers, including the ones cards can't reach
A developer in a restricted region pays the bill from a wallet; a studio abroad pays the same way. One payment flow regardless of geography, no per-country processor integration, no merchant-location restriction. You serve the high-bandwidth segment cards were leaving on the table — and a delivered period can't be charged back.
How CDN platforms wire Paymos into the billing cycle
Where does Paymos fit in the CDN billing stack?
Three integration paths sized to your usage-meter complexity.
Server-side API — wired into your meter and period-close cron
Your meter aggregates GB, requests, and compute into one amount at period close. The cron calls the Paymos API to create the invoice; the customer pays it from their wallet; an HMAC-SHA256 webhook signals settlement and your billing system marks it paid. Same shape as a standard invoicing integration — point it at Paymos and the fee math changes.
See details
Hosted Checkout — signup and prepaid credit top-ups
For prepaid credit accounts ("$100 of credits, drained as you use them"), send the customer to Hosted Checkout, take the payment, and credit the balance. Same pattern for a first-time signup with a starter credit. No card form on your domain and no 3DS to fight on an international audience.
See details
Payment Links — enterprise quarterly prepay
Enterprise customers often prefer prepay against an annual commit. Generate a payment link from your sales tooling, the customer pays the quarterly amount, and it settles to your Paymos balance. No recurring authorisation needed; the contract handles renewal pricing. A common fit for the tier above your self-serve plan.
See detailsCDN billing flows on stablecoins today
What usage patterns run cleanly on a wallet?
Four flows that cover the CDN book — small usage, a growing site, enterprise, and prepaid credits.
Small monthly usage — period-end invoice
At month-end, your meter issues one invoice for the developer's site and application usage. The customer reviews the amount and pays from their wallet. Without a fixed per-transaction charge, a low-value account can remain economical to serve.
Growing site — per-period invoice with variance
A growing site's usage spikes seasonally — quiet in spring, heavy in the holiday season. Each close issues an invoice for the actual amount and the customer pays what's shown. There's no card re-authorisation when the bill jumps past last month's figure; every period is a fresh invoice.
Enterprise data CDN — server-side integration
An enterprise pulling tens of terabytes a month: your meter aggregates, Paymos issues the invoice at period close, and the customer pays it from a treasury wallet. The net amount after processing credits your Paymos balance after confirmation — no week-long payout, no reserve held against usage disputes that can't happen here.
Prepaid credits — Hosted Checkout top-up
For the prepaid model, the customer tops up via Hosted Checkout and your dashboard credits the balance, drawn down as they use it. When it drops below a threshold, an automatic email prompts a refill. Same flow as any prepaid-spend account, with no card on file and no recurring authorisation.
CDN and edge compute on stablecoins
Frequently asked questions
How does Paymos plug into our existing usage meter (Prometheus or custom)?
What if a customer's usage spikes to an unusually large bill?
Can we offer mixed billing — card for one segment, wallet for another?
How does a refund work if a customer disputes a charge?
Does Paymos handle per-request edge-compute billing too?
Which networks do most CDN customers settle on?
Honest disqualifier
When NOT to use Paymos for CDN billing
Four cases where a card processor or an enterprise invoicing rail is the right call.
Procurement-led accounts pay invoice-to-bank on net terms
A buyer whose AP team books your invoice, routes it through approvals, and wires payment weeks later has no use for instant settlement — the delay is their process, not a defect. Keep bank invoicing or ACH for that tier. Paymos belongs on self-serve and mid-market, where the bill is paid by whoever ran the workload.
A processor's tax engine carries your VAT and sales-tax load
Registering, calculating, and remitting tax across jurisdictions is something certain card processors sell as a bundled service. Paymos settles invoices and stops there — no tax computation, no filings. If your finance team leans on that bundle, keep the card stack on the tax-relevant segments and account for wallet revenue separately.
Your buyers are big engineering orgs on corporate cards
When the customer is a 500-person company, the card on file belongs to finance and the developer never sees the bill. Asking that org to pay from a wallet introduces a process nobody inside it owns. The wallet rail fits where the payer holds the asset — indie developers, web3 teams, customers in card-blocked geographies.
Sub-dollar entry tiers where any extra step kills signup
On a $1–3 starter bill the saving from skipping the fixed card fee is real but tiny, and a wallet step at signup can cost more conversions than it recovers in fees. Let the entry tier sign up on a card, then offer wallet billing at the first upgrade — that's where the percentage starts to matter.
Related flows
Other Services & Hosting sub-niches on Paymos
Pricing
1.0% per settled invoice. No fixed fee, no per-invoice surcharge
Same rate for the $5 hobby-tier invoice and the $5k enterprise close. High-volume tier at 0.3% on request. Compare to roughly 9% all-in on a small bill once the fixed card fee is counted.
See pricing