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.
Related
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
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.
I want to create a job that runs once a month and charges customers for different fees.
Is it possible to charge multiple customers in one api call ?
If not, what is the rate limit of the api ?
There is no way to charge multiple customers in one API call. You'd need to create one charge for each customer. As for the rate limit of the API, it's not published officially and you'd need to contact Stripe's support directly about this here.
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.