Propsed Extension to payment JWT

[David Bialer]

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).

[Matt Basta]

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.

_______________________________________________
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

[David Bialer]

----- Original Message -----
> 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.

This is for when carriers in a single country don't support the same price points, typically minimum or maximum would be the primary use case. But presumably, they can skip a particular price point, say one support $.50 and another one doesn't. This may be because in reality, they may only support certain fixed tiers in their system. This is NOT the case today, but it could potentially be - and just looking to plan ahead should this case come up.

>
> 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.

I think we would be the decision here in the hands of the developer as to whether they wish to do this. I don't believe we should restrict users by country (like other stores), or in the future, they could choose "Strict Enforcement" of countries, which would mean to only sell to users in that country (based on SIM or GeoIP). Again, we put the decision in the hands of developers and don't do it, by default, by restricting user rights.
>