eMudra eSign API readiness: checks before provider signing goes live

A provider-backed e-sign implementation has more moving parts than a button labelled eSign. Before a team calls a method live, it needs evidence for the provider account, the exact gateway contract, secure return behaviour, the completed PDF, and the way the product handles a cancellation or recovery. This guide is a readiness checklist, not an assertion that any particular provider method is available in Wizard Legal today.

Confirm the provider account and gateway contract

• Obtain the subscribed account's approved demo and live gateway URL, exact form fields, credential handling, callback-domain approval, and method entitlement in writing.
• Confirm the deployed gateway encryption certificate is the provider-approved, current RSA X.509 certificate. Rejecting malformed, expired, or non-RSA configuration is a deployment safety check; it is not validation of the signer certificate in a returned PDF.
• Confirm which method is actually authorised for the account. Do not infer Aadhaar, biometric, DSC, PAN, or generic eSignature eligibility from a shared configuration field.
• Reserve a provider reference for each attempt durably and prove duplicate handling, rather than assuming a random-looking value is unique in production.

Keep the browser hand-off and callback secure

The application should prepare provider fields on the server and hand the signer to the approved HTTPS provider destination in the same browser window. It should not place provider secrets or encrypted fields in a URL, and it should not ask for Aadhaar details, provider credentials, or OTPs itself. Capture the actual success, failure, and cancel callback shapes in demo UAT; an application correlation value is not a substitute for a provider-authenticated callback contract.

Prove the returned document and multi-signer flow

1. 1Run a real single-signer demo transaction and record the returned status, transaction reference, signed artifact format, and retry behaviour.
2. 2Run success, cancellation, failure, replay, and lost-transaction scenarios against the deployed callback, then confirm the application leaves no ambiguous signing state or duplicate credit use.
3. 3For sequential signers, prove that each subsequent provider request uses the prior signed artifact and that placements remain correct on real document dimensions and rotations.
4. 4Validate the completed PDF independently for its CMS signature, signer certificate chain, signing-time policy, revocation state, and timestamp policy where those are required. A structural PDF signature marker is not that validation.
5. 5Revalidate the deployed account and ceremony periodically and after a material provider, certificate, callback-domain, or gateway change. Wizard Legal expires a recorded provider-UAT timestamp after 90 days instead of treating it as permanent approval.

Release only after deployment-specific evidence exists

Keep provider modes unavailable until the account, callback domain, transport, browser ceremony, recovery path, and signed-document checks have been demonstrated together in the deployed environment. Refresh that evidence after the configured revalidation window and after material provider changes; Wizard Legal does not treat an old UAT timestamp as permanent approval. Public copy should describe only the methods that are currently shown as available in the workspace. That protects signers from entering sensitive information into the wrong surface and keeps product claims aligned with real capability.