Updates for SMS and phone authentication
For years, DocuSign SMS and phone authentication solutions have helped organizations protect their agreements. By requiring returning signers to prove their identity with a one-time passcode delivered via a phone call or a text message, organizations ensure that the right signer is gaining access to the envelope.
Until now, however, the “SMS” and “Phone Call” options have been specified by the sender, locking the recipient into only being able to receive an SMS or a phone call to receive their one-time passcode. This posed problems for signers who, for instance, may have provided their landline as a phone number and were being asked to perform SMS authentication. Many individuals still prefer to receive an SMS anyway, so putting that choice in their hands provides for a better customer experience.
Learn more about this functionality in our Recipient Authentication - DocuSign eSignature User Guide. This blog post is focused on what is changing and what the rollout of this new functionality will look like.
What is changing?
When sending an agreement, senders will see a unified option called “Phone Authentication” that will allow the recipient to choose whether they would like to receive a call or a text message to then get the one-time passcode that will grant them access to the document:
Recipients will see a screen like the following when trying to access their envelopes, enabling them to choose the delivery method for their authentication passcode:
All of the envelope history and data will be logged and displayed on the document’s certificate of completion.
Old templates and integrations
If you have old templates or integrations on your account that refer to the old distinct configurations known as “SMS $” and “Phone $”, those will continue to work, but will map to the new recipient experience.
Legacy API parameters/features
Most customers do not have access to our oldest version of phone authentication, but it should be noted that we will discontinue support for the “recipient may provide phone number” or “capture voice recording” settings. Recipients being able to provide their own phone number to then authenticate is not really a trustworthy authentication method, and many customers have been asking us to remove it.
Persistent authentication also works a bit differently. Rather than use the settings at the account level, there are new settings that live on the specific workflow options. You can find them by navigating, on your account’s admin settings, to “Identity Verification” under “Sending & Signing”.
Billing
Because we have merged the ability to receive an SMS or a phone call and put that choice in the hands of the recipient, we will also be merging the billing for these products. The SMS Authentication SKU is going to be the way we will assess all billable units, and we will be ending the sale of the Phone Call SKU. For DocuSign customers, this means getting a more flexible user experience, at a much lower cost per unit.
What about the API?
If you are using the DocuSign API to send envelopes, you will find that the request body has changed slightly. Sending an envelope using this method is very similar to how it works for ID Verification.
The only difference is that, while it may have a unique workflow ID (the system default is c368e411-1592-4001-a3df-dca94ac539ae), this method needs the input of what phone number you want to use, so a sample API request looks like this (extension is an optional attribute that can be entered after CountryCode):
"identityVerification": {
"workflowId": "c368e411-1592-4001-a3df-dca94ac539ae",
"steps": null,
"inputOptions": [{
"name": "phone_number_list",
"valueType": "PhoneNumberList",
"phoneNumberList": [
{
"Number": "2068675309",
"CountryCode": "1",
}
]
}]
},
Note that your workflow ID may be different from the one shown in this code snippet. You can get the list of workflow IDs available for use on your account as described in Step 3 of How to require ID verification (IDV) for a recipient on the DocuSign Developer Center. Use the eSignature REST API method IdentityVerifications:list.
When are these changes coming?
These changes have been live in demo accounts since October 2021, and in new production accounts since December 2021. We will be transitioning all production accounts that include phone or SMS authentication to the new model over time.
To be enabled in your own production accounts sooner, please inquire with your account team or representative.
FAQs
Q: What countries are supported?
A: We support the same countries as the legacy SMS and phone call-based authentication methods we’ve had in the past. Check the dropdown in the Sending web experience for the exact list.
Q: What languages are supported?
A:Supported languages are shown in the footer of the authentication experience. You can also see a list of supported languages on our Global Standard page.
Q: How does/will billing work?
A: All usage units accrue to the SMS SKU.
Q: How long are the One Time Passcodes (OTP) valid for?
A: 10 minutes.
Q: What does the transaction ID in the certificate of completion mean?
A: This is a DocuSign session transaction ID that allows our support team to assist with troubleshooting.
Q: How does branding work?
A: Button color and logos are supported.
Q: How does persistent auth work?
A: Rather than the old authentication platform, which was configured at the account level, the future of these authentication workflows at DocuSign is granular controls that are handled by the specific workflows, on a self-serve basis.
Q: How can I provide feedback or ask additional questions?
A: Please feel free to reach out to your account team or provide feedback via this survey: DocuSign Phone Authentication Survey
Notes
As with any new offering, there are some caveats that are worth noting.
At the time of writing:
- Embedded iframes will not work for this functionality: we recommend that you avoid this concept in general as a best practice. For more information, see Embedded signing and sending on the DocuSign Developer Center as well as this blog post: The problems with iframes.
- Bulk sending works indirectly via our backward-compatibility support. If you specify SMS or Phone in your CSV upload, end users will be shown the new experience accordingly.
Specify/update recipients is currently not supported.