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.
Related
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.
Currently, I working with Stripe gateway service. In my integration use only one Dashboard Stripe Account (one Publishable key + Secret key). I intend that my system create charges in two diferrentes Dashboard Stripe Account, depending others conditions.
I have analysed the "Connected accounts" using only one Dashboard Stripe Account, but is not usefull for me. I intend that each billing company have their Dashboard Stripe Account access (without mistake).
Is there any alternative beyond create customers / payment methods in both Dashboard Stripe Accounts?
pic1:
pic2:
You can build your application to manage two separate sets of keys based on the business logic for when to use one account or the other, but outside of Connect there is no other native support for something like this from Stripe. But you can absolutely do it manually. Yes, you would need to create any customers in both accounts, but this is true in a platform-connected account arrangement, too.
I am new to Google Actions Development. My organization wants to create some Google Actions for our project so that those Actions can directly call our APIs through Google Assistance and get the required data. Earlier I created POC using my personal Gmail account but as now we want to use it for organizational/commercial purpose I want to know which paid Google developer accounts, subscriptions do I need to purchase to use it for my organization.
I believe that the only paid account you'll need is the Firebase. When you create an Action from the DialogFlow platform it automatically creates a Firebase project for you. In order to make external calls, you'll have to update it to a paid account. So if your organization creates a Google account (or use an existing one of course) to create an action, they can just update the Firebase project to the paid and add you as a developer. If you're interested in a more secure agent, I'd suggest you to have a look at the Dialogflow Enterprise version. It has the same capabilities, but offers the security of the GCP.
Is it possible to customize gmail landing page ? I am thinking of using gmail for business to manage my emails and wondering if one can include a link on his business website which directs to their work email account (gmail one) webpage featuring their business logo on it.
If not Google, does anybody provide such flexibility ?
Sounds like you want google for work:
https://www.google.com/work/
"With the exception of Google Apps Vault, all are included in the basic plan, which costs $5 per user per month or $50 per user per year. A premium package, Drive for Work, includes Google Apps Vault plus unlimited storage is available for $10 per user per month."
You will be able to customize the theme with logos of your choice.
I can't be the only one creating websites for customers that want to use PayPal. PayPal says that I have to use the customers account to create an account specific sandbox. Well, I don't want access to the customers account. I don't want to know their password. Is there a way to test the PayPal functionality without having direct access to the customers account?