New Release of DevPay - Lower Fees and Reduced Risk

Amazon DevPay is pretty cool. It allows developers to use Amazon's billing and account management to layer their own business models on top of Amazon EC2 and Amazon S3. Developers using DevPay include SmugMug (for SmugVault), Wowza Media Systems, Red Hat, and SearchBlox.

Earlier today we rolled out a brand new release of DevPay. The new release has two important new features, lower fees and reduced risk.

How, you may ask, are lower fees a feature? Well, it turns out that many developers would like to use DevPay to simply pass their actual AWS charges through to their customers without marking them up. The new release makes this possible because the 3% DevPay fee is now charged only on the value added by the developer. There's still a 30 cent fee for processing each payment.

The new fee structure will be of value to developers using DevPay on top of EC2 because it allows them to pass on bandwidth charges directly. There is no longer a need to add an additional markup to cover the fees that were formerly charged on Amazon's share of the cost. This directly leads to a business model which is both better from an economic perspective and simpler from a structural perspective.

Also, with this new release, Amazon DevPay shares the risk of customer nonpayment with developers. You’re responsible for the cost of AWS services that a customer consumes only up to the amount that the customer pays. Based on your price, if the amount a customer owes is lower than the cost of AWS services that the customer consumed, you’re required to cover the difference, even if the customer does not pay.

The net result of these changes is that the fees developers will pay to use DevPay will be lower. Developers will also pay less in the event that their customers don't pay.

It is worth pointing out that both of these features were implemented as a direct result of customer feedback which started in a thread on the AWS Discussion Forum for DevPay. We're here, and we are listening, but you've got to speak up if you want to be heard!

-- Jeff;

Comments

[Felix]

Hi Jeff,

When are you going to offer the DevPay service to European developers? We do not have US bank accounts. Amazon has several European stores so i don't see why it takes so long.

[John Luxford]

I'll echo Felix and ask the same for Canada. It would be great to have an option like DevPay up here. So far, DevPay, Google Checkout, and Paypal Pro are all US-only (rather, Paypal Pro is 3x the price in Canada, making it unreasonable to choose). I'd love to see some competition, specifically from a flexible option like DevPay, come to Canada and shake things up. We have startups and developers too!!! :)

[Jim Wilcoxson]

If a developer writes a program that uses AWS and sells it at a fixed cost, and uses DevPay to bill customers using the service without markup, why should the developer pay any fees (the 30 cent transaction fee), and why should the developer be responsible to Amazon if the customer doesn't pay? By making his AWS application available, the developer has given Amazon an ongoing AWS customer and is not (in this case of no markup) making any money from the customer after the initial purchase of the application.

If the developer uses DevPay in the future to bill the customer for something other than AWS charges, perhaps for an application upgrade, then I can see where the developer pays the 3%, the 30 cent fee, and loses if the customer doesn't pay.

But for the developer to owe money to Amazon for a customer who doesn't pay, even though the developer is not marking up the service, does not make sense.

The changes are good, but you need to go a little further down the same road Jeff. :-)

Jim

[Justin Kruger]

Other features that amazon should implment.

*charging customers for public S3 files.

*allowing us to charge items by proxy, like instance hours.
-in this case, lets say we have a web service that process video, images, music or some sort of data. obviously we would like to manage the scalability of that app, and charge the user for only what they use. in a few situations, as the developer we might need to have a few things up and running, but it would be nice to charge for that service via processing time, or other metrics that we come up with. so, persay, per instance hour, per image, per movie, per video, per file, per audio file, etc.....

in eccense processing that video or file becomes a job and to some how set a price for that service would be grand.