Electronic signatures

From PegaWiki
This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Electronic signatures

Description Covers integration with applications that support electronic signatures.
Version as of 8.4
Application Pega Platform
Capability/Industry Area Data Integration

Learn about best practices and integrating with electronic signature applications, such as OneSpan or DocuSign. With Pega components available on Pega Marketplace, you can help users digitally sign their documents.


An electronic signature can be a symbol, image, or process attached to a message or a document, which can be used to provide consent to the content in the message or document. It is a digital equivalent of the conventional handwritten wet signature. Electronic signatures do not require any specific technology or process follow, and you can create them by, for example, attaching an image of a signature or a fingerprint. As trusted certificate authorities or service providers do not perform any validation of electronic signatures, these signatures are prone to tampering, less reliable, and cannot be authenticated. You typically use electronic signatures when somebody has to authorize the content of a document.

An electronic signature is easier to use than a digital signature. However it is less secure and less authentic than the digital signature.

Digital signature vs electronic signature

A digital signature is a unique characteristic in digital form, something like a fingerprint embedded in a document. The signer must have a digital certificate to associate with the document. The certification authority issues the digital signature. A digital certificate helps verify the document's authenticity and determine if it has been tampered with. The certificate plays a vital role in the verification of the identity of the person who signed the document.

The main feature of an electronic signature is the intention to sign a document or agreement. Another noteworthy aspect that distinguishes an electronic signature from a digital signature is that an electronic signature can be oral, a simple mouse click, or any electronic authorization.

The following table outlines key differences between digital and electronic signatures:

Digital signatures Electronic signatures
Used to protect the document by providing authentication; cannot be tampered with Used to verify the content of the document
Authorized and regulated by certification authorities Not regulated
Created using cryptographic algorithms Significantly less protected
Can be verified and only obtained by providing proof of identity Cannot be verified
Focused on the security of the document content Represents an intention to agree to the content of the document, such as contract terms and conditions
Preferred over electronic signature because of its high level of authenticity Ease to use, but lower value

Features of electronic signature apps

  • Easy to sign, as you can just view the content of the document and authorize it by signing.
  • Save time and resources, as you do not have to print the document, sign it and upload it.
  • Multiple signature types available – Image upload, scribble, and selection from available fonts are some of the common signature types.
  • Multi-party signatures – Signatures from multiple parties can be captured on a single document.
  • Supports authentications such as one time password (OTP), push notifications, or a static password to access the document for signing. However, documents can still be tampered even after they are electronically signed.
  • Possible to sign on mobile and other hand-held devices.

Adoption of components for electronic signature

DocuSign and OneSpan are commonly used applications that offer electronic signatures. Components are available on Pega Marketplace, which can assist in seamless integration with these applications from any Pega application.

Consider an insurance company that accepts paper applications for insurance policy. Typically, the company advisors approach the individual customers and get the physical paper applications filled and signed.

Due to the pandemic, customers may not be interested to physically meet the advisors. Therefore, the insurance companies decided to switch to an online application with electronic signatures, instead of the manual and physical process.

For this purpose, an online application workflow was developed using Pega Platform, with a decision to use the electronic signature apps.

Now, let's discuss the procedure to integrate with OneSpan and get the applications signed electronically. For OneSpan, we have a Pega component that supports such integrations in Pega Platform version 7.4 and later, that you can download and install using the link from the reference section.

First, you must have access to an OneSpan sandbox account to integrate Pega with, so please contact OneSpan to create one (using the email address Support@onespan.com).

With the account created, there are two ways to integrate with OpenSpan:

  • By using the ClientApps
  • By using the API key

For both methods, you have to sign in to the OneSpan account and look at the integration section to get the required details. The details on type of the integration can be obtained from the below link.


API Access.png

Get integration-related details such as the API key and endpoint URL, and update the OS_LoadApplicationSettings data transform as shown in the following figure:

API settings.png

OneSpan templates are predefined set of elements, in which you can define documents, signers, and signature locations. You can use them multiple times when creating new transactions. You can create template by clicking the NEW TEMPLATE button, as shown in the following figure:

New template.png

