Investigating one affiliate

Opening a row loads that row's referrer and then everything about them: all of their referrals, all of their rewards, their whole six-month earnings history. Two different rows belonging to the same referrer open the same screen.

So this is not "look at this one relationship" — it is "look at this affiliate's entire book, reached through one of their referrals". That is what makes it the right screen for a downline dispute and the wrong one for checking a single pairing (use the list's view dialog for that; it shows the referrer → referred pair and the record's status).

The block under Referral Link renders https://example.com/ref/ followed by the referral row's id. Both halves are wrong: the origin is a literal in the component, and the code is a referral record id rather than a user id.

The real member link is their own user id on the register route — https://your-site.com/en/register?ref=<user id>. Never copy this box to a member. What members see has the real format and the generator that produces it.

It is SUM(reward) across every reward this affiliate has ever earned, regardless of which condition — and therefore which rewardCurrency — produced each one, printed with a $. If your conditions pay in more than one currency, this number is not money in any unit.

The converted, honest version of this figure is on Rewards → Analytics; see The referral and reward analytics headers. The same applies to the Earnings column in the Network table below.

The detail endpoint returns no click-through rate and no average order value. There is no click tracking in this product and no order value on a referral. The component falls back to fixed constants, so every affiliate on your platform shows Click-through Rate 8.3% and Average Order Value $125.

Worse, the Conversion Rate bar uses the same fallback: an affiliate whose real conversion is 0 displays 12.5%, because zero is treated as "no value" and replaced by the placeholder. A genuinely non-zero rate is shown correctly.

Do not use this panel for anything. The affiliate's real numbers are the two tiles above it and the analytics panels on the list screens.

Under BINARY, placement, the two-child limit and spillover decide this picture and nothing else. Commission is paid by walking the sponsor chain — who invited whom — in mlm_referral.referrerId, for both BINARY and UNILEVEL alike.

So a member who appears three levels down in this table because of spillover is still paid as a level-1 referral of whoever actually invited them, and moving a node would change the diagram without changing one payout. Referral structures explains why.

The endpoint returns each reward as date / type / description / status / amount, and the table reads createdAt / conditionId / referrerId / isClaimed / reward. None of those names match, so on a live install every row renders as -, -, -, a Pending badge and $0, however many real rewards the affiliate has and whatever their state.

The number of rows is correct. Nothing in them is. Use /admin/affiliate/reward, filtered by referrer, for the real ledger.

On a BINARY install, asking for a user who has no referral record at all creates one — a self-referral (referrerId = referredId, status ACTIVE) — and a root binary node to hang it from. This is the legacy backfill for users who registered before MLM was enabled, and it runs on a GET.

It is harmless in normal use and it is why a user you merely looked at can appear in mlm_referral afterwards. Do not sweep this endpoint across your user table to "warm" anything.

PUT /api/admin/affiliate/referral/status is a status write and nothing else — it never calls the placement or removal helper. On a BINARY or UNILEVEL install that means a bulk approval sets every referral to ACTIVE and creates no node, so none of them appears in any tree view; and a bulk rejection leaves each node in place, still occupying the slot it was given and still blocking spillover into it.

There is no warning and no log line to find afterwards, because no tree update was attempted to fail. If you script approvals, call the single-id endpoint per referral. If a bulk call has already run, re-issue the same status one id at a time through /{id}/status — placement returns early when the node already exists, so it is safe to repeat.

The single-id status endpoint saves the decision first and does the tree work afterwards, in a guard that logs and warns rather than rolling back. So a referral can be ACTIVE in the list and absent from this screen's Network table.

If an approval does not appear in the diagram, that is a placement error in the backend log, not a lost approval — search pm2 logs backend for Referral <id> set to ACTIVE but the tree update failed. Re-approving through the single-id status endpoint is safe: placement returns early if the node already exists. Note that the absence of that log line does not mean the tree is fine — if the approval came through the bulk endpoint, nothing was logged because nothing was attempted.

Nothing is back-paid. Activity by a referred user while their referral was PENDING produced no reward and will not produce one afterwards. The Pending Longer Than 7 Days card on the Referrals analytics panel is the queue-age figure to watch.

1. "My downline is wrong." Open the member's referral, read the Network tab, and compare the level column against what they were told. Most of these disputes are spillover being read as a demotion, and the answer is that placement does not change earnings.

2. A suspected ring. The Network tab plus the Top Referrers bar on the Referrals analytics panel. One account holding an implausible share of the referrals, with downline members whose own referral counts are zero and whose accounts registered within minutes of each other, is the shape to look for.

3. "Am I earning?" Total Referrals and Total Earnings on this screen, then the real ledger at /admin/affiliate/reward. If the tiles show referrals and no earnings, the question is a condition question, not an affiliate one — go to The hourly reward evaluator and work its check order.

Setting isClaimed = true credits no wallet, writes no transaction and records no platform loss. The reward simply disappears from the member's claimable list.

Use it only to reconcile a reward you settled some other way — credit the wallet through the admin wallet tools first, then mark it claimed so the two records agree. Rewards and payouts covers the real claim path, the payout threshold and the withdraw_affiliate KYC gate.