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, denominated in US dollars. It is recorded to a resolution of one millionth of a dollar ($0.000001). 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.

There is no “credit” unit. The system uses USD. If you see the word “credit” anywhere in the product, that is stale copy — please report it to support.

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

Only these amounts are accepted: 5 · 10 · 20 · 50 · 100 USD. The reason for a minimum: below that, the payment-gateway fee plus the first-top-up bonus makes the transaction a loss for TexAPI. That is a real economic constraint, 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 $10 of real money and $1 of bonus 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: to the micro-dollar, always rounded UP. That favours TexAPI, and this document says so plainly rather than calling it “rounding”. The magnitude: at most $0.000001 per request — 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

Prices exclude VAT — see section 10. Per-plan throughput limits are in the API Terms, section 4.

The plan’s included usage lands in the wallet as real money and does not expire. The period is one calendar month from purchase. Automatic renewal works only on the card channel; orders paid by domestic transfer are one-off and do not renew. There is no pro-rating when you change plans or cancel mid-period.

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.

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 remains unfavourable and must be said: the benefits end the moment you cancel, with no pro-rating — the plan’s discount and throughput limits stop immediately, even if many days of the period remain. If you cancel mid-period and lose the rest of the period you had paid for, TexAPI credits back the corresponding part on request.

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. Once bonus money is in the wallet it does not expire, but it is not refundable — you did not pay for that part.

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.