Skip to main content

Command Palette

Search for a command to run...

Aadhaar Verification for Merchant & Seller Onboarding

Aadhaar Verification

Updated
9 min read
Aadhaar Verification for Merchant & Seller Onboarding
N
Fintech Enthusiast covers topics like GST, Financial Statement & Related content.

A seller joining Flipkart, Meesho, or a regional grocery aggregator is not the same as a salaried employee joining a company. There is no HR file, no offer letter, no payslip trail. What there is: a person who wants to list products, collect payments, and move money through the platform's settlement system from day one.

That financial exposure is what makes Aadhaar verification non-negotiable in merchant onboarding. RBI's payment aggregator guidelines require platforms that handle merchant settlements to complete full KYC before allowing payouts. For most platforms, Aadhaar verification is where that process starts.

The other reason is speed. A seller in Surat or Jaipur registering on a quick-commerce app is not going to courier identity documents to a verification office. The check has to happen on a phone, in minutes. Aadhaar verification built around UIDAI's authentication infrastructure is the only method that works at that pace without sacrificing accuracy.

What Merchant Verification Actually Covers

Aadhaar verification tells you who the merchant is. That is it. Whether their GST registration is real, whether their bank account matches their business name, whether they have a clean payment record — none of that comes from Aadhaar. Platforms that treat a passed Aadhaar check as a full business verification are leaving serious gaps open.

What Aadhaar verification covers in a merchant onboarding context:

  • Identity confirmation (name, date of birth, gender, address as registered with UIDAI)

  • Liveness check when biometric authentication is used

  • Address validation at state and district level

  • Duplicate identity detection across seller accounts

What platforms layer on top of Aadhaar verification:

  • GST registration status check

  • PAN verification and income tax filing status

  • Bank account verification via penny drop

  • Business registration document check (for company sellers)

  • Court record or credit history check for high-value seller categories

Stopping at Aadhaar alone means the platform knows who the seller is but nothing about whether their business credentials are real. Regulated platforms, especially payment aggregators under RBI oversight, cannot stop there.

How Aadhaar Verification Works in a Merchant Onboarding Flow

In most Indian platforms, the seller opens an app or a web portal, types in their Aadhaar number, and an OTP hits the phone number they registered with UIDAI. Done in under a minute on most days.

What runs underneath is the Aadhaar Verification API, sitting between the platform's onboarding system and UIDAI's servers. That connection does not go directly to UIDAI. It routes through a licensed Authentication User Agency (AUA) or KYC User Agency (KUA). The platform cannot legally bypass that intermediary. What comes back through the Aadhaar Verification API call is name, date of birth, gender, address, and a photo if the platform is running eKYC.

For merchant onboarding, the address field carries more weight than it does in gig worker verification. Where a seller is registered often determines their GST filing state and tax jurisdiction. If UIDAI's address record does not line up with the business address the seller submitted, the account gets held for manual review before going live.

UIDAI Compliance Rules That Apply to Merchant Platforms

Once a platform runs Aadhaar verification during merchant onboarding, it owns the UIDAI compliance obligations. That does not transfer to the seller, and it does not transfer to the BGV vendor either.

Key rules:

  • Consent must be recorded. Before any Aadhaar authentication fires, the merchant has to give clear, informed consent. Ticking a checkbox buried in the terms page does not count. The consent record has to survive an audit.

  • Full Aadhaar numbers cannot be stored. Only the last four digits can appear anywhere in the platform's system. The complete 12-digit number sitting in a database without encryption is a UIDAI violation, full stop.

  • Authentication must go through a licensed AUA or KUA. A platform routing Aadhaar checks through an unlicensed vendor is not compliant, regardless of the results those checks return.

  • Data retention has a limit. Under the DPDP Act, Aadhaar-linked data collected during onboarding cannot be kept indefinitely. When the seller's account is closed or inactive beyond a defined period, the data needs to go.

  • VID is a real option. Some merchants will not share their raw Aadhaar number, and they do not have to. A Virtual ID gives them a temporary 16-digit proxy that works just as well. Most licensed Aadhaar Authentication API integrations handle VID natively.

The Tech Side: Aadhaar Authentication API in a Merchant Stack

The moment a seller submits their identity document during onboarding, the platform's backend sends a call to the Aadhaar Authentication API through its AUA or KUA. For OTP-based flows, a result comes back in a few seconds. That matters when a platform is processing hundreds of new seller accounts at the same time across multiple cities.

