OneSpan Sign release 11.50: Accept-only rework
OneSpan Sign version 11.50 was recently deployed to the preview environments. In this latest version, we introduced the OneSpan Notary signing flow, supported signing externally signed documents, allowed a document to be both signable and accept-only, added more details to the audit trail, and completed a number of bug fixes. For a full list of product updates, check the 11.50 Release Note. Also refer to our Trust Center and find the deployment dates for all our environments.
In this blog, we will start with the accept-only rework and demonstrate how to define a document to be both signed and accepted, then we will walk through how to electronically sign a document that has been previously signed by an external solution other than OneSpan Sign. Without further delay, let’s get started!
Accept-Only Rework
In OneSpan Sign, an accept-only document is a document used to confirm that a person agrees to the terms of the transaction and wishes to continue with the process. Previously, once a document has been flagged as an accept-only document, senders cannot add acceptance signatures alongside other signature types and fields.
In order to bring extra flexibility and granularity when designing an electronic signing flow after release 11.50, OneSpan Sign has removed this limitation and senders now have the ability to assign a transaction’s document to be both signable and accept-only. This improvement makes it possible to achieve the use cases in which some signers sign a document while others can only accept the document.
For Ad-hoc Users
When users are designing a document in the UI portal, assigning a selected signer to be an acceptor for the current document grays out all the signatures and fields. However, designating one signer as accept only will not affect any other signers. You can still select other signers and place signatures and fields for them. See the screenshot below:
For RESTful API Users
It is also straightforward for integrated users to leverage this feature. When creating a transaction and building the request JSON, if you want to define an acceptor recipient, don’t specify any “fields” in the “approvals” node assigned to them. At the same time, keep regular signers’ “approvals” as is. See the example below where Signer1 is an acceptor and Signer2 is a regular signer:
HTTP Request
POST /api/packages
HTTP Headers
Authorization: Basic api_key / Bearer access_token Accept: application/json Content-Type: multipart/form-data
Request Payload
{
"roles": [
{
"id": "Signer1",
"signers": [
{
"email": "[email protected]",
"firstName": "John",
"lastName": "Smith"
}
]
},
{
"id": "Signer2",
"signers": [
{
"email": "[email protected]",
"firstName": "Mary",
"lastName": "Doe"
}
]
}
],
"documents": [
{
"approvals": [
{
"role": "Signer1",
"fields": [
]
},
{
"role": "Signer2",
"fields": [
{
"page": 0,
"top": 300,
"subtype": "FULLNAME",
"height": 50,
"left": 100,
"width": 200,
"type": "SIGNATURE"
}
]
}
],
"name": "Test Document"
}
],
"name": "Test Accept-Only Rework",
"status": "SENT"
}
Note that the feature is temporary not available in SDKs.
We Want to Hear Your Feedback
There it is. We have outlined four newly introduced features in release 11.50. If you have any questions regarding this blog or anything else concerning integrating OneSpan Sign into your application, visit the Developer Community Forums. Your feedback matters to us!
