> ## 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.
# List Settlement Documents
> Every post-settlement compliance document filed against a settled B2B-services payment, and whether the set is locked.
## Overview
Once a B2B-services payment is **settled**, one more compliance step remains: evidence that the service was actually delivered. This endpoint reads the delivery proofs you have uploaded against the payment, and whether the set is locked.
It is safe to call at any time — it reads, it never re-runs anything. That includes **before** the payment settles: it answers with `is_settled: false` rather than refusing. Only [Submit Settlement Documents](/api-reference/v3/b2b/submit-settlement) refuses on an unsettled payment.
**B2B services only.** A payment that is not a B2B-services payment is refused. B2B goods has no partner-API settlement path.
## Response
```json theme={null}
{
"success": true,
"message": "Settlement documents",
"data": {
"state": "FRESH",
"is_settled": true,
"is_multi": true,
"required_doc_types": ["delivery_proof"],
"submitted_at": null,
"documents": [
{
"document_id": "4193006825",
"doc_type": "delivery_proof",
"file_name": "delivery-note.pdf",
"file": "https://…s3.amazonaws.com/…?X-Amz-Signature=…"
},
{
"document_id": "7250884131",
"doc_type": "delivery_proof",
"file_name": "signed-acceptance.pdf",
"file": "https://…s3.amazonaws.com/…?X-Amz-Signature=…"
}
]
}
}
```
An empty `documents` array means you have uploaded nothing yet — not that nothing is owed.
`FRESH` (nothing filed yet) or `SUBMITTED` (filed and locked). Two values, not three — there is no draft on this surface, because one [submit](/api-reference/v3/b2b/submit-settlement) files the set in a single call. `documents` is listed in both states, so `FRESH` means "this is what you are holding", not "this is empty". Read this before submitting: once it is `SUBMITTED`, a second submit is refused with `ERR_B2B_SETTLEMENT_002`.
Whether the payment has settled. Documents can only be **filed** after it has; submitting earlier is refused with `ERR_B2B_SETTLEMENT_003`. Uploading earlier is allowed, and so is this read.
`true` for B2B services. Read it together with `required_doc_types` — see below.
Every type this flow accepts. Because `is_multi` is `true`, the set is complete once **one** file of **any** listed type is filed — not one of each. A single-file flow (`is_multi: false`) would need one of every type.
An upload under a type not listed here never reaches this set at all, so a `ref` from one is refused by the submit with `ERR_B2B_SETTLEMENT_001`.
ISO-8601 timestamp of the submission, or `null` while the set is still `FRESH`.
The document's id — **the same value as the `ref`** [Upload Document](/api-reference/v3/b2b/upload-document) handed you. The upload writes this row, so there is only one id to hold on to.
The type the file was uploaded under — you never send a `doc_type` again after the upload. B2B services has exactly one, `delivery_proof`, and accepts **many files under it**. Goods is the opposite — one file per type — which is why the two flows do not share an endpoint.
The stored file's name, for display.
A pre-signed, time-limited URL for the stored file. Fetch it if you need the document back; do not store the URL itself, as it expires.
## What is listed
Only **active** documents, oldest upload first. A delivery proof appears here as soon as it is uploaded, so you can check what you are holding before you file it.
Two things remove a document from this list: uploading is not filing, and `refs` on the [submit](/api-reference/v3/b2b/submit-settlement) is the whole set — a document you do not name there is deactivated and stops being listed. After a submit, this list is exactly what you filed.
## Errors
Reading the set is refused only when the payment itself does not qualify. Both cases are a `400` carrying `40360`; the `details` string says which.
| Cause | `code` | What to do |
| ----------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| The payment id does not resolve for this caller | `40360` | The same answer whether it does not exist or belongs to another merchant, so the endpoint never confirms someone else's payment id. |
| The payment is not a B2B-services payment | `40360` | B2B goods has no partner-API settlement path. |
```json theme={null}
{
"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."
}
}
```
## Related
File the delivery proofs by `ref` and lock the set.
Upload each delivery proof and keep its `ref`.
The whole flow, in order.
## OpenAPI
````yaml GET /pg/payments/{payment_id}/settlement-documents/
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}/settlement-documents/:
get:
tags:
- B2B Verification
summary: List post-settlement documents
description: >-
Every active post-settlement compliance document filed against one
B2B-services payment, and whether the set has been submitted.
This is a read, and it answers on a payment that has not settled yet —
reporting `is_settled: false`. Only the submit refuses before
settlement.
**PSP callers must send `X-Merchant-ID`.**
parameters:
- name: payment_id
in: path
required: true
schema:
type: string
description: UID of the settled B2B-services payment the documents belong to.
example: PR6938527534
responses:
'200':
description: The attached documents.
content:
application/json:
schema:
type: object
properties:
success:
type: boolean
example: true
message:
type: string
example: Settlement documents
data:
type: object
properties:
state:
type: string
enum:
- FRESH
- SUBMITTED
description: >-
FRESH = nothing filed yet, SUBMITTED = the set is
filed and locked. There is no draft on this surface:
files are held as uploads until one submit files them
all.
example: FRESH
is_settled:
type: boolean
description: >-
Whether the payment has settled. Documents can only be
filed after it has; this read is allowed either way.
example: true
is_multi:
type: boolean
description: >-
True for B2B services: the set is complete once one
file of any required type is attached, not one of
each.
example: true
required_doc_types:
type: array
items:
type: string
enum:
- delivery_proof
description: >-
Every document type this flow accepts. Read with
is_multi.
example:
- delivery_proof
submitted_at:
type: string
format: date-time
nullable: true
description: >-
When the set was submitted, or null while it is FRESH.
Naive UTC — no offset is sent.
example: null
documents:
type: array
items:
type: object
properties:
document_id:
type: string
description: UID of the filed document.
example: '4193006825'
doc_type:
type: string
description: >-
Post-settlement compliance document type. B2B
services has one: `delivery_proof`.
enum:
- delivery_proof
example: delivery_proof
file_name:
type: string
description: The stored file's name.
example: delivery-note.pdf
file:
type: string
description: >-
Pre-signed, time-limited URL for the stored
file. Fetch it if you need the document back; it
expires, so do not store it.
example: >-
https://bucket.s3.amazonaws.com/lrs_documents/308/8207383264/delivery-note.pdf?X-Amz-Signature=...
'400':
description: >-
The payment id does not resolve for this caller, or it is not a
B2B-services payment.
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.
not_b2b_services:
summary: The payment is not a B2B-services one
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 is not a B2B-services payment.
security:
- clientAuth: []
clientSecretAuth: []
merchantAuth: []
apiVersionHeader: []
components:
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
````