VERIFICATION STATUS

Event Overview

Event Type: VERIFICATION_STATUS Category: Payment Verification Description: The verdict on a filed verification — approved or rejected A filed verification is reviewed by EximPe. This webhook carries the conclusion of that review: the verdict, the reviewer’s comment, and the state of every document slot on the verification at that moment. It is the event that closes the loop the ask opened — LRS_VERIFICATION_NEEDED on an LRS payment, VERIFICATION_NEEDED on a B2B services payment. Those events say what a payment owes; this one says what came of sending it. VERIFICATION_STATUS fires on an approval and on a rejection, in the same shape. verification_status is the only key that tells them apart.

A send-back is not a verdict, and does not arrive here. When a review sends a verification back for changes, the payment keeps owing something, so the ask is raised again with the reviewer’s comment: LRS_VERIFICATION_NEEDED on an LRS payment, VERIFICATION_NEEDED on a B2B services payment. VERIFICATION_STATUS is only ever APPROVED or REJECTED. A rejection is final: the payment moves to NOT_APPLICABLE and a full refund is raised, so read settlement_status before you send anything after a REJECTED verdict.

When the webhook is sent

A review approves the verification. verification_status is APPROVED and message is an empty string — an approval has nothing to say beyond itself.
A review rejects the verification. verification_status is REJECTED and message carries the reviewer’s comment verbatim.

The same two events are raised for an LRS, a B2B services and a B2B goods payment. Where each review outcome is announced:

Payment	Approved	Rejected	Sent back for changes
LRS	`VERIFICATION_STATUS`	`VERIFICATION_STATUS`	`LRS_VERIFICATION_NEEDED`
B2B services	`VERIFICATION_STATUS`	`VERIFICATION_STATUS`	`VERIFICATION_NEEDED`
B2B goods	`VERIFICATION_STATUS`	`VERIFICATION_STATUS`	Nothing

The webhook is created only if your merchant account (or parent, for sub-merchants) has a webhook URL configured.

Delivery Details

Attribute	Value
HTTP method	`POST`
URL	The webhook URL configured for your merchant account
Content-Type	`application/json`
Timeout	10 seconds
Retries	Up to 5 delivery attempts (backoff: 1 min, 5 min, 15 min, 60 min)

Delivery: immediate, not batched.

Headers

Header	Description
`Content-Type`	`application/json`
`User-Agent`	`Eximpe-Webhook/1.0`
`X-Webhook-Event`	`VERIFICATION_STATUS`
`X-Webhook-Timestamp`	Unix timestamp (string) at the time of the request
`X-Webhook-Signature`	`HMAC-SHA256(encryption_key, raw_body)`, hex-encoded
`X-Webhook-Signature-V2`	`t=<timestamp>,v2=<hex>` where the digest is `HMAC-SHA256(encryption_key, "<timestamp>." + raw_body)`

Verifying. The body is serialised once and those exact bytes are both sent and signed, so hashing the raw request body as received is correct — do not re-serialise the parsed JSON first. Both signature headers are sent. Verify V2 (recommended) or V1 — see Verifying webhooks.

Payload Schema

The payment, the verdict, the reviewer’s comment, and every document slot on the verification. data holds exactly five keys on both verdicts.

{
  "event_type": "VERIFICATION_STATUS",
  "event_time": "2026-09-09T11:42:06.318204",
  "version": "3.0.0",
  "sequence_number": "550e8400-e29b-41d4-a716-446655440030",
  "data": {
    "payment_id": "PR8937616799",
    "order_id": "OD6184252650",
    "verification_status": "APPROVED",
    "message": "",
    "documents": [
      {
        "code": "offer_letter",
        "message": "Letter of admission from the institution",
        "ref": "5282347894",
        "doc_status": "VERIFIED"
      },
      {
        "code": "student_id",
        "message": "University ID card",
        "ref": "5121049200",
        "doc_status": "VERIFIED"
      },
      {
        "code": "fee_invoice",
        "message": "Fee invoice",
        "ref": "3261835736",
        "doc_status": "PENDING"
      }
    ]
  }
}

