Top-ups are the moment billing stops being abstract. A user has burned credits doing real work; they need to trust that buying “more” is straightforward and that balance updates immediately when Stripe says the payment succeeded.
This is written for product and engineering teams wiring Stripe Checkout into a credit wallet. You will get a packaging framework, anti-patterns to avoid, and a clear picture of how Chargly keeps Checkout and balances aligned.
The job packs are really doing
Users are not optimizing dollars-per-credit at checkout. They are asking:
- Will this get me unstuck right now?
- Is this the right size for how I use the product?
- Will my balance actually update so I can continue?
If your packs read like internal SKUs, you lose on all three.
A practical pack ladder
Most products land on three or four offers:
- Try / starter — enough credits to complete a real workflow once or twice. Low friction, low commitment.
- Regular — matches your median weekly or monthly usage for an engaged solo user.
- Power — better effective rate; targets teams or heavy individual use.
- (Optional) Team / annual — only when you truly have a different buyer and usage shape.
Name packs for intent, not inventory:
- “Starter,” “Standard,” “Plus” — boring but legible
- “Builder,” “Ship,” “Scale” — fine if your audience expects that voice
- “Pack A / Pack B” — never; it signals you have not thought about the buyer
Pricing mechanics users already understand
Volume discounts are normal. If the largest pack has a better effective cost per credit, say so plainly on the purchase screen: “Best value for regular use.” Hiding the math invites distrust; over-explaining it invites confusion. One line of plain language is enough.
Packaging principle
Each pack should answer: who it is for, how many credits, and what it costs. Anything else is optional chrome.
What happens after Checkout (and why it must be boring)
The flow you want is deceptively simple: user pays → webhook fires → wallet credits increase → user returns to the product with a fresh balance. Boring is good. Manual reconciliation is where teams lose weekends.
Chargly generates Checkout sessions for configured packs and relies on Stripe webhooks to sync purchases into wallet state. Your product should treat the wallet API as canonical after sync — not “maybe the payment worked.”
Checkout → wallet (mental model)
- User selects a pack and completes Stripe Checkout
- Stripe sends a webhook Chargly handles for credit grant
- Wallet balance updates; ledger shows the top-up line item
- User continues metering from the same customer / wallet identity
Failure modes worth designing for
Stale UI — If the user lands back in your app before webhook latency clears, show a “refreshing balance” state instead of a hard error.
Ambiguous packs — If two packs differ only slightly in credits, users stall. Differentiate on story (trial vs steady use) or merge them.
Surprise foreign fees / taxes — Stripe can help disclose totals; your copy should not promise an all-in price that Checkout cannot honor.
How this fits the rest of Chargly
Packs are one half of the loop; metering is the other. Strong pack design plus clean event names makes support and analytics easier: every deduction line in the ledger should read like the product, every top-up like a receipt.
You are not “selling Stripe objects.” You are selling continuity of work — and packs are the packaging for that promise.