I've used DevPay. My experiences were generally positive. My problems with it were as follows.
1) Amazon doesn't expect one user to buy your service more than one time. Frankly, I didn't expect it either when I started the service or I would have structured it differently. I ended up having to give people free 2nd accounts when they asked for them, since I had no way to bill them for a 2nd account. User would sign up for my service (twitter related), like it, and decide they wanted their other twitter account to also use my service. So they would come back to my site, sign up again with their other twitter user name, I'd send them to Amazon to pay, and they'd get an error, since they had "already purchased that item".
2) Ending the service. When I decided to end the service, I went to try to cancel my devpay billing, so they would just stop billing all my users. This was an email procedure, not a form, which was weird. The email response I got was unsatisfactory to me.
Per your request, we have denied your product. New customers will not be able
to sign up for your product any more. Please note, however, that your product
has customers who have signed up already. These customers will continue to get
billed for their use of your product. If you don?t want your customers to use
your application, please contact them and have them unsubscribe from your
application by going to http://www.amazon.com/dp-applications.
I still have customers paying, since I can't cancel them, all I can do is tell them to cancel themselves. I feel guilty when I see them continue to pay for a discontinued service.
3) I had a general feeling that I was losing some customers due to them not having an Amazon account. I have no actual data to back that up.
All in all, it worked as advertised, but I think I won't use it again.
You're dead-on with #3. We used Amazon Simplepay for a subscription service, then recently switched to direct credit cards via Chargify. Subscription rates doubled instantly.
What percentage of your users are still paying yet do not use or do not have access to the service?
I did dev work for a client, service based site, $10.00 a month. I put in some simple tracking reports to let me know a users login history. I found that high percentages of users paid, logged in once, and never logged in again. This struck me as odd because the service was by nature something if you paid for, you would need to login to use it. It was not a trick to get someone to sign up for a site that adds no new value over time.
What was really interesting is the ~14% of users that only logged in once, ever, but still were paying every month on their credit card. 14% seems really high. I wonder if AOL has the same 14% of users not dialing in but paying for dial up still.
I also found ~5% (guesstimate) go right for a chargeback, do not contact support, and do not click the very easy to find "Refunds" tab that allows a one click full account deletion of all data, refund of the partial month, (which was moved to charging at the end of service, instead of up front).
It is a shame that not even Amazon is challenging PayPal's monopoly in Europe. Neither Amazon DevPay nor Amazon Simple Pay is available in Europe, and Google Checkout is only available in the UK.
Amazon doesn't strike me as being the best of the bunch in terms of i18n, really. Here in Italy, their presence is kind of limited in terms of countries/languages where they are present: only Germany, France and UK. Granted, it's more difficult for a company trucking in physical products to move into new markets, but they seem to be taking their sweet time about it.
Google is a bit better, but still strikes me as very US-centric in some ways.
I hadn't heard of it before so I figured others might not have either.
More importantly, with the introduction of micro instances, this creates a very low barrier of entry into creating a service behind a paywall. I'm looking to do just that, so I'm also curious to hear other people's experiences with DevPay.
In my experience micro instances are not suitable for on-demand services since they have no reserved CPU and frequently stop responding for minutes at a time. They're basically a way for Amazon to sell excess RAM to grid computing customers. On the other hand, I tested them a few days after they first became available and was just experimenting with them as a way to test scalability of a product, so things may have changed since then.
If DevPay worked outside of the US I would be using it for my product today. Since it doesn't, I'm not. And that is probably not a bad thing because it has caused me to build my software in a much more generic way which means I'm not dependent on EC2 either - and in fact, I'm now saving money because EC2 is fairly expensive compared to the other options I now have, including running on some of my in house capacity where it makes sense.
The main notion of DevPay is to act "on behalf of" a user, in order to outsource billing to Amazon while using the common AWS APIs. Once a user signs up to your service using DevPay you get a custom Access and Secret Key that's bound to this user and allows you to do all S3 actions while he's billed.
Unfortunately this hasn't been introduced for EC2 - they only allow Paid AMIs and no way to start these for your users without having their AWS credentials.
Ahhhh interesting, so it doesn't provide you with a generic payment system, but instead provides you with a way to meter content on S3 or the use of an AMI.
That's still an interesting service model, where you charge users on resource consumption rather than on a per item basis. I wonder how well this would work for an image or video processing service or other similar services.
It's been awhile since I checked, but there was also a limitation that meant you could only associate a DevPay ID with an S3-backed AMI, ruling out the more useful EBS-backed AMIs.
Not much content in that thread. Has any used this since then? I'm interested to hear from people who have used it. I'm not seeing a whole lot about it in general, seems DevPay got some interest in 2008 and then faded off.
Agreed. I wasn't aware this was around since 2008 when I initially posted as I hadn't heard of it before. I figured this had already gotten a fair bit of interest so I would just let it go rather than changing it after the fact to an Ask HN post.
Looks like your customers have to have an Amazon account before they can purchase. How would you sell such a concept to a company if they do not have an amazon account?
Perhaps I am reading it wrong...
"""
Embed this link in your web site to allow your customers to purchase your product through Amazon. Customers can sign in with their Amazon.com credentials and select a credit card that is stored in their Amazon.com account. After your customers purchase your application, they are directed back to your web site.
"""
You're reading it right. You send them through Amazon, where they log in with their usual Amazon credentials and can check your rates. When they confirm the purchase, they are redirected back to your page with their authentication tokens as URL parameters.
Without an Amazon account they can't purchase, although in my experiences this hasn't been brought up as a problem by potential customers.
Yes. We had rolled out a Devpay-backed product called "Cloud Gear" about a year ago and ended up pulling it off the shelf due primarily to two irreconcilable issues:
1. their accounting process appeared to have some fundamental innacuracies at the time. We tracked the launching of instances and our numbers did not match up with theirs. There was anomalous usage behavior and Amazon eventually admitted there had been tracking glitches on their end - difficult to deliver a service if the underlying accounting can't be trusted. Note: this may have been (likely has been) remedied since but it was problematic around January '10.
2. As another commenter noted, the signup process for a newcomer was too much to ask of someone who didn't already happen to have an AWS account. And even for those who did it was still a cumbersome hamster maze to put them through and undoubtedly hurt the adoption numbers.
#1 has likely been resolved. #2 is inherent to this type of on-behalf-of arrangement. It is an interesting model and could definitely enable some innovative services. We just found it not ready for primetime when we had tested it back in late '09-early'10.
We tried a while ago. My suggestion: only use it if you're specifically selling to Amazon users (e.g. a EC2 image for Solr). If you're just selling a general SaaS or server product, it's hard enough to get someone to sign up for your service; don't make them sign up for another service too.
