Skip to main content
POST
Upload Payment Verification Details

Overview

The Upload Payment Verification Details endpoint allows you to upload payment verification details for a payment. This updates the associated order with the provided information and uploads the verification details to the payment gateway. Use this endpoint when you receive a PAYMENT_DETAILS_MISSING webhook and need to supply missing verification fields.

Test Data

When testing this API in the sandbox environment, you must use the following specific test values for the API to work correctly:
  • buyer_name: John
  • buyer_postal_code: 560034
  • product_description: This is a test product for test purpose.

📚 Test Data Reference

View all test data – Complete test data guide for sandbox testing.

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

uid
string
required

UID of the payment for which to upload verification details.

Body

application/json

Verification details for the payment's order. Every request rewrites the order's verification fields rather than patching them — a field left out is cleared — so send the complete set on each call. purpose_code and business_model are NOT accepted here: send them together in fields on POST /pg/payments/{payment_id}/verification/.

buyer_name
string
required

Name of the buyer/importer.

Maximum string length: 255
type_of_goods
enum<string>
required

Type of goods.

Available options:
GOODS,
PHYSICAL_GOODS,
DIGITAL_GOODS,
SERVICE
product_description
string
required

Description of the product/goods.

invoice_number
string
required

Invoice number.

Maximum string length: 255
buyer_postal_code
string
required

Buyer's postal/ZIP code.

Maximum string length: 10
buyer_address
string

Buyer's address. Accepted but not enforced. This request replaces the order's verification fields rather than patching them, so omitting it clears any address already on the order.

hs_code
string

HS code of the goods. Required only when type_of_goods is PHYSICAL_GOODS; optional for GOODS, DIGITAL_GOODS and SERVICE.

Maximum string length: 30

Response

Payment verification details uploaded successfully; order updated.

success
boolean
message
string
data
object

Relayed from the payment gateway, so the entries vary by rail: production Cashfree returns the gateway's own document records (shown here), while the sandbox SIMULATOR gateway returns plain order-field names as strings. Read the payment's state from the VERIFICATION_NEEDED webhook or Get Verification Requirements rather than from these arrays.