What Does One Credit Buy? Design Packages Customers Can Actually Compare

A customer looking at your pricing page should not need a spreadsheet to understand what they are buying. “1,000 credits” is a quantity, not an explanation of value. The useful question is what those credits let someone do—and how that changes between packages.

For your October 11, 2026 pricing review, start with the relationship between a purchase and a useful product action. Cred gives you credit types and pricing tiers; your application still decides which actions consume credits and how clearly that cost is presented.

This guide focuses on package design rather than subscription mechanics. The objective is a purchase decision customers can understand and a pricing model you can maintain.

Define the unit before naming the package

Choose a credit unit that maps cleanly to the work your application performs. A fixed-cost export might consume a fixed number of credits. A task whose cost depends on duration or input size needs a clearly disclosed calculation or estimate.

Avoid saying “one credit equals one task” if different tasks consume different amounts. Show the expected deduction before the customer starts, and explain what could change it. Your application must implement that presentation; the ledger cannot infer what your user interface promised.

Start with one credit type when the product has one coherent usage economy. Add another only when customers genuinely need a separate balance or a distinct spending unit—not just because you have added a feature.

Compare packages using the same denominator

Cred pricing tiers associate a credit quantity with a purchase price. That lets you offer different package sizes and evaluate their effective price per credit.

Consider this illustrative example, not Cred's own pricing:

Package	Credits	Price in USD	Price per credit
Small	500	$5.00	$0.010
Medium	2,000	$18.00	$0.009
Large	5,000	$40.00	$0.008

If an export costs 25 credits, these packages support 20, 80, and 200 such exports respectively, assuming the balance is spent only on that action. That is more informative than “best value” alone.

Use one currency consistently in the comparison. Do not compare the total price of one package with the per-credit price of another. If usage varies, label the action count as an example rather than a guaranteed allowance.

Model discounts against expensive usage, too

A larger purchase can have a lower unit price, but that discount is your economic decision—not proof that the underlying work becomes cheaper.

For each proposed tier, estimate the cost of serving its credits under both ordinary and expensive usage patterns. Include the costs your business actually pays: model inference, storage, payment processing, and support where relevant. Use your own measured figures rather than a generic industry margin.

The critical case is a customer spending the discounted package entirely on your most expensive permitted action. If that makes the package unsustainable, adjust the package or the action's credit cost before launch.

Changing the price of a future package is different from changing what an existing balance can buy. Treat those as separate customer-facing decisions, and communicate material consumption changes deliberately.

Keep purchase price and ledger amounts distinct

The pricing reference is the integration contract for retrieving tiers. Cred returns tier prices as two-decimal strings. Parse those deliberately for calculations, and preserve their currency when displaying them.

A credit balance or transaction amount measures credits, not money. Do not display a deduction as a currency charge merely because the customer originally bought that balance with a card. Likewise, a discounted package does not establish a universal cash value for every credit in every customer's wallet.

Keep customer application credits distinct from the CRD balance used for your own Cred platform usage. A purchase screen should show the currency your customer can spend in your product, not your integration's operating balance.

Make the terms visible before payment

Package size is only part of the offer. Customers also need to know whether the purchase is one-off or recurring, which credit type it funds, and what policies apply to unused credits.

Do not invent expiry, rollover, transfer, or refund promises just because the product uses a wallet. Define those policies for your application and confirm that your implementation supports them. For recurring replenishment, use the hybrid billing guide rather than treating a tier name as a billing instruction.

A practical package review

Before publishing your next pricing change:

1. Explain the credit unit in a single literal sentence.
2. Show a representative action cost beside the purchase options.
3. Compare every package using the same currency and denominator.
4. Check discounted economics against expensive permitted usage.
5. Confirm checkout funds the advertised quantity and credit type.
6. State the billing schedule and your unused-credit policies clearly.

Clear credit pricing is not about hiding complexity behind a new currency. It is about making consumption understandable while keeping package design flexible. Build the tiers in Cred, then make their practical meaning visible in your application.