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 and theLRS_VERIFICATION_NEEDED webhook use.
There is nothing to map between them:
The loop
An event arrives
LRS_VERIFICATION_NEEDED lists what the payment owes — each entry a code, a sentence saying why, and whether it can be waived.You send what you have
You read where the payment stands
ACTION_REQUIRED — still waiting on you. IN_REVIEW — with us, nothing further to send.You read what is left, if anything is
GET 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
event.
Complete bodies for every LRS purpose code, generated from the live requirement
sets:
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
relationship_declaration is asked for on every code, but only once
remitter_relation is something other than SELF.
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 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.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: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:GET the same path
satisfied. Authoritative, idempotent, and safe to poll.LRS_VERIFICATION_NEEDED
outstanding and reason, which no requirement list can carry.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.
When the handoff itself does not happen
A complete set can fail to reach a verdict at all: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.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:Related
Get Verification Requirements
LRS_VERIFICATION_NEEDED
Upload Document
ref.Quote LRS Amount
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.
Body
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.
Documents by reference, or waivers.
Whether to run a complete set through the verification gateway. Never forces an incomplete one through.