Subscriptions and features
Access depends on the server feature matrix, subscription state and staff permissions. A plan name in the interface does not authorize an API request.
Plans and addons
| ID | Plan |
|---|---|
| 1 | Lite |
| 2 | Standard |
| 3 | Pro |
| 4 | Premium |
| 5 | Enterprise |
Network modules/License.js defines plans, server limits, Checker/AntiCheat addons and feature keys. Interfaces obtain the current configuration through meta.getLicenses / front.getLicenses and the server feature matrix. This documentation does not freeze prices: draft Minecraft proposals do not change effective values automatically.
addon.checker and addon.anticheat are separate requirements. An addon purchase does not establish technical support for every game or adapter version. Enterprise and dedicated infrastructure also do not replace project isolation checks.
States
Billing.Get distinguishes none, disabled, trial, active, grace, expired. Its response includes validity and related data. Do not derive access solely from a plan name or the user's device clock; use the backend result.
Before payment/plan changes, read billing.getPlans, billing.getPanelData and review available billing API methods. Amount, limits and period depend on server calculations. After a timeout, inspect transaction state/history before retrying a financial operation.
Responsibility
Owners manage permitted project operations; service .cp has separate administrative billing, bonus and project moderation methods. SSO ports legacy PHP responsibilities while existing Network subscription logic remains: ozProtect hosts this backend itself.
SSO bootstrap bonus.coin reports state. It does not automatically grant coins or authorize a new client to spend them.
Sources: modules/License.js, modules/Billing.js, api/billing/Billing.js, api/bonus/Bonus.js, SSO src/methods/front.js.