> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eximpe.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
## 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`](/api-reference/v3/webhooks/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](/api-reference/v3/b2b/submit-verification-details#classify-it-first), 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
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.
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.
Someone sent the buyer address last week and the invoice today. Call this to see where the payment stands before asking for anything.
`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.
```json Nothing has classified this payment theme={null}
{
"success": true,
"message": "Verification requirements",
"data": {
"payment_id": "PR6938527534",
"order_id": "OD3376378679",
"settlement_status": "ACTION_REQUIRED",
"business_model": null,
"purpose_code": null,
"fields": [
{ "code": "business_model", "message": "Business model (B2B or B2C)", "satisfied": false, "provided": false },
{ "code": "purpose_code", "message": "FEMA/FETERS purpose code for this order", "satisfied": false, "provided": false }
],
"documents": []
}
}
```
```json S0802 — classified as B2B services theme={null}
{
"success": true,
"message": "Verification requirements",
"data": {
"payment_id": "PR6938527534",
"order_id": "OD3376378679",
"settlement_status": "ACTION_REQUIRED",
"business_model": "B2B",
"purpose_code": "S0802",
"fields": [
{ "code": "buyer_name", "message": "Buyer / remitter name", "satisfied": true, "provided": true },
{ "code": "buyer_address_line_1", "message": "Buyer address line 1", "satisfied": false, "provided": false },
{ "code": "buyer_city", "message": "Buyer city", "satisfied": false, "provided": false },
{ "code": "buyer_state", "message": "Buyer state", "satisfied": false, "provided": false },
{ "code": "buyer_postal_code", "message": "Buyer PIN code", "satisfied": false, "provided": false },
{ "code": "buyer_email", "message": "Buyer email", "satisfied": false, "provided": false },
{ "code": "buyer_phone", "message": "Buyer phone", "satisfied": false, "provided": false },
{ "code": "invoice_number", "message": "Invoice number", "satisfied": false, "provided": false },
{ "code": "invoice_date", "message": "Invoice date", "satisfied": false, "provided": false }
],
"documents": [
{ "code": "invoice", "message": "Commercial invoice", "satisfied": false, "provided": false }
]
}
}
```
**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](/api-reference/v3/b2b/submit-verification-details) under those codes and the real requirement set appears on the next call. Classify before you upload anything, too: [Upload Document](/api-reference/v3/b2b/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
The payment. It is also the `payment_id` in this endpoint's own path.
The order the payment belongs to.
**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.
| Value | What it means for you |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ACTION_REQUIRED` | The payment is waiting on you. Send what is outstanding. |
| `INFO_PENDING` | The same, earlier in the flow — nothing has been filed yet. |
| `UNDER_REVIEW` | Filed and with EximPe Ops. **Sending is closed.** |
| `VERIFIED` · `READY_FOR_SETTLEMENT` · `SETTLED` | Past verification. Sending is closed. `SETTLED` is also when the [post-settlement document step](/api-reference/v3/b2b/submit-settlement) opens. |
| `EXPIRED` · `REJECTED` · `ON_HOLD` | The payment did not proceed. Nothing you send reopens it. |
| `PAYMENT_PENDING` · `PAYMENT_FAILED` | The money has not arrived, or did not arrive. There is nothing to verify yet; a services payment you can act on starts at the credit. |
| `SETTLEMENT_ERROR` | Settlement was attempted and failed. Verification is behind it; this is an EximPe-side state, not something you clear by sending. |
| `NOT_APPLICABLE` | The payment carries no settlement workflow 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.
`B2B` for every services payment, or `null` while nothing has declared it.
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:
```js theme={null}
const outstanding = [...data.fields, ...data.documents].filter(i => !i.satisfied)
```
Every entry in `fields` and `documents` carries `code`, `message`, `satisfied` and `provided`.
The identifier you send the answer back under — as a key in `fields`, or as a document's `code`. See [Submit Verification Details](/api-reference/v3/b2b/submit-verification-details).
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.
Whether this item still blocks completion. `false` is what "missing" means.
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:
```js theme={null}
const complete = [...data.fields, ...data.documents].every(i => i.satisfied)
```
For where the payment actually stands, read `settlement_status` or the [submit response](/api-reference/v3/b2b/submit-verification-details#the-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.
| `error.code` | When |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `40360` | No such payment for this merchant. The same answer whether it does not exist or belongs to someone else, so the endpoint never confirms another merchant's payment id. |
| `40359` | The payment is classified, but no requirement set covers that business model and purpose code. An **unclassified** payment is not this case: it answers `200`, asking for the two classifying facts. |
## 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"`.
| | Codes |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Fields | `buyer_name`, `buyer_address_line_1`, `buyer_city`, `buyer_state`, `buyer_postal_code`, `buyer_email`, `buyer_phone`, `invoice_number`, `invoice_date` |
| Documents | `invoice` |
**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 not asked for.** The amount that settles is the credit itself, read from the payment, and no tax is collected on top. There is no figure to declare and no key to send: `invoice_amount`, `principal` and `collected_tcs` are all unknown keys here, and sending any of them is a `400`.
**No `hs_code`.** HS codes describe physical goods crossing a border. Services have none, and there is no field for one.
## Related
How to send what this endpoint asks for.
Upload the commercial invoice and keep its `ref`.
The whole flow, in order.
The step that opens once the payment settles.
## OpenAPI
````yaml GET /pg/payments/{payment_id}/verification/
openapi: 3.0.0
info:
title: Eximpe Payment Gateway API
description: >-
API for payment processing and order management through Eximpe payment
gateway. This specification is for v3 API version.
license:
name: Proprietary
version: 3.0.0
servers:
- url: https://api-pacb-uat.eximpe.com
description: Payment Gateway Sandbox URL
security:
- clientAuth: []
clientSecretAuth: []
apiVersionHeader: []
tags:
- name: Card Tokens
- name: Merchants
- name: Orders
- name: Payment Links
- name: Payments
- name: Refunds
- name: Settlements
- name: Subscriptions
- name: Virtual Bank Accounts
description: Create and manage virtual bank accounts and read collected payments.
- name: B2B Verification
description: Verification and post-settlement compliance for B2B payments.
paths:
/pg/payments/{payment_id}/verification/:
get:
tags:
- LRS
summary: Get verification requirements
description: >-
Returns everything a payment's checklist calls for — every field and
document, 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 — `business_model` and
`purpose_code` come back `null`, and the two facts are listed as
ordinary outstanding fields.
The verification webhook lists what a payment is *missing* —
[`LRS_VERIFICATION_NEEDED`](/api-reference/v3/webhooks/lrs-verification-needed)
on an LRS payment,
[`VERIFICATION_NEEDED`](/api-reference/v3/webhooks/verification-needed)
on a B2B-services one. 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`.
**There is no rolled-up `status`.** "Every box is ticked" is not "the
payment passed", and the POST on this same URL returns a `status` of its
own. Fold your own roll-up from the items, and read `settlement_status`
for where the payment actually stands — including whether sending
anything is still possible.
**Do not hardcode the field list.** The requirements are configuration
and are revised as the underlying regulatory matrix is; reading them
from here means a revision does not need a release on your side.
**PSP callers must send `X-Merchant-ID`.**
parameters:
- name: payment_id
in: path
required: true
schema:
type: string
description: UID of the payment the details are for.
example: PR6938527534
responses:
'200':
description: The payment's checklist and the current state of each item.
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: true
message:
type: string
example: Verification requirements
data:
$ref: '#/components/schemas/v3_VerificationState'
examples:
classified:
summary: A classified payment (S0305)
description: >-
Extract — the real response lists every item the checklist
holds. `buyer_name` came in with the payment itself; the
conditional items are satisfied vacuously until
`remitter_relation` says otherwise; the optional fee invoice
never blocks completion.
value:
success: true
message: Verification requirements
data:
payment_id: PR6938527534
order_id: OD3376378679
settlement_status: ACTION_REQUIRED
business_model: B2C
purpose_code: S0305
fields:
- code: buyer_name
message: Buyer / remitter name
satisfied: true
provided: true
- code: buyer_city
message: Buyer city
satisfied: false
provided: false
- code: remitter_pan
message: Remitter PAN
satisfied: false
provided: false
- code: remitter_relation
message: >-
Remitter's relation to the person the remittance is
for
satisfied: false
provided: false
- code: buyer_declaration
message: >-
The LRS declaration the payer affirms: resident in
India, within the LRS limit, permitted purpose
satisfied: false
provided: false
- code: primary_person_name
message: Name of the person the remittance is for
satisfied: true
provided: false
condition: PAYING_FOR_SOMEONE_ELSE
- code: principal
message: Amount to be settled for this payment, in INR
satisfied: false
provided: false
- code: collected_tcs
message: >-
TCS collected from the payer for this payment, in
INR ("0.00" if none)
satisfied: false
provided: false
documents:
- code: relationship_declaration
message: >-
Self-declaration of the remitter's relationship to
the person the remittance is for
satisfied: true
provided: false
condition: PAYING_FOR_SOMEONE_ELSE
- code: offer_letter
message: Letter of admission from the institution
satisfied: false
provided: false
- code: passport
message: Student's passport
satisfied: false
provided: false
- code: student_id_or_visa
message: Student visa or university ID card (either)
satisfied: false
provided: false
- code: fee_invoice
message: Fee invoice
satisfied: true
provided: false
optional: true
unclassified:
summary: Nothing has classified the payment
description: >-
No checklist claims the payment yet, so the two facts that
would resolve one are listed as ordinary outstanding fields.
Send them back through the POST and the real checklist
appears.
value:
success: true
message: Verification requirements
data:
payment_id: PR4471903288
order_id: OD9925177340
settlement_status: ACTION_REQUIRED
business_model: null
purpose_code: null
fields:
- code: business_model
message: Business model (B2B or B2C)
satisfied: false
provided: false
- code: purpose_code
message: FEMA/FETERS purpose code for this order
satisfied: false
provided: false
documents: []
classified_b2b_services:
summary: A classified payment (S0802, B2B services)
description: >-
The complete B2B-services set — nine buyer and invoice
fields and the commercial invoice. Nothing here is optional,
conditional or waivable, and there is no identity item, no
amount and no tax: `remitter_pan`, `principal` and
`collected_tcs` are unknown keys on this flow. `buyer_name`
came in with the credit.
value:
success: true
message: Verification requirements
data:
payment_id: PR6938527534
order_id: OD3376378679
settlement_status: ACTION_REQUIRED
business_model: B2B
purpose_code: S0802
fields:
- code: buyer_name
message: Buyer / remitter name
satisfied: true
provided: true
- code: buyer_address_line_1
message: Buyer address line 1
satisfied: false
provided: false
- code: buyer_city
message: Buyer city
satisfied: false
provided: false
- code: buyer_state
message: Buyer state
satisfied: false
provided: false
- code: buyer_postal_code
message: Buyer PIN code
satisfied: false
provided: false
- code: buyer_email
message: Buyer email
satisfied: false
provided: false
- code: buyer_phone
message: Buyer phone
satisfied: false
provided: false
- code: invoice_number
message: Invoice number
satisfied: false
provided: false
- code: invoice_date
message: Invoice date
satisfied: false
provided: false
documents:
- code: invoice
message: Commercial invoice
satisfied: false
provided: false
'400':
description: >-
The payment id does not resolve for this caller, or no checklist
covers its cell.
content:
application/json:
schema:
type: object
examples:
payment_not_found:
summary: The payment id is unknown, or belongs to another merchant
value:
success: false
error:
code: 40360
message: >-
Payment is not in a state that accepts verification
details.
details: >-
Payment is not in a state that accepts verification
details. Payment not found.
no_checklist:
summary: The order is classified into a cell no checklist covers
value:
success: false
error:
code: 40359
message: Invalid verification request.
details: >-
Invalid verification request. No verification checklist
covers this payment's business model and purpose code.
'500':
description: Unexpected processing failure.
content:
application/json:
schema:
$ref: '#/components/schemas/v3_ErrorResponse'
security:
- clientAuth: []
clientSecretAuth: []
merchantAuth: []
apiVersionHeader: []
components:
schemas:
v3_VerificationState:
type: object
description: >-
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.
required:
- payment_id
- order_id
- settlement_status
- business_model
- purpose_code
- fields
- documents
properties:
payment_id:
type: string
example: PR6938527534
order_id:
type: string
example: OD3376378679
settlement_status:
type: string
enum:
- NOT_APPLICABLE
- PAYMENT_PENDING
- PAYMENT_FAILED
- INFO_PENDING
- ACTION_REQUIRED
- UNDER_REVIEW
- VERIFIED
- READY_FOR_SETTLEMENT
- SETTLED
- SETTLEMENT_ERROR
- ON_HOLD
- EXPIRED
- REJECTED
description: >-
The payment's own state — not a roll-up of the checklist. Staging
closes once the verification has been filed, so `UNDER_REVIEW`,
`VERIFIED`, `READY_FOR_SETTLEMENT` and `SETTLED` refuse further
sends. Read it before you POST.
example: ACTION_REQUIRED
business_model:
type: string
nullable: true
enum:
- B2B
- B2C
- null
description: >-
`null` while nothing has declared it. Send it, together with
`purpose_code`, to resolve the checklist.
example: B2C
purpose_code:
type: string
nullable: true
description: >-
The FEMA/FETERS purpose code the order settles under, or `null`
while none is declared.
example: S0305
fields:
type: array
description: >-
Every field this checklist calls for, satisfied or not. What is
still owed is the subset with `satisfied: false`. On an unclassified
payment this holds the two classifying facts instead.
items:
$ref: '#/components/schemas/v3_VerificationRequirementItem'
documents:
type: array
description: >-
Every document this checklist calls for, satisfied or not. Empty on
an unclassified payment.
items:
$ref: '#/components/schemas/v3_VerificationRequirementItem'
v3_ErrorResponse:
type: object
required:
- success
- error
properties:
success:
type: boolean
description: Indicates if the request was successful
error:
$ref: '#/components/schemas/v3_ErrorDetails'
v3_VerificationRequirementItem:
type: object
description: >-
One field or document a payment's checklist calls for. `code` is the key
you send it back under. `code` and `message` are always present; the
remaining keys appear only when they apply, so their absence is
meaningful — no `waivable` key means the item cannot be waived.
required:
- code
- message
properties:
code:
type: string
description: >-
Stable identifier. Use it as the key in `fields`, or as the `code`
of a document.
example: offer_letter
message:
type: string
description: >-
A sentence about the item, safe to show a payer. On a submit-failure
event the same key says what went wrong instead.
example: Letter of admission from the institution
satisfied:
type: boolean
description: >-
Whether the item still blocks completion. `false` is what "missing"
means. Present on this endpoint; absent on the webhook, which lists
only outstanding items.
example: false
provided:
type: boolean
description: >-
Whether a value actually exists — you sent it, or we already held
it. `satisfied: true` with `provided: false` means nothing is owed
and nothing was sent: an optional item, or a conditional one that
does not apply.
example: false
optional:
type: boolean
description: >-
Present, and always `true`, on items that never block completion.
Absent on required items — there is no `"optional": false`.
example: true
condition:
type: string
enum:
- PAYING_FOR_SOMEONE_ELSE
- PHYSICAL_GOODS_ONLY
description: >-
Present on items owed only in a named case.
`PAYING_FOR_SOMEONE_ELSE` — `remitter_relation` is declared as
something other than `SELF`. `PHYSICAL_GOODS_ONLY` — the order ships
physical goods.
example: PAYING_FOR_SOMEONE_ELSE
waivable:
type: boolean
description: >-
Present, and always `true`, on documents you may discharge with a
`waiver_reason` instead of a file. The item stays `satisfied: false`
until you do — the waiver is yours to record, not ours to assume.
example: true
one_of:
type: string
description: >-
A group name; items sharing one substitute for each other. No
checklist uses it today — where two documents are interchangeable
the checklist gives them a single code instead
(`student_id_or_visa`).
example: student_status_proof
v3_ErrorDetails:
type: object
required:
- code
- message
properties:
code:
type: string
description: Error code (e.g., ERR_ORDER_002)
message:
type: string
description: Error message
details:
type: object
description: Detailed validation error information with field-specific errors
additionalProperties:
type: string
description: Error message for the specific field
securitySchemes:
clientAuth:
type: apiKey
name: X-Client-ID
in: header
description: >-
**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-displayName: Client ID
x-example: your-client-id
clientSecretAuth:
type: apiKey
name: X-Client-Secret
in: header
description: >-
**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-displayName: Client Secret
x-example: your-client-secret
apiVersionHeader:
type: apiKey
name: X-API-Version
in: header
description: >-
**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.
x-displayName: API Version
x-example: 3.0.0
merchantAuth:
type: apiKey
name: X-Merchant-ID
in: header
description: >-
**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-displayName: Merchant ID
x-example: your-merchant-id
````