Skip to main content
POST
Upload a supporting document

Overview

Uploads one supporting file for a payment’s verification and answers with a ref. You then send that ref under the document’s checklist code when you submit verification details:
Upload each file as it arrives. Nothing has to be held back until the set is complete — the ref is what binds a file to a checklist item, and it does that later, on the submit.
Two calls, not one. Uploading a file does not answer a requirement; it stores a file. The requirement is answered when the submit names the ref under a code. That separation is what lets a payer send a passport on Monday and a letter of admission on Thursday without you tracking a half-built request.

The request

multipart/form-data, two parts: The path resolves the payment before anything is stored, under the same ownership rules as the verification endpoint: your own payments, and your sub-merchants’.

Document types

type must be one of these. They are the codes the checklists ask for, so the value you upload under is the same value you submit under:
Read the types you actually need from Get Verification Requirements rather than mapping this table into your code. It is the complete set any checklist can ask for, not the set this payment asks for, and it grows as the regulatory matrix is revised.

The file

Validated on upload, so a bad file fails here rather than at submit time.

The response

201, with the ref:
string
required
The upload’s identifier. Send it as documents[].ref on the verification submit.The stored file is scoped to your merchant account, not to the payment in the path — so a ref stays valid across a retried attempt or a recurring installment, and a ref that is not yours reads as unknown rather than as someone else’s file.
string
required
Echoes the type you sent.

Replacing a document

Uploads are immutable. To replace one, upload the file again — you get a new ref — and submit that ref under the same code. The newer row supersedes the older without discarding it.

Waiving instead of uploading

Some documents may be discharged with a reason instead of a file. Those carry "waivable": true in the requirements; for them you skip this endpoint entirely and send a waiver_reason on the submit:
A waiver on a document that is not waivable is a 400. See Submit Verification Details.
POST /pg/lrs/documents/ predates this route and still works as an alias over the same implementation. New integrations should use the payment-scoped path.

Get Verification Requirements

Which documents this payment actually needs.

Submit Verification Details

Where the ref is bound to a checklist code.

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 payment the document is for.

Body

multipart/form-data
file
file
required

The document file. Allowed extensions: pdf, png, jpg, jpeg, docx, xlsx, csv. Maximum 10 MB. Password-protected PDFs are rejected.

type
enum<string>
required

Document type — one of the codes the checklists ask for, so the value you upload under is the value you submit under. Read the ones this payment actually needs from Get Verification Requirements rather than mapping this list into your code: it is the complete set any checklist can ask for, and it grows as the regulatory matrix is revised.

Available options:
offer_letter,
passport,
student_id_or_visa,
student_id,
fee_invoice,
passenger_list,
traveller_passports,
traveller_visas,
ticket,
invoice,
relationship_declaration
Example:

"offer_letter"

Response

Document uploaded.

success
boolean
Example:

true

message
string
Example:

"Document uploaded"

data
object