Balance and Billing

This document describes how the system actually charges, including the places where that mechanism is not yet complete. Refunds are a separate document: the Refund Policy.

1. What the wallet balance is

The TexAPI wallet balance is prepayment for the service. It is displayed as credits at the fixed rate 100 credits = $1 of usage value, while its canonical accounting denomination is US dollars. The canonical balance is recorded to a resolution of one millionth of a dollar ($0.000001), equal to 0.0001 credit. In accounting terms it is an obligation TexAPI owes you — revenue is recognised only when you actually use the service.

And, precisely, what it is NOT:

• Not electronic money, not an e-wallet in the legal sense of a payment intermediary, not cryptocurrency, not a means of payment. The balance can only be spent on TexAPI’s own service.
• It cannot be transferred to anyone else, bought or sold, or withdrawn as money on demand.

Credits are TexAPI’s internal service-usage unit, fixed at 100 credits = $1 of usage value. Credits are only a customer-facing way to express prepaid TexAPI usage: they are not electronic money, cryptocurrency, a payment instrument, withdrawable cash or a transferable asset. Canonical accounting, database balances, ledger entries, charges and refunds remain denominated and recorded in USD. For example, a $5 top-up adds 500 credits and a $10 top-up adds 1,000 credits, before any bonus.

1.1 The balance does not expire

Your balance does not expire. That is a commitment, and it is consistent with how the system is built: there is no expiry column on the wallet or the ledger, and no expiry logic anywhere.

This applies to a subscription’s included usage too: in economic substance a plan is a prepayment plus a discount, and the unused part remains yours.

1.2 Your balance when you delete the account

If your organisation has other members, deleting your individual account does not delete the organisation and does not affect its balance.

2. Topping up

Each channel has its own ladder. PayOS accepts 100,000 · 200,000 · 500,000 · 1,000,000 · 2,000,000 VND; Creem accepts 5 · 10 · 20 · 50 · 100 USD. The minimums differ because the gateways are priced differently: Creem charges a fixed $0.40 per transaction, while PayOS has no percentage fee. The minimum is not an arbitrary barrier.

On the fixed 27,000 rate: it is a configuration constant, not connected to a live source. The rate applied to an order is fixed when the order is created and recorded on it — changing the configuration afterwards does not re-price existing orders.

On the card surcharge: the amount you will pay is shown before you confirm. The difference is the payment gateway’s fee, not TexAPI’s, and it is not recoverable on a refund.

2.1 After you pay

The gateway notifies TexAPI; TexAPI verifies the notification’s signature, locks the order row, checks the status, then credits the wallet — all in one database transaction. That same transaction applies the first-top-up bonus and any coupon. There is a Confirm payment button if you would rather not wait.

Against double crediting. An order already in the completed state is never credited twice; the bonuses carry a unique database index so they cannot be granted twice. If you ever see money credited twice for one transaction, that is a bug — report it to support, and it is a mandatory-refund case.

2.2 When a payment goes wrong

3. The ledger

Every balance movement leaves an entry, written in the same transaction as the movement itself. Each entry records: the type, the amount (negative is money out), the balance after the entry, a reference type and id, and supporting data. You can see your ledger at Dashboard → Wallet.

A transparency point worth making: the first-top-up bonus, coupon bonuses and welcome credit are all recorded as type adjustment, not as a type of their own — they are distinguishable through the reference field. The “total paid in” column rises only on topup and subscription_grant, which means bonus money does not count as real money received. That is the correct treatment, and it is the basis of the refund rule.

A limitation you should know about: the wallet balance is a single amount with no record of which part came from where. Once 1,000 paid credits ($10 canonical USD) and 100 bonus credits ($1 usage value) are both in the wallet, the system does not track which was spent first. That is why TexAPI uses the rule “refund no more than what you actually paid on that order”.

On immutability: the ledger is protected by the database so that it cannot be updated — a mechanism at the database layer blocks every update on the ledger table, so correcting a wrong entry means writing a compensating one. Deletion is still allowed, because your own account deletion depends on it; before deletion, entries are copied to a retention table.

4. How one request is charged

1. Check the API key, the throughput limits, the key’s spend cap, and the available balance.
2. Place a hold: an estimate of the maximum cost, priced at the undiscounted list rate, and lock that amount in the wallet. This is what stops parallel calls from over-spending the balance.
3. Choose a route and call the infrastructure; fail over on error.
4. Charge for actual usage, applying the discount and the loss floor.
5. Settle: release the hold, debit the real amount, write the ledger entry, and store the pricing receipt on the request record.

A consequence of step 2 that you will see: while a discount applies to you, the hold can be considerably larger than the amount finally taken, because it is priced at the undiscounted rate. Your available balance dips by more than the real cost for a while, and your per-key spend cap is drawn down further than reality. The hold is released when the request finishes.

Rounding occurs in USD first: to the micro-dollar, always rounded UP. Only after that settlement amount is fixed is it converted to credits at 100 credits per USD. One micro-dollar ($0.000001) equals 0.0001 credit, so the maximum rounding increment per request is 0.0001 credit — still $0.000001, or roughly $1 over a million requests.

The pricing receipt on each request records: the tokens counted of each kind, the rate in force, the list rate, the discount level, the gross total, the allowed ceiling, the amount as limited by the balance, and the basis the usage was counted on. The receipt is written once at charging time and read back verbatim — the formula is never rebuilt on view — so the number you see today is the number that was applied that day, even if prices have changed since.

5. When you are charged, and when you are not

This is the most important section of the document. TexAPI publishes the cases that are unfavourable to you too.

5.1 NOT charged

5.2 Charged — even when you did not get a complete answer

A stream cut off mid-way. If the model had generated part of an answer and part of it reached you, that part is charged. This holds in all three cases: the infrastructure timed out mid-stream, the connection dropped, and you disconnected yourself.

How the amount is set when the infrastructure reports no token counts — the typical cut-stream case:

• Output tokens: taken from the tokens actually delivered to you.
• Input tokens: taken from the estimate used for the hold — and only when there are output tokens to charge for.
• If nothing reached you: the charge is zero.

The ceiling that protects you: in this reconstruction, the amount does not exceed the sum placed on hold when the request began. The receipt states which basis was used, so you can check.

Why TexAPI charges, plainly: when a stream is cut, the infrastructure still bills TexAPI for all the work the model did. Charging zero in that case would mean giving away precisely the longest calls — which are the most expensive ones — and would create an incentive to abuse the service by disconnecting on purpose.

If you believe a charge in this group is wrong: send the request id to support. TexAPI holds the full pricing receipt to check against, and will refund if the receipt shows an error.

5.3 An abandoned hold

If the process handling your request dies without settling, the reaper closes the hold after 15 minutes and takes the entire held amount — that is, at the undiscounted list rate, for work you may never have received.

That is unfavourable to you and TexAPI publishes it. If your balance is zero, the hold is closed with nothing taken.

6. A negative balance

Cannot happen. Guaranteed by three independent layers: a database constraint, a check before the debit, and a limit at settlement.

When the balance runs out mid-request: that request completes, and is charged at most the remaining balance — TexAPI absorbs the difference, and the receipt records that the amount was limited by the balance. The next request returns a 402.

TexAPI allows no credit, charges no interest, and offers no credit limit.

7. Prices and price changes

The selling price is derived from cost, not typed in by hand: price = cost ÷ (1 − target margin). Because the price is the result of a division, there is no path by which a model can be priced below cost by a typo.

The cost sync runs roughly every 30 minutes and the selling price adjusts with it. There is currently no human approval step in between — the infrastructure raises its price, yours rises automatically. Four guarantees come with that:

• Prices are never applied retroactively. Each request is charged at the price in force when it was made, and that price is recorded in the receipt.
• TexAPI gives 7 days’ notice when a model’s price rises by more than 10%. There is no automation for this yet — it is done by hand.
• The price and discount of a paid subscription period do not change within that period.
• If you do not accept a new price: stop using the service and ask for the unspent balance back.

7.1 Discounts

A plan discount and a coupon discount stack. A TexAPI promotion competes rather than stacking — the final level applied is the higher of the two.

The loss floor. Every discount is capped by a floor computed from the cost of the exact route that served the request, not an average cost — necessary because routes for the same model can differ greatly in cost. The consequence for you: a published discount may not be applied in full when it hits the floor, and the pricing receipt records when that happens.

8. Subscription plans

Two generations of plans. Plans bought from 24 Oct 2026 (and their renewals) are capped-allowance plans: instead of granting wallet credit, they grant a usage allowance measured at the published PAYG prices that resets on a schedule. Plans bought before that date keep the credit mechanism until the paid period ends.

Prices exclude VAT — see section 10. Per-plan throughput limits are in the API Terms, section 4. The VND figure is what PayOS collects and is the plan's own listed price, not a direct conversion of the USD price; the wallet remains denominated in USD. When a plan is bought by card and the card product is configured to include the processing fee, the final amount may be higher than the listed USD price and is always shown before you confirm.

8.0 The 5-hour window and the weekly allowance

