Get verification requirements
LRS
Get Verification Requirements
Read everything a payment’s purpose code calls for — every field and document, and which are still missing.
GET
Get verification requirements
Overview
Returns the verification requirements for one payment: every field and document its purpose code calls for, which are already satisfied, and which are still outstanding. TheLRS_VERIFICATION_NEEDED webhook tells you what a payment is missing — a code, a sentence, and whether it can be waived. This tells you the whole requirement set, and it is the only place that carries a code’s human-readable label, including the exact wording a payer must be shown to affirm buyer_declaration.
Call it when the event arrives, and render your collection form from the response.
Do not hardcode the field list. Requirements are configuration, not code, and are revised as the underlying regulatory matrix is. Reading them from here means a revision reaches your integration without a release on your side.
When to use it
1
You need the whole set
The event lists what is outstanding. Call this when you also need what is already satisfied — reconciling your own record against ours, or rendering a progress view.
2
You missed an event
Webhooks get lost, retried, or arrive mid-deploy. This endpoint is authoritative and idempotent — call it any time.
3
You are resuming
A payer supplied three documents last week and two today. Call this to see where the payment stands before asking for anything.
4
You are building the form
fields and documents describe the whole set, satisfied or not, with labels safe to show a payer. Filter on satisfied for what is still owed.Response
Complete, unedited responses: an education payment (S0305) with nothing supplied yet, the same payment after a complete set was submitted and refused, and a payment no requirement set applies to.
required_* is the whole set; missing_* is the subset still outstanding. Here 21 fields are required and 18 are missing — buyer_name, invoice_amount and purpose_code came in with the payment itself.
The second example is the one worth reading twice: status: "complete" means nothing is outstanding of what the purpose code asks for — not that the payment passed. Whether it then cleared PAN verification, the sender match and the money check is reported by the submit response and by LRS_VERIFICATION_NEEDED. This endpoint does not repeat it.
documents lists six for S0305, of which four are satisfied: false. The optional invoice is not owed because it is optional, and the relationship self-declaration is not owed because its condition cannot be evaluated until you declare remitter_relation. Both are still listed, with provided: false — that is how you know they exist.Reading the response
There is one list per kind, holding the whole set. There is no separate “missing” array — what is still owed is a filter:fields and documents is a requirement item:
boolean
required
Whether this item is met.
false is what “missing” used to mean: it blocks status from reaching complete.An OPTIONAL item is satisfied from the very first response, and a CONDITIONAL item whose condition does not hold is satisfied vacuously. Neither blocks completion.boolean
required
Whether you have actually sent it, or we already held it. Read alongside
satisfied:That last row is why
satisfied alone is not enough. To offer optionals to a payer as well as chase what is owed, widen the filter:string
required
The identifier you send the answer back under — as a key in
fields, or as a document’s code. See Submit Verification Details.string
required
A human-readable description, safe to render to a payer.
string
required
REQUIRED, CONDITIONAL or OPTIONAL.A CONDITIONAL item is owed only in the case named by condition. It is not listed as missing while that case cannot yet be determined — for example, the relationship declaration only becomes owed once you tell us the remitter is not the person the remittance is for.An OPTIONAL item never blocks completion, but the webhook keeps offering it until you send it — an optional invoice nobody is told about is one nobody sends.boolean
required
When
true, you may send a waiver_reason instead of a file — a visa that the destination does not require, a ticket not yet issued.A waivable document stays satisfied: false until you either upload it or record a waiver. The waiver is yours to declare, not ours to assume.string
Present on
CONDITIONAL items. relation_not_self means the item is owed when the remitter is not the person the remittance is for.string
Items sharing a group satisfy each other. Send any one and the whole group clears; send none and all of them stay listed so you can choose.For education with a travel leg, the student visa and the university ID card are alternatives — either proves student status.
Statuses
Nothing is re-run when you call this. A
GET never verifies a PAN, posts to an LRS counter or moves a payment; it reports the requirement set and what has been collected against it.A payment reads
not_applicable most often because no purpose code has been declared on it yet. The ordinary PAYMENT_DETAILS_MISSING and VERIFICATION_NEEDED events name exactly which fact is missing — purpose_code or business_model — in their own missing-field list. Supply it and call this again.What each purpose code asks for
The exact set is always what this endpoint returns — this is a summary, and a revision lands here before it lands in any table.Fields
Every LRS code asks for the common core (buyer name, address, contact, invoice number and date, invoice amount, purpose code, payment term), the remitter’s verified identity (remitter_name, remitter_pan, remitter_dob, remitter_relation),
buyer_declaration, and amount_to_be_settled. On top of that:
buyer_declaration is a single affirmation whose label is the full text the payer
must be shown — resident in India, within the applicable LRS limit for the financial
year, and not for a purpose prohibited under Rule 3 read with Schedule I of the FEM
(Current Account Transactions) Rules, 2000. Send true once they have affirmed it.
amount_to_be_settled is the amount to settle for this payment, in INR. TCS is not
collected — EximPe computes it.
Documents
¹ Alternatives — supplying either one clears both.
S1107 has no travel leg, so no visa
exists and the university ID card stands alone.
² Required only when remitter_relation is not SELF.
The three travel codes share one requirement set. They differ in what the remittance
is for — other travel, medical treatment, pilgrimage — not in what you must collect.
The requirement set can grow
Answering one requirement can reveal another. Declaringremitter_relation as anything other than SELF flips the relationship self-declaration to satisfied: false, because that document is only owed in that case.
This is expected. Re-read fields and documents from the response after every write rather than assuming the list you started with is final.Authorizations
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.
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.
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.
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.
Path Parameters
UID of the payment the details are for.
Response
The payment's requirements and their current state.