The five steps
1
Create your merchants
PSPs create a sub-merchant for each business they collect for. Wait for approval before collecting.Create Merchant · Merchant Approved webhook
2
Set up a way to get paid
Today that is a virtual account: create one and give the buyer its account number and IFSC.Virtual Bank Accounts
3
The buyer pays
We create a payment and send you a webhook. Its status is
ACTION_REQUIRED, because we do not have the compliance details yet.4
Send the compliance details
Tell us who paid, what for, and attach the documents. The status becomes
IN_REVIEW.For LRS payments we tell you exactly what is needed, you send it, and it completes itself. See LRS Verification.5
Get your money
We convert the amount to be settled at the exchange rate on the settlement date and send it to your account abroad. Status becomes
SETTLED. Our fee, the GST on it, and any tax were paid by the buyer on top, so the whole amount reaches you.What it costs you · Settlement APIs · Payment Settled webhookHow the buyer pays
Money can reach you by more than one Indian payment method. Today that means a virtual account — an Indian account number we issue for you, which your buyer pays into by NEFT, RTGS, or IMPS, exactly as they would pay any local supplier. Give them two things: the account number and the IFSC.Virtual Bank Accounts
Create one, share it, and handle the money arriving.
The method only decides how the money arrives. Once a payment exists it behaves the same way whichever route it came by — same statuses, same webhooks, same compliance step, same settlement. So everything from step 3 onwards is unaffected by which method you use, and adding a method later does not change the integration you have already built.
Who is who
The two amounts
These are not the same number, and mixing them up is the most common way a payment stalls.
Ask for the amount to be collected. Declare the amount to be settled. Collect the smaller of the two and the payment sits short until the buyer tops up.
Payment statuses
Settlement is reported separately, by the settlement APIs and
PAYMENT_SETTLED.
When things go wrong
The buyer paid too little. The payment waits, and theoutstanding entry on the event names the shortfall. Either have the buyer transfer the difference and link that credit as a top-up with linked_payment_id, or declare a smaller principal for what actually arrived and submit again.
A document was rejected. We tell you exactly what is wrong. Fix only that item and send it again.
The money came from someone else’s account. This applies to LRS payments only. The name on the sending account did not match the PAN you gave us, so the payment stays in action_required with reason: SENDER_NAME_MISMATCH. Either we refund it and the buyer pays again from their own account, or you send us the PAN of whoever actually paid — the payment then settles against that person and counts against their LRS limit.
You need to refund. Refunds go back to the buyer’s own account. You can refund part of a payment, more than once. If your balance does not cover it, the call fails — collect more and try again.
Where refund money comes from. A refund is netted against your upcoming settlements. We hold a balance for each merchant, and the refund comes out of money we have not settled to you yet. If that balance is too small the call is rejected, so retry once you have collected more.
Next
Set up collection
Create a virtual account and take your first payment.
Send compliance details
Read what the payment needs, send it, repeat until nothing is left.