The core of this system rests on a foundational principle: currency-specific credit balances are never directly modified. Rather than a simple mutable counter, which is prone to race conditions and opaque manual adjustments, we utilize a comprehensive, immutable ledger of movements. Every grant, charge, and expiration is logged as a permanent record. This design ensures that every change is self-explanatory, eliminating the risk of double-charging or untraceable edits by replacing overwrites with a chronological stream of definitive events.

This architecture rigor of Kong Konnect Meter & Billing is what enables the commercial agility discussed in our launch post without compromising financial integrity. By separating fiat payment from live consumption, we provide a verifiable audit trail essential for revenue recognition and resolving support inquiries. Konnect’s ledger calculates the current balance by querying this historical log rather than relying on a static value. Grants generate a funded movement, while settlement-based charges create a consumed entry for each underlying grant. Credits can even have a usage duration which, once passed, causes them to be recorded as expired. Consequently, the balance surfaced to users or finance teams is always reconstructable and fundamentally accurate by its very construction.

With the structural framework providing audit-ready confidence, the following steps go through an implementation from start to finish.

This is the one decision that determines how much financial risk your business is actually carrying, so it's worth treating as a strategic choice rather than a default. In the Product Catalog Plans, you now have a new option on what type of settlement mode this product will use. If you choose the ‘Credits only’ mode, all the usage on that rate card draws from the customer's existing credit balance rather than generating a standard post-consumption invoice. A simple and straightforward credit model tied to the customer wallet. On a Credit-only plan, exhausted credits either block further usage or let the ledger go negative, depending on how you configure the plan. It is key to decide which you want up front, since it determines whether a runaway workload gets stopped or just tracked for later collection.

If you want a prepaid-plus-overage model instead, where credits get consumed first, and then the customer is invoiced for anything beyond, use Invoice overage mode. The same grant and monitoring steps apply either way; only the behavior at zero balance changes.  Any existing Product Plans will be configured in this mode as without any credits this provides identical behavior prior to this feature release.  

Billing Customers are the entity credits attached to using that customer currency. Changing the currency after issuing a credit grant will cause unique fiat currency wallets to be created. At the moment, funds granted in one currency can not be transferred to a different currency.

One access note before you go further: issuing grants and managing plans requires the Metering & Billing Admin role in Konnect. If you're scoping this out for a team, decide now who holds that role — it's worth limiting given that it controls real money movement.

This is where the launch post's growth story actually gets implemented — onboarding credit, loyalty rewards, and negotiated purchases all become the same underlying object, configured differently. A grant needs an amount, currency, funding method, and — optionally — priority and expiration.

The example above uses Promotional funding, which is usable immediately with no payment workflow. It is set to expire after 1 month which is optional but encourages consumption behaviors. We have also set the priority, which allows the sequencing of which grants will get used up first. If you're selling credits rather than giving them away, the configuration is slightly different. 

Here, the customer receives 100.00 USD in credits, but the invoice generated against them is 80.00 USD, based on the negotiated per-unit cost basis. The credit amount and purchase amount are intentionally decoupled which allows you to run discounts or negotiated rates without touching the credit ledger logic at all. In this example the credit won’t expire until after a year from when it was granted. The priority of the grant is also lower so the promotional grant will get used up first.

If you handle payment outside Konnect entirely, use the Externally Settled charge type for  funding and sync settlement status yourself as the external payment clears:

In all cases when issuing the grant we immediately record the funds as moved and increase the customer's settled balance with no separate activation step.In the future additional stages for credit availability will be supported such as on payment settlement. 

When a customer has multiple grants it is critical to understand how the priority is handled. Let’s take this draw down** **as an example**.** Say a customer holds three grants in USD:

A 90-credit worth of charge comes in. Konnect will consume 50 from A (same priority as B, but it expires sooner), then 40 from B, and leaves C untouched because its priority value is higher. Use this to design grant strategy deliberately. For example, if you want a promotional credit to definitely burn before a customer's purchased balance, give it a lower priority number, not just an earlier expiration date.

So a quick recap on the key configuration points:

• - Charge Type:** **determines the commercial story behind the credits. 
• - Promotional for free credit, 
• - Invoice when the customer is paying through Konnect billing (the credit amount and invoice amount can legitimately differ based on per-unit cost) 
• - External when payment is reconciled in your own system and synced back.
• - Expires after: An optional field and only affects unused credits. If a customer spends part of a grant before expiration, only the remainder expires. 
• - Credit draw-down priority: Controls the order of credit consumption when a customer holds multiple grants in the same currency. Lower values draw down first; ties are broken by earliest expiration, then by stable movement order. This is deterministic and worth designing around. For example, give promotional credits a lower priority like we did so they burn before purchased credits.

Once the subscription and grant exist, metered usage on the Credit only (or Invoice overage) rate card consumes credits automatically. There's no separate "spend credit" call to make and no reconciliation job to run. Billing applies credits as charges are processed, using the deterministic draw-down order described above. This is what turns "we have a credit system" into "engineering doesn't have to think about it after setup."

As part of our ledger we provide two different yet important numbers: settled and pending balances.

Use settled balance for audit-style point in time specific views and only reflect committed movements. For example on Monday the total credit balance might be $80 USD but the next day due to expiration the balance could drop to $0 USD. The settled balance for Monday will always be $80 regardless of funding changes that occur after. If support or finance ever asks "what was the balance when this invoice was cut," the answer depends on which timestamp you query, not just which movements exist today.

The pending balance when you need a conservative answer to "can this customer keep going?", since it also accounts for open, not-yet-finalized charges. If for example I have the same $80 USD in my settled balance but have open charges for $20 USD the pending balance would show $60 USD. Only when the Subscription billing cadence is triggered or the subscription is cancelled does a pending balance get converted into a settled balance.

This walkthrough covers the common path. If you're designing for multiple simultaneous grants, want to understand exactly how draw-down order interacts with expiration, or need the accounting detail behind why balances are always correct, the documentation will go even deeper.

Prepaid credits are live now in Kong Konnect Metering & Billing. The business case is straightforward: get paid before usage happens. The reason it's safe to build a financial strategy on top of it is everything above: an immutable, auditable ledger, deterministic consumption order, and a balance that's always derived rather than asserted. That's the difference between a credit counter and a credit system where you can put real revenue protection behind.

*Ready to stop floating receivables and start collecting before consumption? *[_*Get started*_](https://konghq.com/products/kong-konnect/features/usage-based-metering-and-billing)_*Get started*_* with Konnet Metering & Billing or *[_*talk to our team.*_](https://konghq.com/contact-sales)_*talk to our team.*_