Eg if you’re a CFO, would you being willing to take the risk just to save a couple of bucks on a no-name eSign service for all your sensitive legal & vendor agreements, or use the worldwide Trusted eSign platform of DocuSign - which has gained acceptance by regulators as being an authoritative legal signature of contracts.
We learned this pretty quickly with our banking products. Having your own bundled, first-party e-sign features can help differentiate your product from other vendors, but if the only thing you are selling is e-sign, they probably won't look at you. We do have an in-house e-sign feature in our product now. We evaluated integration with Adobe & DocuSign, but their APIs were so far away from what we needed that we decided to DIY.
Consider this - what is a bank going to do with raw access to something approximating docusign APIs? They outsource everything. Their vendors are the ones who would be consuming something like this and then reselling it. Getting onto the QVL for a US financial institution (and staying there) is usually a monster battle if you are a new kid on the block.
If you still wanted to market this solution towards US financial institutions, I'd start with the vendors of those institutions. Companies like Jack Henry & Associates, FiServ, CSi, FIS, Harland Clarke, et. al.
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.
Can you elaborate on this? Why people would want to have the signature first before showing the document?
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.
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.)
Alternative to eSign is to just send PDF documents. And as the person to add their signature to it.
Typical FUD preached by many online companies to lure customers.
Even verbal contracts are enforceable (with the caveats of course). These will be fine for the most boring cases. The others are signed with lawyers anyways.
This is the important part you're ignoring. Yes, verbal contracts between businesses are binding, but only to the extent you can actually prove the terms in a court of law.
Using DocuSign (or similar) is about risk mitigation, specifically about being able to prove the the contents of the contract in legal proceedings.
The risk with being a business that allows for verbal contracts is that one of your vendors may be unscrupulous and truly screw you over. And that's a matter of when, not if.
Here is a summary from their TOS:
"DocuSign provides tools and features that help to establish the authenticity of a signer, such as email verification, access code, SMS verification, phone verification, and knowledge-based authentication. However, it's important to note that while these tools can enhance the security and authenticity of the signing process, DocuSign itself does not guarantee the authenticity of the signers. The responsibility of ensuring the identity of the other party lies with the user"