This page covers services only — consulting, software, and everything else in the table below. Physical goods need an HS code and a buyer IEC, which this flow does not collect.
PSPs send
X-Merchant-ID on every call here, naming the sub-merchant the payment belongs to. The purpose codes you may declare come from that sub-merchant’s account, not yours.Do it in this order
There is no pre-payment step here. Everything happens after the money lands. Submit is a single call, not a loop of partial sends. We check the whole set at once and either take it into review or tell you what is wrong with it.Declare what the service was
Every services payment settles under one FEMA purpose code, and you pick exactly one. There is no default and no way to leave it blank.Send the details
Two calls. Upload the invoice first and keep theref it returns, then send that ref alongside the fields.
Uploading the invoice is multipart/form-data:
buyer_address_line_2, buyer_email and buyer_phone are accepted and optional — send them if you hold them, because they are what our team uses to reach the buyer if something needs clarifying.
Submit Services Verification
Full request body, every validation error, and the sandbox test values.
Five things that will bite you
The invoice amount must equal what actually landed. Not approximately — we allow one paisa for rounding and nothing more. If the buyer transferred ₹4,49,500 against a ₹4,50,000 invoice, the submission is rejected until the two agree. Raise a revised invoice for what arrived, or have the buyer send the balance and declare against the full amount once it is there. There is no HS code here. HS codes describe physical goods crossing a border. Services have none, and there is no field for one. Rejected is terminal, and the money goes straight back. A rejection is not a stronger send-back. It closes the payment, and we automatically initiate a full refund to the buyer — you cannot resubmit or correct it. Only a send-back reopens the payment for editing. Read the decision, not just the fact that something came back. Proof of delivery comes after settlement, not before. It’s a separate submission that only opens once the payment reachesSETTLED. Uploading it early is not possible, and holding your settlement waiting to attach it is a mistake people make once.
Editing closes the moment you submit. While a payment is in review, the fields and the invoice are frozen — no corrections, no swapping the file. If you spot a mistake after submitting, wait for the send-back and fix it then.
After it settles: proof of delivery
Once the money has reached you, one thing is still owed: evidence that the service was actually delivered. It sits outside the verification flow — nobody reviews it, and it does not gate your settlement — but it is what backs the remittance if the transaction is ever examined. Upload one or more files underdelivery_proof — a signed acceptance note, a milestone sign-off, a delivery confirmation email, a timesheet. Send what genuinely evidences delivery.
The set locks when you submit it, so upload everything before you do.
Payment statuses
Readverification_status on the payment.
A rejection does not appear in this table. It ends the payment and refunds it, and you learn about it from the refund rather than from a verification status.
Next
Collection Overview
How a payment moves from the buyer’s bank to your account abroad.
Webhooks
Every event, the payload, and how to verify the signature.