Payouts
How revshare is computed, when a payout row appears, and how the money moves.
How it is computed
On the 1st of each month, UTC, we close the previous calendar month: we sum successful payments by your customers over the period and multiply by your revshare rate. The result is a payout row in pending.
One row per currency. If you sold in both roubles and dollars, the month produces two rows, each with its own revenue_cents in its own minor units. A month with no revenue produces no rows at all: an empty period is not a payout.
The rate is frozen into the row at computation time. If the rate is revised later, already-computed periods are not rewritten.
The computation is idempotent: re-running the same period double-counts nothing.
Read
GET /api/v1/reseller/payouts
{
"payouts": [
{
"id": "77b1...",
"reseller_id": "0f2c...",
"period_start": "2026-07-01T00:00:00Z",
"period_end": "2026-08-01T00:00:00Z",
"revenue_cents": 128745,
"currency": "USD",
"revshare_pct": 30,
"payout_cents": 38623,
"payout_usdt": 421.3,
"status": "paid",
"tx_hash": "0x...",
"created_at": "2026-08-01T00:03:11Z",
"paid_at": "2026-08-03T12:40:00Z"
}
]
}
Statuses: pending — computed, not sent; paid — sent, with the transaction hash in tx_hash.
Requires payouts:read. The same view is in the dashboard under "Payouts".
How the money arrives
USDT-TRC20 to the address set in the dashboard. The transfer today is made by an operator by hand, who then records the hash — automatic sending is planned. Because of that, a few working days pass between the computation on the 1st and the funds landing.
The minimum payable amount, and the handling of disputed payments and refunds, are set out in the partner agreement.
Refunds
A chargeback is deducted from revenue. A high refund share triggers a warning first, then an automatic suspension pending review: a suspended partner cannot create customers and stops branding the app.