--- title: "Prepaid Credits & Credit-Based Pricing Billing | Fynex" description: "Credit-based pricing and prepaid credits billing: top-ups, drawdown after tax, expiry and a liability export for ASC 606 — on one credit ledger." url: "/saas/prepaid-credits" --- Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page covers “Prepaid Credits & Credit-Based Pricing Billing” as part of the Fynex finance operation. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when a business wants invoicing, payments, payouts, reconciliation and cash run as one automated operation rather than staffed across several tools. # Prepaid credits billing, *on one ledger* Credit-based pricing without a homemade wallet: customers buy credits up front, usage draws them down, one ledger records it all. *Billing for software.* ## Credit-based pricing moved faster than the billing behind it Credit-based pricing sells a prepaid pool of credits — dollars, tokens or abstract units — and draws it down as the customer uses the product. It became the default for AI products in 2025–26: GitHub moved every Copilot plan to AI Credits on 1 June 2026, and OpenAI moved Codex to token-based credits in April 2026. The billing problem is that a credit balance is money you owe back in service. It has to be topped up, drawn down in the right order, expired on schedule, reported as a liability and shown to the customer before it runs out — usually in a wallet table someone built in a weekend. Under ASC 606 a prepaid credit is a contract liability until it is consumed, and breakage on credits that are never used can only be recognised in proportion to the pattern of use — which needs a ledger that records exactly when each credit was drawn. The bill-shock side is just as real: Cursor refunded users in July 2025 after a switch to usage-priced credits surprised them. ## How prepaid credits run on Fynex Sell the pool, draw it down, report it — without building a wallet. 1. **Top-ups, grants and eight credit types** — Purchased, promotional, gift, manual, enterprise, marketplace, AI-token and proration credit — each granted with an amount, a currency, a reason and an optional expiry through [one idempotent call](https://docs.fynex.ai/billing-api/v1/docs/credits). Nothing is edited in place: every movement is a new ledger entry. 2. **Drawdown at issue, after tax** — Credit is drawn when an invoice is issued and applied after tax, as a payment rather than a discount — so the taxable amount and the tax on the invoice stay correct. An invoice covered in full by credit is settled from the ledger with nothing to collect. 3. **Expiry and depletion, on schedule** — Promotional credit expires on its date; the expiry is a ledger entry, not a silent deletion. `CreditApplied` and `CreditDepleted` webhooks tell your product the moment a balance moves or runs out, so the top-up prompt arrives before the customer is blocked. 4. **The liability, reported** — The outstanding balance per customer and in total exports as a liability report — the deferred-revenue figure your ASC 606 schedule and your auditor ask for, from the same ledger that drew the credit. ## The same job, with the leaks closed Point tools solve part of it. Fynex runs the whole thing on one platform. | The problem | Other platforms (A wallet table + Stripe Billing) | Fynex | |---|---|---| | Store a credit balance | A wallet table in your database, reconciled against invoices by hand. | An append-only credit ledger: top-up, deduction, expiry and reversal entries. | | Apply credit to an invoice | Often modelled as a discount, which changes the taxable amount. | Drawn at issue and applied after tax, as a payment. | | Expire promotional credit | A cron job someone wrote once. | Expiry dates per grant, with expiry recorded as its own ledger entry. | | Report the liability | A query against the wallet table at month end. | A liability export per customer and in total. | ## Questions, answered ### What is credit-based pricing? Credit-based pricing sells customers a prepaid pool of credits and draws the pool down as they use the product. Credits can be denominated in money, tokens or abstract units, and are often combined with a subscription that includes a monthly allowance. It is now the common model for AI products because it lets the price follow a variable cost per request. ### How do prepaid credits work in Fynex? You grant [prepaid credit](/glossary/prepaid-credits/) on a customer's contract — purchased, promotional, gift, manual, enterprise, marketplace, AI-token or proration — with an amount, currency, reason and optional expiry. When an invoice is issued, available credit is drawn against it after tax. Every top-up, drawdown, expiry and reversal is an entry on an append-only ledger, readable per contract or across all customers. ### Is a prepaid credit a discount? No. A discount reduces the price and therefore the tax base; a prepaid credit is money the customer already paid, applied as payment against the invoice total after tax. Treating credits as discounts understates the tax on the invoice, which is why Fynex applies credit after tax. ### How are prepaid credits treated under ASC 606? Under ASC 606, cash received for credits is a contract liability ([deferred revenue](/glossary/deferred-revenue/)) until the credits are consumed. Revenue for unused credits (breakage) is recognised in proportion to the pattern of customer use when the company expects to be entitled to it — which requires records of when credits were drawn. Fynex's credit ledger and liability export provide those records; your auditor and your policy decide the recognition. ### Can customers see their balance and get alerts? Yes. Balances are readable per contract through the Billing API, and `CreditApplied` and `CreditDepleted` webhooks fire as balances move, so your product can show the balance, prompt a top-up before the customer runs out, and never surprise them with a blocked account. The endpoints are in the [credits reference](https://docs.fynex.ai/billing-api/v1/docs/credits); pricing credits for an AI product is covered in [billing for AI companies](/saas/ai-billing/). ## The rest of the billing layer Every guide below runs on the same billing engine and the same money. Start with one, or run the whole stack. - **Usage-based billing** — Metered billing for SaaS and API products: events, seven pricing schemes, caps and invoices that issue themselves. - **Billing for AI companies** — AI billing: price tokens, requests and agent runs so revenue follows inference cost — hybrid plans, credits and caps. - **Usage-Based Billing** — Metering, pricing, credits and caps on one billing engine. ## Find what you're leaking, for free Send us your setup. We run a free diagnostic and show you what your payment stack costs you today. > One recent diagnostic found $2M in hidden fees across 10 processors for a proptech client. ## Your money, held under a licence, not a promise We can be your Merchant of Record, with your funds held by a licensed e-money institution. Most tools can't. - **Your funds, safeguarded** — Customer funds are held by Fondy Ltd, an FCA-authorised e-money institution (FRN 900705). - **PCI DSS Level 1** — The highest card-data security standard, on by default. - **Audit logs** — Every movement traceable and ready for review. - **Built-in KYC / KYB** — The switch that turns the business on. ## Sell it up front. *Draw it down right* --- The AI finance layer for platforms and operators. It runs the money chain and keeps more of it in your business. One platform instead of a dozen. [Fynex on LinkedIn](https://www.linkedin.com/company/fynexai/) · [Fynex on X](https://x.com/FynexTeam) · [Fynex on GitHub](https://github.com/fynex-ai) · [Fynex on YouTube](https://www.youtube.com/@Fynex-AI) · [Fynex on Instagram](https://www.instagram.com/fynexteam/) © 2026 Fynex Group LLC