> ## 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. # Submit Verification Details > Send a payment's verification details — fields and document refs — in one JSON call, keyed by the codes the requirements name. ## Overview Sends verification details for a payment, keyed by the same codes that [Get Verification Requirements](/api-reference/v3/lrs/verification-requirements) and the [`LRS_VERIFICATION_NEEDED`](/api-reference/v3/webhooks/lrs-verification-needed) webhook use. There is nothing to map between them: | Where you read it | What you do with it | | ---------------------------------------------------- | --------------------------------- | | the webhook's `action_required_fields[].field` | the keys you put in `fields` | | the webhook's `action_required_documents[].document` | the `code` you put in `documents` | | the `GET`'s `fields[].code` | the key you put in `fields` | | the `GET`'s `documents[].code` | the `code` you put in `documents` | The response is two keys — the payment, and where it now stands. ## The loop [`LRS_VERIFICATION_NEEDED`](/api-reference/v3/webhooks/lrs-verification-needed) lists what the payment owes — each entry a code, a sentence saying why, and whether it can be waived. Fields as a map, documents as refs from [Upload Document](/api-reference/v3/lrs/upload-document). Partial is fine. `ACTION_REQUIRED` — still waiting on you. `IN_REVIEW` — with us, nothing further to send. From [`GET`](/api-reference/v3/lrs/verification-requirements) on the same path, or from the next event. Both name it in the codes you just sent. ## The body depends on the purpose code There is one endpoint and one envelope — `fields`, `documents`, `finalize` — but **what belongs inside them is decided by the payment's purpose code**, not by you. Sending a key the code does not ask for is a `400`. You never have to work out which set applies: `GET` the same path and it tells you, or read the codes off the [`LRS_VERIFICATION_NEEDED`](/api-reference/v3/webhooks/lrs-verification-needed) event. Complete bodies for every LRS purpose code, generated from the live requirement sets: ```json S0305 - Education, with travel leg theme={null} { "fields": { "buyer_address_line_1": "12 Brigade Road", "buyer_city": "Bengaluru", "buyer_state": "Karnataka", "buyer_postal_code": "560001", "buyer_email": "ravi@example.com", "buyer_phone": "+919876543210", "invoice_number": "INV-2026-0041", "invoice_date": "2026-08-01", "payment_term": "Advance", "remitter_name": "RAVI KUMAR", "remitter_pan": "ABCPK1234F", "remitter_dob": "1985-04-12", "remitter_relation": "PARENT", "buyer_declaration": true, "amount_to_be_settled": "150000.00", "student_name": "Ananya Kumar", "student_dob": "2005-09-30", "student_passport_number": "Z1234567" }, "documents": [ { "code": "student_passport", "ref": "" }, { "code": "student_visa", "ref": "" }, { "code": "loa", "ref": "" }, { "code": "relationship_declaration", "ref": "" } ], "finalize": true } ``` ```json S1107 - Education, fees only theme={null} { "fields": { "buyer_address_line_1": "12 Brigade Road", "buyer_city": "Bengaluru", "buyer_state": "Karnataka", "buyer_postal_code": "560001", "buyer_email": "ravi@example.com", "buyer_phone": "+919876543210", "invoice_number": "INV-2026-0041", "invoice_date": "2026-08-01", "payment_term": "Advance", "remitter_name": "RAVI KUMAR", "remitter_pan": "ABCPK1234F", "remitter_dob": "1985-04-12", "remitter_relation": "PARENT", "buyer_declaration": true, "amount_to_be_settled": "150000.00", "student_name": "Ananya Kumar", "student_dob": "2005-09-30" }, "documents": [ { "code": "university_id_card", "ref": "" }, { "code": "loa", "ref": "" }, { "code": "relationship_declaration", "ref": "" } ], "finalize": true } ``` ```json S0306 - Travel, other theme={null} { "fields": { "buyer_address_line_1": "12 Brigade Road", "buyer_city": "Bengaluru", "buyer_state": "Karnataka", "buyer_postal_code": "560001", "buyer_email": "ravi@example.com", "buyer_phone": "+919876543210", "invoice_number": "INV-2026-0041", "invoice_date": "2026-08-01", "payment_term": "Advance", "remitter_name": "RAVI KUMAR", "remitter_pan": "ABCPK1234F", "remitter_dob": "1985-04-12", "remitter_relation": "PARENT", "buyer_declaration": true, "amount_to_be_settled": "150000.00" }, "documents": [ { "code": "passenger_list", "ref": "" }, { "code": "traveller_passports", "ref": "" }, { "code": "traveller_visas", "ref": "" }, { "code": "invoice", "ref": "" }, { "code": "ticket", "ref": "" }, { "code": "relationship_declaration", "ref": "" } ], "finalize": true } ``` ```json S0304 - Travel, medical theme={null} { "fields": { "buyer_address_line_1": "12 Brigade Road", "buyer_city": "Bengaluru", "buyer_state": "Karnataka", "buyer_postal_code": "560001", "buyer_email": "ravi@example.com", "buyer_phone": "+919876543210", "invoice_number": "INV-2026-0041", "invoice_date": "2026-08-01", "payment_term": "Advance", "remitter_name": "RAVI KUMAR", "remitter_pan": "ABCPK1234F", "remitter_dob": "1985-04-12", "remitter_relation": "PARENT", "buyer_declaration": true, "amount_to_be_settled": "150000.00" }, "documents": [ { "code": "passenger_list", "ref": "" }, { "code": "traveller_passports", "ref": "" }, { "code": "traveller_visas", "ref": "" }, { "code": "invoice", "ref": "" }, { "code": "ticket", "ref": "" }, { "code": "relationship_declaration", "ref": "" } ], "finalize": true } ``` ```json S0303 - Travel, pilgrimage theme={null} { "fields": { "buyer_address_line_1": "12 Brigade Road", "buyer_city": "Bengaluru", "buyer_state": "Karnataka", "buyer_postal_code": "560001", "buyer_email": "ravi@example.com", "buyer_phone": "+919876543210", "invoice_number": "INV-2026-0041", "invoice_date": "2026-08-01", "payment_term": "Advance", "remitter_name": "RAVI KUMAR", "remitter_pan": "ABCPK1234F", "remitter_dob": "1985-04-12", "remitter_relation": "PARENT", "buyer_declaration": true, "amount_to_be_settled": "150000.00" }, "documents": [ { "code": "passenger_list", "ref": "" }, { "code": "traveller_passports", "ref": "" }, { "code": "traveller_visas", "ref": "" }, { "code": "invoice", "ref": "" }, { "code": "ticket", "ref": "" }, { "code": "relationship_declaration", "ref": "" } ], "finalize": true } ``` The three travel codes take an identical body. They differ in what the remittance is *for* — other travel, medical treatment, pilgrimage — not in what you must collect. `S0305` shows `student_visa`; `university_id_card` would do just as well. They are alternatives, and the requirement set says so — the webhook merges them into one entry, and sending either clears both. **Do not send both.** Every example declares `remitter_relation` as `PARENT`, which is what makes `relationship_declaration` required. Declare `SELF` and it drops out. ### What differs, and what does not | | `S0305` | `S1107` | `S0306` · `S0304` · `S0303` | | ----------------------------------- | :------------------: | :------------------: | :-------------------------: | | Buyer, invoice, declaration, amount | same | same | same | | Remitter identity (4 fields) | same | same | same | | `student_name`, `student_dob` | ✓ | ✓ | — | | `student_passport_number` | ✓ | — | — | | Documents | 4 + optional invoice | 2 + optional invoice | 5 | `relationship_declaration` is asked for on every code, but only once `remitter_relation` is something other than `SELF`. **Do not branch on the purpose code in your own integration.** Read the requirement set instead. The codes above are what the matrix asks for today; it is configuration, and a revision reaches you through the API without a release on your side — but only if you are reading it rather than reproducing it. ## Partial sends are merged Send three fields today and two tomorrow and you have sent five. Nothing you sent earlier is wiped by a later call, and a document sent twice supersedes the first without discarding it. This is deliberate: nobody collects a passport scan, a visa and a letter of admission in the same instant. [`GET`](/api-reference/v3/lrs/verification-requirements) the same path whenever you want to know where that has left the payment. ## Values Field values are strings, numbers or booleans. **`buyer_declaration` is a single affirmation covering every claim.** Its `label` is the exact text the payer must be shown; send `true` once they have affirmed it. TCS is not collected — EximPe computes it, so there is no figure to declare. **An unknown key is a `400`, not a silent drop.** A misspelled `remitter_pan` that we quietly ignored would leave the payment waiting forever for a field you believe you sent. Every key is checked before any is written, so one typo cannot half-apply a call. Omit a key rather than sending `null` or an empty string. A boolean requirement — the LRS declarations — is only satisfied by `true`; `false` reads as not yet answered. ## The response Two keys, whatever you sent: ```json theme={null} { "success": true, "message": "Verification details received", "data": { "payment_id": "PR6938527534", "status": "ACTION_REQUIRED" } } ``` | `status` | What it means | What to do | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | `IN_REVIEW` | The set was complete, the verification gateway took it, and it passed. The payment is with us. | Nothing. | | `ACTION_REQUIRED` | Something is still owed — the set is short, you held it back with `finalize: false`, or the gateway did not pass the payment. | Find out what, then send it. | **`ACTION_REQUIRED` never means your details were discarded.** Everything that reached us is held against the payment, whether the call ended in a refusal, a vendor outage or a half-finished set. You re-send the one thing that failed, not the whole set. ### Finding out what is still owed This response does not say. Two places already do, and a third copy is one more thing that can drift out of step with them: The whole requirement set, each entry carrying `satisfied`. Authoritative, idempotent, and safe to poll. Fires on a refusal too, naming the same codes with a sentence per item — plus `outstanding` and `reason`, which no requirement list can carry. A refusal is where the two differ, and it is worth knowing which to read. Everything the requirement list named can be supplied and the payment still not proceed, because supplying a PAN is not the same as it verifying — and the requirement list has nothing to say about that. The event does: it is where a shortfall's rupee figure (`outstanding`), a headline conclusion (`reason`: `PAN_NOT_VERIFIED`, `SENDER_NAME_MISMATCH`, `PURPOSE_CODE_NOT_ALLOWED`, `PURPOSE_CODE_NOT_IN_REGISTRY`) and the per-item sentences you can show a payer all live. ## Completion `finalize` defaults to `true` and applies only to a **complete** set. It never forces an incomplete one through. Pass `finalize: false` to stage details without triggering verification — useful when you know more is coming, and the response is `ACTION_REQUIRED` because, deliberately, it still is. When a complete set is submitted it runs through the verification gateway — PAN verification, the sender-to-account-holder match, the TCS recomputation and the exactly-once LRS counter posting. `IN_REVIEW` means all of that passed. **Travel purpose codes cannot complete yet.** A complete set on `S0306`, `S0304` or `S0303` comes back `ACTION_REQUIRED` with `reason: "PURPOSE_CODE_NOT_IN_REGISTRY"` on the event, however much you send. Collecting and submitting works — the details are held against the payment — but the payment will not advance until the travel rules are in place. Education (`S0305`, `S1107`) is unaffected. ### When the handoff itself does not happen A complete set can fail to reach a verdict at all: | What happened | `status` | Event | | ------------------------------------------------------------------------------------------------------------------------ | ----------------- | ----- | | A dependency was briefly unreachable. **Your details are saved**; repeat the request to complete it, re-sending nothing. | `ACTION_REQUIRED` | none | | Verification declined the payment — for example it is already past submit. | `ACTION_REQUIRED` | none | | This purpose code has no automated verification: details are recorded and the payment proceeds through review. | `IN_REVIEW` | none | **`ACTION_REQUIRED` with a complete requirement set and no event means the handoff did not land.** Repeat the same request — the set is still complete, so it is retried rather than re-sent, and an outage costs you one call. A refusal the gateway actually reached always arrives as an event, so silence is what tells the two apart. Details are stored before verification is attempted and are never discarded by it. ## Where each value goes Most fields flow into the verification and settlement record. Three are collected but held rather than forwarded, and it is worth knowing which: | Field | Where it goes | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `buyer_name` | Held. The credit's own sender name on the order is authoritative — the LRS own-account check compares the verified PAN holder against *that*, so a submitted value must not overwrite it. | | `purpose_code` | Held. Read from the order, which is what the settlement file uses. | | `payment_term` | Held. Nothing in the settlement record holds it yet; your answer is kept against the payment until something does. | Everything else reaches the verification gateway. TCS is not collected at all — EximPe computes it. ## Related What this payment needs, and what it already has. The event that tells you a payment owes details. Pre-upload a file and reference it by `ref`. TCS and the all-in total, before the buyer transfers. ## OpenAPI ````yaml POST /pg/lrs/payments/{payment_id}/verification/ openapi: 3.0.0 info: title: Eximpe Payment Gateway API description: >- API for payment processing and order management through Eximpe payment gateway. This specification is for v3 API version. license: name: Proprietary version: 3.0.0 servers: - url: https://api-pacb-uat.eximpe.com description: Payment Gateway Sandbox URL security: - clientAuth: [] clientSecretAuth: [] apiVersionHeader: [] tags: - name: Card Tokens - name: Merchants - name: Orders - name: Payment Links - name: Payments - name: Refunds - name: Settlements - name: Subscriptions - name: Virtual Bank Accounts description: Create and manage ICICI virtual accounts and read collected payments. paths: /pg/lrs/payments/{payment_id}/verification/: post: tags: - LRS summary: Submit verification details description: >- Sends verification details for a payment, keyed by the same codes the requirements and the [`LRS_VERIFICATION_NEEDED`](/api-reference/v3/webhooks/lrs-verification-needed) webhook use. There is nothing to map: the event's `action_required_fields[].field` are the keys you put in `fields`, and its `action_required_documents[].document` are the `code` you put in `documents`. **JSON only.** `fields` is an object; `documents` is a list of `{code, ref}` naming files uploaded earlier through [Upload Document](/api-reference/v3/lrs/upload-document). Files are never posted to this endpoint — a `multipart/form-data` request is a `415`. **Partial sends are merged, never replaced.** Send what you have; nothing you sent earlier is wiped by a later call. **Completion is automatic.** Once nothing is outstanding the set is run through the verification gateway — PAN verification, the sender-to-account-holder match, the TCS recomputation and the LRS counter posting. Pass `finalize: false` to stage without triggering it. **The response is two keys**: `payment_id` and `status`. For what is still owed, [`GET`](/api-reference/v3/lrs/verification-requirements) this same path or read the event — both name it in the codes you just sent. **PSP callers must send `X-Merchant-ID`.** parameters: - name: payment_id in: path required: true schema: type: string description: UID of the payment the details are for. example: PR6938527534 requestBody: required: true content: application/json: schema: type: object properties: fields: type: object description: >- Answers keyed by requirement code, e.g. `{"remitter_pan": "ABCDE1234F", "payment_term": "Advance"}`. Values are strings, numbers or booleans. An unknown key is a 400 rather than a silent drop — a typo you never hear about would leave the payment waiting forever for a field you believe you sent. Omit a key rather than sending null or an empty string. additionalProperties: true example: buyer_city: Bengaluru remitter_pan: ABCDE1234F remitter_relation: SELF buyer_declaration: true amount_to_be_settled: '150000.00' documents: type: array description: Documents by reference, or waivers. items: type: object required: - code properties: code: type: string description: The requirement code this document answers. enum: - fee_invoice - offer_letter - passport - relationship_declaration - student_id_or_visa - student_id - student_passport - student_visa - university_id_card - loa - invoice - passenger_list - traveller_passports - traveller_visas - ticket example: student_passport ref: type: string description: >- A `ref` returned by Upload Document. Send this or `waiver_reason`, not neither. example: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d waiver_reason: type: string description: >- Why this document is not being supplied. Only accepted on items whose `waivable` is true. example: Destination is visa-free for this passport finalize: type: boolean default: true description: >- Whether to run a complete set through the verification gateway. Never forces an incomplete one through. example: fields: buyer_city: Bengaluru remitter_pan: ABCDE1234F remitter_relation: SELF buyer_declaration: true amount_to_be_settled: '150000.00' documents: - code: student_passport ref: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d - code: traveller_visas waiver_reason: Destination is visa-free finalize: true responses: '200': description: >- Details received. The body says where the payment now stands, and nothing else. content: application/json: schema: type: object properties: success: type: boolean example: true message: type: string example: Verification details received data: type: object properties: payment_id: type: string description: The payment these details were recorded against. example: PR6938527534 status: type: string enum: - IN_REVIEW - ACTION_REQUIRED description: >- Where the payment stands after this call. `IN_REVIEW` — the set was complete, the verification gateway took it, and nothing more is owed from you. `ACTION_REQUIRED` — something still is: the set is short, you passed `finalize: false`, or the gateway did not pass the payment. It never means your details were discarded. example: ACTION_REQUIRED examples: action_required: summary: ACTION_REQUIRED — something is still owed description: >- A partial send, a `finalize: false` hold, and a complete set the gateway refused all answer the same way: the payment is still waiting on you. `GET /pg/lrs/payments/{payment_id}/verification/` for the codes still outstanding; a gateway refusal also arrives as an `LRS_VERIFICATION_NEEDED` event carrying a sentence per item, plus `outstanding` and `reason`. value: success: true message: Verification details received data: payment_id: PR6938527534 status: ACTION_REQUIRED in_review: summary: IN_REVIEW — the payment is with us description: >- Everything the purpose code asks for was sent, the set went through the verification gateway, and it passed. Nothing further to send. value: success: true message: Verification details received data: payment_id: PR6938527534 status: IN_REVIEW '400': description: >- Invalid request — an unknown code, a value that is not a scalar, an unusable document reference, or a waiver on a document that cannot be waived. The offending code is named in `error.details`. content: application/json: schema: $ref: '#/components/schemas/v3_ErrorResponse' example: success: false error: code: ERR_LRS_001 message: Unknown or misplaced field(s). details: buyer_citty: Not a requirement of this payment's purpose code. '404': description: No such payment for this merchant. content: application/json: schema: $ref: '#/components/schemas/v3_ErrorResponse' '500': description: Unexpected processing failure. content: application/json: schema: $ref: '#/components/schemas/v3_ErrorResponse' security: - clientAuth: [] clientSecretAuth: [] merchantAuth: [] apiVersionHeader: [] components: schemas: v3_ErrorResponse: type: object required: - success - error properties: success: type: boolean description: Indicates if the request was successful error: $ref: '#/components/schemas/v3_ErrorDetails' v3_ErrorDetails: type: object required: - code - message properties: code: type: string description: Error code (e.g., ERR_ORDER_002) message: type: string description: Error message details: type: object description: Detailed validation error information with field-specific errors additionalProperties: type: string description: Error message for the specific field securitySchemes: clientAuth: type: apiKey name: X-Client-ID in: header description: >- **Client Application ID** - Your unique application identifier used to authenticate API requests. You can find your Client ID in the Developer Settings section of the merchant dashboard. x-displayName: Client ID x-example: your-client-id clientSecretAuth: type: apiKey name: X-Client-Secret in: header description: >- **Client Secret Key** - Your secret key used alongside the Client ID for secure authentication. Keep this confidential and never expose it in client-side code. Available in the Developer Settings section of the merchant dashboard. x-displayName: Client Secret x-example: your-client-secret apiVersionHeader: type: apiKey name: X-API-Version in: header description: >- **API Version** - Specifies which version of the API to use (e.g., '1.X.X', '2.X.X', or '3.X.X'). This header allows you to control which API version your integration uses. Default version information is available in the Developer Settings. x-displayName: API Version x-example: 3.0.0 merchantAuth: type: apiKey name: X-Merchant-ID in: header description: >- **Merchant Identifier** - The unique ID for the merchant account. This is required for PSP (Payment Service Provider) merchants who manage multiple merchant accounts. You can find merchant IDs in the Merchant Management section of the dashboard. x-displayName: Merchant ID x-example: your-merchant-id ````