Subscription Billing & Invoicing is the job of running recurring revenue: plan and price management, usage metering, proration, dunning, and invoices. The catalog scopes it to 35 providers across 822 APIs, banded by how completely each one describes itself.
| Band | Providers |
|---|---|
| exemplar | 5 |
| strong | 15 |
| developing | 4 |
| thin | 6 |
| emerging | 4 |
| minimal | 1 |
Twenty of thirty-five are exemplar or strong. For a use case this operationally unforgiving, that is a healthier distribution than most.
Who is at the top
| Provider | APIs | Composite | Band |
|---|---|---|---|
| Avalara | 71 | 75.7 | exemplar |
| Adyen | 202 | 72.3 | exemplar |
| Paystack | 21 | 68.5 | exemplar |
| Amazon Data Exchange | 6 | 68.2 | exemplar |
| ExchangeRate-API | 7 | 66.4 | exemplar |
| Axway | 33 | 65.2 | strong |
| Tink | 25 | 64.8 | strong |
| Airwallex | 14 | 64.3 | strong |
| dLocal | 16 | 64.1 | strong |
Avalara at the top of a billing use case is the detail worth pausing on. The highest-scoring provider here does tax, not charging. Anyone who has built recurring billing knows why: getting the money is the easy part, and getting the tax right across jurisdictions is where the project actually goes wrong.
A build path
Recurring billing decomposes into five problems, and they are rarely the same vendor.
- Metering — capture what the customer used, idempotently, at volume. This is the piece teams most often build themselves and most often get wrong under retry.
- Rating and plans — turn usage into money. Plan definitions, tiers, proration on mid-cycle change.
- Tax — Avalara’s territory. Jurisdiction, nexus, product taxability. Not a lookup table.
- Collection — Adyen, Airwallex, dLocal, Paystack. Cards, local methods, cross-border. Note that three of the four leaders here are non-US-centric; recurring revenue is a global problem and local payment methods decide conversion.
- Dunning — the retry, notify, and downgrade choreography after a failed charge. The least glamorous component and the one with the largest revenue impact.
The gap in the cohort
Metering is the weakest-described layer in this set. Collection and tax are covered by exemplar-band providers with large, mature surfaces; usage capture is where you find the thin and emerging bands.
That is backwards relative to the risk. A double-counted usage event overbills a customer, and a dropped one silently loses revenue — both discovered at invoice time, weeks later. It is the component that most needs described idempotency semantics, and the one where the catalog finds them least often.
Takeaway
35 providers, 822 APIs, and a tax vendor at the top of a billing use case. Assemble recurring revenue from at least four different providers, expect the collection and tax layers to be well described, and expect to do the hard verification work yourself on metering.
Browse the use case at apis.io/use-cases/subscription-billing/.