// Represents: GET /commissions_payments · Admin/CommissionPaymentController — see docs/ISYSTEM_REFERENCE.md §Batch 3 "Commissions payments" /* Commissions ▾ → Commission Payments. THIS SCREEN MOVES REAL MONEY. ------------------------------------------------------------------------------------------------ Real endpoints simulated here: GET /commissions_payments/ index() L50 — the page (generics/index.blade.php) GET /commissions_payments/rows/ rows() L83 — serverSide DataTables feed GET /commissions_payments/{id} edit() L253 — edit-modal body POST /commissions_payments/pay/{id} pay() L226 — single payment (CSRF POST via doBan) POST /commissions_payments/{id?} store() L263 — save amount + note Views: admin/generics/index.blade.php + filters/commissions_payments.blade.php + models/commission_payment.blade.php; JS driver public/js/pages/generic/commissions_payments.js (+ shared banConfirm/doBan in public/js/custom.js:58/104). Page title = Str::plural(__('backend.extras.commissions_payments')) — main_label is set twice at index() L74/L78, the second one wins. WHAT MOVES THE MONEY (CommissionsController::payCommissions L1204-1245 → performPayout L1252-1283): 1. pay()/bulk force `payable = true` and save. 2. `amount <= 0` is rejected outright — no claim, no transfer. 3. IDEMPOTENT ATOMIC CLAIM: UPDATE commissions_payments SET paid = 1, pay_time = WHERE id = ? AND paid = 0 0 rows affected ⇒ somebody already paid this row ⇒ skip. The in-repo comment is explicit: a crash mid-flight under-pays, it never double-pays. That ordering is preserved verbatim below (hcpayAttempt) — the claim happens BEFORE the transfer, and an already-paid row can never be paid a second time. 4. performPayout() builds a per-game_type description and calls TransferController::processTransfer (TransferController.php:516, `add` case L571-698) with type='add', system='commissions', payeer_id = the RECIPIENT'S SKIN-ADMIN ANCESTOR (User::getMyParent(ADMIN_LEVEL, user_id)) and api_key = that admin's api_key. So the money leaves the skin admin's own wallet, not a platform float account. 5. processTransfer: DB transaction + lockForUpdate on both users, payer must satisfy balance + credits >= amount, payer.balance -= amount, receiver.balance += amount, available_balance recomputed as credits + balance, and TWO mirrored `transactions` rows are written (payer `out`, receiver `add`). A `transaction_history` row is written ONLY when the receiver is a PLAYER (user_level 30) — commission recipients are agents/shops, so in practice no history row is produced. Same engine, same mechanics as src/pages/HostDeposit.jsx (§Batch 5 "Deposit"), which documents the engine-side defects that live below this screen and are not reproducible from its markup (swallowed rollback, no idempotency key, api_key only checked against *some* users row, no-op saveLog). 6. Non-`ok` response ⇒ THE CLAIM IS RELEASED (paid = 0, pay_time = null), `details` keeps the JSON error and Log::error fires; the operator sees backend.extras.something_went_wrong = "Something went wrong". Success ⇒ `details` keeps the JSON response. Rows are NOT created here. Crons create them: GET /crons/payMonthlyCommissions → payMonthlyCommissions() (previous commission month from getDateCalendario(); per user × game_type sport_profit/casino/ casinolive/virtual; `payable` seeded from the commission profile's auto_pay; rows carrying edit_user_id are skipped by recalculation; every payable && !paid row for the period is then auto-paid), GET /crons/payWeeklyCommissions (same routine, commission_type='weekly'), and GET /crons/payTurnover → payTurnover() (weekly `sport_turnover` rows for agents whose sport profile tipologia ∈ [1,3]). The Period column only displays the stored "Y-m-d,Y-m-d" string — there is NO period picker on this screen, so hrsPeriodOptions("commission") / ("week") are used below to generate the mock rows' periods instead of as a filter: they reproduce the real first-Monday → day-before-next-first-Monday commission months (getDateCalendario) and the Mon–Sun turnover weeks. KNOWN-BUG POLICY (CLAUDE.md) — divergences implemented, each flagged at its call site: (1) Bulk "Pay All" / "Pay Selected" are, on the real platform, SIDE EFFECTS OF THE GET /rows LISTING REQUEST: the JS stuffs hidden inputs pay_all_hdn=1 / pay_selecteds_hdn= into the DataTables column-search values, redraws, then clears them (commissions_payments.js L139-157); rows() L147-172 then pays synchronously inside that GET. No CSRF, no POST semantics, and a browser refresh with those params still attached re-fires the attempt — the only thing standing between that and a double payment is the paid=0 claim. For a money-moving action that is a real defect, so the evident intent is implemented here: an explicit, confirmed, POST-style action (HcpayPayModal) that states amount, recipient and period before anything moves. (2) The listing filters are loose LIKEs — ID is a substring match ("4" returns 244), User Type is LIKE '%v%' on users.user_level so "2" (Skin Access) also returns every 20 (Shop) row, and Commission Type "casino" also returns "casinolive" rows. Exact matching is implemented instead; each field's Tip says what the real one does. Preserved faithfully, NOT "fixed": the atomic claim and its error text ("Payment status Paid"), the amount <= 0 rejection, the claim release on transfer failure, `payable` being forced true before any attempt, sortability limited to Username and Skin, the raw untranslated `commissions.casinolive` label, and the absence of KPIs/export/create — this screen genuinely has none. */ const { useState: hcpayUseState, useMemo: hcpayUseMemo } = React; /* Deterministic PRNG (FNV-1a + mulberry32) — same convention as the sibling Host pages, so the ledger renders identically on every load and the narrative rows below stay pinned. */ const hcpayHash = (s) => { let h = 2166136261 >>> 0; for (let i = 0; i < s.length; i++) { h ^= s.charCodeAt(i); h = Math.imul(h, 16777619); } return h >>> 0; }; const hcpayRng = pbRng; // was a local copy of mulberry32 — see pbRng in src/data.jsx /* UsersController::usersLevels() display names (Master/Agent/Promoter/Shop are per-skin overridable via custom_*_name — defaults used). Same map as HostReportCommissions.jsx's HRCM_LEVELS, widened to every level the User Type filter offers. */ const HCPAY_LEVELS = { 0: "Super Admin", 1: "Affiliate", 2: "Skin Access", 4: "Customer Care", 6: "Administration", 8: "Master", 9: "Regulation User", 10: "Agent", 15: "Promoter", 20: "Shop", 30: "Player", }; /* Option order mirrors usersLevels() as the real select renders it. */ const HCPAY_LEVEL_OPTS = [6, 1, 4, 30, 20, 15, 10, 8, 2, 0, 9].map(v => ({ value: String(v), label: HCPAY_LEVELS[v] })); /* game_type → __('commissions.'). `casinolive` has NO key in the repo's default lang, so the real screen prints the raw key — reproduced honestly rather than silently translated. */ const HCPAY_GAME_LABEL = { sport_profit: "Sport GGR", sport_turnover: "Sport Turnover", casino: "Casino GGR", casinolive: "commissions.casinolive", virtual: "Virtual GGR", }; /* The filter select offers only these four — there is deliberately no `casinolive` option upstream. */ const HCPAY_GAME_FILTER = [ { value: "casino", label: "Casino GGR" }, { value: "sport_profit", label: "Sport GGR" }, { value: "sport_turnover", label: "Sport Turnover" }, { value: "virtual", label: "Virtual GGR" }, ]; /* commission_type → __('backend.extras.'), column labelled "Periodicity" (commissions.periodicity). */ const HCPAY_PERIODICITY = { monthly: "Monthly", weekly: "Weekly" }; const HCPAY_PAGE_SIZES = [5, 10, 25, 50]; // commissions_payments.js lengthMenu; pageLength 50 /* Skins the acting user can see (rows() scopes by Auth::user()->getSkinIDS()). Names + currencies are the ones data.jsx BRANDS / HostSkins.jsx already configure, so a skin means the same thing on every screen of this build. `admin` is the skin-admin ancestor resolved by User::getMyParent(ADMIN_LEVEL, user_id) — it is both the currency source for the Amount column and the wallet every payment is debited from. */ const hcpayDmy = (iso) => { const p = (iso || "").split("-"); return p.length === 3 ? `${p[2]}/${p[1]}/${p[0]}` : ""; }; /* `d/m/Y G:i:s` — G is the hour WITHOUT a leading zero, which is why the real Last Update column prints "02/03/2026 8:31:01" rather than "08:31:01". */ const hcpayStamp = (iso, h, m, s) => { const [y, mo, d] = (iso || "").split("-"); return { text: `${d}/${mo}/${y} ${h}:${String(m).padStart(2, "0")}:${String(s).padStart(2, "0")}`, ts: Date.parse(`${iso}T00:00:00Z`) / 1000 + h * 3600 + m * 60 + s }; }; const hcpayNextDay = (iso) => { const d = new Date(`${iso}T00:00:00Z`); d.setUTCDate(d.getUTCDate() + 1); return d.toISOString().slice(0, 10); }; /* Last Update stamp for rows touched in this session — same d/m/Y G:i:s shape as the cron-written ones. */ const hcpayNow = () => { const d = new Date(); const p = (n) => String(n).padStart(2, "0"); return { text: `${p(d.getDate())}/${p(d.getMonth() + 1)}/${d.getFullYear()} ${d.getHours()}:${p(d.getMinutes())}:${p(d.getSeconds())}`, ts: Math.floor(d.getTime() / 1000) }; }; /* performPayout() description. The reference quotes one variant verbatim — "Commissions on GGR Sport (dd/mm/YYYY - dd/mm/YYYY)" — the others follow its shape. */ const HCPAY_DESC_HEAD = { sport_profit: "Commissions on GGR Sport", casino: "Commissions on GGR Casino", casinolive: "Commissions on GGR Casino Live", virtual: "Commissions on GGR Virtual", sport_turnover: "Commissions on Turnover Sport", }; const hcpayDesc = (r) => { const [a, b] = r.period.split(","); return `${HCPAY_DESC_HEAD[r.game_type] || "Commissions"} (${hcpayDmy(a)} - ${hcpayDmy(b)})`; }; const hcpayJson = (o) => JSON.stringify(o, null, 2); /* THE BRAND LIST AND THE NETWORK BEHIND IT ARE GONE — invented brands with invented admin wallets, and an invented set of operators with per-user scales and auto-pay flags. The brand filter is a `skins` feed. */ /* THE PAYMENT ROWS WERE GENERATED, INCLUDING WHICH ONES HAD BEEN PAID. `hcpayBuildRows` invented four commission months and three turnover weeks, an amount per (user, game type) from a PRNG, and then set `paid` from a hardcoded rule — with two named exceptions written in by hand: "lucca1's newest Casino Live row settled at exactly 0.00" and "the one funds failure in the set: gb24admin's wallet holds 1,850.00 EUR". A settlement screen showing which commissions have been paid, from a generator with scripted failures. `commission_payments` (007) is the real table and carries every column the screen reads: period, amount, currency, payable, paid, paid_at, the game_type, the periodicity — and `ledger_entry_id`, which is the difference between "marked paid" and "money moved". `commission_settlement_drift` exists to find rows where those two disagree. */ const hcpayRowFromDb = (r) => { const u = r.user || {}; const sk = r.skin || {}; return { id: Number(r.id), period: `${r.period_start},${r.period_end}`, periodStart: r.period_start, periodEnd: r.period_end, skin: sk.name || "", skinId: r.skin_id == null ? null : Number(r.skin_id), cur: r.currency || sk.currency || "", /* The PAYER is the brand's admin account. It is not on this table — the payout is made from whoever runs the payment — so it stays null rather than being assumed to be the skin admin, which was hardcoded before. */ payer: null, user: u.username || String(r.user_id), userId: r.user_id == null ? null : Number(r.user_id), level: u.user_level == null ? null : Number(u.user_level), amount: Number(r.amount) || 0, commission_type: r.periodicity || "", game_type: r.game_type || "", /* 0/1 rather than booleans: every filter and comparison on this screen already speaks in those, and upstream stores tinyints. */ paid: r.paid ? 1 : 0, payable: r.payable ? 1 : 0, pay_time: r.paid_at ? Date.parse(r.paid_at) : null, updated: { ts: Date.parse(r.updated_at || r.created_at) || 0 }, /* MONEY MOVED, OR NOT. A row marked paid with no ledger entry is a settlement nobody funded — shown rather than smoothed over. */ ledgerEntryId: r.ledger_entry_id == null ? null : Number(r.ledger_entry_id), details: r.details || null, edit_user_id: null, note: r.note || "", _raw: r, }; }; const HCPAY_BLANK = { skin: "", status: "", level: "", id: "", username: "", game: "" }; /* ================================================================================================= The payment attempt — payCommissions() → performPayout() → processTransfer(), in that order. Returns a result record; it never mutates, the caller applies the state changes. ================================================================================================= */ const hcpayAttempt = (row, payer, recvBal, seq) => { const base = { id: row.id, row, desc: hcpayDesc(row) }; // payCommissions L1206: amount <= 0 is rejected before anything is claimed. if (row.amount <= 0) { return { ...base, outcome: "rejected", claimed: false, message: "Amount must be greater than zero" /* label inferred — the guard returns early without a backend.* key */ }; } /* ATOMIC CLAIM — UPDATE … SET paid = 1, pay_time = ? WHERE id = ? AND paid = 0. 0 rows affected means the row was already settled: the attempt is skipped, never retried. pay() surfaces exactly this text on a single payment (controller L230-231). */ if (row.paid === 1) { return { ...base, outcome: "already", claimed: false, message: "Payment status Paid" }; } // processTransfer `add`: payer must satisfy balance + credits >= amount (TransferController L589-597). if (payer.bal + payer.cr < row.amount) { // EMBED-OK: `row` is a mapped row — `user` is a username string. const details = { status: "error", message: "not enough balance", type: "add", system: "commissions", payeer: row.payer, receiver: row.user, amount: row.amount.toFixed(2), currency: row.cur }; // Claim released: paid back to 0, pay_time null, details keeps the JSON error, Log::error fires. return { ...base, outcome: "failed", claimed: true, released: true, details, message: "Something went wrong" /* backend.extras.something_went_wrong */ }; } const newPayer = Math.round((payer.bal - row.amount) * 100) / 100; const newRecv = Math.round(((recvBal || 0) + row.amount) * 100) / 100; // EMBED-OK: `row` is a mapped row — `user` is a username string. const details = { status: "ok", type: "add", system: "commissions", payeer: row.payer, receiver: row.user, amount: row.amount.toFixed(2), currency: row.cur, transaction_id: seq + 1 }; return { ...base, outcome: "paid", claimed: true, details, newPayer, newRecv, tx: [ { tx: seq, who: row.payer, side: "Payer · skin admin", type: "out", amt: -row.amount, col: "ref_new_balance", newVal: newPayer }, // EMBED-OK: `row` is a mapped commission-payment row — `user` is the username string the mapper produced, not the embedded user object. { tx: seq + 1, who: row.user, side: "Receiver", type: "add", amt: row.amount, col: "ref_new_balance", newVal: newRecv }, ], }; }; /* ================================================================================================= Presentational pieces ================================================================================================= */ const HcpayStatusPill = ({ paid }) => ( {paid ? : } {paid ? "Paid" : "To pay"} ); /* Modal chrome — shared .bp-modal, full-screen on mobile (brief §11). The real modal is generaModalGestione() → admin/utils/modal.blade.php with the body AJAX-loaded from GET /commissions_payments/{id}. */ const HcpayModal = ({ title, icon, onClose, children, footer, wide, tone }) => (
e.stopPropagation()}>
{icon && }{title}
{children}
{footer &&
{footer}
}
); /* The three Customer-Care permissions this screen splits across. Documentation, not a control: the demo persona is the super admin, for whom the policy short-circuits on SUPERADMIN. */ const HcpayGates = () => (
Who can do what here — CommissionPaymentPolicy splits this screen across three Customer-Care permissions, and every one of them also needs the row to be unpaid.
Back-office permissionUnlocksAlso satisfied by
support_commission Seeing the screen at all — sidebar entry (a) and CommissionPaymentPolicy::viewAny. Skin admin of the same skin · Super admin
support_commission_edit_payments The Edit action (update policy) — and only while the row is unpaid. Skin admin of the same skin · Super admin
support_commission_payments The Pay action, single and bulk (pay policy) — unpaid rows only. Skin admin of the same skin · Super admin
); /* ================================================================================================= Edit modal — GET /commissions_payments/{id} → POST /commissions_payments/{id} Left column is read-only row info; only amount and note are editable. ================================================================================================= */ const HcpayEditModal = ({ row, onClose, onSave }) => { const [amount, setAmount] = hcpayUseState(String(row.amount)); const [note, setNote] = hcpayUseState(row.note || ""); const [errs, setErrs] = hcpayUseState(null); const save = () => { /* Inline Validator::make in store() L265-287 — amount: required|gt:0, note: required. Failure returns ajaxError JSON with a `campierrati` key list, which the modal paints onto the offending fields. The messages themselves are __('backend.*') keys that do not resolve in the committed lang files. */ const e = {}; const n = parseFloat(String(amount).replace(/,/g, "")); if (String(amount).trim() === "") e.amount = "Insert an amount"; // label inferred else if (!isFinite(n)) e.amount = "The amount must be a number"; // label inferred else if (!(n > 0)) e.amount = "The amount must be greater than 0"; // label inferred (rule: gt:0) if (!note.trim()) e.note = "Insert a note"; // label inferred if (Object.keys(e).length) { setErrs(e); return; } onSave(row, n, note.trim()); }; const info = [ ["Period", {row.period.replace(",", ", ")}], ["Skin", row.skin], ["Username", row.user], ["User Type", HCPAY_LEVELS[row.level]], ["Amount", `${hrsMoney(row.amount, row.cur)}`], ["Periodicity", HCPAY_PERIODICITY[row.commission_type]], ["Commission Type", HCPAY_GAME_LABEL[row.game_type]], ["Status", ], ["Payable", row.payable ? "Yes" : "No"], ]; return ( }> {errs && (
Some fields need attention.{/* ajaxError + campierrati */}
)}
Row dataRead-only in the real modal too — everything except amount and note comes from the cron that generated the row.
{info.map(([k, v]) => (
{k}{v}
))}
{ setAmount(e.target.value); setErrs(null); }} /> {row.cur}
{errs && errs.amount &&
{errs.amount}
}
Changing the amount stamps edit_user_id on the row. From that moment every recalculation cron skips it — payMonthlyCommissions / payWeeklyCommissions / payTurnover all guard on whereNotNull('edit_user_id'), so the figure you save here is final until someone pays it.
{/* commissions.note */}