Get verification requirements
B2B Services
Get Verification Requirements
Everything a B2B services payment is asked for — the nine buyer and invoice fields, the commercial invoice, and which are already satisfied.
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. TheVERIFICATION_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.
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; 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: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 — this flow raises no submit-failure event, so there is no second place this key means something else.boolean
required
Whether this item still blocks completion.
false is what “missing” means.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:
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 a400; 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.Related
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
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 checklist and the current state of each item.
Example:
true
Example:
"Verification requirements"
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.