Skip to main content
POST
Mark payments as settled (sandbox)
Sandbox only. This endpoint returns 400 in production. It operates only on transactions created through the Simulator payment gateway — a real Cashfree or ICICI transaction is rejected.Your account must be assigned the Simulator gateway in sandbox. Contact your EximPe integration manager if it isn’t.

Overview

Settlement is the one part of the payment lifecycle you cannot trigger yourself: it happens when money actually moves, on the bank’s schedule. That makes settlement webhook handlers and reconciliation logic awkward to test. This endpoint settles payments on demand. It applies a simulated fee schedule, creates a real settlement record, and fires PAYMENT_SETTLED exactly as production would.

How the amounts are calculated

Per payment, against the order amount: The settlement totals are the sums across the batch:
  • settlement_amount = Σ payment net − Σ refund amounts − Σ chargeback amounts
  • settlement_charges = Σ platform fees
  • settlement_gst = Σ GST
Refunds and chargebacks carry no fee of their own. They debit the total at their full amount, mirroring the real settlement pipeline.
These are simulator figures, not your contracted rates. Use them to check that your reconciliation arithmetic holds, not to predict production settlement amounts.

Side effects

Each payment in the batch gets settlement_status = SETTLED and its per-payment breakdown populated — fee, tax, net, forex rate, settlement currency — in the same shape a real settlement produces.
The batch is atomic. If any payment fails validation nothing is written, so a partially-settled batch is not a state you can reach.

What each payment must satisfy

A payment is rejected unless it is:
  1. Yours — belonging to your merchant account or one of your sub-merchants
  2. On the Simulator gateway
  3. CAPTURED
  4. Not already settled — a payment belongs to exactly one settlement
A UID owned by a different merchant is indistinguishable from one that does not exist. Both simply fail to resolve.

Reading validation errors

Unresolvable UIDs come back grouped by category, with the first failure in each. Empty categories return [].
Because only the first failure per category is reported, fix them one at a time or pre-validate your list. State problems name the offending UID directly:

Testing your settlement handler

1

Capture a payment

Create an order and complete it on the Simulator gateway so the payment reaches CAPTURED.
2

Settle it

POST /pg/settlements/mark-settled/ with that payment’s UID.
3

Receive the webhook

Your endpoint gets PAYMENT_SETTLED carrying the new settlement.
4

Reconcile

GET /pg/settlements/{settlement_id}/ and check your records agree.
To exercise a net settlement, create a refund and a chargeback against the payment first, then pass all three UIDs in one call and confirm settlement_amount equals the payment net minus both.

Gotchas

"941.00", not 94100. Parse as decimal — never as a float, for money.
Re-settling returns is already settled. Create a fresh payment for each settlement test.
Refunds and chargebacks carry no fee. They only reduce settlement_amount.
Both simulator endpoints are POST.

Set Refund Status

Drive a refund to any status on demand.

PAYMENT_SETTLED

The event this endpoint fires.

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.

Body

application/json
payment_uids
string[]
required

Payments to settle. Each must be CAPTURED, on the Simulator gateway, yours, and not already settled.

Minimum array length: 1
Example:
refund_uids
string[]

Refunds to fold into the same settlement. Each debits the total at its full amount and carries no fee of its own.

Example:
chargeback_uids
string[]

Chargebacks to fold in. Same treatment as refunds.

Example:

Response

Settlement created and the payments marked settled.

success
boolean
Example:

true

message
string
Example:

"Payments marked as settled successfully"

data
object