> ## 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 Settlement Documents > File a settled B2B-services payment's delivery proofs by ref, and lock the set — in one call. ## Overview Closes the post-settlement compliance step. Send the `ref` of every delivery proof you want on the record; this call names them as the payment's set, drops any upload it does not name, and locks the result. ```bash theme={null} curl -X POST 'https://api-pacb-uat.eximpe.com/pg/payments/PR6938527534/settlement/submit/' \ -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 '{ "refs": ["8207383264", "5512907744"] }' ``` ```json theme={null} { "success": true, "message": "Documents submitted", "data": {} } ``` **There is no attach step, and no draft.** The draft window is the upload step: an upload is durable and readable back, so collect proof over days — before the payment settles, if you have it — read the set with [List Settlement Documents](/api-reference/v3/b2b/list-settlement-documents), and send the refs when it is ready. This is the same shape [Submit Verification Details](/api-reference/v3/b2b/submit-verification-details) uses for its documents — upload once, reference by id, file in the call that completes the set. ## The request One key. The `ref` of each delivery proof to file against this payment, from [Upload Document](/api-reference/v3/b2b/upload-document). Every ref must be an upload made against **this payment** — a ref from another of your payments reads as unknown, the same answer a made-up one gets. A ref repeated in one call files one document. **`refs` is the whole set, not an addition to it.** A delivery proof you uploaded against this payment and do not name here is deactivated by this call: what you send is what ops sees. Read the set back with [List Settlement Documents](/api-reference/v3/b2b/list-settlement-documents) first if you are unsure what you are holding. **No `doc_type`.** The `type` you uploaded under already decided where the file was stored, so this call has nothing to cross-check — an `invoice` ref is simply not one of this payment's settlement documents and reads as `ERR_B2B_SETTLEMENT_001`. ## What "complete" means here B2B services requires **at least one `delivery_proof`**. That is the whole test — there is no per-type checklist as there is on the goods flow, and many files ride under the single type. Sending `refs: []`, or omitting the key, is a `400`. **The whole call is one transaction.** If any ref is refused, nothing is filed, nothing is dropped, and the set stays `FRESH`. Fix the ref and send the complete list again — you are not left with half a set. **Submitting is final.** The set becomes read-only; a second submit is refused with `ERR_B2B_SETTLEMENT_002`. Read the set back with [List Settlement Documents](/api-reference/v3/b2b/list-settlement-documents) before you call this. ## Errors Every refusal is a `400` in the standard envelope: ```json theme={null} { "success": false, "error": { "code": "ERR_B2B_SETTLEMENT_004", "message": "Upload all required documents before submitting.", "details": "Upload all required documents before submitting." } } ``` | Cause | `code` | What to do | | -------------------------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `refs` is empty or absent | `ERR_B2B_SETTLEMENT_004` | Send at least one `delivery_proof` ref. | | A ref is not one of this payment's delivery proofs | `ERR_B2B_SETTLEMENT_001` | The same answer whether it does not exist, was uploaded against another payment, or was uploaded as an `invoice`. Upload the file against this payment with `type=delivery_proof`. | | The payment is not settled | `ERR_B2B_SETTLEMENT_003` | Wait for [`PAYMENT_SETTLED`](/api-reference/v3/webhooks/payment-settled). | | Already submitted | `ERR_B2B_SETTLEMENT_002` | Nothing to do — the step is done. Read `state` from [List Settlement Documents](/api-reference/v3/b2b/list-settlement-documents) to tell the two apart before calling. | | The payment is not a B2B-services payment | `40360` | B2B goods has no partner-API settlement path. | | 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 refs are the payload, so they are answered for first.** An unknown ref is reported before the payment's own state is judged — a `400` carrying `ERR_B2B_SETTLEMENT_001` does not tell you the payment has settled, only that the ref did not resolve. An empty list, which names no ref, does surface the state: an unsettled payment answers `ERR_B2B_SETTLEMENT_003` rather than `_004`. ## Related Upload each delivery proof and keep its `ref`. Read the set back before locking it. The whole flow, in order. ## OpenAPI ````yaml POST /pg/payments/{payment_id}/settlement/submit/ 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/submit/: post: tags: - B2B Verification summary: Submit post-settlement documents description: >- File a settled B2B-services payment's post-settlement compliance documents and lock the set, in one call. `refs` names files already uploaded through `POST /pg/payments/{payment_id}/documents/` — the same upload-once, reference-by-id shape the verification endpoint uses for its documents. There is no attach step and no draft to keep: an upload is durable and scoped to your merchant account, so you can collect proof over days and hold the refs until the set is ready. No `doc_type` rides the request. Each upload already carries the type it was stored under, and that type is cross-checked against what this flow files. B2B services files one type, `delivery_proof`, and takes many files under it — at least one is required. Resolving, filing and locking are one transaction: if any ref is refused, nothing from the call is filed. After this the set is no longer editable. **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 requestBody: required: true content: application/json: schema: type: object properties: refs: type: array description: >- The `ref` of each uploaded file to file against this payment. Every ref must belong to the calling merchant and must have been uploaded under a type this flow files (`delivery_proof`). A ref repeated in one call files one document. An empty or omitted list is refused as an incomplete set. items: type: string maxLength: 64 example: - '8207383264' - '5512907744' responses: '200': description: Documents submitted. content: application/json: schema: type: object properties: success: type: boolean example: true message: type: string example: Documents submitted data: type: object description: Always an empty object on a write that returns nothing. example: {} '400': description: >- The payment id does not resolve, it has not settled, a ref is unknown or of a type this flow does not file, the list is empty, or the set is already submitted. 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. unknown_ref: summary: A ref is not an upload belonging to this caller value: success: false error: code: ERR_B2B_SETTLEMENT_001 message: Document not found for this payment. details: Document not found for this payment. not_settled: summary: Nothing can be filed before the payment settles value: success: false error: code: ERR_B2B_SETTLEMENT_003 message: >- Documents can only be uploaded after the payment is settled. details: >- Documents can only be uploaded after the payment is settled. incomplete: summary: B2B services needs at least one delivery_proof value: success: false error: code: ERR_B2B_SETTLEMENT_004 message: Upload all required documents before submitting. details: Upload all required documents before submitting. unknown_doc_type: summary: A ref was uploaded under a type this flow does not file value: success: false error: code: ERR_B2B_SETTLEMENT_005 message: Unknown document type. details: Unknown document type. already_submitted: summary: Submitting twice is refused value: success: false error: code: ERR_B2B_SETTLEMENT_002 message: >- Documents have already been submitted and can no longer be changed. details: >- Documents have already been submitted and can no longer be changed. 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 ````