A step-by-step guide to onboarding merchants as a payment aggregator in India. Eight stages, the options at each one, exactly how each step connects to the next, real costs, and what breaks. Written for someone who has not built this before.
Verified September 2026Free · No signupOfficial sources only
BeginnerStart here. No prior knowledge assumed.
How to use this page
This page walks you through building one thing: the system that decides whether to let a business
accept payments through you, and keeps deciding after you have said yes.
Merchant onboarding is not customer KYC with a company name in the field. You are
not verifying that a person is who they claim; you are assessing whether a business is what
it says it is, what it will sell, how often it will refund, and whether its failure becomes your
loss.
Watch out
The rulebook was consolidated a year ago and most integration guides predate it. The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025, issued 15 September 2025, replaced a decade of scattered circulars with one Master Direction covering PA-O (online), PA-P (physical and proximity, brought into scope for the first time) and PA-CB (cross-border). Merchants onboarded before 31 December 2025 had to be brought into compliance within a year of the Direction — which for most aggregators meant a large-scale re-onboarding exercise rather than a policy update.
Four questions, and only one is customer KYC
Four questions, and only the first resembles customer KYC:
Question
What answers it
Does this business exist?
Registration, PAN, bank account, CKYCR record, a real address
What does it actually sell?
Website, catalogue, category code — and whether the three agree
What will it cost me?
Refund and chargeback profile of that category, settlement exposure
The asymmetry that shapes the whole build: in customer KYC a bad actor costs you one account. In merchant onboarding a bad actor takes money from your other customers, and you are the one who settles the disputes. A fraudulent merchant is a liability that arrives as hundreds of chargebacks weeks later, after the settlement has left your escrow. That is why the Directions push responsibility onto the aggregator rather than the acquiring bank.
What this is not:
Not a form. The decision continues after go-live. Step 7.
Not finished at the merchant. Step 4 is the one that surprises people.
Not lighter because the merchant is small. Step 3.
The whole journey, in one table
#
Step
In plain words
1
Establish the entity
PAN, registration, bank account, CKYCR.
2
Check the people
Directors, ownership, antecedents, sanctions.
3
Decide the path
Full or simplified — and what simplified does not reduce.
4
Understand what they sell
Category code, and who sells through them.
5
Price the risk
Refunds, chargebacks, settlement hold.
6
Set up the money
Escrow, and the transaction it may never touch.
7
Monitor against the profile
The obligation that never ends.
8
Offboard
The step nobody builds until they need it.
Note
Steps 4, 7 and 8 are where this diverges from every other onboarding build on this site, and they are the three that a KYC vendor will not sell you. Steps 1 to 3 are verification and the market is mature. Nobody sells you sub-merchant visibility, profile-based monitoring, or a clean way to remove a merchant whose money you are still holding.
IntermediateBuild it. Pipelines, tools and working code.
Steps 1 to 3 — entity, people, and which path
Steps 1 and 2 — the entity and the people
Customer due diligence on a merchant follows the KYC Master Direction, and the Directions add two
specific obligations at onboarding: retrieve the merchant's KYC record from the Central KYC
Records Registry with their consent, and conduct a background and antecedent
check.
The CKYCR step is worth doing properly rather than treating as a box. A record that already exists
tells you the entity has been verified elsewhere; a record that conflicts with what the
merchant has given you is the most useful signal available at onboarding and it is free.
On the people: directors and beneficial ownership, sanctions and adverse media, and — the one
most often skipped — whether these individuals appear behind a merchant you have already
terminated. An internal check against your own offboarding history catches more than any
external list.
Step 3 — the simplified path, and what it does not simplify
The Directions permit a lighter onboarding process for small merchants: domestic annual
turnover not exceeding ₹40 lakh, or export turnover not exceeding ₹5
lakh. That path is PAN or Form 60 verification, Contact Point Verification of
the business premises, and one certified officially valid document of the proprietor or authorised
signatory.
Watch out
Simplified documentation is not simplified responsibility. Background checks and ongoing monitoring still apply in full. And where a non-bank aggregator uses designated agents to perform digital KYC, it must record the agent who assisted each merchant and carry out due diligence on the agents themselves. The lighter path opens a segment that was genuinely hard to serve profitably — and it moves the risk into agent quality, which is a network you now have to train, monitor and answer for. The documentation got lighter. The liability did not move.
Steps 4 to 6 — what they sell, who sells through them, the money
Steps 4 to 6 — what they sell, who sells through them, and the money
Python — steps 4 to 6, what they sell, who sells through them, and the money
# STEP 4. WHAT THEY SELL -- AND WHO SELLS THROUGH THEM.
# The requirement most integration guides omit entirely:
#
# "A PA shall ensure that a marketplace onboarded by it does not accept
# payments for a seller not onboarded on to the marketplace's platform."
#
# You are answerable for people you never onboarded. If your merchant is a
# marketplace, its sellers are inside your perimeter.
def marketplace_controls(merchant, platform):
if not merchant["is_marketplace"]:
return None
return {
# Contractual: the marketplace must not collect for unlisted sellers.
"contract_clause_required": True,
# Operational: you need a way to SEE this, not just a promise.
"seller_list_feed": platform.seller_roster_endpoint, # or periodic file
"reconcile_settlements_to_roster": True,
# The detection signal: money settling to a seller who is not listed.
"alert_on": "settlement_to_unrostered_seller",
"escalation": "suspend_marketplace_settlement, not just the seller",
}
def category_consistency(merchant):
"""Three sources should agree. When they do not, that IS the finding."""
declared = merchant["declared_mcc"]
site = classify_from_site(merchant["url"]) # what it actually sells
catalogue= classify_from_catalogue(merchant["items"])
agree = declared == site == catalogue
return {"agree": agree, "declared": declared, "observed": (site, catalogue),
# A merchant declaring a low-risk code while selling a high-risk
# product is not a data-entry error. It is the oldest trick here.
"action": "onboard" if agree else "manual_review"}
# STEP 5. PRICE THE RISK BEFORE YOU PRICE THE MERCHANT.
def settlement_terms(merchant, history):
cat = merchant["mcc"]
return {
# Longer hold for categories that refund late: travel, events,
# pre-order, anything delivering weeks after payment.
"settlement_hold_days": history.p95_dispute_lag(cat),
"rolling_reserve_pct": history.chargeback_rate(cat) * SAFETY,
# The exposure is not the transaction. It is everything unsettled
# when the merchant stops answering the phone.
"max_exposure": estimate_unsettled_peak(merchant),
}
# STEP 6. THE ESCROW, AND THE TRANSACTION IT MAY NOT TOUCH.
ESCROW_RULES = {
"separate_account": "scheduled_commercial_bank_in_india",
"no_commingling_with_pa_operating_funds": True,
# Explicit in the Directions and frequently missed:
"cash_on_delivery": "NOT PERMITTED through the escrow account",
# PA-CB: three accounts, not one.
"pa_cb_accounts": ["domestic_escrow", "inward_collection", "outward_collection"],
"pa_cb_per_transaction_cap_inr": 2_500_000, # Rs 25 lakh
"fx_counterparty": "authorised_dealer_only",
}
# WHAT TO CHECK
# [ ] if the merchant is a marketplace, you can SEE its seller roster. A
# contract clause with no feed behind it is not a control
# [ ] declared category is checked against the site and the catalogue, not
# just stored
# [ ] settlement hold derives from the category's dispute lag, not from a
# single default applied to everyone
# [ ] your exposure number is unsettled funds at peak, not average ticket
# [ ] Cash-on-Delivery never routes through the escrow account
# [ ] PA-CB: three accounts, and no FX with anyone but an Authorised Dealer
# [ ] the agent who onboarded each merchant is recorded against that merchant
THE finding, and it is what makes this different from every other onboarding build:you are answerable for people you never onboarded.
The Directions require that a payment aggregator ensure a marketplace it has onboarded does
not accept payments for a seller who is not onboarded onto that marketplace's platform. Read
that as an engineering requirement rather than a legal one and it changes the build: you need
visibility of your merchant's sellers, which means a roster feed and settlement
reconciliation against it, not a clause in a contract.
It is the mechanism behind a recognisable fraud — a legitimate marketplace with light
controls becomes a payment channel for sellers who could never have been onboarded directly. The
aggregator sees one compliant merchant and settles money for dozens of businesses it has never
assessed.
Note
The detection signal is settlement, not onboarding. You will not catch this at the front door, because the marketplace passes every check. You catch it by reconciling settlements against the seller roster and alerting on money moving to a seller who is not on it — and by escalating to the marketplace rather than the individual seller, because the seller was never your counterparty.
The second finding is smaller and catches people constantly: the escrow account may not be
operated for Cash-on-Delivery transactions. That is explicit, and it removes a flow many
Indian merchants assume is available. Build the COD path outside the escrow or do not offer it.
Steps 7 and 8 — monitoring, and offboarding
Step 7 — monitoring against the profile
The obligation does not end at onboarding. The Directions require the aggregator to
monitor transactions subsequently undertaken by merchants to ensure these are in line with
the merchant's business profile.
That phrase — in line with the business profile — is the whole design brief.
It means you must have recorded a profile specific enough to be departed from, which most onboarding
forms do not: expected monthly volume, average ticket, category, customer geography, refund rate.
What a departure looks like in practice: volume rising by an order of magnitude in a week; average
ticket moving sharply in either direction; transactions from geographies the merchant does not serve;
a refund rate that jumps; card testing, visible as a burst of small authorisations with a high failure
rate.
Watch out
A profile recorded as a dropdown cannot be departed from. If onboarding captures “retail” and nothing else, every subsequent transaction is in line with the profile by definition, and the monitoring obligation is met on paper and not at all in fact. Capture numbers at onboarding — expected volume, expected ticket, expected geography — and treat the merchant’s own estimate as the baseline. A merchant who wildly under-declares their volume has told you something at the moment they told you.
Python — steps 7 and 8, profile departure and the exit nobody builds
from datetime import timedelta
# STEP 7. "IN LINE WITH THE MERCHANT'S BUSINESS PROFILE."
# That phrase is the design brief. It needs a profile specific enough to be
# departed from -- which a dropdown is not.
def capture_profile(application):
# Ask at onboarding, before the merchant has reason to be careful.
p = {
"expected_monthly_volume": application["declared_volume"],
"expected_avg_ticket": application["declared_ticket"],
"expected_geographies": application["declared_markets"],
"expected_refund_rate": application["declared_refunds"],
"mcc": application["category"],
}
assert all(v not in (None, "", []) for v in p.values()), \
"a profile with blanks cannot be departed from"
return p
def profile_departure(window, profile):
# Each of these is a different fraud, not one anomaly score.
flags = []
if window.volume > profile["expected_monthly_volume"] * 10:
flags.append("volume_spike") # laundering, or a lie at onboarding
if window.avg_ticket > profile["expected_avg_ticket"] * 5:
flags.append("ticket_inflation") # bust-out forming
if window.small_auth_failure_rate > 0.5:
flags.append("card_testing") # stolen-card validation
if set(window.geographies) - set(profile["expected_geographies"]):
flags.append("unexpected_geography")
if window.refund_rate > profile["expected_refund_rate"] * 3:
flags.append("refund_abuse")
return flags
# STEP 8. OFFBOARDING. NOBODY BUILDS IT UNTIL IT IS URGENT.
def offboard(merchant, ledger, policy, watchlist):
ledger.stop_new_transactions(merchant) # first, and immediately
# Do NOT release on the normal cycle. Chargebacks arrive for weeks.
ledger.freeze_settlement(
merchant, until=now_ist() + timedelta(days=policy["dispute_window_days"]))
# The DIRECTORS, not the entity. The same people return under a new name.
watchlist.add_people(merchant["directors"], reason=merchant["termination_reason"])
return {
"notified_with_reason": True,
"record_retained": True, # a terminated merchant complains
# Settle this in policy BEFORE you need it: the merchant's customers
# are owed refunds out of money you are holding.
"customer_refund_position": policy["terminated_merchant_refunds"],
}
# WHAT TO CHECK
# [ ] the profile has NUMBERS. A category label makes every transaction
# compliant by definition and the obligation unmeetable
# [ ] each departure type routes differently. Card testing is an incident;
# a volume spike is a review
# [ ] offboarding freezes settlement rather than releasing it on schedule
# [ ] the DIRECTORS go on the internal list, not the company
# [ ] the refund position for a terminated merchant's customers is decided
# in policy, not improvised by whoever is on shift
# [ ] the full record survives termination
Step 8 — offboarding
Nobody builds this until they need it, and by then it is urgent and the money is already in
motion.
What it has to do: stop new transactions immediately; hold settlement for
the dispute window, not release it on the normal cycle; keep the funds available for
chargebacks that will arrive for weeks; notify the merchant with a reason;
preserve the entire record, because a terminated merchant is the one most likely to
generate a complaint or a legal question; and add the directors to your internal list
so the same people cannot return under a new entity.
And the awkward part, which is a policy decision rather than an engineering one: the
merchant's customers are owed refunds from money you are holding. Decide that position before
you need it.
What it costs
Merchant onboarding — what it costs
Verified September 2026
Verification stackdirect
PAN, GST, bank account, registration, director and beneficial ownership checks, sanctions and adverse media. Per merchant, and cheap. See Getting Access for which of these are self-serve today.
Contact Point Verificationdirect
A physical visit to the business premises. Required on the simplified path, and the one component that does not scale with software — it is a person, in a place, on a day.
CKYCR retrievaldirect
Small per lookup. Worth doing for the conflict signal rather than the record — a CKYCR entry that disagrees with what the merchant gave you is the cheapest finding at onboarding.
Website and catalogue classificationdirect
Automated category checking against what the merchant declared. Usually built rather than bought, and it is where a mis-declared category is actually caught.
Sub-merchant visibilityindirect
The line nobody budgets. If you onboard marketplaces, you need their seller rosters and settlement reconciliation against them. This is integration work per marketplace, not a vendor product.
Ongoing monitoringdirect
Transaction monitoring against each merchant's recorded profile, indefinitely. Scales with merchants, not with revenue, which is why it is the line that hurts in a long-tail book.
Manual reviewdirect
Category mismatches, profile departures, and every simplified-path exception. Size it against your onboarding volume, not your headcount budget.
Getting it wrongindirect
A fraudulent merchant is chargebacks against money already settled, plus the regulatory position that due diligence was yours. Non-compliant merchants had to be remediated or re-onboarded under the 2025 Directions, which for large books meant outreach, re-documentation and offboarding the non-responsive — with real revenue attached.
Where to buy these: Fraud Risk Build Sheet names every tool with its unit cost. Getting Access covers which ones you can sign up for today, which need a sales call, and which are licensed.
Note
The number worth computing before anything else: what share of your merchant book is a marketplace, and for how many of those can you currently see the seller list? If the first number is material and the second is near zero, sub-merchant visibility is your largest compliance gap and it is invisible in every dashboard you own.
AdvancedShip it. Failure modes, thresholds and evidence.
Three versions you could build
Verification only
Build: PAN and registration → bank account penny-drop → CKYCR retrieval
→ director and sanctions screening → approve or decline.
You get: a defensible front door and no view of what happens afterwards.
Adequate only if your merchants are simple businesses selling their own goods, and
you should know which of yours are not.
Verification plus profile
Build: the above, plus category checked against the site and catalogue → a
numeric business profile captured at onboarding → settlement terms derived from the category's
dispute behaviour → monitoring against that profile → a working offboarding path.
Trade: more onboarding friction and materially less exposure. The
offboarding path is the part you will be glad of.
The marketplace case
Build: the above, plus seller rosters from every marketplace merchant, settlement
reconciliation against those rosters, alerting on settlement to an unrostered seller, and escalation
to the marketplace rather than the seller.
It breaks when: the marketplace obligation is met with a contract clause and no
feed. A promise you cannot verify is a promise you will be answering for.
Note
If you take one thing from this page: capture a numeric business profile at onboarding. Expected volume, expected ticket, expected geography. Without numbers, the monitoring obligation is unmeetable by construction — and the merchant's own estimate, given before they have any reason to be careful, is the most honest figure you will ever get from them.
What goes wrong
What goes wrong
Why
Fix
Marketplace settles for unlisted sellers
Clause in the contract, no feed behind it.
Seller roster, reconciled against settlement.
Category declared, never checked
Stored as entered.
Compare against the site and the catalogue.
Profile is a dropdown
Onboarding captured a label.
Numbers. Otherwise nothing can depart from it.
One settlement hold for everyone
Simplest to build.
Derive from the category's dispute lag.
COD routed through escrow
Assumed available.
Explicitly not permitted. Build it outside or not at all.
Simplified path treated as lighter liability
Lighter documents read as lighter duty.
Background checks and monitoring apply in full.
Agent not recorded against the merchant
Agent was a channel, not a field.
Record the agent; do due diligence on agents.
Terminated director returns as a new entity
No internal list.
Screen against your own offboarding history.
Offboarding releases settlement normally
No separate path.
Hold for the dispute window. Chargebacks arrive for weeks.
PA-CB using one escrow
Domestic pattern reused.
Three accounts, and FX only with an Authorised Dealer.
This page is a guide, not a specification. Payment aggregator authorisation and merchant onboarding are governed by the 2025 Directions and by the KYC Master Direction, both of which are amended regularly. Nothing here is legal advice. Build from the notified text your authorisation is granted under, and have your onboarding policy, your escrow arrangements and your marketplace contracts reviewed by qualified counsel.
Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry commentary.
officialReserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 — issued 15 September 2025 (RBI/DPSS/2025-26/141), consolidating the previous circulars into one Master Direction covering PA-O, PA-P and PA-CB. Customer due diligence of merchants under the KYC Master Direction, CKYCR retrieval with merchant consent at onboarding, background and antecedent checks, the requirement that a marketplace onboarded by a PA does not accept payments for a seller not onboarded to its platform, ongoing monitoring against the merchant business profile, escrow with a scheduled commercial bank, the prohibition on operating the escrow for Cash-on-Delivery, the three-account structure and per-transaction cap for PA-CB, and the restriction of foreign exchange dealings to Authorised Dealers. www.rbi.org.in
officialRBI Master Direction — Know Your Customer, 2016 as amended — the customer due diligence standard that merchant onboarding must meet, including officially valid documents, beneficial ownership identification and ongoing due diligence. www.rbi.org.in
officialRBI Directions — simplified merchant onboarding thresholds — the lighter path for merchants with domestic annual turnover not exceeding ₹40 lakh or export turnover not exceeding ₹5 lakh: PAN or Form 60 verification, Contact Point Verification, and one certified officially valid document of the proprietor or authorised signatory — with background checks and ongoing monitoring still applying in full. www.rbi.org.in
officialRBI Directions — use of agents for digital KYC — the requirement that a non-bank payment aggregator record the agent assisting each merchant and carry out due diligence on persons appointed as authorised or designated agents. www.rbi.org.in
officialFinancial Intelligence Unit — India — the registration and reporting obligations that apply to non-bank payment aggregators under the PMLA framework. fiuindia.gov.in
officialCentral KYC Records Registry — the registry from which a merchant KYC record is retrieved at onboarding with the merchant’s consent. www.ckycindia.in
industryLegal and compliance commentary on the 2025 Directions — the practitioner reading of the remediation timeline for merchants onboarded before 31 December 2025, the PA-P authorisation deadline, net worth thresholds of ₹15 crore at application rising to ₹25 crore by the end of the third authorised financial year, and the operational scale of re-onboarding a large merchant book. Interpretation and commentary, not the notified text.
industryVendor and industry material on merchant onboarding practice — category classification, contact point verification at scale and agent network management. Directional; vendor material describes what is sellable rather than what is required.
Checked September 2026. The Directions consolidated a decade of circulars in September 2025 — anything written before then describes a framework that no longer exists.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.