For banks
Verified beneficiaries, added in one step, on a format you can read without us.
A Seedha code packs an IFSC, an account type and an account number into one string with check digits. Your app can validate it offline with an open library, look up the holder's name we verified with a single read-only call, and show your customer "Confirm beneficiary" instead of a blank form. Your app moves the money. We only answer whose account it is.
Why a bank should want this.
Payments Vision 2028 proposes a shared responsibility framework in which the customer's bank and the beneficiary's bank "jointly bear the liability arising from unauthorised digital payment transactions". A bank that will share liability for where money lands wants every beneficiary verified at the moment it is added, not after the complaint. A code with check digits cannot be mistyped into a valid one, and a name confirmed at the beneficiary's bank cannot be swapped by a forged invoice.
It also returns the large payments to your rails. IMPS and NEFT carry no merchant charge and are what a buyer uses above the UPI limits. Easy, verified beneficiaries make IMPS the natural choice from ₹50,000 to ₹5 lakh, where your customer wants instant confirmation and your bank earns a fee.
What it costs you.
Nothing. The format is published under Creative Commons, the libraries under Apache 2.0, and the look-up API is free for banks. There is no contract to sign before your team tries the sandbox. The only thing we ask is that a conforming implementation calls it a Seedha code, so your customers recognise it from one bank to the next.
The API
Two calls.
GET /api/v1/codes/{code} returns the account, the type, the bank, the name we verified and when, the organisation behind the code and whether anyone has reported it. It is cacheable, answers 304 to a matching ETag, and needs no key. POST /api/v1/codes/{code}/confirmations lets your app tell us a customer saved the beneficiary, so a reported code can be traced; it needs your bank key.
The TypeScript library validates and decodes codes offline against the published test vectors; a Python port follows, and a Java port is planned. Nothing in your app has to call us to know whether a code is well formed.
GET /api/v1/codes/IN89HDFC0012341150200012345678
If-None-Match: "…"
200 OK · ETag · Cache-Control: public, max-age=60
{
"code": "IN89HDFC0012341150200012345678",
"display": "IN89 HDFC 001234 11 50200012345678",
"ifsc": "HDFC0001234",
"accountNumber": "50200012345678",
"accountType": "11",
"accountTypeLabel": "Current",
"bank": "HDFC Bank",
"verification": "verified",
"nameAtBank": "SHREE CEMENT AGENCY",
"verifiedAt": "2026-10-20",
"organisation": { "tradingName": "Shree Cement Agency" },
"openReports": 0
}Where this goes
From a link your customer taps to a QR your app reads.
Now
Your customer opens a seedhapay.in link from a WhatsApp message or a QR. The page shows the verified name and the account, and the customer pays by IMPS, NEFT or RTGS from your app.
Next
Your app registers for the seedhapay.in link. Tapping it opens your app on a "Confirm beneficiary" screen, pre-filled from the API, with the name we verified beside the name your core banking returns.
Then
Your app's scanner reads the Seedha QR natively, the way banks in Vietnam read VietQR, and your bank issues codes to its own current-account customers on their statements and cheque books.
Ask for a sandbox key.
Tell us the bank and what you want to build. You get a key for the confirmations endpoint and a test account to look up; the read calls need no key at all.
SeedhaPay moves no money and holds no funds. Nothing here implies endorsement by the Reserve Bank, NPCI or any bank. Terms for the bank API.