Product Guide 17
Fintech AI

Merchant Onboarding: How to Build It

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:

QuestionWhat 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
Who is behind it?Directors, beneficial ownership, antecedents, sanctions
Note

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

#StepIn plain words
1Establish the entityPAN, registration, bank account, CKYCR.
2Check the peopleDirectors, ownership, antecedents, sanctions.
3Decide the pathFull or simplified — and what simplified does not reduce.
4Understand what they sellCategory code, and who sells through them.
5Price the riskRefunds, chargebacks, settlement hold.
6Set up the moneyEscrow, and the transaction it may never touch.
7Monitor against the profileThe obligation that never ends.
8OffboardThe 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 wrongWhyFix
Marketplace settles for unlisted sellersClause in the contract, no feed behind it.Seller roster, reconciled against settlement.
Category declared, never checkedStored as entered.Compare against the site and the catalogue.
Profile is a dropdownOnboarding captured a label.Numbers. Otherwise nothing can depart from it.
One settlement hold for everyoneSimplest to build.Derive from the category's dispute lag.
COD routed through escrowAssumed available.Explicitly not permitted. Build it outside or not at all.
Simplified path treated as lighter liabilityLighter documents read as lighter duty.Background checks and monitoring apply in full.
Agent not recorded against the merchantAgent was a channel, not a field.Record the agent; do due diligence on agents.
Terminated director returns as a new entityNo internal list.Screen against your own offboarding history.
Offboarding releases settlement normallyNo separate path.Hold for the dispute window. Chargebacks arrive for weeks.
PA-CB using one escrowDomestic pattern reused.Three accounts, and FX only with an Authorised Dealer.

Where to go next

Watch out

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.

  1. 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
  2. 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
  3. 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
  4. 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
  5. officialFinancial Intelligence Unit — India — the registration and reporting obligations that apply to non-bank payment aggregators under the PMLA framework. fiuindia.gov.in
  6. officialCentral KYC Records Registry — the registry from which a merchant KYC record is retrieved at onboarding with the merchant’s consent. www.ckycindia.in
  7. 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.
  8. 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.

Nothing is sent from here. The link carries only this page’s title and address.