Appmint Billing, Usage and Service Credits

Written guide

Written course script · documented draft · Payment and ledger verification pending

This combined course follows account credit from Billing into Usage & Spending. The full procedures below also serve the separately navigable Billing and Usage module courses. They describe the same application screens, not additional billing products or a required paid subscription.

Billing shows the account credit and its transactions. Usage explains the recorded services that changed that balance. We'll follow both sides, compare the identifiers and export a statement so an account question can be answered from the actual records.

Part 1 — Billing and credit transactions

Written course script · documented draft · No purchase performed

Overview

Billing is where you inspect account credit and its transactions. We'll read the balance, locate a transaction and walk through the credit-purchase interface, including what to check if payment succeeds but the account has not updated.

Appmint applications are free under the product direction for this programme. This course does not invent a paid phone or mandatory subscription. It documents the account-credit interface present in the application; whether a particular service consumes credit depends on that organization's configured service agreement and actual usage. Do not turn a generic plan label into a new pricing claim.

1. Inspect Billing Overview

Historical Appmint capture: Overview shows10credit and No transactions found. This is a retained account state, not a promised starting balance, purchase receipt or current price.

Read Credit balance first, then use Transaction History to inspect the entries behind an account question. Billing Settings is a separate tab. Buy Credits opens a payment flow; it is not needed simply to inspect history. An empty Recent Transactions panel does not demonstrate that all services are free or that the account has never had activity. Check the statement period in Usage separately, and preserve any loading/error state rather than interpreting it as an empty history.

Open Account → Billing and select Overview. Wait for account and balance loading to finish. Read Credit balance and inspect Recent Transactions.

The page also displays plan, renewal, limits and status values when supplied by the account record. Missing renewal information appears as N/A; a default Free Plan label does not establish every possible service rate or agreement. Use the actual organization's configuration.

The main balance combines profile and balance responses. A missing balance is shown as unavailable when both sources fail. A failure notice is not a zero balance. The separate Current Usage card reads another company-data field; if two displayed balances disagree, refresh and compare the Usage statement before acting on either.

This is the account's available credit. The recent rows show transactions, while the Usage page explains how recorded services used the balance.

Recent Transactions shows up to five loaded rows. View all transactions switches to Transaction History; it does not establish unlimited server history or a new export.

2. Find a transaction and retain its identity

Open Transaction History. Locate the intended date, description and amount. Inspect its Status and Payment Method. Copy the transaction ID using the adjacent copy control; the visible shortened ID is not the complete identifier.

Pending and completed are different states. A row in the list does not prove that a provider settled a payment. Reconcile the controlled provider result with the account transaction and balance when verifying a purchase.

The current All time selector and Export button in this tab have no active handlers. These controls currently do not perform the named actions. Use Account → Usage → Export for the available usage-statement JSON export, understanding that this is a different dataset.

If history fails to load, choose its retry action. If it loads successfully with no rows, check that this is the intended organization and that a relevant transaction actually exists. Do not repeatedly initiate payment to populate the table.

3. Enter an account-credit amount

Choose Buy Credits. The Purchase Account Credit form opens.

1. Read Amount (USD) and replace the prefilled amount with the deliberately chosen amount.
2. The current client validates a minimum of $1 and maximum of $10,000. These describe the interface's allowed amount, not a required purchase or recommended spend.
3. Choose Cancel to leave without proceeding when only inspecting the form.
4. In an authorized controlled payment demonstration, choose Continue to Payment once and wait for payment creation.

The request specifies USD and Stripe. If no payment client secret returns, the form reports a failure instead of opening checkout. Do not treat that failure as a completed charge.

Check the amount before continuing. This creates the payment setup; the next screen is where the actual payment is confirmed.

4. Confirm payment and verify the account update

On the Stripe checkout screen, check the displayed amount and currency and use only the methods actually offered. The surrounding form's generic wallet copy is not proof that Apple Pay or Google Pay is enabled in every browser or environment.

Complete the controlled checkout using the credentials appropriate to its actual test/live mode. Never put a test card into a live checkout or show private payment details in the course. Back to amount selection returns to the amount form; it should not be described as a verified provider cancellation of every previously created intent.

After payment confirmation, Appmint calls its completion endpoint. On success, Billing closes the purchase form and refreshes account data. Verify three things:

• The provider result identifies the same payment and amount.
• Transaction History shows the corresponding transaction and its actual state.
• Credit balance reflects the intended completed credit.

