Billing and Payments

Keeptrusts separates operational usage, billing-budget configuration, subscription billing, and payment readiness. Use the surface that matches the question:

Need	Console surface
Explain requests, tokens, or cost	Usage
Set or review a billing threshold or declared hard limit	Budgets
Review plan, balance, current-period charges, or attribution	Bills
Manage invoices, payment methods, contacts, funding, or auto top-up	Bills → Payments
Reconcile wallet transactions and credit use	Payment History

Review the current bill

Open Bills to inspect:

• current subscription state;
• available funded balance when applicable;
• current-period service attribution;
• team, user, agent, tag, and service breakdowns where the underlying usage is attributed; and
• comparison and annotation context exposed for the billing period.

Totals and attribution answer different questions. A charge can be valid while some usage remains unattributed to a team or agent. Investigate missing resource tags or identity context instead of reallocating it by assumption.

Manage payment methods

In Payments, authorized billing administrators can add a payment method, set a default, or remove an eligible non-default method.

Before changing the default:

1. Confirm the organization and billing account.
2. Check active subscription and auto-top-up dependencies.
3. Add and validate the replacement method.
4. Set it as default.
5. Confirm the updated state.
6. Remove the old method only when it is no longer required.

The current default method cannot be removed directly. Users with read-only billing access can review state but cannot perform mutations.

Keeptrusts selects the configured payment-provider checkout flow through the API. Follow the returned checkout and callback flow; do not assume one payment provider applies to every deployment.

Add funds

Use Add funds when the organization operates with funded balance:

1. Confirm the amount and organization.
2. Start checkout.
3. Complete the provider-hosted step.
4. Return to Keeptrusts and wait for confirmed status.
5. Verify the wallet transaction in Payment History.

Do not treat a browser redirect or a submitted checkout as settled funds. Verify the recorded transaction and balance. Top-ups and credits are non-refundable where the console states that condition; review it before confirming.

Configure auto top-up

Auto top-up settings describe how funded balance should be replenished with the configured payment method and threshold. The current runtime does not initiate the first automatic top-up attempt when a reservation is insufficient or a settlement lowers the balance, so do not rely on this setting as a live funding path.

Before enabling it:

• confirm the default payment method;
• select thresholds and amounts that match approved spend controls;
• identify the billing owner and alert recipients; and
• review the applicable token, provider, wallet, and billing-budget controls.

If a retry state already exists, repeated payment failure can suspend it. Inspect the recorded failure, update the payment method if needed, and verify the state. Do not repeatedly retry payment without resolving the recorded cause.

Stored auto-top-up settings do not replace manual balance monitoring, a budget, or an approval to spend.

Invoices, contacts, and settings

Use invoice settings and billing contacts to keep legal name, address, tax, and notification details current. Review changes before the next invoice closes.

Payment history and invoice records should be reconciled with:

• the exact billing period;
• currency;
• funded-balance transactions;
• subscription charge;
• usage or service attribution; and
• credits, adjustments, or annotations.

A shared bill uses a tokenized public link. Treat the link as sensitive, expire or replace it when no longer required, and share it only with the intended recipient. Search engines are instructed not to index the shared-bill page, but that is not an access-control substitute.

Cancel or change a subscription

Before changing a plan or cancelling:

1. Review the effective date and displayed commercial effect.
2. Export required invoices and usage evidence.
3. Confirm impact on funded workloads and operator access.
4. Identify the owner for gateway and application changes.
5. Complete the console confirmation.
6. Verify the resulting subscription state.

Do not infer that cancelling a subscription stops every independently running gateway process. Coordinate runtime and application shutdown separately.

Diagnose a spend-related request failure

1. Preserve the response code, error code, request ID, token ID, provider, and model.
2. Check the active control for that path: governed token depletion, provider budget, or managed wallet balance.
3. Open Budgets for billing-threshold context. A stored billing budget or Unified Access budget policy is not, by itself, proof of the rejection.
4. Open Bills → Payments and confirm funded-balance and payment readiness.
5. Use Usage to determine the traffic and attribution leading to the state.
6. Review the relevant configuration and Trail chronology.
7. Change a budget or funding control only with the required approval.
8. Re-run one representative request and verify its outcome.

See Spend, Budgets, and Billing for the enforcement boundary of each budget type.

Next steps

• Spend, Budgets, and Billing
• kt spend
• Resource Tags
• Trail and Audit Evidence