> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eximpe.com/llms.txt
> Use this file to discover all available pages before exploring further.
# LRS VERIFICATION NEEDED
> Technical reference for the LRS_VERIFICATION_NEEDED webhook event, including payload schema, field specifications, and implementation details.
***
## Event Overview
**Event Type**: `LRS_VERIFICATION_NEEDED`\
**Category**: Payment Verification\
**Description**: An LRS payment needs verification details before it can settle
This webhook fires when a payment settling under an LRS purpose code is missing details required for its purpose code. Unlike the generic verification events, it names **exactly** which fields and documents are outstanding.
**This event replaces the others for LRS payments.** A payment that receives `LRS_VERIFICATION_NEEDED` will not also receive [`PAYMENT_DETAILS_MISSING`](/api-reference/v3/webhooks/payment-details-missing) or [`VERIFICATION_NEEDED`](/api-reference/v3/webhooks/verification-needed). Two events carrying different lists for the same outstanding work would leave you chasing both.
Fires for all five LRS purpose codes — `S0305` and `S1107` (education), and
`S0306`, `S0304` and `S0303` (travel). The codes it names differ per purpose
code; see [Get Verification Requirements](/api-reference/v3/lrs/verification-requirements)
for what each one asks for.
### When the webhook is sent
1. **On a successful payment**, once the payment is recognised as LRS — its purpose code determines this.
2. **After you supply verification details**, if the purpose code was not known earlier. A purpose code is often chosen at submission time, so a payment can only be recognised as LRS then; until it is, the generic events apply.
3. **When a complete set does not pass verification.** Supplying everything the list named is not the end of it: the PAN still has to verify, the sender still has to match the account holder, and the credit still has to cover the amount. A payment that fails one of those comes back in this same event, with two extra keys — see [After a submit that did not pass](#after-a-submit-that-did-not-pass).
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
* The payment is actually missing something — a payment with everything already supplied gets no event
***
## 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) |
| **Pacing** | Delivered on a rate-paced queue, so a burst of payments arrives smoothly rather than all at once |
### Headers
| Header | Description |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `Content-Type` | `application/json` |
| `User-Agent` | `Eximpe-Webhook/1.0` |
| `X-Webhook-Event` | `LRS_VERIFICATION_NEEDED` |
| `X-Webhook-Timestamp` | Unix timestamp (string) at the time of the request |
| `X-Webhook-Signature` | HMAC-SHA256 signature of the request body (JSON string with keys sorted, no extra whitespace), using your API key as the secret. Hex-encoded. |
**Signature verification (recommended):**\
Compute `HMAC-SHA256(encryption_key, raw_body)` where `raw_body` is the exact UTF-8 request body as received. Compare the hex result with the `X-Webhook-Signature` header to ensure the webhook is from the platform and unchanged.
***
## Payload Schema
The payment, every item it still owes and why, and where to send them.
These are complete, unedited payloads — one per LRS purpose code. Nothing is
trimmed, so what you see is what arrives.
```json Education, with travel leg (S0305) theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T10:30:00.123456Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440000",
"data": {
"payment_id": "PR6938527534",
"order_id": "OD3376378679",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_pan",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_relation",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_passport_number",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "student_passport",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "student_visa/university_id_card",
"message": "Send either student_visa or university_id_card — one satisfies both.",
"waivable": false
},
{
"document": "loa",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "invoice",
"message": "Optional for this purpose code.",
"waivable": false
}
]
}
}
```
```json Education, fees only (S1107) theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T10:31:12.884210Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440001",
"data": {
"payment_id": "PR8125440971",
"order_id": "OD5590284413",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_pan",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_relation",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_dob",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "university_id_card",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "loa",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "invoice",
"message": "Optional for this purpose code.",
"waivable": false
}
]
}
}
```
```json Travel - other (S0306) theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T10:32:41.005917Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440002",
"data": {
"payment_id": "PR7042318866",
"order_id": "OD8451220934",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_pan",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_relation",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "passenger_list",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_passports",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_visas",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
},
{
"document": "invoice",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "ticket",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
}
]
}
}
```
```json Travel - medical (S0304) theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T10:33:08.447362Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440003",
"data": {
"payment_id": "PR2288140537",
"order_id": "OD1904663270",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_pan",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_relation",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "passenger_list",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_passports",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_visas",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
},
{
"document": "invoice",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "ticket",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
}
]
}
}
```
```json Travel - pilgrimage (S0303) theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T10:34:55.219043Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440004",
"data": {
"payment_id": "PR9317025648",
"order_id": "OD4726180395",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_pan",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "remitter_relation",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "passenger_list",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_passports",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "traveller_visas",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
},
{
"document": "invoice",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "ticket",
"message": "Required for this purpose code. May be waived with a recorded reason.",
"waivable": true
}
]
}
}
```
```json S0305, relation not self theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-14T11:02:19.730558Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440005",
"data": {
"payment_id": "PR6938527534",
"order_id": "OD3376378679",
"message": "LRS payment: verification details are required before settlement.",
"action_required_fields": [
{
"field": "buyer_address_line_1",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_city",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_state",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_postal_code",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_email",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_phone",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_number",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "invoice_date",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "payment_term",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "buyer_declaration",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "amount_to_be_settled",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_name",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_dob",
"message": "Required for this purpose code.",
"waivable": false
},
{
"field": "student_passport_number",
"message": "Required for this purpose code.",
"waivable": false
}
],
"action_required_documents": [
{
"document": "student_passport",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "student_visa/university_id_card",
"message": "Send either student_visa or university_id_card — one satisfies both.",
"waivable": false
},
{
"document": "loa",
"message": "Required for this purpose code.",
"waivable": false
},
{
"document": "invoice",
"message": "Optional for this purpose code.",
"waivable": false
},
{
"document": "relationship_declaration",
"message": "Required because the remitter is not the person the remittance is for.",
"waivable": false
}
]
}
}
```
The three travel codes — `S0306`, `S0304`, `S0303` — carry identical
requirement sets. They differ in what the remittance is *for*, not in what
you must collect.
The last tab is the same payment as the first, after the payer declared a
`remitter_relation` other than `SELF`. Two things changed: the relationship
self-declaration appeared as `CONDITIONALLY_REQUIRED`, and the remitter
identity fields dropped off the list, because declaring them satisfied them.
***
## Field Specifications
Always `"LRS_VERIFICATION_NEEDED"` for this webhook event
ISO 8601 datetime when the webhook event was created
**Example**: `"2026-08-14T10:30:00.123456Z"`
Envelope version (e.g. "3.0.0")
Unique identifier for this webhook event (UUID), useful for idempotency
**Example**: `"550e8400-e29b-41d4-a716-446655440000"`
The payment, what it owes, and where to send it
UID of the payment. Use it in the verification endpoint's path.
UID of the order the payment belongs to
Human-readable summary. Safe to log; not a value to branch on.
The **fields** still owed, plus any optional ones you have not sent. See
**Entries** below.
The **documents** still owed, plus unsent optionals. Same shape, keyed on
`document` instead of `field`.
**Only on a submit that did not pass, and only when money is short.** The
amount still owed on this payment in rupees, as a decimal string —
principal plus fees, GST and TCS, less what was received.
Absent otherwise. A requirement-matrix event never carries it: nothing has
been priced at that point.
**Example**: `"12500.00"`
**Only on a submit that did not pass**, and only where one headline
conclusion explains it. See [the reason table](#after-a-submit-that-did-not-pass).
**Example**: `"PAN_NOT_VERIFIED"`
In `action_required_fields`: the code, and the key you put in `fields` when you
[submit](/api-reference/v3/lrs/submit-verification-details).
In `action_required_documents`: the code, and the document `code` when you submit —
either as a multipart part named `document.`, or as an entry in `documents`.
**A code containing `/` is two alternatives merged** — see below.
Why the item is wanted, in a sentence — safe to render to a payer, and the
entry's whole explanation.
| It says | Meaning |
| ------------------------------------------ | --------------------------------------------------------- |
| "Required for this purpose code." | Owed outright |
| "Required because …" | Owed because a condition now holds; the sentence names it |
| "Optional for this purpose code." | Accepted but not owed; listed until you send it |
| "Send either X or Y — one satisfies both." | A merged alternative |
| "… May be waived with a recorded reason." | Appended when `waivable` is `true` |
When `true` you may record a `waiver_reason` instead of supplying the document —
a visa the destination does not require, a ticket not yet issued.
The item is still listed until you do; `waivable` describes how it may be
discharged, not whether it is required. The `message` says so too.
***
**Entries carry no label.** A code, a sentence, and a waiver flag is all an
entry has. For the human-readable name of a code — and for the exact wording a
payer must be shown to affirm `buyer_declaration` — call
[Get Verification Requirements](/api-reference/v3/lrs/verification-requirements),
which returns the whole requirement set rather than just what is outstanding.
## After a submit that did not pass
Sending everything the list named is not the same as passing. Once a set is
complete it goes to the verification gateway, which verifies the remitter's PAN
against the name and date of birth, matches the credit's sender to the account
holder, recomputes TCS and checks that the money received covers what is being
settled. Any of those can refuse.
A refusal arrives as **this same event** — same type, same envelope, the same two
`action_required_*` lists — because an LRS payment should learn what it owes in
one vocabulary whether the answer came from the requirement matrix or from the
checks that run after it. The `message` differs, and there are two extra keys:
```json theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-16T10:30:00.123456Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440000",
"data": {
"payment_id": "PR4497584646",
"order_id": "OD4646580935",
"message": "LRS payment: verification did not pass. The payment stays in Action Required until what is listed below is resolved.",
"action_required_fields": [
{
"field": "amount_to_be_settled",
"message": "The credit received does not cover the amount to settle plus fees and TCS. Either the buyer tops up the shortfall, or a smaller amount is declared.",
"waivable": false
}
],
"action_required_documents": [],
"outstanding": "12500.00"
}
}
```
A refusal with a single headline conclusion carries `reason` instead:
```json theme={null}
{
"event_type": "LRS_VERIFICATION_NEEDED",
"event_time": "2026-08-16T10:30:00.123456Z",
"version": "3.0.0",
"sequence_number": "550e8400-e29b-41d4-a716-446655440001",
"data": {
"payment_id": "PR4497584646",
"order_id": "OD4646580935",
"message": "LRS payment: verification did not pass. The payment stays in Action Required until what is listed below is resolved.",
"action_required_fields": [
{
"field": "remitter_pan",
"message": "The remitter's PAN could not be verified against the name and date of birth given. Check all three and re-send.",
"waivable": false
}
],
"action_required_documents": [],
"reason": "PAN_NOT_VERIFIED"
}
}
```
**The payment stays in Action Required and stays submittable.** Nothing is lost:
everything you sent is still held against the payment. Fix what is named and
re-send only that — a partial send is merged with what is already there.
### `outstanding`
Present only when the credit does not cover the payment. `action_required_fields`
tells you *that* it is short, under `amount_to_be_settled`; this is *by how much*,
in rupees.
You have two ways to clear it, and they are genuinely different: have the buyer
transfer the shortfall (then link that credit as a top-up when you re-submit), or
declare a smaller `amount_to_be_settled`. The same figure comes back on the
[submit response](/api-reference/v3/lrs/submit-verification-details#completion),
so you do not have to wait for this event to act on it.
### `reason`
A single machine-readable conclusion, present where one exists. It is a headline,
not the whole story — read `action_required_fields` either way.
| `reason` | What happened |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PAN_NOT_VERIFIED` | The remitter's PAN did not verify against the name and date of birth given. All three have to agree. |
| `SENDER_NAME_MISMATCH` | The name on the credit is not the account holder the payment would settle for. A third-party credit cannot settle on someone else's PAN — re-declare the actual account holder as the remitter. |
| `PURPOSE_CODE_NOT_ALLOWED` | The purpose code is not one this merchant account is enabled for. |
| `PURPOSE_CODE_NOT_IN_REGISTRY` | The purpose code is not one we recognise for LRS. |
**A shortfall carries no `reason`.** Nor does any other refusal that came out of
the full check rather than from one of the conclusions above — those carry
`outstanding` and the two lists and nothing else. `reason` appears only when a
single named conclusion is the whole story, so treat its absence as normal and
act on `action_required_fields` either way.
### The codes a refusal names
A refusal reports itself in the same codes the requirement matrix uses, so a fix
goes back through the same endpoint and the same key you collected it under:
| Code | What to do |
| ---------------------- | ----------------------------------------------------------------------------------------- |
| `remitter_pan` | Check the PAN, the remitter's name and the date of birth together, and re-send all three. |
| `buyer_declaration` | The declaration was not affirmed. Re-send it once the payer has consented. |
| `amount_to_be_settled` | Either the buyer tops up the shortfall or you declare a smaller amount. |
| `purpose_code` | Declared on the order, not here — the code is not one this account may use. |
| `documents.` | Named as an entry in `action_required_documents`; send the file. |
Two entries are conclusions rather than codes, and there is nothing to re-send
under that name:
| Entry | What it means |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `primary_person` | The remitter is not the person the remittance is for, so that person has to be named — send `student_name`, `student_dob` and `student_passport_number`. |
| `tcs` | The TCS figure does not reconcile with our own calculation. You do not declare TCS; if this appears, raise it with us rather than re-sending. |
## Alternatives arrive merged
Where two documents satisfy each other, you get **one** entry, not two:
```json theme={null}
{
"document": "student_visa/university_id_card",
"message": "Send either student_visa or university_id_card — one satisfies both.",
"waivable": false
}
```
**The joined code is a label, not something to send back.** Submit one of the
halves — `student_visa` *or* `university_id_card` — which is why the `message`
spells them out. Posting `student_visa/university_id_card` is a `400`.
Sending either one makes the whole entry disappear from the next event. Two rows
for one obligation reads as two obligations, and chasing a payer for both is the
most common way to make this flow feel worse than it is.
## Optionals are listed until you send them
An optional item — the fee invoice on `S0305` — appears with the message
"Optional for this purpose code." and stops appearing once you supply it.
It is listed because an optional document nobody is told about is one nobody
sends. It never blocks completion: a payment with only optionals outstanding is
complete.
## Conditionals can appear later
An item like the relationship self-declaration only shows up once its condition
holds. Declaring `remitter_relation` as anything other than `SELF` brings it in,
so it can arrive in an event **after** you thought you had the full list. Its
`message` names the condition, so the arrival is explicable rather than arbitrary.
The reverse also happens: answering the remitter identity fields removes them
from the next event. The list is what is *outstanding*, not what the purpose code
asks for in total — for that, call
[Get Verification Requirements](/api-reference/v3/lrs/verification-requirements).
***
## Responding to the event
Show the payer each `message` for why the item is needed. A code containing `/` is one obligation — ask for either half.
`POST /pg/lrs/payments/{payment_id}/verification/` — [Submit Verification Details](/api-reference/v3/lrs/submit-verification-details) takes fields and files in one call. Partial sends are merged, so you can send as things arrive.
The response carries `fields` / `documents` after the write, each entry flagged `satisfied`. When nothing is left unsatisfied the payment is verified automatically.
Answering one requirement can reveal another. Declaring `remitter_relation` as anything other than `SELF` adds the relationship self-declaration, because that document is only owed in that case. Always read the response rather than assuming the original list was final.
## Do not hardcode the codes
The requirement set is configuration and is revised as the underlying regulatory matrix is — new purpose codes become supported, a document turns waivable, a field stops being needed.
Drive your form from [Get Verification Requirements](/api-reference/v3/lrs/verification-requirements), and a revision reaches your integration without a release on your side. Hardcode the codes and it will not.
## Related
Send the answer back, fields and files in one call.
The same list, on demand — for resuming or reconciling.