> ## 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.
# Submit B2B Services Verification Details
> What a B2B services payment is asked for, and how to send it — the buyer, the invoice fields, and the commercial invoice. No identity, no amount, no tax.
## Overview
A B2B services payment answers a short list: who the buyer is, which invoice this is, and the invoice itself. **No identity document, no amount to declare, no tax.** This page is that list, and what happens once it is complete.
**Same endpoint as [Submit Payment Verification Details](/api-reference/v3/payment/submit-verification-details).** One URL answers every verification ask — `fields`, `documents`, partial sends and the response shape all work identically. Only what a payment is *asked for* differs, and that is what this page covers.
Send details keyed by the same codes that [Get Verification Requirements](/api-reference/v3/b2b/verification-requirements) and the [`VERIFICATION_NEEDED`](/api-reference/v3/webhooks/verification-needed) webhook use. There is nothing to map between them — the `GET` names an item under `code`, the event names the same string in `action_required_fields`, and this endpoint takes it back under that key.
**JSON only.** `fields` is an object; `documents` is a list of `{code, ref}` naming files uploaded earlier through [Upload Document](/api-reference/v3/b2b/upload-document). Files are never posted to this endpoint.
## The loop
[`VERIFICATION_NEEDED`](/api-reference/v3/webhooks/verification-needed) lists what the payment owes, as a flat array of codes in `action_required_fields`. While the payment is still unclassified that list is a legacy order-field check and can name `product_description` and `hs_code`, which this flow never asks for — classify the payment, then read the real set from [Get Verification Requirements](/api-reference/v3/b2b/verification-requirements).
A VBA credit arrives unclassified. Send `business_model` and `purpose_code` before anything else can be checked.
[Upload Document](/api-reference/v3/b2b/upload-document) returns a `ref`.
Fields as a map, the invoice as `{code, ref}`. Partial is fine — later sends merge over earlier ones.
The response says both: a `status`, and `outstanding` — the codes still owed after this write.
## Classify it first
A payment with no `business_model` and `purpose_code` on its order has no requirement set, so nothing else about it can be validated. Both travel together:
```bash theme={null}
curl -X POST 'https://api-pacb-uat.eximpe.com/pg/payments/PR6938527534/verification/' \
-H 'X-Client-ID: ' -H 'X-Client-Secret: ' \
-H 'X-Merchant-ID: ' -H 'X-API-Version: 3.0.0' \
-H 'Content-Type: application/json' \
-d '{ "fields": { "business_model": "B2B", "purpose_code": "S0802" }, "finalize": false }'
```
They can ride along with everything else in one call, but sending them first is the simplest thing to do.
**`business_model` and `purpose_code` must travel together, and only once.** Send one without the other and the call is refused naming the one you left out. Once set, sending either again is a `400` — `Already set on the order; it cannot be changed here.`
**Which codes are B2B services?** `S0802`, `S0803`, `S1005`, `S1009`, `S1010`, `S1013`, `S1015`, `S1016`, `S1017`, `S1105`, `S1106` — all against `business_model: "B2B"`. They share one requirement set. The code must also be one your settling entity is enabled for; a valid code you are not enabled for is rejected just like one that does not exist.
## The complete body
Nine fields and one document. This is the whole of it:
```json S0802 — B2B services theme={null}
{
"fields": {
"buyer_name": "Northwind Technologies Pvt Ltd",
"buyer_address_line_1": "7th Floor, Prestige Tower, Residency Road",
"buyer_city": "Bengaluru",
"buyer_state": "Karnataka",
"buyer_postal_code": "560025",
"buyer_email": "ap@northwind.co.in",
"buyer_phone": "+919876543210",
"invoice_number": "INV-2026-0041",
"invoice_date": "2026-08-01"
},
"documents": [
{ "code": "invoice", "ref": "8207383264" }
],
"finalize": true
}
```
**The buyer here is the Indian remitter, not your customer abroad.** These fields describe whoever in India paid you — the same party the credit came from. `buyer_postal_code` is stored on the order as an Indian PIN code, so send the remitter's Indian address rather than your own overseas one.
**No amount and no declaration key.** The amount that settles is the credit itself, read from the payment, and no tax is collected on top — so there is no `principal` and no `collected_tcs` to send. The declaration is recorded by the act of filing a complete set rather than sent as a field. All three are `400`s if you send them.
## Values
Field values are strings.
| Kind | Send |
| ------------------- | --------------------------------------------------------------------------------------------- |
| `invoice_date` | `YYYY-MM-DD` |
| `buyer_postal_code` | A six-digit Indian PIN code |
| `business_model` | `B2B`. Case-insensitive. |
| `purpose_code` | One of the eleven services codes your merchant account is allow-listed for. Case-insensitive. |
**An unknown key is a `400`, not a silent drop.** A misspelled `invoice_number` that we quietly ignored would leave the payment waiting forever for a field you believe you sent. Every key is checked before any is written, so one typo cannot half-apply a call.
Omit a key rather than sending `null` or an empty string — a blank value is itself a `400`, with the same reasoning.
### Documents
One entry, naming the invoice's checklist code and the `ref` you got from [Upload Document](/api-reference/v3/b2b/upload-document):
| Key | |
| ------ | ----------------------------------------------------------------------------------------------------------------- |
| `code` | `invoice` — the only document this set asks for. |
| `ref` | A `ref` returned by Upload Document **for this payment**. A ref from one of your other payments reads as unknown. |
Sending the same code twice in one call is a `400`. Sending it again in a **later** call is fine — the newer ref replaces the earlier row.
**One citation covers every invoice on the payment.** The citation names the `code`, and this flow has exactly one document type per code, so **all** the payment's invoices are filed when the set completes — not just the one whose `ref` you sent. Upload a second invoice and it goes with them; you do not cite it, and you cannot leave it out.
**`waiver_reason` is not accepted on this flow.** No B2B services item is waivable, so there is nothing to discharge with a reason instead of a file. Sending one is a `400` reading `This document cannot be waived.`, keyed by the document's code.
**`linked_payment_id` and `reason` are ignored here.** The shared request body accepts them, but they mark a payment as a top-up of an earlier one — an LRS concept. B2B services has none, so both are read and discarded rather than refused. Do not send them expecting a link.
## Partial sends are merged
Send three fields today and two tomorrow and you have sent five. Nothing you sent earlier is wiped by a later call, and a field's newest value wins.
**`finalize` defaults to `true`.** It applies only to a **complete** set and never forces an incomplete one through, so a partial send is accepted either way — you do not have to set it. Pass `finalize: false` when you have sent everything but do not want the verification filed yet.
**That tolerance ends once the verification has been filed.** A payment whose `settlement_status` is `UNDER_REVIEW`, `VERIFIED`, `READY_FOR_SETTLEMENT` or `SETTLED` refuses further sends — the staged rows are the record of what went to the gateway, and a later edit would leave them disagreeing with what was actually filed. [`GET`](/api-reference/v3/b2b/verification-requirements) the same path to read `settlement_status` before you send.
## The response
Three keys, whatever you sent:
```json Still owed theme={null}
{
"success": true,
"message": "Verification details received",
"data": {
"payment_id": "PR6938527534",
"status": "incomplete",
"outstanding": ["buyer_city", "invoice"]
}
}
```
```json Filed theme={null}
{
"success": true,
"message": "Verification details received",
"data": {
"payment_id": "PR6938527534",
"status": "in_review",
"outstanding": []
}
}
```
| `status` | Meaning |
| ------------ | ---------------------------------------------------------------------------------- |
| `incomplete` | Something is still owed — `outstanding` lists the codes. |
| `complete` | Everything was sent, but the set was staged rather than filed (`finalize: false`). |
| `in_review` | The complete set was filed. The payment is with EximPe Ops for review. |
**Three values, not four.** A complete set either files — `in_review` — or is refused with a `400` naming what to fix. There is no `action_required` here; do not write a branch for a value you will never receive.
**A refusal never discards your details.** Everything you sent is staged against the payment before the filing is attempted, so a `400` on the finalizing call costs you a re-send of the one thing that failed, not the whole set.
## Completion
A complete B2B services set hands off to its own verification gateway, and `in_review` is what says it got there. That handoff is also what writes the staged values onto the order — which is why a second group of refusals only appears on the finalizing call.
## Errors
Every refusal is a `400`, whatever the reason — the code inside the envelope is what tells them apart, not the status.
| `error.code` | When |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `40359` | The send itself is wrong — see the messages below. Also: the payment has no requirement set, and you did not send the classifying pair. |
| `40360` | No such payment for this merchant — the same answer whether it does not exist or belongs to someone else. Also: the verification has already been filed and details can no longer be changed. |
| `ERR_IMPORT_VERIFICATION_001` | The `invoice_number` is already used by another of your payments. Raised only by the call that files — see [below](#raised-only-by-the-call-that-files). |
| `ERR_B2B_SERVICES_004` | The verification has left your hands — under review, approved or rejected — and can no longer be edited. |
| `ERR_B2B_SERVICES_006` | A document being filed does not belong to this payment. |
**Branch on `code`, not on `message`.** `40359` is shared with the other verification flows; `message` names which one refused you, so a classified B2B services payment always reads `Invalid B2B services request.` The code is the stable part.
Before the payment is classified there is no flow to name, and the wording is `Invalid verification request.` instead — the one case on this flow where the message is not the services one.
Not every refusal is `40359`. A few carry a code of their own, listed above — they are the specific ones, and they say more than the shared code does. Treat any code you do not recognise as a `400` you should not retry unchanged.
A `400` on the send carries `details` keyed by the offending code, so one call reports every problem at once:
```json theme={null}
{
"success": false,
"error": {
"code": 40359,
"message": "Invalid B2B services request.",
"details": {
"buyer_citty": "Not a requirement of this payment's checklist.",
"invoice": "This is a document code; send it under 'documents'."
}
}
}
```
| Message | Cause |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Not a requirement of this payment's checklist.` | The code is not one this set asks for — `hs_code`, `iec`, `principal`, `invoice_amount` and `remitter_pan` all land here. |
| `This is a document code; send it under 'documents'.` | `invoice` appeared as a key in `fields`. |
| `This is a field code; send it under 'fields'.` | The reverse. |
| `Blank value; omit the key instead.` | `null`, `""`, or whitespace. |
| `Sent more than once in this call.` | The same document code twice in one `documents` array. |
| `Unknown document ref.` | The `ref` is not one of this payment's active documents. A ref uploaded against another payment, or superseded by a later upload of the same type, reads as unknown. |
| `This document cannot be waived.` | A `waiver_reason` on an item whose `waivable` is not true. No B2B services item is waivable, so every `waiver_reason` on this flow lands here. |
| `Already set on the order; it cannot be changed here.` | `business_model` or `purpose_code` after classification has landed. |
### Raised only by the call that files
A second group appears only when a complete set is filed, as the staged values are read for the gateway and written onto the order:
| Message | Cause |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Not a date; send YYYY-MM-DD.` | `invoice_date` will not parse. |
| `Enter a valid Indian PIN code.` | `buyer_postal_code` is not a PIN code in the India Post directory. A foreign postal code lands here — the buyer is the Indian remitter, not your customer abroad. |
Filing is also what writes the staged buyer and invoice fields onto the order, and the order validates them on write — which is where that PIN code is judged. `invoice_number` is unique per merchant, so a collision surfaces here too. Unlike the refusals above it does **not** answer under `40359` — it carries its own code:
```json theme={null}
{
"success": false,
"error": {
"code": "ERR_IMPORT_VERIFICATION_001",
"message": "Invoice number already exists.",
"details": "Invoice number already exists."
}
}
```
`invoice_number` is unique per merchant across filed verifications. Re-using one from an earlier payment is refused here, not at the call that staged it — raise a new number and send that field again.
These all arrive on the finalizing call rather than the call that staged the value, because nothing reads a date as a date — or writes anything to the order — until the set is complete. Your details are still saved; fix the named code and re-send only that.
## Related
What this payment is asked for, and what is already satisfied.
Upload the commercial invoice and keep its `ref`.
The whole flow, in order.
The step that opens once the payment settles.
## OpenAPI
````yaml POST /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/:
post:
tags:
- LRS
summary: Submit verification details
description: >-
Sends verification details for a payment, keyed by the same codes the
verification webhook and `GET /pg/payments/{payment_id}/verification/`
use. There is nothing to map: every one of those places names an item
under `code`.
**JSON only.** `fields` is an object; `documents` is a list of `{code,
ref}` naming files uploaded earlier through Upload Document
([LRS](/api-reference/v3/lrs/upload-document) · [B2B
services](/api-reference/v3/b2b/upload-document)). Files are never
posted to this endpoint.
**Partial sends are merged, never replaced.** Send what you have;
nothing you sent earlier is wiped by a later call. That ends once the
verification has been filed — a payment in `UNDER_REVIEW`, `VERIFIED`,
`READY_FOR_SETTLEMENT` or `SETTLED` refuses further sends.
**An unclassified payment accepts only `business_model` and
`purpose_code`**, and they must travel together. Nothing else can be
validated until a checklist claims the payment.
**Completion is automatic.** Once nothing is outstanding the set is run
through any verification the payment needs — PAN verification, the
sender-to-account-holder match, the TCS recomputation and the LRS
counter posting. Pass `finalize: false` to stage without triggering it.
**The response carries `outstanding`** — the codes still owed after this
write. You do not need a second call to learn what is left.
**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
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
fields:
type: object
description: >-
Answers keyed by checklist code, e.g. `{"remitter_pan":
"ABCPK1234F", "buyer_city": "Bengaluru"}`. Values are
strings, numbers or booleans. Dates are `YYYY-MM-DD`;
amounts (`principal`, `collected_tcs`) are decimal strings
in rupees. An unknown key is a 400 rather than a silent drop
— a typo you never hear about would leave the payment
waiting forever for a field you believe you sent. Omit a key
rather than sending null or an empty string; a blank value
is also a 400.
additionalProperties: true
example:
buyer_name: Acme Imports Pvt Ltd
buyer_city: Bengaluru
invoice_number: INV-2026-0041
invoice_date: '2026-08-01'
documents:
type: array
description: >-
Documents by reference, or waivers. Each entry names exactly
one of `ref` and `waiver_reason`; sending both, neither, or
the same code twice in one call is a 400.
items:
type: object
required:
- code
properties:
code:
type: string
description: >-
The checklist code this document answers, as named by
the verification webhook or GET
/pg/payments/{payment_id}/verification/. The codes are
configuration and are revised over time — read them
rather than hardcoding them.
example: invoice
ref:
type: string
description: >-
A `ref` returned by Upload Document. Send this or
`waiver_reason`, never both.
example: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d
waiver_reason:
type: string
description: >-
Why this document is not being supplied. Only accepted
on items whose `waivable` is true.
example: Destination is visa-free for this passport
finalize:
type: boolean
default: true
description: >-
Whether to run a complete set through the payment's
verification gateway — the LRS gateway on an LRS payment,
the B2B-services one on a services payment. Never forces an
incomplete set through.
linked_payment_id:
type: string
nullable: true
description: >-
The earlier payment this one tops up — the buyer was short,
or paid the TCS separately. Resolved against your own
payments; a link that cannot be resolved is refused. Read by
the call that files, so send it with the call that completes
the set. LRS only: a B2B-services payment has no top-up
concept and ignores this key rather than refusing it.
example: PR6938527534
reason:
type: string
nullable: true
enum:
- REMAINING_AMOUNT
- TCS_PAYMENT
description: >-
Why the two payments are linked; an audit label on the link.
`REMAINING_AMOUNT` — covering a principal shortfall.
`TCS_PAYMENT` — paying the TCS separately. Only valid
together with `linked_payment_id`. LRS only, like
`linked_payment_id`: ignored on a B2B-services payment.
example: REMAINING_AMOUNT
example:
fields:
buyer_name: Acme Imports Pvt Ltd
buyer_city: Bengaluru
invoice_number: INV-2026-0041
invoice_date: '2026-08-01'
documents:
- code: invoice
ref: a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d
finalize: true
responses:
'200':
description: >-
Details received. The body says where the payment now stands and
what is still owed.
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: true
message:
type: string
example: Verification details received
data:
type: object
required:
- payment_id
- status
- outstanding
properties:
payment_id:
type: string
description: The payment these details were recorded against.
example: PR6938527534
status:
type: string
enum:
- incomplete
- complete
- in_review
- action_required
description: >-
Lower-case, always one of four. `incomplete` —
something is still owed; `outstanding` names it.
`complete` — nothing is outstanding and nothing was
filed (you passed `finalize: false`, or this checklist
is not an LRS one and needs no gateway handoff).
`in_review` — the set was complete, the gateway took
it, and it passed. `action_required` — the set was
complete and filed, and the gateway did not pass the
payment. It never means your details were discarded.
example: incomplete
outstanding:
type: array
items:
type: string
description: >-
The codes still owed after this write — the same codes
you would get by filtering the GET on `satisfied:
false`. Empty when nothing is.
example:
- invoice_number
- invoice
examples:
incomplete:
summary: incomplete — something is still owed
description: >-
A partial send. `outstanding` is the list; you do not need a
second call to read it.
value:
success: true
message: Verification details received
data:
payment_id: PR6938527534
status: incomplete
outstanding:
- invoice_number
- invoice_date
- invoice
in_review:
summary: in_review — the payment is with us
description: >-
Everything the checklist asks for was sent, the set went
through the verification gateway, and it passed. Nothing
further to send.
value:
success: true
message: Verification details received
data:
payment_id: PR6938527534
status: in_review
outstanding: []
action_required:
summary: action_required — the gateway did not pass it
description: >-
An empty `outstanding` with this status is not a
contradiction: the checklist is satisfied, the gateway
refused. The verdict arrives as an LRS_VERIFICATION_NEEDED
event with the conclusion folded into the relevant entry's
message. No event at all means the handoff itself did not
land — repeat the same request.
value:
success: true
message: Verification details received
data:
payment_id: PR6938527534
status: action_required
outstanding: []
complete:
summary: complete — staged, not filed
description: >-
The checklist is satisfied but nothing went to the gateway:
either you passed `finalize: false`, or this payment's
checklist is not an LRS one.
value:
success: true
message: Verification details received
data:
payment_id: PR6938527534
status: complete
outstanding: []
'400':
description: >-
The payment id does not resolve, the send names codes the checklist
does not, the order refuses the values on write, or staging has
already closed. `error.message` names the payment's flow — an LRS
payment reads "Invalid LRS request.", a B2B services payment
"Invalid B2B services request.", and a payment nothing has
classified yet "Invalid verification request." The code is the same
either way, so branch on the code.
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.
already_filed:
summary: Staging closes once the verification has been filed
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. This payment's verification has already been
filed; its details can no longer be changed here.
unknown_codes:
summary: Codes that are not requirements of this payment's checklist
value:
success: false
error:
code: 40359
message: Invalid LRS request.
details:
buyer_citty: Not a requirement of this payment's checklist.
invoice: This is a document code; send it under 'documents'.
order_refused_the_write:
summary: >-
Filing writes the values onto the order, which validates
them
value:
success: false
error:
code: 40359
message: Invalid LRS request.
details:
buyer_postal_code: Enter a valid Indian PIN code.
duplicate_invoice_number:
summary: >-
The invoice number is already used by another payment (B2B
services)
description: >-
`invoice_number` is unique per merchant, and the collision
is raised by the call that files, as the staged values are
written onto the order. This refusal carries its own code
rather than the shared `40359`. **B2B services only** — the
LRS path writes the order without catching the collision, so
there it surfaces as a `500` rather than this `400`.
value:
success: false
error:
code: ERR_IMPORT_VERIFICATION_001
message: Invoice number already exists.
details: Invoice number already exists.
already_classified:
summary: >-
The business model and purpose code cannot be changed once
set
value:
success: false
error:
code: 40359
message: Invalid LRS request.
details:
business_model: Already set on the order; it cannot be changed here.
purpose_code: Already set on the order; it cannot be changed here.
blank_value:
summary: A blank value is refused rather than silently dropped
value:
success: false
error:
code: 40359
message: Invalid LRS request.
details:
buyer_city: Blank value; omit the key instead.
'500':
description: Unexpected processing failure.
content:
application/json:
schema:
$ref: '#/components/schemas/v3_ErrorResponse'
security:
- clientAuth: []
clientSecretAuth: []
merchantAuth: []
apiVersionHeader: []
components:
schemas:
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_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
````