What the Aadhaar Authentication API returns in a standard eKYC call:

  • Name as registered with UIDAI (cross-checked against the submitted name)

  • Date of birth (confirms legal trading age)

  • Gender (stored for account records)

  • Address (state and district) (matched against submitted business address)

  • Photo (eKYC only) (used for face-match against a live selfie)

  • Authentication result (pass or fail, with a UIDAI reason code on failure)

First-attempt failure rates are higher than most product teams expect. A seller running a phone number they bought three years ago and never registered with UIDAI will fail the OTP step even if everything else about them is clean. Same for someone whose Aadhaar account got locked for unrelated reasons. 

Auto-rejecting on the first failure means turning away real sellers over a fixable problem. The flow needs a manual review path for those cases, not a hard stop.

City-Level Merchant Onboarding Patterns

Across Mumbai, Bengaluru, Delhi NCR, Hyderabad, Pune, and Chennai, Aadhaar-based merchant onboarding has been running long enough that sellers in these cities walk in expecting to do everything from a phone. The infrastructure is set, the BGV vendors are plugged in, and compliance teams have dealt with enough audits to know what the paperwork needs to look like.

Tier 2 and Tier 3 cities are where the real volume is growing. Sellers in Coimbatore, Indore, Vadodara, Ludhiana, and Bhopal are signing up for national marketplaces at a pace that makes any manual process unworkable. Aadhaar data quality in these cities is often better than in the metros. Rural enrollment campaigns in Tamil Nadu, Gujarat, and Madhya Pradesh ran more thoroughly than many urban ones, and the UIDAI records from those drives are cleaner and more recently updated.

The problem in smaller cities is not bad documents. It is mobile number linkage. A seller in a small town might be using a SIM they never formally linked to their Aadhaar. OTP-based verification will fail for that person even though their identity is perfectly fine. Any platform relying only on OTP authentication will run into this repeatedly and needs an offline XML or VID-based fallback written into the onboarding flow.

Common Gaps in How Platforms Run Merchant Aadhaar Verification

Most problems come from process design, not from the technology itself.

  • Skipping Aadhaar re-verification when a dormant seller account is reactivated

  • Treating a passed Aadhaar check as complete KYC for regulated payment flows

  • Using a BGV or KYC vendor that is not itself a licensed AUA or KUA with UIDAI

  • Storing unmasked Aadhaar numbers in seller management databases without encryption

  • Not offering a VID or offline XML path for sellers who fail OTP authentication

  • Failing to log consent in a format that holds up during a regulatory review

Every item on that list gets fixed before launch or becomes a problem after one. Product teams optimizing for registration conversion and compliance teams building for audit readiness are often in different meetings. They should not be. A seller account that cleared onboarding through a non-compliant KYC flow is a regulatory liability sitting on the platform's books, and it does not get less risky over time.

Frequently Asked Questions

Is Aadhaar verification mandatory for all merchant onboarding in India? 

Depends on what the platform does with money. Any platform processing merchant settlements under RBI's payment aggregator framework has to complete full KYC, and in practice that means Aadhaar-based verification, before a single payout goes out. Pure marketplace models without direct payment settlement have more room, but most have adopted the same standard anyway because it is easier to be audit-ready from the start than to retrofit compliance later.

What if a merchant's Aadhaar address does not match their business address? 

It goes to manual review, not automatic rejection. Plenty of legitimate sellers run their business from a location they moved to after their last Aadhaar update. The compliance team looks at the mismatch, asks for a business registration document or a recent utility bill, and clears it from there. The Aadhaar check itself passed. It just cannot answer the address question by itself.

Can a company seller use Aadhaar for business KYC? 

Aadhaar only works for individuals. When a company registers as a seller, the authorised signatory goes through Aadhaar verification as a person. The business entity side of the KYC covers the company's registration certificate, GST documents, and director identification separately. The Aadhaar Verification API call ties to the human signing the agreement, not to the company name on the paperwork.

How does the Aadhaar Authentication API handle high seller registration volumes? 

It handles load well when the AUA integration is set up with proper rate limits and the platform has coordinated throughput capacity for high-volume windows like festive season launches. The API on UIDAI's side is built for scale. Where platforms run into trouble is queue management on their own side when a spike hits and the onboarding system has not been load-tested at that volume.

What happens when a seller fails Aadhaar authentication? 

Route it to a review queue, not a rejection screen. Most failures trace back to three things: a mobile number not linked to the Aadhaar, a locked UIDAI account, or a network drop on UIDAI's end. None of those mean the seller is fraudulent. The seller can unlock a locked account through UIDAI's self-service portal. For people who cannot receive OTPs at all, offline XML verification or VID-based authentication are the standard routes out.