[somery]

That's interesting that you ended up developing an in-house document e-signing feature for your product. I'm curious, would it be possible for you to choose a self-hosted and open-source solution like Docuseal, integrated with your product to outsource the complexity and speed up the development? (if such an option existed back then?)

[bob1029]

> outsource the complexity

Honestly the bulk of complexity seemed to emerge from the mismatch between what we thought would be a good e-sign API and what APIs were actually available.

The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.

We also needed a way to in-line bank-specific e-sign consent documents into the experience, giving the e-signer a way to decline consent and have this decline kick off an appropriate back-office workflow. The other reason we went in house is we wanted to completely close the loop. After the last e-signer completes their piece, our product detects this condition and submits all final documents to the institution's long-term cold storage system. Getting this to work with a 3rd party API looked like a total non-starter to me - We can't just send the docs right away. There are time-of-day constraints on when those systems will be available throughout the week.

Our e-sign solution ultimately turned into a workflow-style experience with 6-7 steps.

[pottertheotter]

> The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.

Can you elaborate on this? Why people would want to have the signature first before showing the document?

[bob1029]

In our solution, providing the up-front signature does not construe immediate consent to terms of whatever hypothetical documents. We have a subsequent review phase where the customer is expected to confirm each document meets their expectations (i.e. with their actual signature on it). Only after confirming all of the documents is the transaction considered to be completed and the signed copies taken as official.

The more complicated answer is that we are serving e-signatures for business accounts wherein there might be 10+ authorized signers involved. In these cases, we want to permit parallel sign completion. To allow this, each signer gets to view an isolated scope of documents with just their signature affixed. This also helps to conceal the signature specimens of other parties until the entire transaction is considered finalized. If a required party to an account does not want to participate, then no one gets to see anyone else's ink.

At the very end, all participants of the signing ceremony receive emailed copy of documents that combine signatures from all participants.

[yencabulator]

> Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant.

Why would I sign something I haven't seen?

Businesses & government in USA seems to like asking for my signature on a little LCD pad, without showing me what I'm signing. That's absolutely horrible and anti-consumer behavior.

(And yes, I do diff DocuSign-style PDFs before and after the insertion of the pseudosignatures and visible watermarks, or PDFs from before and after a email-print-sign-scan-email cycle.)