TL;DR If this question doesn't make sense, please check the following video explanation: https://www.youtube.com/watch?v=9o2KhiBf1lY
I created a Chrome extension and followed the directions here: https://developer.chrome.com/webstore/one_time_payments
In the drop-down, I changed it to a subscription system with a free trial.
And my Chrome extension successfully uses the License API to check the payment status.
But now I'm wondering:
Where do my users go to pay for the full version?
How long is the free trial configured for?
You might be thinking that I have to use the Payments API, but the documentation says:
If the trial is expired, you can direct the user to the web store listing to purchase the item.
Why does it say to direct the user to web store? If I go there, it just says to install the chrome extension, there's no option to pay for it.
And how can it know when the free trial has expired? I never configured a value for it and there's no "free trial duration" specified in the docs.
Meanwhile, the Payments API makes it clear that it's for in-app purchases with SKUs. If this is the only way to accept payment, what's the purpose of that pricing configuration that I set up above?
Thank you for your help.
You have all the answers in the documentation. Read it carefully.
You decide the length of the trial period. In your extension's code, when you check the user's license, it will reveal when your extension was first installed. Compare that with the current date to determine if the user is still within the trial period or not.
The trial and the paid extension are the same, both installed from Chrome's Web Store. If the purchase button doesn't appear to you may be because you are the developer.
In the documentation you have sample code to request the license and check the trial period.
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.
Testing out the platform I was running on both a developer account and a Trial Business Pro account until I purchased a standard plan.
Up until I purchased the standard plan, envelope statuses would update by the second and the functionality built with the Apex Toolkit was working well.
Once changing to the standard paid plan, envelopes statuses take 10-15 minutes to update and some functionality is not working.
My question is:
Do the different plans have different status updating times in Salesforce?
Is functionality of the Apex Toolkit limited between the different plans?
Does the Connect option (which is missing now) have anything to do with the above?
Thanks!
They do not. Writeback to Salesforce takes place via DocuSign Connect. Some plans don't support Connect out of the box but the actual writeback times / delays do not differ between account plan types.
Indirectly, the only way that a plan type can interfere with an API call that worked on another plan type is if it had entitlement to a feature that your new plan does not, IE: The ability to allow Comments, to set recipient signing language, to set envelopeID Stamp Control, etc...
I would highly suspect that it does -- in fact I'm a little surprised that your writebacks are happening at all if you don't have Connect enabled. Salesforce adds an object reference IE: Opportunity / AccountIds to the envelope's custom fields on send. When Connect sees these fields, it knows to write back to that specific object. Without Connect enabled and configured it shouldn't be able to process these writebacks at all.
I think you should have a conversation with your Account Rep first regarding Connect entitlement, then you can reconnect your Salesforce instances to the updated DocuSign account which is something that we can help you with.
Regards,
Matt
I'm approaching completion of my chrome extension and need to explore monthly subscription options. What is the best approach to doing this?
As #Deliaz stated, Chrome Web Store Payments supports both monthly and yearly subscription models. As with one-time Chrome Web Store payments, you have the option of providing a free trial.
For details about app payment options, you may check the Charging for your app documentation in the Overview.
Unfortunately the top-voted answer on this mentions Chrome Web Store Payments which was shut down by Google on February 1, 2021.
The only other thing I know like Chrome Web Store payments to monetize your extension is ExtensionPay. It's open source and works on all browsers, not just Chrome, which is nice.
Otherwise, you'll need to build an authentication system and sync it with your extension. Then you'll need to use a way of taking payments like Stripe or Paddle or Paypal or something and sync that with your user's extension.
I am curious if anyone else has had these options show up highlighted on the Developer Dashboard. I have been maintaining an extension since September that manages tabs and collects no information.
Highlighted in yellow on the Developer Dashboard:
Please provide the following information:
Physical Address
Privacy Policy
To ensure a more transparent and positive experience for users, the email address, physical address, and link to your privacy policy that you provide in the developer dashboard will be displayed publicly on your item details page(s) in the Chrome Web Store.
Please provide a current, valid postal address where you may be contacted. If you offer items or in-app purchase items for sale, you may be required to provide a postal address under our developer terms and consumer protection laws; failure to do so may result in the suspension of your account and/or sales of your items. Please ensure that you keep these details up to date if they change. By providing your email or postal address information, you consent to Google publicly displaying or disclosing that information in connection with your items. Learn more
My extension will prompt the user for a donation after 30 days, but it can be disabled. Setting a privacy policy is one thing, but I simply don't have a non-personal address I can give out. Google seems to be mistaking me as a business.
Since September 30, 2014. Google has already changed its policies regarding paid app developers. Every developer who opened the developer console starting that date was greeted with a message stating that a physical address must be added in account settings. The change will influence primarily developers who distribute paid apps or allow in-app-purchases.
Visit this link for more information.
Note the key phrase in the notification: "If you offer items or in-app purchase items for sale". I believe that means you're not required to give out your addresses if, as in my case, you have a free extension and an app that include "Donate" buttons, and if you're an individual, not a company.
Edit: This looks similar to the German Impressum law. Anyway, it doesn't look mandatory in my case.
Update - received this email from Google after asking them what was going on.
Hi Jason,
In accordance with consumer protection laws and current industry best practices, starting on 3/9/2016 we are implementing a number of changes to product listings in the Chrome Web Store. These changes will ensure a more transparent and positive experience for users. Changes include:
As a developer, you must provide a valid email and physical business address where users can contact you directly. The email address and physical business addresses will be displayed on your product details page(s) on the Storefront.
All products that offer in-app purchases to users and/or subscription-based products will have a price range (highest and lowest price) displayed on the ’s product details page in the Chrome Web Store.
You can add an email address and physical business by logging into your developer account in the Chrome Web Store developer dashboard (link). Please comply within 30 days of receiving a notification on the developer dashboard. If any of your products offer in-app purchases or are subscription based, please go to your developer account to review the prices and publishing status.”
It appears they removed the option to post my address from my account, so it is puzzling they sent this email.
I’m integrating authorize.net into my web application. I’ve used the direct post method (DPM)to charge the account initially. However, for each transaction I also need to set up automated reoccurring billing. How would I go about doing this without asking for the information again, particularly when after DPM posts the initial transaction, the credit card data is no longer available?
I also would like to get the status of each reoccurring transaction so it can be confirmed and followed up on if necessary.
You can't do that with DPM as it takes the user's credit card information off of your website so you don't have access to it. If you want to make an initial payment and then use ARB to create a subscription you need to use AIM with ARB.
You need to use the ARB interface in order to do recurring transactions but there are a lot of problems with it, like lack of support (send an email and wait a couple of weeks for a non-helpful response for example) and weak documentation.
Documentation for SOAP interface for Authorize.net ARB:
http://www.authorize.net/support/ARB_SOAP_guide.pdf
And for the XMl interface:
http://www.authorize.net/support/ARB_guide.pdf
ARB programming documentation:
http://developer.authorize.net/api/arb/
I just switched off of Authorize.net to USAEPAY. Here are some reasons why:
1. When you use Authorize.net ARB, your customer comes on the site to sign up, and you send the ARB request to create the subscription and you get back a success code so you give the user the subscription. Then later that night they actually try to collect the first payment and a lot of times this fails, so you get a spreadsheet emailed to you the next day about the problem. This is terrible because now you lost the opportunity to say to the customer at sign up time that the card is declined. Goodbye sale!
2. I don't know if they added this recently but they didn't have a way to verify if a customer's credit card is still valid. Imagine 3 months into a subscription the card is over the limit, or cancelled, or expired etc. You don't know so how do you prompt the customer to put in a new card? You just stop getting paid, unless you want to manually open these spreadsheets and start emailing customers. YUCK.
USAEPAY works much better, the API is easier, its much better documented and you get email responses in 1-2 days and its less expensive. For example, you can query USAEPAY to get a list of successful payments, and verify that you shouldn't deactivate the account for non-payment:
http://wiki.usaepay.com/developer/soap-1.4/methods/getcustomerreport
Before you go too far with AuthNet I highly encourage you to save yourself a lot of pain and contact FranchisePaymentNetwork (FPN) to get set up with USAEpay.
They can even POST BACK to your website to let you know if a transaction is successful or not for recurring billing transactions and you can query it to verify that customer payments are getting collected so you know if you should expire an account or not.
I am not affiliated with USAEpay or Franchise Payment Network except as a satisfied paying customer / consumer of their services.