Skip to main content
GET
Get verification requirements

​
Overview

Returns the verification requirements for one B2B services payment: every field and document it is asked for, which are already satisfied, and which are still outstanding. The requirement set is chosen by two facts on the order — its business model and its purpose code. Until both are declared no set claims the payment, and this endpoint asks for them instead. The VERIFICATION_NEEDED webhook lists what a payment is missing, as a flat array of codes in action_required_fields. This returns the whole set, each item an object carrying message, satisfied and provided. The codes are shared — an item the event names is an item you send back under the same key — but the shapes are not, so build your form from here rather than from the event.
Before the payment is classified, the event is not reading this set. No requirement set claims an unclassified payment, so VERIFICATION_NEEDED falls back to a legacy order-field check and can name product_description and hs_code — goods fields this flow never asks for. Ignore them, classify the payment, and read the real set from here.
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

Someone sent the buyer address last week and the invoice 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 user. Filter on satisfied for what is still owed.

​
Response

Two complete, unedited responses: a payment nothing has classified yet, and the same payment once it is classified as B2B services.
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 requirement set appears on the next call. Classify before you upload anything, too: Upload Document is routed by the payment’s flow and refuses until the pair has landed.
buyer_name reads satisfied: true in the second response because the credit carried it. The set accounts for what we already hold, so you only collect the rest.

​
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.
​
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.The list is every value the key can hold, not every value you will see. A B2B-services payment you are verifying lives in the first three rows, and ends in SETTLED or NOT_APPLICABLE; the rest are here so an unexpected value is a value you can look up rather than a surprise.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. Read this key before you send, and you will not collect a refusal you had no way to see coming.
​
string | null
required
B2B for every services payment, 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.
​
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 user.A refused filing is answered inline, in the 400’s details keyed by the offending code. The same code also rides the VERIFICATION_NEEDED event that refusal raises, so the two agree.
​
boolean
required
Whether this item still blocks completion. false is what “missing” means.It can go back to false on the invoice. If Ops rejects the invoice during review, the item is owed again and the payment is sent back for it. Upload a replacement and cite the new ref — re-sending the rejected one changes nothing.
​
boolean
required
Whether a value actually exists — you sent it, or we already held it. On this flow every item is required and none is conditional, so the two keys move together: false/false is owed, true/true is done.
Keys you will not see on this flow. optional, condition, waivable and one_of appear only when they apply, and no B2B services item is optional, conditional or waivable. Their absence is meaningful, not an omission.

​
No status, deliberately

There is no rolled-up complete / incomplete on this response. “Every box is ticked” is not “the payment passed” — a complete set still goes to the gateway, and a gateway can refuse it. And the POST on this same URL already returns a status that means something else. Fold your own roll-up when you want one:
For where the payment actually stands, read settlement_status or the submit response.
Nothing is re-run when you call this. A GET never 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 the B2B services set 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. All eleven services purpose codes share one set: S0802, S0803, S1005, S1009, S1010, S1013, S1015, S1016, S1017, S1105, S1106, each against business_model: "B2B".
No identity item at all. Nothing in this set is checked against an external register — no PAN, no IEC, no registration number. buyer_name is a plain value you send, so there is no step to clear before you can submit.
invoice_amount is asked for, but it decides nothing. Send it in rupees; it is cross-checked against the credit and refused if the two are more than a paisa apart. What settles is still the credit itself, and no tax is collected on top — amount_to_be_settled remains an unknown key here, and sending it is a 400.
No hs_code. HS codes describe physical goods crossing a border. Services have none, and there is no field for one.

Submit Verification Details

How to send what this endpoint asks for.

Upload Document

Upload the commercial invoice and keep its ref.

B2B Services Verification

The whole flow, in order.

List Settlement Documents

The step that opens once the payment settles.

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.