Plan an eMudra / emSigner Signer Gateway release

This guide explains the controlled release boundary for an eMudra / emSigner Signer Gateway integration. It is not a live-provider announcement, a substitute for the provider's account-specific instructions, or an invitation to paste a certificate, Aadhaar value, OTP, credential, or DSC PIN into Wizard Legal. Confirm the exact provider contract for the subscribed account before changing any deployment setting.

Bind the approved provider contract before enabling a method

• Obtain the account-approved sandbox and production gateway addresses, supported signing modes, gateway encryption certificate, permitted callback domains, retrieval terms, and exact request/response contract from the provider.
• Store gateway credentials and certificate material only in the deployment secret system. The application checks the configured gateway certificate is a current RSA X.509 certificate before it can create a provider attempt; that protects the hand-off configuration, not the signer's PDF certificate.
• Keep a durable, unique provider reference for every signing attempt. The provider reference, envelope, recipient, document version, and callback outcome must be correlated on the server rather than trusting a browser return page.
• Enable only the signing methods actually approved for the subscribed account. A shared field or an old sample request is not evidence that Aadhaar, biometric, DSC, or generic eSignature is authorised for a deployment.

Place signatures on the real PDF before the hand-off

1. 1Load the actual source PDF and add a required field for each signer. The draft editor lets the owner move those fields before sending; the final page bottom-stack preset keeps default multiple signer fields distinct rather than overlapping them.
2. 2For a provider attempt, the server validates the PDF page count and each normalized field rectangle, then converts the saved fields to the provider page-level coordinate representation. Never guess a page number or use a browser-only placement as evidence that the provider will stamp the intended location.
3. 3For sequential signers, use the prior provider-returned signed artifact as the next attempt's source and prove the appearance and document hash after every signer. The final signer must close the co-signing sequence according to the approved provider contract.
4. 4Run these cases with real page sizes, rotations, and multiple fields in the provider sandbox before allowing an owner to use the method in production.

Prove every success, failure, cancel, and recovery path

1. 1Generate encrypted provider fields on the server and submit them by HTTPS POST in the same browser window. Do not put encrypted parameters, credential material, or a document payload in a link or client-side storage.
2. 2Exercise the configured success, failure, and cancel URLs with the provider's real redirect or callback shapes. Validate correlation, idempotency, replay handling, and the final user-visible state; a URL visit alone must not mark an envelope complete.
3. 3Use the provider's documented retrieval or status route only after the account contract permits it, and retain the provider result with the local attempt. Recovery is for a missing or interrupted return, not a shortcut around callback validation or document verification.
4. 4Record the exact test evidence: request reference, outcome, provider response, returned original PDF, callback result, audit-chain state, and independent verification output. Re-run UAT after a gateway, certificate, callback-domain, provider, or material application change.