The purpose of this post is to check if different Docusign accounts can be linked to same application but the billing should be done against a single account.
For example,
Suppose there are three organization OrgA, OrgB and OrgC. OrgA has an agreement with OrgB and OrgC to execute the proposals for them. Docusign account details of OrgB and OrgC are shared with OrgA. Hence while executing and sending an envelope OrgA can use the accounts of OrgB and OrgC. But the billing of the above should be done against OrgA by the Docusign without deducting it from OrgB and OrgC. Is there any way to achieve this in Docusign.
Yes, ISVs have the option of reselling DocuSign services. In such cases, different customers have limited access to DocuSign and the ISV pays DocuSign for all DocuSign services. See the OEM licensing docs.
Otherwise, no: the sender (creator of the transaction) pays DocuSign. So when Org B sends an envelope, Org B pays DocuSign, even though Org A created the application that was used to send the transaction.
Related
I am trying to integrate our web app with DocuSign. We expect our web app customers will authenticate and grant consent to our app to make API calls on behalf of their DocuSign accounts. Then our app will create envelopes (using access tokens to customer DocuSign accounts) and allow our app users to sign them using embedded signing.
We've built a prototype using demo account and everything works like a charm.
The only thing what is still unclear for me is how it is supposed to work after going live.
Am I right that our customer will be charged each envelop sending, since our integration makes call on behalf of their account?
Is it enough for our customer to pay for Standard eSignature Plan to make embedded signing work, or they should choose Enhanced Plans (the one where API feature is listed)
Should our account plan (which holds Integration Key) be at least Advanced Developer to support embedded signing?
Could anyone advise on the matter. Thanks!
Am I right that our customer will be charged each envelope sending, since our integration makes call on behalf of their account?
A. Yes, you're right. If your customer logins in to DocuSign using their own DocuSign user account, then their DocuSign account is charged. Your own DocuSign account is not involved, at all, in this scenario. Your client id (integration key) can be used by any DocuSign account user with their own account, once they grant consent to it.
Is it enough for our customer to pay for Standard eSignature Plan to make embedded signing work, or they should choose Enhanced Plans (the one where API feature is listed)
A. I don't believe that the standard eSignature plan includes support for embedded signing.
Should our account plan (which holds Integration Key) be at least Advanced Developer to support embedded signing?
A. Either Advanced Developer or a "regular" eSig account that supports embedded signing. This is for your testing purposes. If you use a regular account that supports embedded signing then your other company groups can share the account for use in sending out agreements for signature.
Also
Please sign up as an ISV with DocuSign via https://partners.docusign.com
(no charge.) Being a registered partner provides you with additional information and enables you to use the partner use license to sell your app to DocuSign customers.
Pro-tip: use your developer account to automatically test your app. Preferably once a day. New releases are first launched on the developer system about a week before production. DocuSign has thousands of tests to guard against regression bugs. But it is possible for a bug to slip through. If you detect any issues on the developer system then DocuSign will typically stop the production deployment to fix the issue.
Added
Re error message when a feature is not enabled: see this question.
Re which plans include the embedded signing feature: sorry, I don't have that information.
I am building a customer web portal or a self-service platform, one of the features of the portal is for customer to upload required documents. Customer would have to go through full authentication to access the web portal to upload required documents and perform other functions.
I want to embed DocuSign and use its signature capabilities for customer to fill out forms and provide signatures. Some of the documents requires multiple signatures from legal parties of an organization.
My questions:
How do I send DocuSign to multiple signers?
Would each signer have to authenticate to the portal to sign documents or is there a way DocuSign can route document to the signers without all of them authenticating to the portal?
Each signers/recipient can have their own unique URL which is different based on the recipient involved.
You can have multiple recipients sign the same document/envelope and each of time can sign, either in turn, or whenever based on the routing order.
URLs for signing should not be shared, as they are private for the signer.
Your app can either embed the URL inside, or if you would rather use remote signing, then each recipient would get an email with the link to sign.
There's no need for signers to authenticate, unless you wish them to do so, which is certainly more secure, but not a requirement of DocuSign.
Here is a code example for embedded signing in 7 languages.
Here is a code example for remote signing in 7 languages.
I've a use-case to integrate e-signature with an existing application of some confidential customer.
Initial question that came into my mind was: "Does signer need to have docusign account or not ?"
I've found the answer of the above question in "Login Requirements" section of this article:
https://support.docusign.com/en/guides/ndse-admin-guide-security-settings
As per above answer, it depends on the sender whether s/he wants signer to have docusign account or not.
But my question is "Why and in Which case a sender would like to have signer's docusign account and In which case it would be fine without signer's account ?"
Need help regarding the use-cases, i.e when an account is needed and when not.
Re: Need help regarding the use-cases, i.e when an account is needed and when not.
With DocuSign, a signer very rarely needs a DocuSign account nor has any charge for a signer.
Senders always need an account on DocuSign.
Signers don't need an account when:
The signing request is sent to them via email
nor when the signing ceremony is presented within the flow of a website (embedded signing)
The only time that I can think of where the signer must have an account is when the sender wants DocuSign to implement Part 11 privacy rules for their account. In this case, the signer must authenticate themselves and log into a DocuSign account before signing.
I have a system in which I am integrating the DocuSign API.
Inside my system my client can send a document to the emails that it defined.
I have a DocuSign account with the Integration Key enabled on my system, how do I register within my account the subaccounts for each of my clients to send their contracts to their clients using the API?
I have already tested the entire Docusign API, I just can not find how to register sub-accounts to send on behalf of each client of mine!
Your question is not too clear. Hopefully this will be of help:
DocuSign does not have "subaccounts."
DocuSign has organizations (which group together an organization's or company's accounts).
Customers often have multiple accounts, with or without the organization capability. Accounts have account-wide settings. So it is common that the HR and Finance departments will have separate accounts, with different settings.
Accounts have one or more members (users). An individual can be a member of more than one account.
An Integration Key (also called a client_id) identifies an application.
An Integration Key (and its app) can be used by any user on any account. The user must give permission for the application to act on his/her behalf.
DocuSign has a developer sandbox (called demo) and multiple production systems (Europe, North America 1, 2, 3, etc). The Integration Keys in demo are entirely separate from those in the production systems.
The "Go-live" process is used to copy an Integration Key from demo to the production systems.
Is it possible to create a temporary user which has the ability to annotate/tag only one document. This user should not have access to anything else in docusign except for that one document.
Alternatively, is it possible to create an editor recipient for a document through an api call, without that user being required to have a docusign account?
Per the docs:
[Editors have] the same management and access rights for the envelope as the sender and can make changes to the envelope as if they were using the Advanced Correct feature. This recipient can add name and email information, add or change the routing order and set authentication options for the remaining recipients. Additionally, this recipient can edit signature/initial tabs and data fields for the remaining recipients. The recipient must have a DocuSign account to be an editor.
So both Editor recipients and Senders need to have a DocuSign account.
You can programmatically create new users and then delete them, but then you have issues of gaining access to the envelopes that they sent.
In addition, there are business issues: DocuSign users are not sharable.
Ideas
Depending on your business requirements and situation, you can have a larger number of users, for less cost per user. That way everyone involved in the envelope transactions can be a user and have access/editing privileges as needed. Talk to your sales person.
Enable your users to set up the envelope via your software app, not DocuSign. Then your app sends out the envelope. If your app will be sending on behalf of multiple users, you can use the Send On Behalf Of technique.