I need to integrate DocuSign in my mobile app to allow my customers to sign documents with embedded signing & sending flow.
My doubts are:
Does my customers (senders) need to pay an eSignature Plan?
Does my company need to pay an API Plan?
I'm looking for the Intermediate API plan and I notice a limit of 100 documents/month, but my customers need to sign way more documents, a few thousand I think, how can I proceed?
Let me try to answer your questions.
Yes, if they need to send - they need to pay for some plan. The plans are based on the number of envelopes they send a month. Similar to minutes or phone plan. If, on the other hand, they only needed to sign, they wouldn't need an account. But someone else would have to be the "sender" and have the account.
You do need an account to be able to publish your app and go-live. Almost all plans, with the exception of freemium are eligible.
Your customers would have to contact our sales team to get an account that meets their needs. https://www.docusign.com/products-and-pricing to scheduled a call or call 1-877-720-2040
Related
A few weeks ago I implemented my first REST integration with the DocuSign API. Things over all went smoothly and with very little complaints. One particular hang up I experienced though was some confusion in regards to the Developer account and how it relates to the General account. I started with a developer account and used the test credentials to build my integration. Once my integration passed inspection it required me to choose another paid docusign account that the integration key would "go live" on. This is all pretty straight forward.
The curve ball came when I actually went to purchase the API account and it said, "you aren't eligible to purchase this". There isn't clear instruction on the site, so my questions are:
1.) In what order does the account creation need to go? Developer > General (Paid) > API Plan (Paid)?
2.) Does DocuSign expect the user, as the customer, to purchase the plan or should that plan be purchased through my developer account?
I tried to reach out to customer service directly, but it was pretty much a, "give us all of your money, then we'll help" situation. I have several customers who are interested in this integration, but I'm not comfortable presenting this as an option until I get a better understanding of the process. Any advice is greatly appreciated.
In general, DocuSign does require a paid account to complete the Go Live process. If you - the integration owner - will not be using DocuSign yourself, you would want to reach out to the [DocuSign Partners program][1] to receive a free Partner account that can hold your integration key instead of having to purchase one.
From there, the end users of your integration can purchase their own DocuSign accounts. You could potentially act as a reseller of DocuSign if you were so inclined.
https://www.docusign.com/partners/become-partner
If you still need assistance, please email apihelp#docusign.com with this information. Someone will help you right away.
I have a simple question. We are a CRM and are integrating with Docusign. So, whenever our customers want to send an envelope, they can send it from the CRM.
Do our customers have to purchase a separate API plan with Docusign?
From what I have read through, that is not the case but API limit of 1000 API calls per hour apply.
Can anyone confirm this?
You'll want to talk to your Account Manager for specific recommendations, or the Sales team if you don't have one.
As a general matter, you would need to own an API plan as the integration's owner but your customers could use your integration on any DocuSign account that has the appropriate level of features/functionality.
I am in the process of creating a DocuSign integration. Would anyone happen to know which type of account customers need to purchase from DocuSign in order to leverage my DocuSign integration? Can't the credentials for any account outside of a free trial be used to access a DocuSign integration as a customer? What's odd is that most integrations I've seen in the past require the user to have at least a Professional Account, which I believe is now called Standard (# $25 per user).
Any feedback is greatly appreciated! Thanks.
So, the account you use to develop the integration has nothing to do with the account used by customers to access your integration.
As long as the account has "API Access" it could use any integration. These includes most of the plans that are sold including the lowest tier (web and mobile) and even some trial accounts get access to the API (at least while the trial is on). I can't get you a through answer about every single type of account as we have so many, but in general you should find most accounts would be able to use your integration.
We're planning a web service based on recurring monthly payments.
The site would have similar user accounts as Netflix or Spotify. The site would have an account section were the user can manage the billing and other details.
I've looked into different payment gateway provides, but I'm still wondering how to implement the user account as a part of the main site and how to combine that to the billing system.
First some information:
The site would first have just one monthly plan xx$/month
Credit cards need to be accepted
We're based in EU
We don't want to use PayPal
The user account section would contain:
User profile (name, email, etc.)
Website options (features on / off)
Subscription & billing management (edit credit card, current period, cancel, etc)
Questions:
How to combine the basic user accounts on my site with the billing system provider?
What information should I store in my own database?
Should I use a 3rd party user account management software on top of a payment gateway provider?
If so, which one would work similar to Spotify's account management?
How to setup the first sign up flow where user enters CC information?
Thank you for the ideas!
This is relatively easy to do using Laravel (a php framework) and a package called cashier. This package uses a payment service called Stripe which allows you to create recurring payments. There is even a tutorial on how to do it on Laracast.
I have a client who has content that he wants to publish on the web (and potentially for iPad). He wants the viewer to pay to subscribe for the content.
Is there a service out there I can integrate with to for handling the accounts and collecting the monthly subscription fee (using credit cards or something else)?
There are several services out there that can help you with this - Recurly (where I work), Chargify, CheddarGetter, Spreedly, etc. These services handle the recurring billing aspect, customer management, email communication, following up with failed payments, etc. You'll also need a payment gateway (to process the cards) and a merchant account (for the payment gateway to deposit the funds into).
Authorize.net and PayPal both have recurring billing features, but the logic for upgrading/downgrading accounts is not there or difficult to use, and you'll still need to handle customer communication for failed payments and other actions.
You need to use a payment gateway here, which will be responsible for handling the transaction between your site and the many different payment networks. There are a lot of operations happening in between, so you might want to check out the wikipedia article for a step by step information on that.
We personally use authorize.net in our company for many of its advantages, some of which are:
It has an API that makes it easy to integrate with any language.
It is a trusted brand already, proven by the number of merchants that use them.
It is secure.
It provides the service with a reasonable price.
Most of major payment gateway providers do support recurring billing or subscription plans, paypal,authorize.net etc, most of the time you have to log in to your account admin console and configure a plan, and send the payment plan id with the payment request to the payment gateway. some payment gateway providers, like Braintree supports to create recurring billing plans dynamically and assign users to that plan at the run time it self, how ever it's always better to go for a local payment gateway provider or a payment gateway which provides low fees, if your preferred payment gateway provider is not supporting recurring billing anther options is to store cc details on the server and and handle it your self but it's a great risk to store cc details on the server, and you will have to follow PCI standards and it's hard.