PAYMENT UNDER REVIEW

Event Overview

Event Type: PAYMENT_UNDER_REVIEW Category: Payment Verification Description: The payment’s verification was accepted; it is with us and needs nothing from you This is the event that ends the verification conversation. Everything the payment’s checklist asked for was supplied, the verification gateway took the set and passed it, and the payment moved to Under Review while it works its way to settlement.

It carries the same body as the events that ask for details, with an empty list. Every event in this family answers one question — what does this payment still need from me? Here the answer is nothing, and action_required_fields is [] because that is what nothing looks like.If you already handle VERIFICATION_NEEDED, you can route this event through the same handler and it will do the right thing.

When the webhook is sent

An LRS submit passed. A complete set was filed through Submit Verification Details, the gateway verified the PAN, matched the sender to the account holder, reconciled TCS and confirmed the credit covers the amount. The synchronous response to that same call reads "status": "in_review".
In sandbox, when a simulated payment is moved to Under Review — either by supplying the last outstanding verification field, or by choosing that settlement status on the simulator page.

The webhook is created only if your merchant account (or parent, for sub-merchants) has an active API credential with a non-empty webhook URL.

Delivery Details

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

Headers

Header	Description
`Content-Type`	`application/json`
`User-Agent`	`Eximpe-Webhook/1.0`
`X-Webhook-Event`	`PAYMENT_UNDER_REVIEW`
`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. Prefer V2: the timestamp is inside the signed material, so a captured delivery cannot be replayed with a fresh one.

Payload Schema

{
  "event_type": "PAYMENT_UNDER_REVIEW",
  "event_time": "2026-08-25T09:14:07.418322",
  "version": "3.0.0",
  "sequence_number": "550e8400-e29b-41d4-a716-446655440020",
  "data": {
    "payment_id": "PR6938527534",
    "order_id": "OD3376378679",
    "verification_status": "UNDER_REVIEW",
    "message": "Payment is under review",
    "action_required_fields": [],
    "payment_verification_expiry": null
  }
}

Field Specifications

Root Level Fields
Data Object Fields

string

required

Always "PAYMENT_UNDER_REVIEW" for this webhook event

string

required

ISO 8601 datetime when the webhook event was created, in UTC and without an offset suffix.Example: "2026-08-25T09:14:07.418322"

string

required

Envelope version (e.g. “3.0.0”)

string

required

Unique identifier for this webhook event (UUID), useful for idempotency

object

required

The payment and its state

string

required

UID of the payment

string

required

UID of the order the payment belongs to

string

required

Always "UNDER_REVIEW" on this event — it is the payment’s own settlement state, read at the moment the event was raised.

string

required

Always "Payment is under review". Safe to log or show; not a value to branch on.

array

required

Always empty on this event. Nothing is owed — that is the whole point of it.

string | null

required

A gateway-set verification deadline where one exists. null here: nothing is being asked of you, so no clock is running.

What to do when you receive it

Respond 2xx as soon as you have accepted the payload, so the delivery is not retried.
Verify the signature against the raw request body.
Record the payment as under review and stop chasing the payer. Nothing more is needed from either of you.
Wait for settlement. PAYMENT_SETTLED is the next event in this payment’s life.

Sending is closed from here. A payment in UNDER_REVIEW refuses further verification details — the staged rows are now the record of what was actually filed with the gateway, and a later edit would leave the two disagreeing. VERIFIED, READY_FOR_SETTLEMENT and SETTLED are closed for the same reason.If something genuinely has to change after this point, raise it with us rather than re-submitting.

Under Review is not the same as verified. It means the set was accepted and the payment is with us. A VERIFIED payment sends no event of its own, because there is nothing for you to act on either way — settlement is the signal to wait for.

The family this event belongs to

Four events share one body, so a single handler can read all of them:

Event	`action_required_fields`	Means
`VERIFICATION_NEEDED`	Plain field codes	Something is owed.
`LRS_VERIFICATION_NEEDED`	Entry objects, plus `action_required_documents` and `submit`	Something is owed on an LRS payment.
`PAYMENT_UNDER_REVIEW`	`[]`	Nothing is owed; the payment is with us.

The one difference worth knowing: on LRS_VERIFICATION_NEEDED the list holds objects ({code, message, …}); on the other two it holds strings. Check the element type, or route on event_type.

Submit Verification Details

The call whose success raises this event.

LRS_VERIFICATION_NEEDED

The event that says something is still owed.

PAYMENT_SETTLED

The next event in the payment’s life.

Get Verification Requirements

Read settlement_status to confirm where a payment stands.

Order

Payment

Merchant

Settlement

Refund

Virtual Bank Accounts

LRS

Webhooks

Event Overview

When the webhook is sent

Delivery Details

Headers

Payload Schema

Field Specifications

What to do when you receive it

The family this event belongs to

Submit Verification Details

LRS_VERIFICATION_NEEDED

PAYMENT_SETTLED

Get Verification Requirements

​Event Overview

​When the webhook is sent

​Delivery Details

​Headers

​Payload Schema

​Field Specifications

​What to do when you receive it

​The family this event belongs to

​Related

Submit Verification Details

LRS_VERIFICATION_NEEDED

PAYMENT_SETTLED

Get Verification Requirements

Event Overview

When the webhook is sent

Delivery Details

Headers

Payload Schema

Field Specifications

What to do when you receive it

The family this event belongs to

Related