3 ms·
View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.
by inoda 8y ago
View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.
- treis 8y agoThis is the point where someone is extremely confused but I'm not sure which one of us it is. My understanding is that you have a page at the end of some process for the user to sign a document. The first time the user goes to the page they see the screen to sign something (View 1). They refresh the screen. Now they see some dashboard like screen where they can see everything (View 2). Is that not right?
- inoda 8y ago1. We want the application user to sign a contract. 2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah) 3. We redirect the user to the special DS url. 4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.
- treis 8y agoSo you're not embedding the DS page in your site. You're redirecting the user to DS?