What is the use case for variable price across carriers in a particular region? The use case for variable prices across regions, as you've said, is to make apps affordable in different regions. This doesn't really apply to carrier, though, as a user under one carrier vs. a user under another carrier in the same region probably wouldn't have a different perception of an item's value. E.g.: In the US, I wouldn't assume that Sprint customers would be willing to pay more or less than AT&T customers for the same item.
Otherwise, I think this is a great idea. The biggest challenge, though, is going to be enforcing the pricing on the client side, since this change would put the choice of which price point to use in the hands of the user's device rather than in the hands of the developer generating the JWT. ----- Original Message ----- From: "David Bialer" <[email protected]> To: "dev-webapps" <[email protected]> Sent: Tuesday, May 28, 2013 11:17:16 AM Subject: Propsed Extension to payment JWT I would like to propose an extension to payment JWT to be able to support more flexible pricing by country, carrier, and payment method. The first issue that I would like to solve is that not all payment methods support all pricePoints. For example credit card payments with a particular payment provider do not support pricePoints lower than $.99 (pricePoint 10), while other payment methods may support lower price points. This issue also comes up for the Marketplace not tied to a carrier, where the minimum payment via credit card today is $.99. So if an app is priced at $.10 and is also available on Android (which may be credit card only), we would need to charge a minimum of $.99. This would be the case for an app offered in "Rest of the World". The second issue is that prices should not have to be uniform across all countries. Socioeconomic differences across countries mean that the value of a $.99 app in one country may be more affordable at $.50, for instance. Ultimately this should be up to the developer to decide what price to charge in a particular store. NOTE: today we do not restrict users to only purchase in their region, so a user could buy from another region if the price is cheaper and be charged on their credit card in their own 'home' currency. The third issue is that not all carriers support all price points. The reality of the situation is that they typically have a max and minimum amount they can charge to a mobile bill. Also, some carriers have fixed price tiers. By carrier, I am referring to the combination of country:carrier as a unique combination. Allowing local overides by country and carrier would allow the developer to take control of their pricing. One suggestion to add to the JWT something like below: pricePoint: 1, localPricePoints: { venezuela: {pricePoint: 10} } .. to say: use price point 1 everywhere except for in Venezuela use price point 10. The case of needing to price differently between carriers within a region has not yet occurred. But planning for it, we could expand as follow. pricePoint: 1, localPricePoints: { venezuela: { carriers: { "*": {pricePoint: 10}, movistar: {pricePoint: 5} } } } To say, use price point 1, but in venezuela use price point 10 except movistar where it should use price point 5. A method overide may be that we have a rounding rule - something that says if a price point is not available round up to nearest, round down to nearest, or none (default). So, for instance: pricePoint: 5 roundingRule: up (OR down, none) would mean if an app sold in Italy is offered at pricePoint 5 (€.49) and offered on Android which would need credit card payment, it would be offered at pricePoint 10 €.89). _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
