TimMillerDyck's account

Hi Duo, thanks for the response. Is SharePoint 2016 supported? SharePoint 2013 is quite old at this point.

Hi, for others finding this page, I was also getting 'The number of Pre-Verify results does not match the number of documents that were sent for verification.' and 'number of documents that need verification = 2, number of verification results = 0' back from the OneSpan REST API.

The issue was actually corruption in the PDF I was sending. I had incorrectly base64-encoded a test PDF and the resulting decoded byte stream I was using to test with OneSpan was not the same bytes as the original PDF.

So, I would suggest anyone seeing this error double-check that the PDF bytes they are actually sending to the OneSpan REST API are correct.

Hi Duo,

Thank you so much!

Yes, we are using the RESTful API to create DRAFT status signature packages and I am referring to the sender name in the recipient list on the package designer page where signature placement boxes are dropped onto a preview of the document.

I have tested adding to our REST call the custom data field senderVisible set to false as mentioned:

"data": {
    "senderVisible": false
  }

This works exactly as desired, where the sender name is now no longer displayed on the designer web page UI. Only the two signer names are displayed on the left.

Could the senderVisible field be added to the list of request payload custom transaction data fields documented here:

  https://community.onespan.com/documentation/onespan-sign/guides/feature-guides/developer/custom-transaction-data

or in some other place where I could find all the supported custom data fields?

Regards,
Tim

Hi Duo, thanks so much for the quick response!

Re: (1) Disable In-Person Activation Email

Regarding e-mail addresses for in-person signers, we will have some in-person signers that do not provide us with e-mail addresses or possibly have no e-mail accounts. Do we need to make up fake e-mail addresses simply to fill in data for in-person signers?

Thanks for the link to the API to send e-mail notifications for those signers that are not using in-person signing.

Re: (2) In-person SMS Authentication

Ah, so it sounds like if we configure the package for in-person signing, we need to take special steps to still force the remote signers to do SMS Authentication like we require them to do now.

Is there a specific REST API JSON parameter we need to set to do this for this on a per-signer level? Right now, we get SMS Authentication to be enforced just by sending:

  "auth": {

  "scheme": "SMS",

  ...

for each signer with their cell phone number.

Thanks,
Tim

Thanks again for these responses, Duo!

This is good to hear. It sounds like we should have no technical barriers then to getting mixed in-person+URL-auth and remote+SMS-auth signers in the same signature package.

Regards,
Tim