How AIWave checkout actually works
The short version: AIWave's current public checkout uses PayPal, the minimum top-up is $5, and the group that processes a request determines the billing multiplier. This page replaces older payment-method information that no longer matched the live configuration.
Open the Console, check the top-up screen and inspect the group applied to your requests. Do not assume that a successful top-up, by itself, proves a particular group is active.
The three facts that matter
| Boundary | Current state | What to verify |
|---|---|---|
| Checkout | PayPal | The live top-up screen names the same method. |
| Minimum | $5 | The amount meets the current MinTopUp value. |
| Billing group | Effective request group | Confirm the group used for the request instead of inferring it from account history. |
Why the group is part of the price
A model's dated input, cache-hit and output rates are only one layer of a forecast. AIWave also exposes group multipliers. The public rate ledger currently shows default ×1 and VIP ×0.9. The effective group is therefore part of the calculation, not a footnote.
For a reproducible estimate, save four fields together: exact model ID, rate date, token shape and effective group. If any of those changes, recalculate. The Pricing ledger lists all current model rows, while the live pricing API is the model and ratio source of truth.
A small funding test
Use the minimum amount for the first funded check. Create one bounded request, store its request ID and usage, then compare the observed deduction with the dated ledger and effective group. A test that cannot be reconciled should be investigated before traffic grows.
- Confirm the exact model ID in the live catalog.
- Record input, cache-hit and output rates with the date.
- Verify the request group in the Console.
- Set a small output cap and send one non-sensitive prompt.
- Compare usage and deduction; keep the request ID.
What this page does not promise
It does not promise that a top-up automatically changes every token or request. It does not publish checkout options that are absent from the live configuration. It does not turn the 99.9% operating target into an SLA. Those boundaries are deliberate: a payment page should reduce ambiguity, not create it.
Where to check next
Use Pricing for the dated rate ledger, Trust for observed route evidence and limitations, and Docs for the first API request. If the live Console disagrees with an article, the live configuration controls and the article should be corrected.
Six-question check
This update serves a developer already evaluating payment risk, gives a five-step reconciliation test, remains useful after a model launch, makes AIWave more distinctive through explicit boundaries, avoids giveaway/price-war positioning and supplies the trust-evaluation → first-payment stage. Principles: FP-4, FP-6, FP-7; HB-1, HB-2, HB-5.