NID Verification

NID Verification

This page explains how Bangladesh National ID (NID) verification works in the Payload service, how reviewers process a submission, and how the team can test the workflow in Payload Admin.

Overview

An NID verification record stores a user’s NID number and the front and back images of the document. The record is associated with one user and has a review status. Admins and moderators review the record; when its status changes, a hook attempts to synchronize the result to the user’s profile and sends an email for approval or rejection.

The verification data is split into two collections. nid-media stores the document images, while nid-verifications stores the NID number, links the images to a user, and tracks the review result. This separation lets the service apply specific access rules to identity images and verification records.

Collections

Collection	Purpose	Important access rules
nid-verifications	Stores the user relationship, NID number, front/back image relationships, review status, and rejection reason. A user can have only one record.	Authentication is required. Users can read and update their own record; admins and moderators can read and update all records. Only admins can delete. Field-level restrictions below still apply.
nid-media	Stores uploaded NID images separately from general listing/profile media. Accepts image files and creates a thumbnail.	Authentication is required. Users can read, update, and delete their own files; admins and moderators can access all files.

Verification Fields

Field	Meaning
user	Related user. Defaults to the authenticated user. The relationship can only be set on create or changed by an admin.
nid_number	NID number submitted for review. Required. An owner can change it before approval; admins and moderators can change it at any time.
front_image / back_image	Required relationships to files in nid-media. An owner can change them before approval; admins and moderators can change them at any time.
status	pending, approved, or rejected. Defaults to pending. Only admins and moderators can set or change it.
rejection_reason	Optional review explanation. Only admins and moderators can create or change it. It is included in the rejection email when present.

The verification record requires an NID number, but this collection does not define a format check for it. Account registration has its own 10- or 17-digit check; do not assume that check is applied when a reviewer enters or edits a verification record in Admin.

Review Workflow

1. A user submits their NID number and front/back images. The images are stored as NID media and associated with the verification record for that user.
2. The verification record starts in pending status. The user and submitted document details are linked together so reviewers can find and review the submission.
3. An admin or moderator opens the record in Payload Admin and chooses approved or rejected. For a rejection, the reviewer can provide a reason.
4. When the status changes, the afterChange hook maps it to the user’s verification_status:

NID verification status	User verification_status
pending	pending
approved	verified
rejected	unverified

5. On an approval, the user receives an “Account Verified” email. On a rejection, the user receives an email containing the rejection reason or a default explanation. Changing or saving other fields without changing status does not trigger this status-change workflow.

The synchronization and email work are performed by the same hook, but errors are caught and written to the Payload logs. When testing, verify the user’s resulting verification_status and check the server logs/email rather than assuming a successful record update guarantees both side effects completed.

Test in Payload Admin

Use a test account and test images only. Do not upload real identity documents to a shared development environment unless the team has explicitly approved it.

1. Start the Payload service and open http://localhost:3000/admin.
2. Sign in as an admin or moderator. Open Admin > NID Media and upload front and back test images. These files are for exercising the review workflow; do not use real NID documents.
3. Open Admin > NID Verifications and create a record for a test user. Select the uploaded images, enter a test NID number, and leave the status as pending. Each user can have only one verification record.
4. Save the record and open the associated user in the Users collection. Confirm that the verification status changes to pending.
5. Return to the verification record, change the status to approved, and save. Confirm the user’s status changes to verified and check that the approval email is delivered or logged by the development email adapter.
6. To test rejection, use a separate test user and verification record. Set the status to rejected, enter a rejection reason, and save. Confirm the user’s status changes to unverified and that the reason appears in the rejection email.

A save that leaves the status unchanged will not retrigger status synchronization or review email delivery. The user relationship is unique, so use a different test user for a separate verification record. Check the Payload server logs if a status update succeeds in Admin but the user status or email does not change.

Implementation Files

• Verification collection and status hook: frontend/payload/src/collections/NIDVerifications.ts
• NID image collection and upload settings: frontend/payload/src/collections/NIDMedia.ts
• User NID and verification fields: frontend/payload/src/collections/Users.ts
• Payload collection registration: frontend/payload/src/payload.config.ts
• Email transport and development fallback: Emails documentation