The unit is "USD at published PAYG prices". Every request is priced at the PAYG rates in effect, and exactly that figure moves the two window counters. Cheap models stretch an allowance further than expensive ones; when the price list changes, the token value of an allowance changes with it, and we announce price changes in advance (section 7). Fixed windows, reset on Vietnam time (GMT+7): the 5-hour window resets at 0h · 5h · 10h · 15h · 20h (the last window of a day, 20h–24h, is 4 hours); the week resets Monday 00:00. The dashboard shows an exact countdown to each reset.

Inside the allowance: requests charge nothing — no wallet hold, no deduction; usage only moves the meter. Past the cap — spill into the PAYG wallet (on by default): continued usage bills the wallet at the published PAYG price minus your plan's discount (3/5/8%). Spilling spends money already in your wallet and creates no debt; switch it off under Top up & plans. With spilling off (or an empty wallet) new requests receive 429 subscription_limit_exceeded carrying the reset time. Allowances do not carry over between periods and do not convert to credit. RPM, TPM and key counts still apply alongside.

8.1 Cancelling a plan

Cancel at Dashboard → Wallet → Subscription. When you cancel, TexAPI stops the recurring charge at the payment gateway itself — you have nothing further to do on the gateway side. You keep every benefit of the period you paid for until its end: throughput allowances and the plan discount are not cut off immediately.

If stopping the charge at the gateway fails for a technical reason, the interface tells you so at the moment of cancelling rather than reporting success. In that case, if a period is still charged, the system recognises it as a refund owed rather than re-activating the plan, and TexAPI refunds that entire period.

What happens at the end of that period: the plan discount and throughput allowances stop, and the wallet switches back to the PAYG allowance (60 RPM, 250,000 TPM, 2 API keys). Unused credit remains in the wallet and does not expire. On the PayOS channel there is no automatic charge, so continuing after the period ends requires buying the plan again.

9. Coupons and bonus credit

The “held coupon” mechanism, understood correctly: a top-up bonus coupon cannot be valued at the moment you enter it, because its value depends on the amount you top up. So when you enter it, the coupon is held and only applied when you actually top up. Two consequences: holding a coupon is not redeeming it — the coupon’s redemption count has not been used; and an organisation can hold one coupon at a time — entering a second replaces the first.

If applying the coupon fails at the moment of the top-up, your top-up is still credited — the mechanism is designed so a failure at the coupon step cannot lose the money you paid.

First top-up bonus: 10% on the first real-money top-up, once per organisation, with a unique database index guaranteeing it is never granted twice. Thus a $10 first top-up adds 1,000 paid credits plus 100 bonus credits. Bonus credits do not expire, but they are not refundable — you did not pay for that part.

Stacking cap: the total bonus on one top-up — first-top-up bonus, top-up coupon and partner bonus — never exceeds 20% of the amount funded. If the sources add up to more, the system grants at most 20% and records the capped portion in the transaction history.

Abuse prevention: a total redemption count per coupon, a per-organisation count, a minimum top-up, a rate limit on entering codes, and a verified email required to top up. Creating multiple accounts to collect a bonus more than once is prohibited conduct.

10. Tax and invoices

Two commitments while that machinery does not exist, both protecting you:

• If a tax obligation arises on transactions the system did not collect for, TexAPI absorbs it for those completed transactions — no back-billing of customers who have already paid.
• You need an invoice: send the request to support. TexAPI handles it by hand. That is not a long-term arrangement and TexAPI is not calling it one.

11. Manual adjustments by TexAPI

An operator can adjust your balance — crediting or debiting it. Every adjustment:

• writes an adjustment entry in the ledger you can see;
• writes an immutable audit record naming who did it and the written reason (mandatory);
• is limited by the per-role amount ceiling;
• requires two-factor authentication above a threshold.

A debiting adjustment is permitted only to: correct a system crediting error, claw back bonus credit granted through abuse, or process a transaction reversed at the payment gateway. Every case must carry its reason in the audit record, and TexAPI notifies you.

An adjustment is not a refund. An adjustment changes the wallet balance; a refund sends money back to your payment method.

If you see an adjustment in the ledger you cannot explain: contact support, and TexAPI replies with the recorded reason within 5 working days.

12. Reconciliation and disputes

The ledger is the authoritative record of your balance. If you believe the balance or a charge is wrong:

1. Check the ledger (Wallet) and the pricing receipt of the request in question (Usage Logs).
2. If it still looks wrong: contact support with the request id or the ledger entry id.
3. TexAPI replies within 5 working days, with the reconciling figures.
4. If TexAPI is wrong: it adjusts or refunds, and charges no handling fee of any kind.