> ## Documentation Index
> Fetch the complete documentation index at: https://afrizon-admin.tunzaa.co.tz/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify vendor identity with KYC documents

> Step through the KYC document review flow in Meneja — from vendor submission to your approval or rejection decision, and what each verification status means.

Before a vendor can go live on your platform, they must pass an identity and business verification check. Vendors submit one or more documents during onboarding, and you review each document individually in the Meneja dashboard. The platform tracks verification at both the document level and the overall vendor level, so you always have a clear picture of where a vendor stands in the approval process.

## How the KYC flow works

<Steps>
  <Step title="Vendor submits documents">
    During onboarding (or later from their profile), the vendor uploads verification documents. Each uploaded item becomes a `VerificationDocument` record with an initial `verification_status` of `pending`.
  </Step>

  <Step title="You review each document">
    Open the vendor's profile and navigate to the **Documents** section. For each document, you can see its type, submission date, and current status. Review the uploaded file via `document_url`.
  </Step>

  <Step title="Approve or reject the document">
    Select **Approve** to mark the document as `verified`, or **Reject** to mark it as `rejected`. When rejecting, you must provide a rejection reason, which is stored in `rejection_reason`.
  </Step>

  <Step title="Approve or reject the vendor">
    Once all required documents are verified, you can approve the vendor as a whole. If documents are missing or invalid, you can reject the vendor. This updates the vendor's top-level `verification_status`.
  </Step>

  <Step title="Activate the vendor">
    An approved vendor still starts with `is_active` set to `false`. After approval, activate the vendor to make their store visible to shoppers.
  </Step>
</Steps>

## VerificationDocument fields

Each document submitted by a vendor contains the following fields:

| Field                       | Description                                                                             |
| --------------------------- | --------------------------------------------------------------------------------------- |
| `document_id`               | Unique identifier for this document record                                              |
| `document_type_id`          | Reference to the configured document type (e.g. business registration, tax certificate) |
| `document_type_name`        | Human-readable name of the document type                                                |
| `document_type_description` | Description of what the document type covers                                            |
| `document_url`              | URL of the uploaded file                                                                |
| `number`                    | Document number or reference code (e.g. registration number)                            |
| `verification_status`       | Current review outcome for this document                                                |
| `rejection_reason`          | Reason provided when the document is rejected; `null` otherwise                         |
| `submitted_at`              | ISO 8601 timestamp of when the vendor uploaded the document                             |
| `expires_at`                | Expiry date of the document, if applicable                                              |
| `verified_at`               | Timestamp of when the document was approved                                             |

## Document verification statuses

| Status     | Meaning                                                         |
| ---------- | --------------------------------------------------------------- |
| `pending`  | The document has been submitted and is awaiting review          |
| `verified` | You have reviewed and approved the document                     |
| `rejected` | You have reviewed the document and it did not meet requirements |

<Note>
  The `verification_status` field on an individual `VerificationDocument` uses `verified` (not `approved`) to indicate a passing review. The top-level vendor `verification_status` uses `approved`.
</Note>

## Overall vendor status

After you act on a document, the API response includes an `overall_vendor_status` field that reflects the vendor's aggregate verification state. This value is derived from the combination of all document statuses and any explicit approve or reject action you take on the vendor as a whole.

The vendor-level `verification_status` can be:

| Value      | Meaning                                                                                          |
| ---------- | ------------------------------------------------------------------------------------------------ |
| `pending`  | One or more documents are still under review, or the vendor has not yet been explicitly approved |
| `approved` | All required documents have been verified and the vendor has been approved                       |
| `rejected` | The vendor has been rejected, either due to failed documents or an explicit rejection            |

<Warning>
  Approving a vendor sets `is_active` to `false` by default. You must separately activate the vendor to make their store live. Rejecting a vendor also sets `is_active` to `false`.
</Warning>

## Rejecting a vendor or document

When you reject a document or a vendor, the dashboard prompts you to select or enter a rejection reason. Common reasons include:

* Incomplete or missing verification documents
* Invalid or expired verification documents
* Inconsistent business information
* Violation of platform policies

The rejection reason is stored in `rejection_reason` on the `VerificationDocument` record (for document-level rejections) or sent as part of the vendor status update payload (for vendor-level rejections).

<Tip>
  Always provide a clear rejection reason. The reason is available to you when you review the vendor record later, helping you track why a vendor was previously rejected.
</Tip>