> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/feature-guides/acquire-and-convert/guide-usage-based-signup-with-credits.md). # Building a Usage-Based Signup with Credit Top-Ups ### Overview Not every product sells by the seat. APIs, messaging, compute, and AI products bill by what the customer *uses* — and customers want to start small, prepay a balance, and top up when they run low. A **usage-based signup journey** signs a customer onto a metered plan and (optionally) sells them a starter pack of **credits**, with a self-service **top-up** flow they can return to whenever their balance runs down. This guide builds both halves: the metered signup, and the credit top-up that keeps the account funded. ### The example we'll build **Vela, an SMS API platform,** sells messages by the unit. A developer signs up on a **pay-as-you-go** metered plan, buys a **$50 starter credit pack**, and sends messages against that balance. When the balance runs low, Vela prompts them to top up — a two-click flow that adds more credits without touching the subscription. ### Before you begin * A **metered plan** in your catalog. In **Commerce → Product Catalog**, a product's charges can be **Flat Fee, Per Unit, Tiered, or Volume** bands — use Per Unit/Tiered/Volume for usage pricing (for Synced products, set the charges in your billing system and re-sync). * If you're selling prepaid balances, your account model supports **credits** — prepaid or goodwill balances attached to an account, with an aggregate **credit balance** you can apply against a payment. ### 1. Build the metered signup journey 1. Go to **Content → Journeys** and click **+ New Journey**. 2. Set **Type** to **E-Commerce** and name it (for example *SMS API — Signup*). 3. Build the flow: **Plan (metered) → Signup → Billing → Confirmation** * **Plan** — present the metered plan; make clear it's priced per unit (and show any included volume or tier breaks). * **Signup / Billing** — the usual **Signup** and **Payment** roles create the account and capture a method. * **Confirmation** — show the customer they're live and what their balance / rate is. ### 2. Sell a starter credit pack (optional) Many usage products pair a metered plan with a **prepaid balance** so customers aren't billed in arrears: * Add a step (or a choice on the plan step) to buy a **credit pack** — for example $50 of credits. * On purchase, **issue a credit** to the account; the credit becomes part of the account's **credit balance**, which can be **applied against payments**. The customer now draws down a prepaid balance as they use the product. A pure pay-as-you-go model skips this — the customer is simply billed for usage. Selling credits up front improves cash flow and gives customers a spend cap they control. ### 3. Build the top-up flow The top-up is its own short flow the customer returns to — keep it separate from the subscription so refilling a balance never risks a plan change: 1. Create a small **Customer Self-Service** journey (or a payment page) named *Add Credits*. 2. **Show the current balance** so the customer knows where they stand. 3. Let them pick a top-up amount, take payment, and **issue the new credit** to the account — raising the balance immediately. Link this flow from the customer portal and from low-balance notifications. ### 4. Prompt before they run dry Usage products lose customers to *empty balances mid-task*, not to churn decisions: * Use **notification templates** to send a **low-balance** alert ("You have \~500 messages left") with a direct link to the top-up flow. * Optionally surface a balance meter and a **Top up** button in the customer portal so they can refill the moment they notice. ### 5. Measure usage and balances * Watch signups and top-up volume on the **Analytics** funnels. * Track **credit balances** at the account level (the aggregate balance is queryable) so you — and your customers — always know what's funded. ### Get creative * **Auto-recharge.** Offer "top up automatically when my balance drops below $10" so heavy users never run dry (a stored method + a recurring top-up). * **Volume discounts.** Use **Tiered** or **Volume** charges so heavier usage earns a better unit rate — and surface the next tier as an incentive. * **Goodwill credits.** Issue a credit as a save offer or apology (a CSR drops $20 of credits on an account) — the same credit mechanism powers retention gestures. * **Free starter balance.** Seed new signups with a small free credit so they can try before they fund. ### Tips * **Pick the right charge model.** Per Unit for simple usage, Tiered/Volume when you want unit price to change with quantity — set this on the product's charges. * **Keep top-ups off the subscription.** Refilling a balance is a payment + credit issuance, not a plan change — build it as its own flow so the two never collide. * **Warn early.** A low-balance nudge with a one-click top-up recovers far more usage than a hard stop. ### FAQ **How do I price by usage?** On the product's charges, use **Per Unit**, **Tiered**, or **Volume** bands instead of a flat fee (for Synced products, configure the charges in your billing system and re-sync). The metered plan then bills by quantity. **What are credits, exactly?** Prepaid or goodwill **balances attached to an account**. You issue credits, the account carries an aggregate **credit balance**, and that balance can be applied against payments — ideal for prepaid usage and for goodwill gestures. **Should I sell credits or just bill for usage?** Both work. Prepaid credits improve cash flow and give customers a spend cap; pure pay-as-you-go is lower-friction to start. Many products offer a starter credit pack *and* metered billing for overage. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/guides/feature-guides/acquire-and-convert/guide-usage-based-signup-with-credits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.