// NO PROD JSON API (bucket B — feed is a DataTables render payload or
// {"html":...}, not data) — mock until backend (see PROD_API_INVENTORY.md)
// Represents: GET /payments/to-confirm/ · AdminPaymentsController::show('to-confirm') — see docs/ISYSTEM_REFERENCE.md §Batch 10.2
/* PayBO → To Confirm. NEW SCREEN (Batch 10).
THE PROTOTYPE ALREADY HAD SOMETHING CALLED "To Confirm" AND IT IS NOT THIS.
Transactions.jsx carries a `to_confirm` status tab that filters the
transaction list. isystem's To Confirm is its own PayBO section over its own
table, `payment_cascade_holds` — a WITHDRAWAL HELD MID-CASCADE, not a
transaction with a status. Different entity, different columns, different
actions. The status tab stays (it is a real thing too); this is the section.
Why it was invisible to the coverage check, and the third distinct blind
spot found in this audit:
· controller-level -> UsersController "covered" hid /myaccount (Batch 9)
· action-level -> one action, ONE view, TEN screens (here)
`AdminPaymentsController::show($section)` returns `admin.payments.index`
for every one of dashboard | transactions | deposits | withdrawals |
methods | players | reports | activity | settings | to-confirm. An
action-level check sees one screen; an operator sees ten. The manifest now
reads the route's own where() constraint, so a section added upstream shows
up untriaged rather than hiding behind a sibling.
TWO KINDS OF HOLD, and the row reads differently for each:
withdrawal a PSP in the cascade failed; the next one is queued.
Buttons: Confirm / Skip.
withdrawal_review the amount is at or above the brand's review
threshold and NO PSP HAS BEEN CALLED YET.
Buttons: Approve / Skip.
RESERVED FUNDS CHANGE WHAT SKIP MEANS. isystem answered "are these funds
reserved" with a non-empty 64-character `reserved_token` string it matched
against withdrawal_requests.token; here the hold carries a real foreign key
and "reserved" means the withdrawal has a debit ledger entry. On a reserved
hold, Skip refunds and the
button turns danger-red; on an unreserved one it just advances past the
failed PSP. Same button, two very different consequences — modelled, and
spelled out in the confirm dialog.
Writes are a FORM POST with a redirect and a session flash, not AJAX:
POST /payments/to-confirm/action, validated hold_id:required|integer,
action:required|in:confirm,skip. Ownership is re-checked on the write, and a
hold outside the operator's skins returns the SAME message as a missing id
("Hold not found or not accessible.") so the endpoint cannot be used to
probe another brand's hold ids. Kept.
Confirm calls a PSP and Skip can refund a reservation. Both move money, so
both are DISABLED behind NoBackend per docs/REAL_VS_MOCK.md §4. Everything
else — the two kinds, the reserved distinction, the columns, the ownership
rule — is real.
Deliberately NOT added (isystem has none of these): filters, search,
sorting, pagination, export, bulk confirm/skip, or a history of decided
holds. The section lists pending rows and nothing else. */
/* Nine holds used to be generated here, complete with five plausible PSP error
strings ("cURL error 28: Operation timed out after 30001 milliseconds"),
invented player usernames and reserved-fund tokens. Every row on this queue
is a withdrawal waiting on a human decision — the worst possible place for a
fabricated one. They are `payment_cascade_holds` rows now. */
const ptcHoldRow = (h) => {
const req = Array.isArray(h.request) ? h.request[0] : h.request;
return {
id: Number(h.id),
/* A hold with a threshold and no failed provider is the review case: the
amount is at or above the brand's review threshold and no PSP has been
called. Anything else is a cascade retry. */
kind: h.threshold_amount != null && !h.failedProvider ? "withdrawal_review" : "withdrawal",
created_at: h.created_at ? String(h.created_at).replace("T", " ").slice(0, 16) : "—",
user_id: h.user_id == null ? null : Number(h.user_id),
username: h.user ? h.user.username : "—",
skin_id: h.skin_id == null ? null : Number(h.skin_id),
brand: h.skin ? h.skin.name : "—",
amount: Number(h.amount) || 0,
currency: h.currency || (h.skin ? h.skin.currency : "") || "",
/* "reserved" = the funds already left the player. One boolean derived from
the withdrawal's debit ledger entry, not a token string compared by hand. */
reserved: !!(req && req.debit_ledger_entry_id),
withdrawalRequestId: h.withdrawal_request_id == null ? null : Number(h.withdrawal_request_id),
threshold_amount: h.threshold_amount == null ? null : Number(h.threshold_amount),
failed_provider_code: h.failedProvider ? h.failedProvider.code : null,
next_provider_code: h.nextProvider ? h.nextProvider.code : null,
outcome: h.outcome || null,
last_error: h.reason || "",
status: h.status,
};
};
const ptcMoney = (v, c) =>
`${Number(v).toLocaleString("en-US", { minimumFractionDigits: 2, maximumFractionDigits: 2 })} ${c}`;
/* rtrim(rtrim((string) $threshold, '0'), '.') — 2000.00 renders as "2", not
"2000.00". Reproduced because it is what an operator sees. */
const ptcThreshold = (v) => String(v).replace(/0+$/, "").replace(/\.$/, "") || String(v);
const PtcDialog = ({ hold, action, onClose }) => {
const isReview = hold.kind === "withdrawal_review";
const isReserved = !!hold.reserved;
const skipRefunds = action === "skip" && isReserved;
return (
{action === "confirm" ? (
isReview
? <>Approving releases the withdrawal into the cascade. No PSP has been called yet — this is the first call.
: <>Confirming calls {hold.next_provider_code}, the next PSP after {hold.failed_provider_code} failed. If that call also returns ERROR the hold goes to failed; several paths reset it to pending so it stays in this queue.
) : (
skipRefunds
? <>These funds are already debited (withdrawal_requests.debit_ledger_entry_id is set on request {hold.withdrawalRequestId}). Skipping refunds them — the money goes back to the player and the withdrawal does not happen.
: <>Nothing is reserved on this hold, so skipping just advances past the failed PSP. No money moves.
)}
) },
];
const reviewCount = holds.filter(h => h.kind === "withdrawal_review").length;
const reservedCount = holds.filter(h => h.reserved).length;
return (
Every PayBO section aborts 403 rather than degrading, and the write endpoint re-checks skin ownership: a hold outside your skins returns the same message as a hold that does not exist, so the endpoint cannot be used to probe other brands' ids.}
explainer={{
title: "What this queue is, in plain English",
bullets: [
"These are not transactions with a status. They are rows in payment_cascade_holds — a withdrawal that stopped part-way and needs a decision.",
"Two reasons a withdrawal lands here: a PSP failed and the next one is queued (Confirm), or the amount is at or above the brand's review threshold and no PSP has been called yet (Approve).",
"Where the amount says “reserved”, Skip is a REFUND — the money goes back to the player. Where it does not, Skip just advances past the failed PSP.",
"The Transactions page also has a “To confirm” tab. That is a different thing: a status filter over transactions, not this queue.",
],
}}
>
{/* An empty payout-decision queue and a failed read are opposite
facts, and this screen has no filters to blame either on. */}
{() => }
{dialog && setDialog(null)} />}
);
};
window.PayboToConfirm = PayboToConfirm;