Skip to main content
Money has arrived, and the payment is sitting in ACTION_REQUIRED — we have the funds but not the paperwork. We tell you exactly what it needs, you send it, and the payment completes itself once nothing is outstanding.
New to the rules? Read LRS & Compliance first. This page walks through the API.
LRS is always scoped to the sub-merchant, never the PSP. The purpose codes you may declare, the fees applied and the documents cited all come from the account the payment settles to.How that account is named differs by call. Quote LRS Amount and the older POST /pg/lrs/documents/ alias have no payment to read it from, so a PSP names the sub-merchant with X-Merchant-ID. Every call that carries a payment_id in its path — Get Verification Requirements, Submit Verification Details and Upload Document — derives it from the payment.

​
Before the buyer pays

Two calls, in order:
  1. Verify PAN — confirm the buyer’s PAN is real and matches their name. Nothing downstream works until this passes.
  2. Quote LRS Amount — tells you the full amount to ask the buyer for, inclusive of TCS and our fee. Ask for that figure, and the payment covers itself.
PSPs: the fee in that quote is the sub-merchant’s. Our fee and the GST on it resolve against the account the payment settles to, on the quote and on Submit Verification Details alike — so the figure the quote returns is the figure the payment is held to, and the one refusal.outstanding_cents measures a shortfall against.

​
Once the money lands

The payment is created as ACTION_REQUIRED, and a LRS_VERIFICATION_NEEDED webhook names exactly what’s still needed — which fields, which documents, and any amount short. From there it’s one loop, repeated until nothing is outstanding:
  1. Upload each document as it arrives via Upload Document, and keep the ref it returns.
  2. Send what you have via Submit Verification Details — fields as a map, documents as {code, ref}. Partial sends are fine; later sends merge over earlier ones.
  3. Read the response: status says where the payment stands, and outstanding names what’s still owed.
  4. If nothing is outstanding, the set goes to our checks — PAN, sender match, tax — and the payment moves to in_review, then settles.
If you ever need the whole picture rather than just what changed — you missed a webhook, or you’re resuming a payment someone else started — Get Verification Requirements returns the complete set, satisfied or not. It’s idempotent; call it any time.

Submit Verification Details

The full request body for every purpose code, and every error.

Get Verification Requirements

The full response shape, and what each purpose code asks for.

​
When it doesn’t go straight through

​
Four things that will bite you

Partial sends merge. Three fields today and two tomorrow is five fields. Nothing you sent earlier is wiped, so send each thing as you get it rather than waiting for the full set. An unknown key is rejected, not silently dropped. A misspelled field would otherwise leave the payment waiting forever for something you believe you sent. Omit a key rather than sending null or an empty string. A boolean is only satisfied by true — false reads as not yet answered. A failed check doesn’t discard what you sent. Everything you already sent is kept. Fix only what the event names, and send that.

​
The payment has a deadline

A payment that never completes its verification is refunded to the buyer — terminal, and nothing you send afterwards reopens it. Treat the moment the money arrived as when the clock started, surface it in your own UI, and chase against it.

​
Once it’s filed

A filed verification is reviewed by us, and the outcome reaches you as a webhook: Order two verdicts on one payment by the envelope’s event_time. sequence_number is a random identifier, not a sequence.

​
After it passes

Once it clears review, the money is settled to you. Track it with the Settlement APIs and the Payment Settled webhook.