Payment confirmation and the account update are separate steps. We check the transaction and refreshed balance before treating the credit as available.

No payment was made to author this course; purchase completion and account-credit reconciliation remain unverified here.

5. Recover from a partial payment result

The form has a specific warning for payment completed but account update failed. If that appears, retain the payment intent and transaction identity, refresh Billing and inspect history before doing anything else.

Do not start another purchase merely because the displayed balance has not changed. Provide Support with the amount, currency, time, organization ID, payment identifier and exact warning so the existing transaction can be checked. Keep card details and secrets out of the report.

For a provider decline or validation error, read the specific returned message. Correct the relevant input or payment method; do not describe every error as an Appmint balance problem.

6. Understand Billing Settings and current incomplete controls

Open Billing Settings and inspect the displayed Billing Contact, Billing Address and Subscription Plan information.

Current-source limitations matter here:

• Change and Edit set a profile tab value, but this component does not render a profile tab. They are not a complete billing-contact/address edit flow.
• The settings Upgrade control has no handler. The Overview Change Plan link is a different route and must not be narrated as proof of a paid product requirement.
• Auto reload is described as disabled, but this page does not provide an implemented enable/configuration flow. Do not invent a toggle or promise automatic replenishment.

If billing identity needs correction, use the actual supported organization/account workflow and verify it. Company Profile does not provide a legal-address editor. Report the missing billing edit path when needed.

Closing and source status

Use Billing to inspect account credit and transaction identity. For a purchase, confirm both payment and the account update. If those disagree, investigate the existing transaction before trying again.

Source reviewed: account/billing.tsx, account/credit-purchase.tsx, hooks/use-org-management.tsx and the shared Stripe checkout integration. Live proof pending: account state consistency, controlled purchase, provider receipt, completion failure recovery and transaction persistence. Product pricing has not been inferred from incomplete plan controls.

Part 2 — Usage and service statements

Written course script · documented draft · Live ledger reconciliation pending

Overview

Usage & Spending explains recorded changes to your account balance. We'll choose a period, inspect spending by service, read individual statement rows and export the same information for a closer review.

This is an account-service statement, not customer order revenue or an assertion that Appmint applications require a paid plan. Use the actual organization's service agreements and recorded usage. Do not invent fixed provider prices for the course.

1. Select the period

Historical Appmint capture: four Ai/agent/stream entries are visible for the displayed period. Their amounts were rounded to0.00 in this older view. Current source retains additional precision for small amounts; do not use this old rounded display as proof that the operation costs exactly zero.

Follow one row across When → Service → Detail → Amount → Balance after before comparing it with the summary. The date controls determine the requested statement period; Current balance is the account's present balance, not the balance at that period's start. Use Refresh after selecting the final date range, wait for the result, then Export that same statement. Read its exact amount and timestamp when the on-screen value is small or the operation occurred near midnight. The service chart groups entries; it does not replace their individual references.

Open Account → Usage. The page title is Usage & Spending. Set the start and end dates in the header. Each date change reloads the statement; choose a valid ordered range and wait for the final request to complete. Use Refresh to retrieve it again.

The default window is approximately the last 30 days. The current implementation converts the date-only inputs to UTC boundaries and includes the end date through its final millisecond. Row times are formatted in the browser's locale. When reconciling events near midnight, retain the exported ISO timestamp rather than assuming the visible local calendar day is the exact query boundary.

A failed request displays Usage for this range with retry and clears the statement. Retry after fixing access/connectivity. A failed load is not “No charges in this range.”

2. Read the three summary figures

The balance is current. Spending belongs to the dates we've selected. Several small charges can be grouped into one readable row, so the charge count can exceed the number of rows below.

Do not subtract period spending from current balance and call the result an opening balance. Credits, prior spending and other dates also affect the account. Use the actual ledger values for reconciliation.

3. Compare spending by service

Read Spending by service. Each row identifies its service and provider where known, amount and share of the selected spending total. Choose a service with recognizable activity and compare it with the statement rows below.

These bars are a breakdown, not interactive configuration or a direct retry button. To change service settings, open the corresponding module. To investigate an unexpected charge, retain its identity and detail first.

Older entries may have a label inferred from their endpoint because they lack richer metadata. A readable label does not prove every historical event includes model, unit quantity or provider-level detail.

4. Read the statement rows

