I want to dive into SendGrid (GoDaddy SMTP is sh*ty).
But I don't understand the difference between the Free plan and Lite plan.
Of course, Lite plan is really cheap, but seems to have less features than the Free plan, which is... free.
I first told myself that the free plan most be a trial (with limited time). But the website says "No credit card needed, no expiration."
So why does somebody would prefer the lite to free?
Bonus question : The only feature I need is something like a "Send Folder", so I can be sure all emails have been sent. Does both plans have this?
Update: the Lite plan no longer exists.
The Lite plan is for people that want to pay purely based on the number of emails sent. It has a limited feature set as a result. The free account has all features and has no expiration. Someone might choose Lite instead of Free because they want to send more than 12,000 emails/mo but don't need all the credits or features in the $9.95 plan.
SendGrid doesn't store any email content, so there isn't really a "sent" folder, but you can see a report of the last 7 days of email event activity by clicking on the "Activity" item in the navbar. Additionally you can have all this data pushed to you in near real-time via the Event Webhook, and very soon you'll be able to pull via API as well.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I've found today in my inbox an email from google where they announce that CWS payments API is deprecated
I'm working to create a Chrome extension that I want to release with the in-app payments support to let the user purchase a license to unlock full features. I was oriented to the CWS native payments API, but Google's decision to deprecate the API is a very bad news.
At the moment I've found a nice Wordpress plugin that will manage licensing, I'm thinking of using it to create a licenses backend but I'm not sure about it because it's mainly focused to be used for wordpress themes or plugins, so to implement it on client side for an extension would require some workarounds.
How do you will manage your in app purchases and licensing for Chrome extensions or Electron apps?
Alright, so as I am in the same situation as you are, I did a little bit of research. Here is a summary of my findings and comments on the matter.
There are three things to think about before you get started with the implementation:
The type of payment processing service you want to use;
The way you want to limit features for the free version (and for multiple tiers of plans);
The security of your users information through your extension.
Let's go through each of these one at a time.
1. Type of payment processing
There are two main types of service providers that will allow you to collect payments in you extension. Payment processing platforms are the first type: they allow you to process payments and will generate receipts, but they won't manage the different taxes and regulations of different countries. If you operate solely in one country, or in a few countries where taxes and regulations are the same, this won't affect you.
However, if you have users around the world, especially in Europe, implementing the rules to handle all of the different taxes and regulations can get really complicated and messy. But you have to do it, otherwise you put yourself in a situation where you are at risk of getting fined. That is where the second type comes in: the merchants of record. These are companies that will charge the users on your behalf, removing all of the complexities of taxes and regulations from your plate. They're essentially acting as a reseller of your products. Of course, they take a small cut from your revenue to pay for the weight that they're taking off your shoulders and putting onto their own.
Payment processing platforms will be cheaper (ex.: 2.9% + 0.30$ per transaction for Stripe), while merchant of records take a bigger cut (ex.: 5% + 0.50$ for Paddle). However, if you deal internationally, the 2.1% higher price is likely more advantageous for you, just because it saves you a lot of time and development work.
It's important to note however that merchant of records are unlikely to take on a brand new project, especially for Chrome extensions. That's because the amount of revenue those extensions generate on average is pretty low, and often not really worth it for them. Still, I suggest you hit up a few of them before deciding do go the classic payment processing way, just in case you can get in touch with a salesperson who sees potential in your project and is willing to take you on.
Here are a few merchant of records:
Cleverbridge
2Checkout (offers both MoR and basic payment processing services)
Paddle (does not support new Chrome extensions at the moment)
FastSpring (does not support Chrome extensions anymore, as of 2021)
Here are a few payment processing platforms:
Stripe
Paypal (from my experience, Paypal is a lot less developer friendly than Stripe)
2. Limiting features for free or tiered plans
The way features are limited for non-paying users will differ from one extension to the other.
If the features you want to limit in your extension already rely on a backend, to fetch or process data for example, it would make sense to implement the limitations on the server side. You would simply pass the user's ID, which could be stored in chrome.storage, to each request made to the backend. In addition to that, you could also disable the related elements on the client side, such as hiding or greying out buttons, tabs or fields, to make it clear to the user that those features are locked. You'll want to make sure the limitations are in place on the backend as well however, because otherwise a user could just inspect your extension and enable premium features without paying.
If your extension mostly or only operates on the client-side, then you will have to render the interface conditionally, based on the user's plan. The scripts or interfaces that will be added will most likely have to be returned by a backend, as pretty much anything that is done only on the client-side could potentially be inspected and exploited. In that case, any backend technologies or platforms you are most familiar with can probably be used to set things up.
Keep in mind that most of the payment processing and MoR listed above have APIs and guides on how to implement them securely in apps and websites. However, if you know Wordpress well and can set up a secure communication between your Wordpress and your extension, go ahead. If you want to use an online service like Zapier to link existing authentication and licensing services together, go ahead and do that!
There could be a lot more details in this section - there is a ton of material to cover, so I suggest you look for articles and tutorials online to help guide you in this process if you don't have much experience in the matter.
3. Security
This section won't be long, but it is very important one. No matter which payment processing platform you decide on or how you limit access to features in your extension, it is crucial that you make sure that your users information can never fall into the hands of another user. That includes reverse engineering and exploits of your system.
The more things you decide to handle yourself, the more risk there is, especially if you are not experienced. Keep that in mind when making your decision(s).
That's all for me. I hope that helps a bit!
I know it's probably a lot of information without any detailed "how-to", but without having in-depth knowledge of your product and situation, it is impossible to say what you should do exactly.
P.S.
If that can offer any guidance, here's what I will be doing for my own extension. Seeing as it's already very reliant on a PHP backend, I will add a few features to the backend in order to communicate with the Paddle API. So all of the limitations will be implemented on the backend, and I will add messages and visual indicators on the frontend to inform the free users of what they can and cannot do.
[Edit]
I just received a message from Paddle indicating that they do not support new Chrome extensions at the moment. Sorry for the misleading there.
[Edit: June 2021]
After an update earlier this year, FastSpring has updated their security standards, which makes it unusable within Chrome extensions. After I enquired, their support agents informed me that they do not support Chrome extensions anymore (and that it was only "accidentally" supported before).
We have a web application that occasionally receives web request that we detect as attempts to inject SQL code, from Google virtual servers (Compute Engine).
I was asked to find a way to identify who is responsible for said machines, so that we can take the corresponding legal actions on our part, or at least, confirm that Google shut down those servers.
What I need is to find a way to communicate with Google, by email or chat, but I haven't found information about it.
EDIT 1:
I have tried to communicate with Google to indicate the information I am looking for, but the only contact available in my case is with the billing department, which could not confirm that they will give me that information if I buy a technical assistance package. On the other hand, I understand that this package is to review requirements of the applications that you own, but in my case I am looking for legal information.
What was recommended to me was to enter the corresponding application in
https://support.google.com/code/contact/cloud_platform_report?hl=en
but I have not received a response for weeks.
I am disappointed in Google, especially because of the importance of computer security.
I will keep searching information.
You can find all information concerning Tech support, phone support and Chat support in your Google Cloud console. Also, this doc shows different supports based on your support role or package.
I have a chrome extension that im looking to monetize with subscription and free trial.
I have followed all the guide detailed here: https://developer.chrome.com/webstore/one_time_payments
Everything works, its all good, just now I need to know how to actually trigger the payment flow when a user decides they want to pay for my extension.
I can see that there is a "buy.js" for in-app purchases but im not sure how you are supposed to do it for one-time payments.
The only way I can see of doing it is by opening a new tab to my chrome store page and then somehow educating the user that they need to press the orange button...
Theres got to be a better way of doing it than that tho, surely??
If you want your extension to be paid using Chrome Web Store Payments, you have to follow Chrome Web Store Payments rules, which include fixed price tiers and the fact that payment must be initiated by Chrome Web Store. The in-app purchases work differently.
So yes, your users will have to subscribe using the orange button in your extension's Chrome Web Store entry. Usually they need not to be "educated" to do that: after all, that is the page they installed your extension from, and the orange button was already there.
Depending on which kind of free trial experience you offer, you can display relevant reminders to your users.
For example, if your free trial limits some functionality of the extension, you can prompt the users to subscribe when they try to use one of the premium functions, and/or display a Subscribe button in a visible part of your extension that links to your Chrome Web Store entry.
If your free trial is time-limited, you can display a counter of how many free-trial days your users have remaining, and the Subscribe button mentioned above. When the trial period is over you can automatically alert the users and open the Chrome Web Store entry of your extension. This latter approach (time limited free trial period) is the one I am currently using in my extensions and so far I've had no problems with the users or confusion on their part.
I'm making a desktop app for a company, and they would like to get it featured in the windows app store for Windows 10 users.
The app will likely only work on desktop computers, it's not designed for mobile. What it does is perform lookups on lists of cell phone numbers, and outputs a spreadsheet with carrier info, and it requires a credit for each cell phone number looked up. The credits are bought in bulk through the company's sales team, there is no automated method to purchase them.
Because there is no automated system, it would be difficult to set up in-app purchases, also if Microsoft takes a cut of in-app payments then it wouldn't be feasible due to the tiny profit margin of the credits. But according to this (section 10.8.1), if the app consumes anything that has to be purchased then it needs to use the in-app purchasing api.
Does anyone know if there's some way around this? Or if it only applies to regular apps and not desktop only ones, which I understand are a different type of listing?
I realise I can get a developer account and go through this with them but I don't really want to spend this company's money on the dev account if Microsoft are just going to say no.
Thanks :)
That section of the policy refers to payments taken within the application.
It doesn't sound like what your application will do though. Your application is allowing the allocation (spending) of credits bought separately.
It's a small distinction but an important one. You may have seen other applications work around such limitations by requiring the user to go to a website to buy something and then return to the app to use it.
When submitting the app there is a declaration for "This app allows users to make purchases, but does not use the Windows Store commerce system." You can read more about this declaration at https://msdn.microsoft.com/en-us/library/windows/apps/mt148523.aspx but this shouldn't apply to your scenario.
There are potential legal implications here and if the company has any concerns about entering a legal agreement with Microsoft regarding financial matters then they should seek appropriate legal council. Having a developer ask other developers about legal matters is likely only suggest asking a lawyer.
The documentation (http://developers.box.com/webhooks/) talks about webhooks in the context of "user's account". I read that as getting notifications only about the objects to which I have access.
Let's say I want to be notified every time there is a new upload anywhere across my organization. Do I need to be an admin to accomplish this, or is the webhooks scope not subject to my user permissions?
While we're continuing to enhance webhooks, there is some administrative functionality built-in. For instance, if you can get your webhooks installed for all your users, and have the webhook point to one endpoint, that can track all activity in your account.
There is a way to force webhooks on all users in your domain as an administrator. However, this feature hasn't been optimized for companies that use webhooks for internal use. That's still in progress.
If you'd like to be kept in the loop, or try some workarounds with what we have, feel free to contact us at api [at] box [dot] com. With more information, we may find something that works today, based on your exact needs.
At this point, the webhooks are only provided at the user level. If you log on as an admin and setup an application that gets webhooks, you will only get the same set of notifications as you see in the "Updates" tab in the Web UI.
We are looking to expand the webhooks capabilities, and this is one area that we may explore. However, it is not currently scheduled, so I can't provide any idea of even rough dates.