Check a bank account in one call.

Bank accounts: you send an account number and an IFSC, and you get back whether the account is valid, plus the name at the bank, the bank and the branch where the provider returns them. UPI is documented and priced but not callable yet: it takes a UPI ID alone and returns the account number, IFSC, bank and branch and the name at the bank, and until it opens a call to it is refused with 409 TYPE_NOT_AVAILABLE rather than queued. The remaining types in the catalogue — PAN, GST, Aadhaar, IFSC, driving licence, voter ID, passport, mobile and PAN to GSTIN — are coming soon, and calling one is refused the same way rather than half-answered.

A UPI ID, in the ordinary name@bank form — that is the whole input, and it is the point: no account number and no IFSC. It also needs your explicit assertion that the person consented to the check, because the rails require one and we will not manufacture it on your behalf; the assertion is stored against that call so it can be shown later. You may optionally send a name, which switches on name matching and adds a match score to the answer. It is not callable yet, so nothing can be spent on it today. When it opens, a drop that never settles will be refunded rather than charged — it tells us nothing about the account.

One call, one charge, whenever we give you a definitive answer — and both answers are definitive. A valid account costs ₹2.00, and so does an account that does not exist, is closed, or cannot take credits: you asked a question and we answered it. What you are never charged for: a request we reject as malformed, a call refused because your balance is too low, a coming-soon type, a rate-limited call, and a call where we could not reach an answer at all — that last one is charged and then refunded automatically, so you see both lines in your ledger and end where you started. Retrying the same request_id never charges twice.

₹2.00 per bank-account validation. Every type is priced per call and every call is chargeable — there is no cheaper mode and no free check. That is the published list rate, drawn from your prepaid API wallet; your organisation's effective rate is shown in your dashboard before you run anything. There is no monthly fee to switch the add-on on, no minimum and no contract — an unused wallet simply sits there. GST applies as per Indian tax law.

You get 502 VALIDATION_FAILED, and the charge is refunded automatically — the response itself tells you so, and the refund is a ledger entry pointing at the debit it reverses. A failed lookup keeps its request_id and keeps returning that same failure, so one id always means one outcome; to try again, send a new request_id.

No. You choose the request_id and it is the idempotency key: send the same one again with the same input and you get the stored result back, with no second charge. Send it with different input and it is refused as 409 REQUEST_ID_REUSED rather than silently overwriting the first outcome. Underneath, a repeated debit is refused by the database itself, not merely by our code.

Yes, and it is free. A test key (sk_test_) runs the same validation, the same idempotency and the same response shape, marked as a sandbox call — but it never contacts a bank and never touches your balance. The last four digits of the account number choose the outcome, so you can build and test the failure paths, including the refund, before you fund anything.

No. The Validation Suite is standalone: it has its own wallet, its own API keys and no dependence on employee records, so an organisation that wants nothing but the validation API can switch it on and start calling. If you do run your workplace on SubhX Nexus it is the same login and the same organisation — just a separate wallet.

An organisation admin, and anyone they grant the Manage API keys permission to through a custom role — so the person building the integration does not have to be an admin of your whole organisation. Keys carry a scope, an optional IP allowlist and an expiry, and spending needs a key with write scope: a read-only key can see your balance and your history but cannot run a validation.

Not its shape. The method, the path, the request, the response and the error codes are our contract, and they do not change when we change, add or fail over between the providers behind them — which vendor answers is deliberately invisible to you. Additions are new optional fields; anything that would break an integration goes to a new version instead, and every change is published in the API changelog.