Customers and data accounting

Customer access is represented by users, orders, and data ledgers. The resources are related but answer different questions: who may connect, which package they may use, and which physical byte pool pays for traffic.

Users

Open full size

Users can be direct customers or resellers with managed sub-users; the page pairs package analytics with current account records.

1. 1The resource header shows the user count and starts user creation.
2. 2The current table fields show user, type, orders and data, balance, and recent activity.

Create a user with a unique username and strong password. Email can be omitted in a headless reseller integration when identity is mapped in your own system. Configure account type, connection limit, source-IP allowlist, blocked domains, and package assignment according to the customer’s contract.

An IP allowlist is an additional gateway restriction, not passwordless access. Domain blocklists deny matching destinations; they are separate from provider selection.

When editing a user, preserve the mapping used by your billing or CRM system and change one access control at a time. Re-test authentication after username, password, allowlist, package, reseller relationship, status, or connection-limit changes. Deactivate access before deleting a mapped customer, and retain the order and accounting references required by your policy.

Orders

Open full size

An order is the entitlement that joins one customer to one package, one active ledger, and an access state.

1. 1Order controls support searching and creating an entitlement.
2. 2The table shows package, user, active ledger, data allocation, and access together.

A root order belongs to the main purchaser and owns physical data ledgers. A reseller-created child order belongs to a sub-user and carries that customer’s assigned limit. Both can point at the root order’s current active ledger.

Resetting an order’s proxy password invalidates previously distributed credentials. Coordinate rotation with the customer, avoid logging either password, and test the replacement before closing the support operation.

Data ledgers

Open full size

Ledgers are the physical byte pools. Their rows link the order, byte amount, invoice, state, expiration, and creation time.

1. 1Use ledger controls to find the exact order or invoice context before changing data.
2. 2The current table fields expose the durable accounting record rather than a derived chart label.

Physical pool versus child limit

Root ledger

Stores total and remaining bytes for the root user/package purchase. Proxy traffic from the root or its children consumes this shared pool.

Child allocation

Stores how much one sub-user may spend. Adding data raises the personal limit; it does not reserve or transfer bytes out of the root ledger.

For each metered traffic batch, the active root ledger decreases and the order that actually generated traffic increases its data_spent. Direct parent traffic therefore increments the root order; sub-user traffic increments that child’s order while still decreasing the shared root ledger.

This design permits overcommit: the sum of child limits can exceed physical remaining bytes. Monitor both the root pool and every child balance before promising guaranteed capacity.

Allocation is not reservation

A successful child data-add operation proves the personal limit changed. It does not prove the root pool contains enough bytes for every child to consume its full allowance.

Multiple-ledger lifecycle

1. A paid expiring limited-data purchase can create a separate ledger so its expiry remains independent.
2. Unlimited or compatible non-expiring purchases can merge according to the package and invoice flow.
3. The ledger created or updated by the latest paid invoice becomes active for the root and its child orders.
4. When it expires or reaches zero, accounting marks it expired and selects the oldest-created remaining valid ledger.
5. If a replacement exists, the whole order tree is switched to it; credentials do not need to be rebuilt.
6. If no valid ledger remains, metered access stops for the root tree. A finite child can also stop independently when its personal limit is exhausted.

Usage arrives in batches, so the final record can cross zero. Treat a small negative remainder as final-batch overdraft evidence, not as a second allocation.

Built-in purchase and invoice flow

A public package can be purchased through an invoice flow. Invoice creation calculates current package pricing and initializes the selected payment provider; a hosted checkout link may then be returned. Do not activate service because the browser returned from checkout. Confirm paid invoice state and the resulting order/ledger.

Coupon previews validate a code against package and amount without creating an invoice. Administrative coupon management belongs to authorized commerce staff. Rewards and affiliate balances are separate commercial resources and should be reconciled with your own financial records when used.

Safe manual data change

1. Confirm the target customer, package, order type, current personal limit, and root-ledger balance.
2. Record the operator, ticket or payment reference, byte amount, unit conversion, and intended result.
3. Add or subtract the exact integer byte value once.
4. Reload the user, order, and ledger; inspect the audit log and related transaction history.
5. If the response was lost, read current state before retrying. A timeout does not prove the write failed.

Use access and automation for server-to-server provisioning and signed accounting notifications.