Credit-based pricing for APIs: why we chose credits over per-call
Micropayments have a bad reputation. Subscriptions don't fit bursty usage. Credits sit in the middle — and map cleanly to what developers actually think about.
When you're pricing an API, you have three basic options: per-call (micropayments), subscription (flat monthly), or credits (pre-purchased units). Each has trade-offs.
Why not per-call?
Per-call pricing sounds fair — you pay for exactly what you use. But it has real problems:
- Unpredictable costs. Your bill depends on how much your agent does, which can vary wildly week to week. - Mental overhead. Every API call has a visible dollar cost. Developers start optimising around price instead of building. - Billing complexity. Charging $0.02 per call means thousands of tiny transactions. Stripe fees eat into margins.
Per-call works when individual calls are expensive (compute-heavy ML inference, for example). For a product search that costs us fractions of a cent to serve, it's the wrong model.
Why not pure subscription?
Subscriptions are predictable and simple. But they don't fit bursty usage patterns. A developer building a new integration might use 500 credits in a week, then nothing for a month. A flat subscription either overcharges them (wasting money in quiet months) or undercharges them (running out in busy months).
Why credits?
Credits sit in the middle:
- Predictable unit cost. 1 credit = 1 search, 2 credits = 1 product lookup. The developer knows exactly what things cost. - Flexible purchasing. Buy a credit pack when you need it. Subscribe for monthly allocation. Mix and match. - No waste. Credits don't expire (on packs). You're not paying for a subscription you don't use every month. - Simple billing. One Stripe transaction for a credit pack, not thousands of micropayments.
Our implementation
TradeSDK offers both: subscription plans with monthly credit allocations (Free: 10, Starter: 100, Pro: 500, Business: 2000), plus one-time credit packs (50, 200, 500, 1000 credits) that never expire.
The mapping is transparent:
- bunnings_search = 1 credit
- bunnings_product = 2 credits
- nuway_search = 1 credit
- nuway_product = 2 credits
No hidden costs. No surprise bills. The developer can reason about what their agent will cost to run.
The psychology
Credits also work psychologically. A developer thinks "I have 100 credits left" rather than "I've spent $14.37 this month." The unit is meaningful — it maps to real actions, not abstract dollars. It's the same reason arcade tokens work better than coins: the abstraction creates a mental buffer that reduces purchase anxiety.
We're not claiming credits are revolutionary. But for an API where calls are cheap, usage is bursty, and the customer is a developer who values predictability, they're the right fit.