Skip to main content
GET
Get verification requirements

​
Overview

Returns the verification requirements for one payment: every field and document its checklist calls for, which are already satisfied, and which are still outstanding. The checklist is chosen by two facts on the order — its business model and its purpose code. Until both are declared no checklist claims the payment, and this endpoint asks for them instead. The LRS_VERIFICATION_NEEDED webhook lists what a payment is missing. This returns the whole set. Both describe the same items in the same shape, from the same read — an entry here is an entry there plus satisfied and provided.
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 missed an event

Webhooks get lost, retried, or arrive mid-deploy. This endpoint is authoritative and idempotent — call it any time. It is also the only place that reports settlement_status, which tells you whether sending anything is still possible.
2

You need the whole set

The event lists what is outstanding. Call this when you also need what is already satisfied — reconciling your record against ours, or rendering a progress view.
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 a message per item 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, a payment nothing has classified, and a travel payment whose documents include waivable ones.
The unclassified response is not an error. business_model and purpose_code come back null, and the two facts that would resolve them are listed as ordinary outstanding fields — same shape as any other entry. Send them back under those codes and the real checklist appears on the next call.

​
Reading the response

​
The payment

​
string
required
The payment. It is also the payment_id in this endpoint’s own path.
​
string
required
The order the payment belongs to. Every verification event names it under this key too.
​
string
required
The payment’s own state — not a roll-up of the checklist. This is the one thing an item list cannot tell you, and it is why this endpoint is worth calling when an event was missed: it says whether acting on the list is still possible at all.A payment can also read NOT_APPLICABLE, PAYMENT_PENDING, PAYMENT_FAILED or SETTLEMENT_ERROR — states in which no verification is being asked of you.Once the verification has been filed, staging closes: a POST to this path is refused rather than half-applied, because the staged rows are the record of what actually went to the gateway. UNDER_REVIEW, VERIFIED, READY_FOR_SETTLEMENT and SETTLED are the four states where that is true. Read this key before you send, and you will not collect a refusal you had no way to see coming.
​
string | null
required
B2B or B2C, or null while nothing has declared it.
​
string | null
required
The FEMA/FETERS purpose code the order settles under, or null while none is declared.

​
The items

There is one list per kind, holding the whole set. There is no separate “missing” array — what is still owed is a filter:
Every entry in fields and documents carries code, message, satisfied and provided. The remaining keys appear only when they apply, so their absence is meaningful: no optional key means the item is required, no waivable key means it cannot be waived.
​
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 of the item, safe to render to a payer. On buyer_declaration it is the wording the payer must be shown before affirming.The same key on a submit-failure event carries a sentence about what went wrong instead. One key, always the plainest thing there is to say about the item.
​
boolean
required
Whether this item still blocks completion. false is what “missing” means.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 a value actually exists — you 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:
​
boolean
Present, and always true, on items that never block completion. Absent on required items — there is no "optional": false.An optional item is listed until you supply it, because an optional document nobody is told about is one nobody sends.
​
string
Present on conditional items, naming the case that makes them owed.While the condition cannot yet be evaluated — the relation has not been declared — the item reads satisfied: true, provided: false. It is still listed, so you know it exists.
​
boolean
Present, and always true, on documents you may discharge with a waiver_reason instead of a file — a visa 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
A group name. Items sharing a group substitute for each other: send any one and the whole group clears.No checklist uses this today — where two documents are interchangeable the checklist gives them a single code instead (student_id_or_visa). The key is part of the contract because a future revision may split such a pair, and an integration that reads it will absorb that without a release.

​
What was sent under a document code

