Verification queue
The verification queue is where companies become visible and trusted on the marketplace. It’s at /internal/admin/verifications and needs the super_admin or verifier role.
Getting in
The /internal/admin/* panel sits behind Cloudflare Access, separate from the app’s own login, and additionally requires a row in admin_users. A user who clears Access but isn’t an admin sees “Admin access denied”; one who doesn’t clear Access gets a 401.
MFA is a Cloudflare Access policy, not an in-app screen. There is nothing to enable inside DynaCargo — the app only records which authentication methods were used into the audit metadata.
The nav is filtered to your capabilities: Overview, Verifications, Disputes, Support, Reviews, Payment logs, Admin users, Erasure and Audit log. Your current role is shown at the end of it.
Reviewing a company
Click Review docs ({n}) to open the document viewer. Documents open through short-lived signed URLs, so a link you copy won’t keep working — reopen from the queue instead.
Check the PACRA registration number and the TPIN against the uploaded documents. Those two are what most decisions turn on.
Deciding
- Approve — the company becomes publicly visible on the marketplace and its provider page, and carries the ✓ Verified badge. No reason needed.
- Reject — opens a dialog with a Reason template: Documents illegible or low quality, PACRA registration number does not match, TPIN / tax number invalid or unverifiable, Submitted documents have expired, Required documents missing, or Other (see notes). Add notes — required when you pick Other — then Confirm rejection.
- Suspend — the same, with its own templates: Suspended pending compliance review, Suspended pending complaint investigation, or Other (see notes).
Every decision is written to the audit log with your identity.
Use the templates rather than Other wherever one fits. Consistent reasons are what let the company actually fix the problem and come back, and what makes the queue’s rejection reasons worth reading in aggregate.
Bulk approval
Select all low-risk ({n}) then Bulk approve ({n}). The page states the rule next to the buttons: “Low-risk = pending with TPIN + PACRA on file.” Anything else is skipped rather than approved.
Each row shows its own PACRA number and TPIN inline — a row reading PACRA … · TPIN — is missing its TPIN and won’t be picked up by the low-risk selection.
You’ll get a summary — “Approved n, skipped n, failed n” — and every approval in the batch is audited under a shared batch id, so a bad batch can be traced as one action.
Cross-border clearance
Separate from verification, and granted separately. A company that has asked for it shows a cross-border requested badge with the request date.
The badge is the only signal — the queue sorts by status and then by age, so a clearance request does not rise to the top and will sit among the ordinary pending rows. If you’re working the queue for clearance requests specifically, scan for the badge rather than expecting them first.
Use Grant cross-border to clear them, or Revoke cross-border to take it back.
This matters more than it looks. Cross-border loads are only shown, matched and biddable for cleared carriers, and the matcher skips uncleared carriers silently — they get no error and no explanation, just no work. A request sitting in the queue is a carrier wondering why the platform is empty.
Before granting, check the COMESA Yellow Card and carrier licences on the company profile.
Role gating
View-only roles — read_only, finance — can see the queue but get no action buttons. verifier can decide verifications but can’t manage admin users.