none
Payment model for a cloud app with Azure backend? RRS feed

  • Question

  • I am building a Win8/WP8 application with an Azure-hosted service as a back end. I have been struggling to find a business/payment model which would allow me to support Azure-related costs.

    I have read this thread: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/thread/8b78d62d-e8d5-4928-9ebb-67d5f4a907c3. The question nicely sums up the general problem with currently available payment models in cloud-based application scenarios, but it does not really match my situation.

    To make the explanation simple, let's say that

    • My app allows users to collaboratively edit a document that is stored in Azure.
    • A user can initially create a certain number of documents for free.
    • The server-side keeps track of remaining document count (i.e. a user account is maintained there).
    • To limit storage costs, all stored documents will eventually expire (and will be automatically deleted).

    The above system is based on "credits": the users occasionally pay for the right to create a certain number of additional documents.

    So far I haven't been able to come up with a payment model which could work with this system, having in mind the following constraints:

    1. The payments obviously won't be regular: users will buy credits as needed.
    2. Once paid for, the credits themselves will not expire. A user can decide to create a document a year or two from now.
    3. Users should be able to buy more credits even if they haven't used up all that they currently have.

    The constraint (1) rules out any model based on subscription. That leaves me with in-app purchases of application features. I could try and wrap credits into features, say Feature1=10 credits, Feature2=25 credits etc.

    Problems with feature-based model:

    • A "feature" should somehow expire when the remaining credits drop to zero. But how? Features do not have such a counter. (I'm talking about the remaining document counter, not the number of times an application can be run.)
    • The constraint (3) prevents users from buying the same feature twice in order to add some more credit.

    Are there any alternatives? Am I missing something? Thanks in advance for any hints and suggestions.


    Sunday, February 3, 2013 9:03 AM

All replies

  • While this might not address the challenge your facing with the payment model, have you considered using the SkyDrive API that is part of Live Connect instead of an Azure backend? This would enable your app to use the storage associated with your users' SkyDrive accounts instead of having to pay for it in Azure. Since storage would be associated with individual SkyDrive accounts, you wouldn't have to worry about purging old documents to reduce storage cost.
    Monday, February 4, 2013 7:45 PM
  • Unfortunately, the description of "collaborative document editing" I provided above was too simplified.

    In reality "collaborative" means there is a non-trivial logic involved when merging changes from multiple users, which is something that requires a service (i.e. code) that runs at the backend. There are other reasons too, such as sending notifications to all participants (for which I plan to use newly introduced service notification bus) and a need to maintain per-user account (for keeping track of their remaining credit, and billing).

    All this can be nicely handled by an Azure service.

    Azure costs are per-usage. They force application developers to pass them onto the end users somehow. Given the increasing importance Azure has and will have in future when it comes to cloud applications, I find it strange (and discouraging indeed) that Microsoft does not offer any payment model which would even remotely address the cloud-based scenarios.

    As I said, cloud costs are per-usage costs. By their very nature they cannot be addressed by recurring subscriptions, and neither by features -- no matter how much I try to bend them to fit.

    So the problem I have (which I call "credits") is really a general problem with the current payment models offering, that are out of sync with the cloud-based development model which slowly but surely becomes predominant.


    • Edited by vkdev Tuesday, February 5, 2013 4:46 PM
    Tuesday, February 5, 2013 4:45 PM
  • Hey vkdev,

    As Adam touched on, for your specific challenge I am not aware of a specific resolution while operating inside of the markets you said in your original post, but have you taken a look at Azure apps? I pulled the information for you, and if you were not aware of that option, I am glad I was able to provide it:

    http://msdn.microsoft.com/en-us/hh328553 | Windows Azure Marketplace MSDN Article

    I feel operating through that would circumvent the issues in your original post, but also changes the delivery of your app (through Azure, and not Windows Phone and Windows 8) but I could see an app for all three that would communicate with one another would be very attractive for the professionals that already use Azure. Just two cents to help you out, best of luck with the app!

    -Robert 

    Tuesday, February 5, 2013 5:29 PM
    Moderator
  • Thanks Robert,

    I was not aware of the Azure Marketplace, I will take a look. While I don't think it will be feasible to switch to it in the case of this particular project I'm working on, it might be interesting in future.


    Tuesday, February 5, 2013 5:50 PM
  • After doing some more research, it seems that Windows Phone's Wallet (and in particular OnlinePaymentInstrument class) might be a way to build a payment model based on credits.

    Unfortunately, there is no equivalent feature on Windows 8, so in the end I might have to drop the Windows Store version.

    Wednesday, February 6, 2013 7:58 PM
  • Hello Vkdev,

    You also have the option to use a third party in-app purchasing engine in your Windows Store app, this is permitted by the Windows Store terms.

    -Eric

    Thursday, February 7, 2013 6:42 PM
    Moderator
  • Thanks Eric,

    Sounds interesting. Could you please elaborate that option a bit more?

    More specifically, does that approach support the scenario in which users would pay proportionally for their usage of the application, and where the payments can be arbitrarily frequent (i.e. pay-as-you-go model)?

    Thursday, February 7, 2013 7:51 PM
  • Hello Vkdev,

    This would really be up to the third party commerce engine you choose to go with. You could build your own and tie it into any merchant service that allows credit card processing (such as PayPal) or use some of the one third party services that specifically support in-app purchasing.

    If you used your own in-app payment system you could charge by the minute if you wanted, the limit would be your imagination and what you think your customers would be willing to pay for.

    The big disadvantage of using your own in-app payment system is making the initial sale since it would eliminate the impulse purchase advantage that you get with Microsoft's built in system. For the first purchase, using your own in-app purchasing, your customer would be prompted to provide a payment method, such as a credit card, and at that point some customers might balk at entering this information since they may have the expectation that they should be able to use what they have on file with the Windows Store. Some customers may also hesitate if they do not feel confident enough to provide their credit card information to an unknown entity.

    Of course the advantage to you of implementing your own in-app purchase system is you would not have to pay Microsoft the 30% cut of the proceeds.

    -Eric

    Friday, February 8, 2013 6:59 PM
    Moderator
  • All that I am looking for is a a way to allow users of my application to occasionally (i.e. whenever *they* want) purchase some sort of credits, proportionally to their anticipated usage of my back-end resources.

    It's not a question of avoiding that 30% cut, it's quite the opposite: the last thing I want to spend my time on is rolling out my own payment system. Figuring out the payment model has been so far a tremendous uphill battle, and I lost precious time that should have been used for the development.

    I still don't believe that there is no officially-supported payment model which would fit my business case, because it really is a general one. There will be more and more people who will try to build connected cloud-based applications and they will inevitably face this exact same problem.

    There just has to be an officially supported way to do this.

    Could you guys check this issue with some of your colleagues who worked on a design of the whole payment system built into WP8? (The same question applies to Win Store.)

    Friday, February 8, 2013 7:44 PM
  • I'm having the same issue. I need the backend of Azure to support a database for multiple device use from a single user. If the user has the app on their cell, tablet and laptop, I can't have a localized database. Now, that being said I need a way to pay for the users/clients data usages from Azure and the only way to cover that cost is to support a subscription based business model. Unfortunately, Windows Store doesn't support the subscription model. Third party? Don't even know where to begin with that! Microsoft is shooting themselves in the foot here. If they offered the subscription model with auto renewal, they would make money from both the store fee and the cloud. Any ideas would be helpful, thx.  
    Friday, February 8, 2013 11:54 PM
  • I Just found a company called FastSpring which will allow your users to utilize the purchase of credits. Check it out www.fastspring.com

    Saturday, February 9, 2013 12:20 AM
  • @jjackson12172

    The issue isn't the lack of a subscription model. You simply cannot use a subscription model to offset your Azure costs, because on one side you would ask your users for fixed, regular payments, and on the other side you would have variable, arbitrarily frequent costs based on actual usage of your back-end resources.

    Even if your users go through the hassle of approving regular payments (which is questionable), their actual usage of your Azure resources (a database, computing time, traffic, whatever) will wildly differ from any fixed amount you ask them to pay.

    During one period your users can be particularly active and generate a lot of Azure costs. During some other period they can be inactive and they for sure would not like to be charged for not using your application.

    The real answer is to use the same payment model as the one imposed to you by the Azure back-end: pay-as-you-go, which means a payment model based on credits.

    The question is, which one Microsoft thinks it should be?




    • Edited by vkdev Saturday, February 9, 2013 12:02 PM
    Saturday, February 9, 2013 11:58 AM
  • Rolling your own payment solution, be it PayPal, FastSpring or something else, should only be the last resort.

    Having a third-party payment processor means

    1) Having to spend considerable time implementing the solution correctly (this time would be better used for development of app features)

    2) Your users will have a different, unfamiliar (and more explicit) purchase experience, which will negatively affect your sales.

    Saturday, February 9, 2013 12:06 PM
  • Hey  

    Check out the windows store certification requirements, specifically

    Requirement 4.8 | The app can offer the user the ability to save this authentication, but the user must have the ability to either require an authentication on every transaction or to turn off in-app transactions. If your app uses the Windows.ApplicationModel.Store namespace for in-app purchases, this prompt is provided for you.

    Also here are the current listed business models, which follows along nicely to your original question

    Choosing your business model | This is a great article that explains each breakdown into more links with deeper model specific information.

    I hope this helps, great thread guys!

    -Robert

    Wednesday, February 13, 2013 4:18 AM
    Moderator