We currently use the API for embedded signing in our web application. When reviewing doc reference guide for offline signing, I'd say it's less than crystal clear how that really works. If I'm offline when I obviously can't call the API, so how does one in fact "sign" with DS?
I can appreciate how our client app (again, which currently does embedded signing) can prepare an envelope 'request' offline, and then send that request once we have connectivity. However the REST API guide says the user in fact "signs" the doc while offline -- how does the user ever get to the Docusign interface to do signing?
from the docs
To use Offline Signing, the customer using a client application to
create an envelope on an Internet-capable device, such as a smart
phone or tablet, that is not connected to the Internet and has a
recipient fill out and sign (or initial) the envelope documents. When
the device later connects to the Internet, the client application
uploads the envelope information to DocuSign where it is processed.
Does our offline app (running, say, in/as a Chrome app) somehow connect to local client Docusign software onboard the laptop or mobile device while offline? Any pointers to more complete documentation?
From the docs:
"IMPORTANT: Access to the offline signing capability is limited by
integrator key information. If your integrator key does not have the
correct authorization, you cannot use offline signing. Access to the
offline signing capability will be evaluated on a case-by-case basis."
The reason is because your software would be responsible for providing the legal evidence that the transaction actually happened with the proper security checks. This requires a tighter business arrangement and agreement between your company and DocuSign.
Please get in touch with your business development manager and they can set up a time to talk.
-mb
Related
How can I sign a document via API call without email client and UI interaction? Or if there is no way to sign, perhaps there is a way to force change status of a document?
I've seen many people asked for this and the answer was no, but all those posts are 2 years old. Perhaps there is a solution to it today?
It is possible to do everything via UI, but it is a terrible idea to spend time on an external service instead of your system under test.
Some say it defeats the purpose as the signer must view the document first, yes, but it is irrelevant, I simply want to test the flow of the system under test.
Please advise!
For testing purposes, you do not need to unit test the DocuSign signing ceremony since we test it all of the time. Instead, test that your API calls create the DocuSign envelope correctly.
For example, after your application creates the DocuSign envelope, your tests can interrogate DocuSign (via the API) that the envelope exists, is ready to be signed, etc.
If you're using embedded signing, you can test that your app can successfully obtain the URL for the signing via the DocuSign API.
For an end to end test, test software is available (from test software organizations) to interact with a web browser as a human does. Only test envelopes can be "signed" in this way.
For production signing of documents, the DocuSign signature appliance supports programmatic signing of documents using standards-based signatures (digital signatures). Your workflow must be authorized to sign documents on behalf of the signer.
For example, programmatically signing invoices sent by a company to its customers.
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 have an app were there are 2 kinds of users.
A builder and an owner.
Now there is a centralized platform that I am building, were each builder who have their own docu sign account with them, will register. And then provide with a docusign URL (I am not sure what that is), and the owner then clicks on the link, once they are logged in to their part of the system. They sign the document using docusign and the builder gets the corresponding response in the centralized system.
Is this approach can be done using docusign? Or the working of this is completely different?
You're likely referring to embedded signing vs remote signing from what I understood from your description.
https://developers.docusign.com/docs/esign-rest-api/esign101/concepts/embedding/
In embedded signing, your app will take care of authenticating the users on DocuSign's behalf.
Yes. The Builders are the DocuSign senders. As you say, they have the DocuSign accounts that will be integrated into your system.
The owners are DocuSign recipients. More specifically Signer Recipients.
The owners do not sign into DocuSign at all. They may register (and login) themselves with your app, that's a different issue.
When appropriate, the owners click a link on your app to sign documents.
You then have some options: did the builder initiate a signing request for the owner to sign at some point in the future? Or is the signing request initiated when the owner decides that they want a document generated that they will then sign? (Or both?)
When it comes time for signing, if the signing ceremony is presented by your app to the owner, we call that embedded signing.
If the builder initiates a document to be signed by the owner, then the quickest technique is to immediately send a signing request (by email or SMS) directly to the owner. That's called remote signing by DocuSign. (The other way to do it is to wait until the next time the owner logs into your app. I would not recommend this since it would tend to slow down the completion of the signing process.)
I want to add docusign functionality to an iOS app using this API:
https://www.docusign.com/developer-center/api-overview
Consider this use case:
An agent visits a client in their home. The agent brings his own iPad with my app installed. While interviewing the client the agent fills in all the information on the iPad app that I provide. This is a regular application; not a fillable .pdf. A fillable .pdf is not sophisticated enough to gather all the information we need to gather.
At this point the app could generate a .pdf with all the data that was gathered.
What are my options to have the client sign the document?
Is is possible for the agent to hand the iPad to the client for signing?
Can the client sign without an email address?
What are the caveats to those options?
The docusign site is good, but it is not easy to understand the user experience from the API.
I would guess that the client needs an email address and needs to sign the forms on their device that receives email, but I wanted to confirm.
Take a look at Docusign embedded signing for your usecase.
Embedded Signing - or the Recipient View workflow - allows users to
sign directly through your app or website. When you embed your
recipients you are telling the DocuSign platform your app will
generate signing URLs, authenticate your recipients, present the
signing request, and re-direct once the transaction is complete.
For browser integrations re-directing or framing can be used to host
the signing workflow, for mobile apps (iOS and Android) you should use
a webview.
I am trying to understand how the https://squareup.com/ square Credit Card reader works.
What would be the underlying middleware that is being used to
send the data to the squareup server,
process the payment
send verification to a user of a successfull payment
This is implmented on the iPhone, could there be a generic middleware that could be used for other devices to access this service created, so we could have all type of smartphones access a similar service language independent?
Also what security protocols would be used to ensure the data is sent encrypted over the network?
Their own website contains details about their security technology. They appear to use common and trusted technologies like SSL, which isn't a surprise.
If you want to build an application that integrates with their service, you should contact them. It's possible that they will require you to purchase a license in order to do so. They would also be the authority on the protocols and middleware required to integrate with it.