PAN Card Verification API: A Developer’s Integration Guide

PAN verification is probably the most common identity check in Indian fintech. Every lending app, payment gateway, brokerage, and insurance platform needs it. And most of them are doing it the same way - uploading a PAN image, extracting text via OCR, then hitting NSDL to verify the details.

The tricky part isn’t the happy path. It’s handling blurry photos, laminated cards with glare, company PANs vs personal PANs, and the occasional PAN that NSDL says is “deactivated” when the user insists it’s fine.

This guide walks through integrating a PAN card verification API from scratch - what the API returns, how to handle real-world edge cases, and production-ready code you can copy-paste.

What PAN verification actually does

PAN verification is a two-step process:

Step 1: OCR extraction - Upload a PAN card image (photo or scan). The API extracts the PAN number, name, date of birth, and father’s name from the document using optical character recognition.

Step 2: NSDL verification - The extracted PAN number is checked against the NSDL (National Securities Depository Limited) database. NSDL maintains the master registry of all PANs issued in India. The API confirms whether the PAN is valid, matches the name on record, and reports if it’s linked to Aadhaar.

You can also skip OCR and send just the PAN number directly if you already have it - for example, when re-verifying existing customers or processing data from form submissions.

What data you get back

The verification status is the critical field. Here’s what each value means:

• VALID: PAN exists in NSDL’s database and is active.
• INVALID: PAN number format is correct but doesn’t exist in the registry. Could be a typo or a fabricated number.
• DEACTIVATED: PAN was valid but has been deactivated - usually because the holder has a duplicate PAN (only one is allowed per person) or it was flagged for fraud.

PAN 2.0: What changed

In late 2024, the government announced PAN 2.0 - an upgrade to the existing PAN system. Here’s what matters for developers:

QR code on new cards: New PAN cards include a QR code that contains the holder’s details in encrypted form. This doesn’t affect API-based verification (you still verify against NSDL), but if you’re building a scan-based flow, you can extract data from the QR code as an alternative to OCR.

Unified PAN and TAN: PAN 2.0 merges the PAN and TAN (Tax Deduction Account Number) systems under a single platform. For most developers, this doesn’t change how you verify PANs. The existing 10-digit format stays the same.

No mandatory reissue: Existing PAN cards remain valid. Users don’t need to get a new card. Your current integration continues to work without changes.

The bottom line: PAN 2.0 is mostly a backend modernization by the Income Tax Department. Your verification API calls stay the same.

Integration guide

Prerequisites

• A TheVerifico API key (sign up at theverifico.com for 10 free credits)
• A PAN card image in JPG, PNG, or PDF format (for OCR + verify flow)
• Or just the PAN number as a string (for verify-only flow)

OCR + Verification (image upload)

This is the most common flow: your user uploads a photo of their PAN card, and you get extracted data plus NSDL verification in a single API call.

cURL:

curl -X POST https://api.theverifico.com/api/v1/verify/pan \
  -H "Authorizati>\
  -H "C>\
  -F "document=@pan_card.jpg"

Python:

import requests

