Skip to main content
POST
Submit post-settlement documents

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.
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, and send the refs when it is ready. This is the same shape Submit Verification Details uses for its documents — upload once, reference by id, file in the call that completes the set.

The request

One key.
string[]
required
The ref of each delivery proof to file against this payment, from 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 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 before you call this.

Errors

Every refusal is a 400 in the standard envelope:
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.

Upload Document

Upload each delivery proof and keep its ref.

List Settlement Documents

Read the set back before locking it.

B2B Services Verification

The whole flow, in order.

Authorizations

X-Client-ID
string
header
required

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-Client-Secret
string
header
required

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-Merchant-ID
string
header
required

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-API-Version
string
header
required

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

payment_id
string
required

UID of the settled B2B-services payment the documents belong to.

Body

application/json
refs
string[]

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.

Maximum string length: 64
Example:

Response

Documents submitted.

success
boolean
Example:

true

message
string
Example:

"Documents submitted"

data
object

Always an empty object on a write that returns nothing.

Example: