Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons from Failed DocuSign Integration

profsmallpine.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Lessons from Failed DocuSign Integration

#51

Post by treis »

stingraycharles wrote: post #47
sunir wrote: post #43

Earlier quoted context omitted.

I think it is very unclear what is real and not real. OP is mostly passing blame to DocuSign without achieving full understanding themselves. That is more an indictment on OP than DocuSign even if there is some actual session security problem with DocuSign (likely from the deprecated API).

Yeah and it sounds like they were trying to do something that makes no sense for DocuSign to support: use a single account to sign all users’ documents. DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account? They support oauth and that makes sense and should be the way to do it.

>DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account?

By the signature.

I don't know how it works in DocuSign's internals, but there's no requirement for the signer to have an account. The point of the account is for users to see all of their documents in one place. In OP's case that's everyone's documents because they use a single account.

https://support.docusign.com/articles/How-do-I-sign-a-DocuSi...

Re: Lessons from Failed DocuSign Integration

#52

Post by Bamafan »

treis wrote: post #42
Bamafan wrote: post #36

Earlier quoted context omitted.

Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). A sophisticated enough client user would still have access to the all data associated to the API user.

>Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). It's not really a bug though. It sounds like DS shows a dashboard for the user absent an instruction to show a different page. That's a reasonable default. >A sophisticated enough client user would still have access to the all data associated to the API user. If you use one account to access an API then of course…

I think the part that you may be missing is that View 1 (embedded view) is hosted on DocuSign's domain.

So the view may be designed by the client, but it's not hosted by the client. It's hosted on DocuSign.

Then View 2, is the "dashboard" view which of course isn't designed by the client.

In an ideally designed embedded View 1, it should not be possible to get to DocuSign's "dashboard" (View 2). Sessions should be tracked in DocuSign's API and View 1 refreshes should return the user to hosted View 1 or should return an error.

Re: Lessons from Failed DocuSign Integration

#53

Post by btown »

propter_hoc wrote: post #48

FWIW, I've developed a lot of this sort of tool. For some reason, Adobe E-sign services (formerly known as EchoSign) rarely comes up, but it's actually quite good and cost-effective to develop with. Docusign is indeed pretty terrible as an API, but it does have the benefit that users have heard of it so it has a certain institutional credibility - which is usually important if you're developing the sort of app that n…

Can you give any guidance on Adobe/EchoSign's API pricing? Seems like it's behind a "contact us" enterprise plan these days? https://acrobat.adobe.com/us/en/sign/pricing/plans.html

It generally seems ridiculous to me that it's 2019 and APIs like https://app.hellosign.com/api/pricing are priced per signature request. Even if each finalized signature comes with regulatory retention requirements, that's far from a linear cost... and these are PDFs we're talking about retaining, not videos. The whole ecosystem reeks of price fixing.

Re: Lessons from Failed DocuSign Integration

#54

Post by nulagrithom »

stingraycharles wrote: post #47
sunir wrote: post #43

Earlier quoted context omitted.

I think it is very unclear what is real and not real. OP is mostly passing blame to DocuSign without achieving full understanding themselves. That is more an indictment on OP than DocuSign even if there is some actual session security problem with DocuSign (likely from the deprecated API).

Yeah and it sounds like they were trying to do something that makes no sense for DocuSign to support: use a single account to sign all users’ documents. DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account? They support oauth and that makes sense and should be the way to do it.

DocuSign should've recognized this and let them know the flaws in their plan, but in my experience they're _way_ too sales-oriented to ever do this.

I had a similar experience. I explored their API and got stuck on how to implement my use-case and how to ensure it's legally binding. Sales and "technical" resources assured me it was possible, didn't explain how, and everyone balked at any sort of legal questions and basically told me that was all on us to sort out.

I decided I didn't need help creating a box for users to scribble on. E-signature isn't a technical challenge at all.

Re: Lessons from Failed DocuSign Integration

#55

Post by treis »

inoda wrote: post #49
treis wrote: post #41

Earlier quoted context omitted.

This 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?

1. 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…

So you're not embedding the DS page in your site. You're redirecting the user to DS?

Re: Lessons from Failed DocuSign Integration