{
  "event_type": "VERIFICATION_STATUS",
  "event_time": "2026-09-09T14:07:51.662940",
  "version": "3.0.0",
  "sequence_number": "550e8400-e29b-41d4-a716-446655440031",
  "data": {
    "payment_id": "PR2740518863",
    "order_id": "OD9315704228",
    "verification_status": "REJECTED",
    "message": "The admission letter is for a different intake term. We cannot file this remittance.",
    "documents": [
      {
        "code": "offer_letter",
        "message": "Letter of admission from the institution",
        "ref": "6757940683",
        "doc_status": "REJECTED",
        "rejection_reason": "Letter is for the wrong intake term."
      },
      {
        "code": "student_id",
        "message": "University ID card",
        "ref": "4480912337",
        "doc_status": "VERIFIED"
      }
    ]
  }
}

{
  "event_type": "VERIFICATION_STATUS",
  "event_time": "2026-10-14T09:21:44.508113",
  "version": "3.0.0",
  "sequence_number": "550e8400-e29b-41d4-a716-446655440032",
  "data": {
    "payment_id": "PR5164093827",
    "order_id": "OD7730215946",
    "verification_status": "APPROVED",
    "message": "",
    "documents": [
      {
        "code": "invoice",
        "message": "Commercial invoice",
        "doc_status": "VERIFIED"
      }
    ]
  }
}

{
  "event_type": "VERIFICATION_STATUS",
  "event_time": "2026-10-14T11:03:19.274660",
  "version": "3.0.0",
  "sequence_number": "550e8400-e29b-41d4-a716-446655440033",
  "data": {
    "payment_id": "PR7712349900",
    "order_id": "OD1122334455",
    "verification_status": "REJECTED",
    "message": "The invoice does not match the declared amount.",
    "documents": [
      {
        "code": "invoice",
        "message": "Commercial invoice",
        "ref": "5282347894",
        "doc_status": "REJECTED",
        "rejection_reason": "The invoice total is illegible."
      }
    ]
  }
}

Field Specifications

Root Level Fields
Data Object Fields
Document Entries

string

required

Always "VERIFICATION_STATUS" for this webhook event

string

required

UTC, no timezone suffix, e.g. "2026-09-09T11:42:06.318204". Parse tolerantly — fractional seconds can be absent.

string

required

API version of your account, e.g. "3.0.0"

string

required

Unique ID of this event (a UUID, not an ordering counter). A retry resends the same value; use it to de-duplicate.

object

required

The payment, the verdict, and the documents it was reached on

Exactly five keys, on both verdicts. There is no action pointer on this event — nothing is being asked of you, so there is nowhere to send it.

string

required

UID of the payment the verdict is on.

string

required

UID of the order the payment belongs to.

string

required

The verdict. Two values, and only two:

Value	Means
`APPROVED`	The verification was accepted.
`REJECTED`	The verification was refused.

This is the one event in the family where the key carries a verdict rather than the payment’s own settlement state. On LRS_VERIFICATION_NEEDED and PAYMENT_UNDER_REVIEW the same key reads ACTION_REQUIRED or UNDER_REVIEW. Branch on event_type first and you will not confuse the two vocabularies.

string

required

The reviewer’s comment, verbatim. Safe to log, and safe to render to a payer.Empty string (not null) on an approval. On a rejection it is the reason the verification as a whole was refused — which is not always the same as any one document’s rejection_reason.

array

required

Every active document slot on the verification, whatever the verdict. See Document Entries.

code and message are always present. The rest appear only when they apply, so their absence is meaningful: no rejection_reason means the reviewer left no text on that document.These five are the only keys an entry on a verdict carries. The checklist flags — waivable, condition, optional, one_of — belong to LRS_VERIFICATION_NEEDED, which describes what is owed; a verdict describes what was decided, and never carries them.

