What This Surface Shows
Even though the route lives under transactions, this page is the Backoffice document-verification queue.
Operators use it to:
- review uploaded customer documents
- preview or download files
- run or inspect third-party verification
- approve, reject, cancel, or re-request document flow
How To Read It
This is an action-heavy queue rather than a simple list. The Action column is the main operator workspace.
The page also includes:
- a status selector for the global queue
- tag-driven search
- direct navigation to the player profile
- third-party verification state and history
- document preview links
- route-level pagination with page sizes up to
10,000
Action And Filter Behavior
Statusfilters the global queue by Pending, Approved, Rejected, Canceled, Requested, or All statuses.Search by tagis a staged text input; the queue only changes whenApply Filtersis pressed or the user clicks a tag chip.Clearresets both the text input and the active tag filter- the route-level search is tag-only. It does not search by document name, user id, status, or provider
- the
Actioncolumn is status-driven:Pendingrows exposeApprove DocumentandReject DocumentRequestedrows exposeCancel Document- non-
Rejectedrows outsideRequestedexposeRe-request Document
Verify by 3rd Partyis shown only forbynndocumentsManually verify via Bynnis shown only for non-bynndocuments3rd Party Verification Historyonly appears when a row already has Bynn or SumSub historyDownload Documentonly appears when the row has a latest document URLAdd Documentis hidden on this global route because there is no player context
Common questions
Why is KYC inside Transactions?
Because this route is grouped under the transaction navigation in the current Backoffice structure, even though the same KYC view is also used inside player-document tooling.
Why is Add Document missing here but visible on player-scoped KYC?
Transactions / KYC opens the shared KYC view without a player context, so the Add Document button is intentionally hidden on this route. That helper is only rendered inside a player-scoped workspace.
Which actions actually change workflow state?
The main state-changing actions are:
- approve
- reject
- cancel request
- re-request document
- submit document to Bynn
- update player profile from Bynn history
The other actions are inspection helpers such as preview, download, history, or third-party verification.
Why do some rows show a 3rd-party report and others do not?
The dedicated View Report link is only shown for rows where documentName === 'bynn'.
The frontend first resolves a dossier id and then opens the external Bynn dashboard for that dossier.
Why can the 3rd-party verification column look inconsistent?
The Bynn values are part of the live admin/backend flow, but sumsubVerificationStatus and sumsubVerificationDate are still injected as placeholder data in UserController.getUserDocument for testing.
Treat the combined 3rd Party Verification column as:
- reliable for live Bynn-backed state
- not yet a fully authoritative production source for SumSub state
Known caveats
- This route reuses the player KYC view under the transactions navigation.
- The action column mixes read-only helpers and mutation controls.
- Some actions depend on document type, current status, provider history, and whether a latest document URL exists.
- The route-level search is a tag substring filter built from joined
users.tags, not a generic queue search over all visible columns. - The visible
Verify by 3rd Partyicon in the row action stack is currently a placeholder handler. The live Bynn verification transport is owned by the approve/manual verification modals. View Reportis an external-dashboard lookup, not an in-app workflow state change.- Secure document download uses a backend-generated filename based partly on the casino brand name.