AV | Posts: 36

Using Senders in package

0 votes

Hi,

 

I am working on a scenario where I need to send a package for eSign on behalf of a sender from an "account" different from that of the Sender.

Each package could have different sender or I can use a sender that I used in an earlier package. 

1. If the sender already has a onsepan account, do I still need to add the Sender programmatically to the "account" before I can send the package? If so, when I add the sender to the "account", does the Sender have to do anything before I can add him as sender in a new package?

 

2. If the sender does not have a onsepan account, do I still need to add the Sender programmatically to the "account" before I can send the package? If so, when I add the sender to the "account", does the Sender have to accept the invite before I can add him as sender in a new package?

 

Currently, when I add a Sender to a package but is not a "sender" added in my account but the Sender already has a onespan account, I get the following error.

Could not create a new package. Exception: The remote server returned an error: (403) Forbidden. HTTP POST on URI https://sandbox.esignlive.com/api/packages.
 Optional details: {"messageKey":"error.forbidden.accountNotAccessible","message":"The operation requested cannot be done by the user requesting 
 it because there is an account access mismatch","code":403,"name":"Access Denied"}

 

Kindly advise. Thank you.


Duo_Liang | Posts: 3776

Reply to: Using Senders in package

0 votes

Hi Anupama,

 

If you are using the feature "sender on behalf of another sender". In .NET SDK, it takes effect with below code snippet:

.WithSenderInfo(SenderInfoBuilder.NewSenderInfo(""))

In this case, you can only reassign ownership to senders under your own account. You may already know that a sender (an email) can only belong to one account. Therefore you have to invite them if the email not a sender yet, or you have to use that sender's account owner's API Key to create the package on his/her behalf.

 

Duo


AV | Posts: 36

Reply to:

0 votes

Thank you. In my scenario, the senders will usually have their own OneSpan account, so adding them as a Sender to another account will gave an error as you said. I got this error.


 Optional details: {"messageKey":"error.validation.senderAlreadyMemberOfAnother","code":400,"message":"Sender is already a member of another account.","name":"Validation Error"}

And for those which doesn't already have an account, if I add a Sender to my account , will the sender be able to log in (with a pwd like a regular oneSpan account?) and sign documents?


Duo_Liang | Posts: 3776

Reply to: Using Senders in package

0 votes

Yes, if you add senders to your account, they will receive an activation email with a link to set their password, and thereafter, they can log onto the sender portal. (On the contrary, if you don't want to do so, you can turn off this email template. With API, you can set the sender status as "ACTIVE" directly to save the activation process)

 

Duo


AV | Posts: 36

Reply to:

0 votes

Thanks. Based on the above, I guess then there is no way I can add an existing Account holder as a Sender to another account.

Is there a solution/approach that is available in Onespan for any of the following?

My application (non-web) will be used by several users and I was planning to use one common API Key (Account A) to create the packages with each user (who currently have a onespan account) added as a Sender. This is what I believe you said is not possible as you mentioned "Therefore you have to invite them if the email not a sender yet, or you have to use that sender's account owner's API Key to create the package on his/her behalf."

1. If I have Account A that is used to create packages from an application, how to create packages with another Account B as the owner without the need to know the Account B's API key? Can Account B be assigned as the owner of the package by Account A without B's API key?

2. If I have Account A that is used to create packages from an application, can the package be shared (for edits, signing etc) with Account B ?

or 

3) can the user's API key be retrieved for creating the package using the SDK from my application?

 


Duo_Liang | Posts: 3776

Reply to: Using Senders in package

0 votes

For #1, it's not possible to create package on behalf of Account B without knowing their (1)API Key/ (2)Client ID + Secret pair (new feature released in 11.34)/ (3)login credentials.

For #2, you can add the email as a signer, and share the designer view link, so that any one can review and design the package with the link (every signer can sign, not necessary to be package owner). However, I believe this is against your design that add each of your user as a sender, so that they can have an isolated sender portal.

For #3, if your user is already an OSS client, you may have to develop another structure that allows them to specify any of the API credentials and invoke APIs directly using their API key. 

 

Duo


AV | Posts: 36

Reply to: Using Senders in package

0 votes

Hi,

Thank you for your response. I spoke to the OneSpan support person about my requirement and the following was suggested as a solution to what I want.

my scenario: Account A is the main account and Account B is set up as a Sender under Account A. So in-order to create the package from Account A on Behalf of Account B, I see two options

option 1: As Account B is a Sender on Account A, use the Sender option when creating the transaction.  Account B able to edit the transaction and will Account B be the owner of the transaction. This is a good solution to my scenario.

option 2: This was an option suggested by support.

  1. invoke using Account A’s API key, the call to API that will retrieve Account B’s API key – it was said this will be possible as Account B is under Account What is the code SDK sample to do this using .NET SDK v11.32 
  2. With the retrieved Account B’s API key, call API to create the transaction – this transaction will be owned by Account B

Support asked me to post this info and ask in the forum, Can you please confirm/answer the above?

thanks.

 


Duo_Liang | Posts: 3776

Reply to: Using Senders in package

0 votes

Hi Anupama,

 

The two options work fine IF person B is a sender under Account A. But I thought your issue is your clients have brought their own OneSpan Sign accounts, therefore NOT under your main account. In which case, you can't do too much essentially without invoking APIs with client's API Key.

 

Duo


AV | Posts: 36

Reply to: Using Senders in package

0 votes

Thank you Duo. I came to know of the account set up structure only when the support person told me. That simplified the scenario a lot. 

The way the accounts are set up as Senders under a main account. I am able to use the approach as detailed in "Create package on behalf of another Sender (.NET SDK)". I have tried this and it works! I do not after all need the API key of the sender to be able to send a package by using Main account API key, on behalf of the sender from under main account.

This approach seems to work for my scenario.

The following are the options I have gathered from my own research into OneSpan and from the inputs I received from the support and your responses.

Approach 1: use the approach as detailed in "Create package on behalf of another Sender (.NET SDK)". Our current account set up seems to allow this option to work

Approach 2: Get the API key of the Sender and then create the package; This option seems to be available only when using RESP API calls and not with .NET SDK

Approach 3: I read this article which talks about the option to use Client App token when creating the package programmatically. https://www.onespan.com/blog/onespan-sign-release-1134-api-token-client-application I haven't tried this as this is version of SDK seems to be not available for download.

Can I please request for a meeting/call with you to finalise the approach I need to take keeping in mind maintainability of the solution I choose?

Thanks!

AV


Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off