string

required

The checklist document code — the same value you uploaded the file under as type, and the same value you submitted it under as a document’s code. On a B2B payment it is the document type, such as invoice.

string

required

The document’s label — what the item is, as the checklist describes it. It is not a comment on this document and it does not change with the verdict.

string

The upload identifier the upload call returned for the file held in this slot — Upload Document for an LRS payment, Upload Document for a B2B services one. It is the same ref you submitted, so it maps straight onto your own record of what you sent.On a B2B services payment it is present only when the document came from an upload you made, and it is never present on a B2B goods payment.

string

Where this one document stands.

Value	Means
`PENDING`	Not reviewed individually.
`VERIFIED`	Accepted.
`REJECTED`	Refused — replace it.

A slot can read PENDING on an approved verification: a verdict is reached on the set, and not every document needs an individual mark for that.

string

The reviewer’s text about this document. Present only when they left some, which in practice means a REJECTED one.This is the sentence to show a payer when you ask for a replacement file — data.message is about the verification, this is about the document.

`documents` is the whole slate

documents lists every active document slot on the verification, not only the ones that failed.

On a rejection, it shows what failed alongside what passed — so a payer is asked to replace one file, not all of them.
On an approval, it is the record of what was accepted and the state each document ended in.

Two things never appear:

Superseded documents. Re-uploading a document gives you a new ref and the newer row supersedes the older; only the current row for each slot is listed.
The files themselves. No document file, URL or download link is ever included in a webhook payload. ref identifies the upload; it is not a link to it.

A slot listed here is a slot on this verification. For the whole checklist, including fields, optional items and what is still outstanding, call Get Verification Requirements (LRS or B2B services), which reports the same three document keys alongside satisfied and provided.

What to do when you receive it

Respond 2xx, then verify the signature

Acknowledge as soon as you have accepted the payload, so the delivery is not retried, and verify the signature against the raw body before acting on it.

Route on verification_status

APPROVED and REJECTED are the only two values. Treat anything else as unknown and log it rather than guessing.

On APPROVED, record it and stop chasing the payer

Nothing further is needed from either of you. PAYMENT_SETTLED is the next event in this payment’s life.

On REJECTED, show what failed

data.message is the verdict on the verification; each entry with doc_status: "REJECTED" carries the reason for that document in rejection_reason. Entries that read VERIFIED need nothing, so do not ask the payer to re-send them.

Confirm where the payment stands

Get Verification Requirements — LRS or B2B services — reports settlement_status, which says whether sending anything further is still possible.

LRS_VERIFICATION_NEEDED

What a payment owes — including after a send-back.

VERIFICATION_NEEDED

What a B2B services payment owes — including after a send-back.

Get Verification Requirements

The whole set, on demand, with settlement_status.

Upload Document

Where a ref comes from, and how to replace a file.

PAYMENT_SETTLED

The next event after an approval.

Order

Payment

Merchant

Settlement

Refund

Subscriptions

Payment Links

Virtual Bank Accounts

LRS

B2B Services

Webhooks

Event Overview

When the webhook is sent

Delivery Details

Headers

Payload Schema

Field Specifications

`documents` is the whole slate

What to do when you receive it

LRS_VERIFICATION_NEEDED

VERIFICATION_NEEDED

Get Verification Requirements

Upload Document

PAYMENT_SETTLED

​Event Overview

​When the webhook is sent

​Delivery Details

​Headers

​Payload Schema

​Field Specifications

​documents is the whole slate

​What to do when you receive it

​Related

LRS_VERIFICATION_NEEDED

VERIFICATION_NEEDED

Get Verification Requirements

Upload Document

PAYMENT_SETTLED

Event Overview

When the webhook is sent

Delivery Details

Headers

Payload Schema

Field Specifications

`documents` is the whole slate

What to do when you receive it

Related