Page body
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:
- 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
Search by tagis a staged text input; the queue only changes whenApply Filtersis pressed or the user confirms the active tag chipClearresets 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 URL
Common questions
Why is KYC inside Transactions?
Because this route is grouped under the transaction navigation in the current Backoffice structure, even though the component is shared with player-document tooling.
Why is Add Document missing here but visible on player-scoped KYC?
/transactions/kyc mounts the shared PlayerKYCSettings component without a player context, so the Add Document button is intentionally hidden on this route. That helper is only rendered when the same component is used inside a player-scoped workspace with player.userId.
Which actions actually change workflow state?
The state-changing actions are:
- approve
- reject
- cancel request
- re-request document
- request document
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 through GET /api/admin/3rd-party-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 component under the transactions navigation.
- The action column mixes read-only helpers and mutation controls.
- Some actions depend on document type and current status.
- 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.
Verification status
- status:
verified_backend - last verified:
2026-04-18 - note: queue filters, row actions, request/cancel/verify/download services, and Bynn third-party transport edges are traced; the remaining caution is that SumSub status/date values are still controller-injected placeholder data