An entry in documents carries three more keys once a row exists for that code. They are absent while the slot is untouched, so their presence is itself the signal that something is held. ref needs a file; doc_status does not — a slot discharged by a waiver is a stored row with no file, and reads PENDING with no ref:
​
string
The upload identifier Upload Document returned for the file held in this slot — the same ref you submitted. Present only once a file has been sent under this code: a replacement upload supersedes the older row, so this always names the current file.
​
string
Where this one document stands: PENDING (not reviewed individually), VERIFIED (accepted) or REJECTED (refused — replace it). Present once a row exists for the slot, including one discharged by a waiver — that row has no file, so it reads PENDING and carries no ref.It is not a synonym for satisfied. satisfied says whether the checklist item blocks completion; doc_status says what a reviewer made of the file.
​
string
The reviewer’s text about this document, present only when they left some. The sentence to show a payer when you ask for a replacement file.
These three are LRS-only, and documents-only. Entries in fields never carry them — a field has no file and no reviewer mark — and the B2B goods and B2B services responses are unchanged. The same three keys appear on document entries in LRS_VERIFICATION_NEEDED and VERIFICATION_STATUS, with the same meanings.

​
No status, deliberately

Earlier versions returned a rolled-up status of complete / incomplete / not_applicable. It is gone, for two reasons:
  • It answered the wrong question. “Every box is ticked” is not “the payment passed”. A payment can be complete on its checklist and still be refused at the gateway — a PAN that will not verify, a sender who is not the account holder, a credit that does not cover the amount.
  • It collided. The POST on this same URL returns a status too, and there the word reports what the gateway did. One word, two meanings, same path.
Fold your own roll-up when you want one, against a definition you chose:
For where the payment actually stands, read settlement_status, the submit response, or LRS_VERIFICATION_NEEDED.
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.

​
Errors

Every refusal is a 400; the code inside the envelope is what tells them apart.

​
What each checklist asks for

The exact set is always what this endpoint returns — this is a summary, and a revision lands there before it lands in any table.

​
Every checklist starts here

Buyer and invoice basics, read straight off the order: buyer_name · buyer_address_line_1 · buyer_city · buyer_state · buyer_postal_code · buyer_email · buyer_phone · invoice_number · invoice_date The one exception is the light B2C set (S0101, S0802, S0301), which asks for buyer_name and an optional invoice, and nothing else.

​
LRS checklists

S0305, S1107, S0303, S0304 and S0306 add the remitter’s verified identity, the declaration and the amounts:
The remitter’s name is not on this list, and neither is the TCS. The name comes from Verify PAN, which you call before you can quote or submit — it is already on file under the PAN you declare. The TCS is the figure we quote against the payer’s year-to-date LRS usage; Quote LRS Amount tells you what to collect, and the credit is checked against it. Neither is yours to re-declare here.
Documents, per purpose code:
student_id_or_visa is one code that accepts either document. Upload a visa or a university ID card under this single code — there is no separate student_visa or university_id_card to send, and no alternative group to reconcile. S1107 has no travel leg, so no visa exists and the university ID stands alone as student_id.

​
B2B checklists

​
The requirement set can grow

Answering one requirement can reveal another. Declaring remitter_relation as anything other than SELF flips the fields naming the person the money is for — student_* on the education codes, primary_person_* on the travel ones — and the relationship self-declaration to satisfied: false, because they are only owed in that case. This is expected. Re-read fields and documents after every write rather than assuming the list you started with is final.

Submit Verification Details

Send the answers back, under these same codes.

Upload Document

Upload a file and get the ref a document entry needs.

LRS_VERIFICATION_NEEDED

The same items, pushed to you, when a payment owes them.

Quote LRS Amount

TCS and the all-in total, before the buyer transfers.

Authorizations

​
X-Client-ID
string
header
required

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-Client-Secret
string
header
required

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-Merchant-ID
string
header
required

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-API-Version
string
header
required

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

​
payment_id
string
required

UID of the payment the details are for.

Response

The payment's checklist and the current state of each item.

​
success
boolean
Example:

true

​
message
string
Example:

"Verification requirements"

​
data
object

What a payment needs and what it already has — the whole checklist, unlike the LRS_VERIFICATION_NEEDED webhook, which lists only what is outstanding. There is deliberately no rolled-up completion field: each item carries its own satisfied, and settlement_status reports where the payment itself stands.