#56

Post by propter_hoc »

btown wrote: post #53
propter_hoc wrote: post #48

FWIW, I've developed a lot of this sort of tool. For some reason, Adobe E-sign services (formerly known as EchoSign) rarely comes up, but it's actually quite good and cost-effective to develop with. Docusign is indeed pretty terrible as an API, but it does have the benefit that users have heard of it so it has a certain institutional credibility - which is usually important if you're developing the sort of app that n…

Can you give any guidance on Adobe/EchoSign's API pricing? Seems like it's behind a "contact us" enterprise plan these days? https://acrobat.adobe.com/us/en/sign/pricing/plans.html It generally seems ridiculous to me that it's 2019 and APIs like https://app.hellosign.com/api/pricing are priced per signature request . Even if each finalized signature comes with regulatory retention requirements, that's far from a line…

Yeah, there's little I hate more than opaque "contact us" pricing. To my surprise when I inquired EchoSign was actually much cheaper than the alternatives. At the time, I had an API license from EchoSign that cost a few hundred dollars a year for a very large number of monthly document signings, with no hard limit (but polite requests to buy additional licenses if you went above the limit). I don't know if they've kept this pricing model though.

Re: Lessons from Failed DocuSign Integration

#57

Post by nsedlet »

We just completed an embedded signature integration with HelloSign. The HelloSign API plans were expensive - but still a fraction of what DocuSign charged (at the time HS was 20% as expensive - pricing seems to have gotten more comparable now).

Integration was easy. The Ruby SDK & JS lib worked great (we have Rails back-end / React front-end). Customer service has been good & responsive. They have to approve your UI before giving live access - but once we had the integration working it took Two slightly annoying things: (1) they don't have per-request fees if you go over your allotted usage. You'll get automatically bumped to the next plan which gives you 3x the request and is almost twice as expensive. (2) they wouldn't let us go month-to-month since we had an existing annual plan that we wanted to be under the same account (so we can share templates). This is tough since it's difficult for us to predict how many requests we'll need.

Re: Lessons from Failed DocuSign Integration

#58

Post by treis »

Bamafan wrote: post #52
treis wrote: post #42

Earlier quoted context omitted.

>Even if they added this feature, the API bug would still remain (it would just be covered up by the UI). It's not really a bug though. It sounds like DS shows a dashboard for the user absent an instruction to show a different page. That's a reasonable default. >A sophisticated enough client user would still have access to the all data associated to the API user. If you use one account to access an API then of course…

I think the part that you may be missing is that View 1 (embedded view) is hosted on DocuSign's domain. So the view may be designed by the client, but it's not hosted by the client. It's hosted on DocuSign. Then View 2, is the "dashboard" view which of course isn't designed by the client. In an ideally designed embedded View 1, it should not be possible to get to DocuSign's "dashboard" (View 2). Sessions should be tr…

I thought OP was embedding something from DS in their page. It sounds like they are redirecting a user to DocuSign.com. I agree that the user being able to access the requester's DS is a massive security issue. So massive that it seems implausible that it actually works that way, but I don't have any experience to know one way or another.

Re: Lessons from Failed DocuSign Integration

#59

Post by bdauvergne »

All those online signatures "click to sign" services are useless anyway, they have absolutely no legal value anywhere (their EIDAS/ETSI whatever are just buzzwords), even in France from where docusign is coming.

https://www.cryptomathic.com/news-events/blog/us-court-rejec...

Re: Lessons from Failed DocuSign Integration

#60

Post by inoda »

inoda wrote: post #14

I was on this project and can speak a bit more on the technical details here. A couple of high level goals: 1. We wanted to use their embedded flows, to keep the experience within our application as much as possible. 2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves wi…

I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable.

The main reason this felt so...sucky for lack of a better term, is that we had multiple discussions about our use case and were told that this would be supported (again, this turns out not to be true? not a huge deal, it happens), and were asked to pay $20,000 upfront of which we got $0 back once realizing the original promises were not true.

As OP pointed out, 20k for a huge company like DS might not seem like much, but for a small start up like us it is. Just from a consumer perspective, this seems like a crappy way to conduct business.

Post reply on HN