Revenue
The Tebex integration and the Revenue and Creator codes pages. Payments reach the dashboard straight from Tebex, not through the agent.
Revenue does not come from the agent. Your Tebex store sends each payment to the dashboard as a signed webhook, and the dashboard matches it to a player by their Minecraft UUID. That is what lets revenue, lifetime value and campaign ROI use real payments.
Connecting Tebex
On Integrations, a member with Connect and disconnect integrations (manage_integrations):
Create a webhook endpoint in Tebex
In the Tebex creator panel, Developers → Webhooks → Endpoints, add an endpoint and copy its
webhook secret. Enable payment.completed, payment.refunded, the payment.dispute.* events and,
for subscriptions, recurring-payment.started and recurring-payment.renewed.
Paste the secret into the dashboard
It is stored encrypted and never shown again.
Paste the endpoint URL into Tebex
The dashboard shows the URL to use. Tebex sends a validation request first; the status turns to Receiving with the first payment.
Import past payments (optional)
With a game server's secret key (Tebex: Game Servers → your server → secret key), the dashboard imports every payment Tebex still lists. Importing again never duplicates a payment. Refunds imported this way are dated on the payment's day.
Buyer names, e-mail addresses, IPs and postal codes are dropped before anything is stored. Disconnect stops new payments; the ones already stored stay.
Definitions
Amounts are in the workspace's currency (Settings). Refunds and chargebacks subtract on the day they happen.
| Metric | Definition |
|---|---|
| Gross revenue | Completed payments. |
| Net revenue | Gross − refunds − chargebacks. |
| Net after fees | Net revenue − the tax and gateway fees Tebex reports per payment. |
| Payers | Unique players with a completed payment. |
| Conversion | Payers ÷ active players. |
| ARPPU | Net revenue ÷ payers. |
| Run rate | Trailing 30-day net revenue × 12. |
| LTV | Net revenue a cohort brings within N days of its first day, per player. |
| CAC and ROI | See Campaigns. |
A payment from a player never seen on the network is still revenue; it is simply unattributed for campaigns and cohorts.
The Revenue page
| Section | Shows |
|---|---|
| Over time | Net revenue per period with refunds and chargebacks below the line, the running total, and payers and payments. |
| Subscriptions and one-off purchases | Net revenue from recurring payments against single purchases. |
| Lifetime value | By cohort, and by campaign over a player's first 90 days. |
| Time to first purchase | Days from a player's first session to their first payment. |
| Top packages, countries and creator codes | Net revenue by each. |
| Top payers | The players who spent the most in the range, net of refunds. |
| Subscriptions | Active, cancelling, started and ended, and churn. They can only be counted once the store also sends the recurring-payment end and cancellation events. |
Creator codes
The codes buyers typed at checkout. Revenue is net: refunds and chargebacks are taken off the code that brought the payment. The page shows the revenue that carried a code and its share of the total, how many codes were used, the average per payment, revenue with and without a code over time, the top codes, and every code with its payments, buyers and last payment.
Who sees revenue
The Revenue page, per-player spend, the revenue KPIs on the Overview and the purchases in the live feed
need Revenue (view_revenue); the Viewer role is seeded without it. The Creator codes page has its
own permission, Creator codes (view_creators).
Something missing on this page? Tell us on Discord