Inspect When, Service, Detail, Amount and Balance after.

Credits display a plus sign; charges display a minus sign. The formatter retains extra decimal places for nonzero amounts below one cent. A small fractional amount should not be described as free merely because a different screen rounded it to $0.00.

The server groups consecutive charges for the same service under its grouping rules. Detail may show total tokens, model, quantity and the count of combined charges. An intervening credit or a different service can create separate rows. The export retains the grouped statement structure and counts; it is not automatically every original raw event.

Check a statement entry

1. Locate a known service entry within the chosen dates.
2. Read its provider and available detail.
3. Compare Amount and Balance after with neighboring rows, allowing for grouped entries and missing historical balances.
4. Inspect the source module's corresponding activity, where that identity is available.
5. Keep any mismatch as a finding; do not generate new service calls simply to force a desired total.

A dash under Balance after means the row has no recorded value. Do not replace it with a guessed zero. A statement row is not proof that an external recipient received a message or a generated asset was useful; usage recording and feature outcome are separate checks.

5. Export and inspect the same statement

Choose Export after the statement has loaded. The download is JSON named with the selected dates, such as usage-2026-10-01-to-2026-10-02.json for those example dates.

Open the downloaded file and check its balance, totals, breakdown and rows. Confirm the dates and entries match what you intended to export. Retain precision when importing into another tool; rounding every row before summing can introduce differences.

The current export serializes the loaded statement locally. It is not a CSV export, an invoice, a provider receipt or a request to fetch all historical usage. Export is disabled when no statement is available.

Review the file for organization and activity details before sharing it. A support report normally needs selected identifiers and the specific mismatch, not an unrestricted account dump.

6. Investigate unexpected or missing usage

First check the organization and exact dates. Refresh, then compare the service breakdown with the matching rows. If a service operation is absent, verify whether it records a charge under the current agreement rather than assuming every app action must consume credit.

If a completed credit purchase is missing, inspect Account → Billing → Transaction History and the provider result. If a charge appears duplicated, compare the combined charge count, timestamps and underlying operation attempts before declaring a duplicate.

For support, include the selected window, service, timestamp, amount, recorded balance and the source operation identifier where available. State what you expected and what the export actually shows. Keep credentials out of the report.

The screen does not implement per-row refund, reverse-charge, rate editing or raw-record drill-down. Those are not hidden actions to add to the lesson.

Closing and source status

A useful account review keeps the date window, service and recorded amounts together. Use the statement to understand balance changes, and the source module to verify what the service actually did.

Source reviewed: account/usage.tsx, AppEngine usage/usage-statement.ts and its grouping tests. Existing tests were read as implementation evidence, not rerun or claimed as fresh live proof. Pending verification: controlled account totals, UTC/local boundary behavior, grouped rows and downloaded JSON against actual ledger records.

Part 3 — Reconcile a specific account question

Choose a known completed transaction in Billing, copy its complete ID and retain its amount/time. Open Usage, select the period containing the corresponding credit and refresh. Identify the credit row and subsequent charges. Current balance is a present-state value; compare row-level Balance after values for historical changes rather than treating the current figure as the period's opening balance.

Export the statement and inspect its totals, grouped rows and timestamps. The statement's Charges count can exceed visible rows because multiple consecutive service charges are grouped. Match the service details to its operation in the relevant application where the available identity permits it.

If a provider confirms payment but the account credit is absent, investigate the existing payment through Support before attempting another purchase. If a usage deduction exists but the expected service result is missing, retain both records: balance recording does not establish successful delivery or a correct AI response.

Why this matters

Keep payment, account credit and service outcome as separate checks. Matching their records is what makes the explanation reliable.

This combined script includes all current controls and limitations covered by the two component courses. No additional live reconciliation was performed while assembling it.

Account Limits is a separate read-only report

Open Account → Limits for Organization limits. The locally corrected shared screen reads the company's configured spend limit and credit balance. Loading/error show unavailable values, absent or nonnumeric fields say Not provided, and an actual zero displays $0.00. Zero does not prove unlimited usage or enforced blocking. This page does not configure caps or notifications and does not establish a monthly reset period or model request quotas.

Use Retry for a failed organization-profile load. Use this course's Usage statement for activity in a selected period; a current profile balance is a different figure. The local Limits component passed eight isolated rendered-state tests on 5 October 2026; a fresh authenticated browser read remains pending.