Two-layer wallet, on purpose

Most platforms with multiple paid products tie everything to a single balance. You top up once, and every product chips away at that one number. It's simple to explain in a marketing page. It's terrible the moment you have to answer "where did my money go" or "why did my monthly credits not expire when I expected".

Qingwave does it differently. There are two layers, and they never mix.

The master wallet is a payment layer

The master wallet is where you top up. It holds USD. That's the only thing it does. It never gets debited when you generate an image or call an API.

You use it for one thing: buying a plan. When you buy a Studio plan or top up the API gateway, USD comes out of the master wallet and credits drop into the product's own sub-wallet.

Think of the master wallet as your stored-value balance. Like Alipay. It pays for things. It doesn't get used up by things.

This sounds redundant if you're used to single-balance systems. The reason matters.

Each product has its own sub-wallet

Every Qingwave product has a sub-wallet: a wallet that only that product can debit. Studio has one. The API gateway has one. Future products will get one each.

Inside each sub-wallet there are typically three tiers of credits:

• Daily free credits — reset at 00:00. Use them first.
• Monthly plan credits — refill when your plan renews. Expire if not used.
• Permanent credits — bought à la carte. Never expire.

Usage drains in that order: daily → monthly → permanent. The soonest-to-expire bucket gets used first, so you don't accidentally let monthly credits expire while burning through permanent ones.

Why two layers? Three reasons.

1. Auditability

When you ask "where did my money go", you can answer it in two queries:

1. Master wallet ledger — every top-up, every plan purchase. Big numbers, low frequency.
2. Per-product usage ledger — every charge, broken down by source (daily / monthly / permanent). Small numbers, high frequency.

If we mashed those together you'd get a thousand-line ledger of mixed events. Splitting them means each ledger has a single shape and a single audience.

2. Expiry semantics make sense

A single-balance wallet can't have an "expiry date" — you can only say "the whole balance expires on X", which is almost never what you want. With sub-wallets, the credits expire, not the wallet. Monthly Studio credits can expire on the 1st of next month without affecting your API credits or your master balance.

3. Teams and partners just work

The same model holds for teams: the team master wallet pays for plans, plans become seats and quotas distributed to members, members consume from their assigned quotas. Same payment-vs-usage split, one level deeper.

For the partner program, commission is yet a third wallet — independent USD, never mixed in with anything. You earned $50 from referrals? That $50 sits in a wallet that's not in your spending path. You can withdraw it without anyone needing to compute "but did you already spend it on Studio?".

What we gave up

This design isn't free.

• Users have to learn the distinction the first time. We try to make it visible — Wallet → Master / Sub-wallets — but it's still one extra concept.
• We can't show a single "Total Qingwave balance" number, because adding stored-value USD to expiring credit pools would be misleading.
• Refunds are slightly more involved: a refund of a plan purchase reverses the master debit and the sub-wallet credit grant.

We think the trade is worth it. Every time we've been tempted to collapse to a single balance — usually under "but it would be simpler!" pressure — the next thing we run into makes us glad we didn't.

If you want to see this concretely, open Wallet in the Console. The Master wallet hero card and the per-product sub-wallets sit on the same page, and the ledger tabs make the split visible at a glance.