Each template has a TemplateID that you need to pass in the OS_ClonePackageRequestPOST clone package.

For OneSpan, you must configure the OS_CreateESignPackage activity that helps you create and manage the eSign package.

Create package.png

a. First step looks for the template ID, if present.

Next template.png

b. OS_CreateESignPackageAPI creates a new package ID for this particular transaction.

A package is a kind of a single transaction/work object for getting signatures from signers on multiple documents related to that work object. You can get signatures from multiple signers on multiple documents.

You need to send all details related to the package like package ID, language, signers and their roles for this package, email message, Package type, and in-person or Remote.

c. OS_ClonePackage runs when you are using a template. Template ID needs to be passed for this to run. If you use a template you do not need to send a document, as the template already contains the document.

d. OS_UploadSingleDocumentAPI uploads the document. It contains all document details such as the unique document ID, document content, and where clients have to sign the document.

e. OS_GetDocumentFieldValues contains document field values.

f. OS_SetReminderSchedule sets reminder values, that help you send reminder emails to clients.

g. OS_SetDocumentVisibility hides documents from individual signers.

h. OS_SendTransaction initiates the transaction in OneSpan. This is a trigger point for package creation in OneSpan, with all the above details.

Once the package has been created, it has a life span until it is deleted or archived (a package ceremony). Once created, you get the unique ID for the package called package_id, which you can use as a future reference to get package status.

OS_CheckForStatusUpdate is an activity that you can call to get the status of a package. This activity downloads attachments if signers have attached any, download the signed copy, and retrieve the transaction summary. OneSpan also communicates a specific status if you update the Pega endpoint URL in the event notification section, for the Callback URL field, as seen in the following figure:

Call back url.png
Package status.png

The above figure represents different stages of the package lifecycle. Package starts in the DRAFT status when we create a package and changes to SENT when you send a transaction. Once the user signs, the package is marked as COMPLETED. The EXPIRED status appears when the package validity expires. Users' actions can also change the status to OPTED_OUT and DECLINE, and you can enable these options in the OS_SigningCeremony data transform.

Signing ceremony.png

Once you receive the status, you can mark the package as completed on the Pega Platform side.


User authentication is one of the key parts to consider when using an electronic signature.

  • Apps provide the following user authentications, which provide secure access to a document, but can not prevent document tampering.
  • Static password – a basic form of authentication, but not recommended as we must share password with all users.
  • Offline OTP – sends OTP to the user’s mobile number and authorizes the user to view and sign document only when they enter a correct OTP.
  • Secure channel-based – supports any channel-based authentication, such as SSO.
  • Push notification-based – sends push notifications to users when they wish to sign in to authorize.


  • Choose the appropriate level of authentication to secure documents.
  • As documents are sent to third-party websites, ensure that the documents are secure.
  • As users can view or sign documents using mobile, advise signers to protect their mobile devices using PINs and strong passwords.
  • Users should always access documents during the signing process within their secure repository to validate the integrity of the document, manage version control of the document, and ensure oversight of the process by the document sender.
  • Protect signatures and documents from tampering by using additional security, if needed.
  • Verify whether the vendor has a consistent track record of protecting customer data

Integration using iFrame

You can integrate with electronic signature apps using iFrame for a more seamless experience. If you send documents to thirdy-party apps with signature details, the apps send emails to the specified clients, and then send signed documents back to Pega. However, for some specific clients, you might need to do a signature on the same screen. For example, an insurance application form or recruitment form by a company, in which the document has to be signed on the fly and not sent to an email for signing offline. In such situations, you can integrate with these apps by showing them in the Pega application using iFrame for a seamless user experience.

To integrate with iFrame, consider the following points:

  • Components do not have any specific rule support for iFrame, you must write custom HTML for loading third-party apps.
  • Loading third-party applications can take three to five seconds, as you need two-way communication before launching in a particular transaction context:
    • Send package details and get the package id created.With Package id, and language, you must load the signing ceremony.
    • Transaction details and language-specific details should be part of the URL parameters.
  • To get back to Pega after transaction completion, you need a JavaScript trigger to give control back to Pega.