Managing reseller customers and pricing

Last updated 30 Aug 2026
View as Markdown

Overview

The reseller portal lets a reseller manage its own downstream customers: view each customer's wallet and grant history, set a monthly spend cap, receive alerts when a customer approaches or breaches that cap, auto-apply welcome credits when an invited customer owner joins, and issue branded monthly statements. Customer-facing prices are resolved from the pricing model attached to the customer organization, so pricing is controlled through the pricing hierarchy rather than per-resource overrides in the customer record.

This article covers the reseller-side customer financial controls and how customer pricing is resolved.

Before you start

  • Your account must belong to a reseller organization; all customer operations resolve the customer through that reseller context, so you can only act on your own customers.
  • Permissions you need, depending on the task:
    • reseller:view — see the portal and the notification centre.
    • reseller_customers:read / reseller:customers — list and open customer records.
    • reseller_billing:read / reseller:billing — read a customer's wallet ledger and grant history.
    • reseller:manage — set or remove a customer's spend cap (the reseller owner also has this).
    • reseller:pricing / reseller_pricing:read — work with the pricing model applied to your customers.
    • reseller:invite — invite customer owners.
  • Your reseller wholesale wallet must hold enough balance before a customer accepts an invitation that carries welcome credits — the grant debits the wholesale wallet.
  • Customer top-ups are verified against your own connected payment gateway; a customer top-up order created on a gateway that has since been deleted will fail verification.
  • The customer organization must be ACTIVE for the daily account sweep to evaluate it.

Steps

1. Open the customer record

In the reseller portal, open your customer list and select the customer you want to manage.

2. Review the wallet ledger

The customer's wallet view shows the current wallet balance and currency, the grant history (every credit on the customer wallet with the granting user's name, the original and remaining amount, and its status), and a paginated transaction ledger, newest first, filterable by credit or debit. This view is read-only — opening it never creates billing.

3. Set a monthly spend cap

On the same customer, set:

  • the cap amount, expressed in your reseller billing currency;
  • the warning threshold, as a percentage of the cap at which you want to be notified;
  • whether the customer is suspended automatically when the cap is breached.

Every write is audited. The cap is returned alongside the wallet ledger so you can see it in context. Remove the cap when it is no longer needed.

4. Watch the notification centre

Alerts appear on the bell in the portal header with an unread badge. Reseller notification events include spend-cap warnings and breaches, low customer wallet balance, high postpaid accrual, customer suspended, customer approved, invitation accepted, and welcome credits skipped. Notifications can be marked read individually or all at once.

Alerts are emitted only on a worse-direction state transition (for example OK to warning, or into breach), so you do not get the same alert every day. State is scoped to the billing period, so a new period starts from a clean slate. Only critical-severity alerts are emailed.

5. Grant credits and let welcome credits apply

When a customer owner accepts their invitation, any stashed welcome-credit amount is granted onto the customer wallet through the audited grant path, debiting your wholesale wallet. The grant is idempotent — concurrent accepts result in exactly one grant — and it never blocks acceptance. If the wholesale balance is insufficient, the grant is skipped and a "welcome credits skipped" notification is raised.

6. Confirm the pricing a customer sees

Customer-facing catalogue prices resolve from the customer's organization, not from a system-wide default: organization → group → region override → pricing model. Within a pricing model, tariff grids and grid items map each resource to a tariff. Period prices use an explicit period override on the tariff when one is set; otherwise the hourly price is multiplied by the configured period multiplier. Storage prices are resolved from the tariff grid first, with the storage policy's direct price only as a fallback.

7. Issue a branded statement

A monthly billing record can be rendered as a branded PDF statement, built from the record's stored customer details. Branding is text-only — brand name and accent colour. The statement carries a statement number derived from your invoice prefix, the billing month and a sequence position; it is labelled a statement, not a tax invoice, and carries no tax-registration or merchant-of-record fields.

Limits & billing

  • The spend cap is not a provisioning-time block. It is evaluated by a daily account sweep: warning notifies you, breach notifies you and, if auto-suspend is enabled, suspends the customer. Between sweeps a customer can spend past the cap; auto-suspend is the backstop, not a hard limit.
  • Auto-suspend only acts on a customer that is still ACTIVE at the moment of suspension, so it never overrides a platform or admin hold.
  • A single credit grant to a customer wallet is capped at 100000.
  • Welcome credits and manual grants debit your reseller wholesale wallet; the customer wallet is credited from it.
  • The reseller wholesale wallet has no self-serve top-up flow — that path is deliberately closed. Only the customer wallet top-up is self-serve, and it verifies against your connected gateway.
  • Low customer wallet balance and postpaid accrual alert thresholds are platform-wide module constants; they are not configurable per customer.
  • Statements are statements, not tax invoices. The statement number is deterministic but not a tax-compliant sequential invoice number.
  • The logo you configure for portal branding is not embedded in the statement PDF; statement branding is limited to brand name and accent colour.

FAQ

Does setting a spend cap stop a customer from creating resources immediately? No. The cap is enforced by the daily sweep, not synchronously at provisioning time. Enable auto-suspend if you need spend to be stopped without manual intervention.

Will I get the same cap alert every day once a customer is over budget? No. A notification is emitted only when the state moves in a worse direction, and the state resets at the start of each billing period.

What happens if my wholesale wallet is empty when a customer accepts an invitation? The invitation acceptance still succeeds. The welcome credit grant is skipped and you receive a "welcome credits skipped" notification so you can top up and grant manually.

Can two people accepting at once cause a double credit? No. The grant is row-locked and idempotent — concurrent accepts serialise to exactly one grant.

Can I give one customer a different price for a specific flavor from the customer record? Not from the customer record. Prices come from the pricing model resolved through the customer's organization and group, so pricing changes are made at the pricing model / tariff grid level.

Can I use a statement for tax filing? No. Statements omit tax-registration and merchant-of-record fields and are labelled as statements.

Related

Did this guide answer your question?If you need customized assistance with your deployment, reach out to our team.
Contact Support