From the Trenches: Sign on Paper

•

Summary•3 min read

In case it's needed, you can use the eSignature API to allow a recipient to sign on paper.

Additional resources

Additional resources

While in general, it's recommended to use Docusign fully electronically, there are cases where it is preferred, or even necessary, to have a recipient sign a physical copy. In these cases, "Print and Sign" (WetSign in the eSignature API) can be used. If you're not familiar with the process, Support documentation is available.

To control whether this feature is enabled for a particular envelope, set the EnableWetSign parameter in the EnvelopeDefinition object. Note that what is set in the API overrules what is set on the account's Signing Settings. In C#, setting an envelope to allow this looks like:

var envelopeDefinition = new EnvelopeDefinition
{
    EnableWetSign = "true",
    EmailSubject = "WetSign Example Envelope",
    Status = "sent",
    CompositeTemplates = new List
    {
        compositeTemplate1,
        compositeTemplate2
    },
};

When the Sign on Paper workflow is used, the document that the recipient signs is added to the envelope as an attachment. Because of this, it's important to consider how your application should handle signed documents.

The simplest way is to request the combined document, which will result in a single PDF with the wet-signed copy appended to the end. If the PDFs need to remain separate, an EnvelopeDocuments::List call can be used to check for the presence of wet-signed files. Docusign Connect can also be used: even with the option to Include Document PDFs disabled, the Connect packet will include filenames and IDs of all envelope documents. In either case, wet-signed copies can be identified by the filename, which begins with "Signed-on-Paper_" and includes a randomly generated GUID. Note that there's nothing in the Recipients definition that defines whether a user signed electronically or on paper. There's also no validation of whether the signer actually completed their role correctly. If there's no room for ambiguity in your workflow, it may be best to explicitly disable wet signing, or at least add an additional role to validate the provided input.

While Sign on Paper solves the problem of needing to accommodate a physical signing in a workflow, it presents a number of issues that should be considered before implementation:

It's not immediately clear through the eSignature API or Docusign Connect when Sign on Paper (wet signing) is used.
Docusign is unable to collect form data from recipients using wet signing.
Docusign is unable to validate that the signer-provided document is filled out correctly, or even that the document returned is the correct document at all.
If the customer selects the Fax-Back option instead of Scan-and-Upload, processing could be further delayed.
The wet-signed copy will be a separate document in the envelope.
There's no simple way to merge envelope documents that have been wet-signed by multiple recipients. A combined PDF is available, but will contain duplicate pages with individual signatures.