resp>= requests.post(
    "https://api.theverifico.com/api/v1/verify/pan",
    headers={"Authorizati>"Bearer YOUR_API_KEY"},
    files={"document": open("pan_card.jpg", "rb")}
)

result = response.json()

if result["success"]:
    data = result["data"]
    print(f"PAN: {data['pan_number']}")
    print(f"Name: {data['name']}")
    print(f"DOB: {data['dob']}")
    print(f"Father: {data['fathers_name']}")
    print(f"Aadhaar Linked: {data['aadhaar_linked']}")
    print(f"Status: {result['verification_status']}")
else:
    print(f"Error: {result['message']}")

Node.js:

c>FormData = require('form-data');
c>= require('fs');
c>= require('axios');

c>= new FormData();
form.append('document', fs.createReadStream('pan_card.jpg'));

c>= await axios.post(
  'https://api.theverifico.com/api/v1/verify/pan',
  form,
  {
    headers: {
      'Authorizati>: 'Bearer YOUR_API_KEY',
      ...form.getHeaders()
    }
  }
);

c>, verificati>= resp>.data;
c>.log(`PAN: ${data.pan_number}`);
c>.log(`Name: ${data.name}`);
c>.log(`Status: ${verificati>}`);

Response time

Average: under 500ms for the complete OCR + verification flow. The OCR extraction itself takes about 100-200ms; the NSDL database lookup takes another 200-300ms.

Handling edge cases in production

This is where most integrations break. Here are the real-world issues you’ll encounter and how to handle them.

Blurry or low-quality images

Mobile cameras, especially front-facing ones, often produce blurry images. Laminated PAN cards catch light and create glare patches that make text unreadable.

What happens: OCR accuracy drops. The PAN number might be extracted with one digit wrong, leading to an NSDL “INVALID” response even though the PAN is real.

How to handle it: - Check the OCR confidence score in the response. If it’s below 85%, prompt the user to retake the photo. - Add client-side image quality checks before upload (resolution > 640px, file size > 50KB). - Suggest the user remove the card from the laminate or avoid direct light.

Company PAN vs Personal PAN

PAN cards come in two types: - Personal PAN (4th character is P): Issued to individuals. Returns name, father’s name, DOB. - Company PAN (4th character is C, H, F, A, T, B, L, J, G): Issued to companies, HUFs, firms, trusts, etc. Returns entity name and registration date - no father’s name or DOB.

How to handle it: Check the 4th character of the PAN number to determine the type. If it’s not “P”, adjust your UI - don’t show “Father’s Name” and “Date of Birth” fields for company PANs.

pan_number = "ABCDE1234F"
pan_type = "personal" if pan_number[3] == "P" else "business"

Deactivated PANs

A user submits a PAN that comes back as DEACTIVATED. They’ll insist it’s their real PAN and that it was working last month.

Common causes: - Duplicate PAN: The person had two PANs and one was deactivated by the IT department - PAN-Aadhaar linking deadline: PANs that weren’t linked to Aadhaar by the deadline became “inoperative” (not deactivated, but functionally similar) - Fraud flag: The IT department flagged the PAN for suspicious activity

How to handle it: Show a clear message: “This PAN has been deactivated by the Income Tax Department. Please contact the IT helpdesk or visit your nearest PAN center to resolve this.” Don’t just show “Verification Failed” - the user needs to know it’s not your system’s fault.

Name mismatches

OCR extracts “RAJESH KUMAR” but NSDL has “RAJESH KUMAR SHARMA”. Or OCR reads “PRIYA S” but NSDL returns “PRIYA SUBRAMANIAM”.

How to handle it: Don’t do exact string matching. Use fuzzy matching with a reasonable threshold. We return both the OCR-extracted name and the NSDL-verified name so you can compare them yourself.

from difflib import SequenceMatcher

def name_match(ocr_name, nsdl_name, threshold=0.75):
 ratio = SequenceMatcher(None, ocr_name.upper(), nsdl_name.upper()).ratio()
 return ratio >= threshold

PAN-Aadhaar linkage

Since July 2023, unlinked PANs are “inoperative” - they can’t be used for financial transactions. The API returns an aadhaar_linked field that tells you whether the PAN is linked.

For KYC flows, you should check this field and warn users with unlinked PANs that they need to link it on the e-filing portal before proceeding.

Pricing

OCR and verification are charged separately. If you upload an image, both OCR and verification run automatically and you’re billed for both. If you send just a PAN number (no image), you only pay the verification fee.

You’re never charged for failed OCR (unreadable images) or invalid PAN numbers.

When you need PAN verification

Here are the most common use cases we see:

Lending and NBFC onboarding: RBI mandates PAN verification for all loan applications. Most lenders verify PAN at the first step of their onboarding flow - before running credit checks or collecting other documents.

Brokerage account opening: SEBI requires PAN for demat and trading account opening. Platforms like Zerodha and Groww verify PAN in real-time during sign-up.

Insurance policy issuance: IRDAI requires PAN for policies above certain thresholds. Life insurance companies verify PAN during proposal processing.

Payment gateway KYC: RBI’s KYC requirements for payment aggregators include PAN verification for merchants processing above ₹5 lakh annually.

HR and payroll: Companies verify employee PANs for TDS compliance. An incorrect PAN in payroll records leads to higher TDS deduction (20% instead of the applicable rate).

Getting started

1. Sign up at theverifico.com - 10 free credits, no card required
2. Copy your API key from the dashboard
3. Make your first call using the code samples above
4. Handle edge cases using the patterns described in this guide
5. Go live - same API key works in production

Average integration time for a PAN card verification API: about 30 minutes for a basic flow, 2-3 hours if you’re building a full onboarding UI with error handling and retry logic.

Related guides

• How to Get FASTag Details Using Just a Vehicle Number
• How to Verify a GST Number via API: Stop Vendor Fraud
• PAN Verification API - Product Page
• API Documentation