865657 - Price tiers are wrong for In-app Payment tester app

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect)

Description

[Victor Carciu]

Prerequisites : 
Install In-app Payment tester app from http://people.mozilla.org/~kmcmillan/mktdev.html

Steps to reproduce:
1.Open the In-app Payment tester app and set the "pricePoint": 15
2.Press the "call navigator.mozPay()" button
3.Enter your PIN

Expected result:
Confirm payment page will be displayed and the price is the correct one

Actual result:
For tier 15 , the price in Euro is 14,19 Euros instead of 28,39

Comment 1

[Kumar McMillan [:kumar]]

Andy, is this tier maybe configured wrong? Where is that accessible, in admin pages?

Here are some logs:

Apr 25 06:16:42 web2.stage.addons.phx1.mozilla.com: [None] w.pay:DEBUG Received JWT: {u'aud': u'marketplace.allizom.org', u'iss': u'dac0cef1-6d96-46a8-a61e-c3edd62ed20b', u'request': {u'name': u'Virtual Kiwi', u'icons': {u'128': u'http://inapp-pay-test.farmdev.com/media/img/kiwi_128.png', u'32': u'http://inapp-pay-test.farmdev.com/media/img/kiwi_32.png', u'64': u'http://inapp-pay-test.farmdev.com/media/img/kiwi_64.png', u'48': u'http://inapp-pay-test.farmdev.com/media/img/kiwi_48.png'}, u'chargebackURL': u'http://inapp-pay-test.farmdev.com/chargeback', u'postbackURL': u'http://inapp-pay-test.farmdev.com/postback', u'productData': u'transaction_id=387', u'pricePoint': 15, u'id': u'd8f0604f-3e4b-434e-af97-e3bc26864554', u'description': u'the most delicious fruit on the Internet'}, u'exp': 1366899385, u'iat': 1366895785, u'typ': u'mozilla-stage/payments/pay/v1'} :/data/www/marketplace.allizom.org-webpay/webpay/webpay/pay/forms.py:31

Apr 25 06:16:43 celery1.stage.addons.phx1.mozilla.com: [] w.solitude:INFO creating product with  name: Virtual Kiwi, external_id: d8f0604f-3e4b-434e-af97-e3bc26864554 , seller: {'resource_pk': 26, 'uuid': 'f61377ef-bc1b-4116-9961-f8f0631f1c0f', 'bango': {'full': {}, 'created': '2013-02-21T12:51:55', 'support_person_id': 598545, 'modified': '2013-02-21T12:52:16', 'seller': '/generic/seller/26/', 'resource_pk': 15, 'package_id': 923485, 'finance_person_id': 598545, 'admin_person_id': 598545, 'sbi_expires': '2014-02-21T00:00:00', 'id': '15', 'resource_uri': '/bango/package/15/'}, 'paypal': None, 'active': True, 'resource_uri': '/generic/seller/26/'} :/data/www/marketplace.allizom.org-webpay/webpay/lib/solitude/api.py:220

Apr 25 06:16:53 celery1.stage.addons.phx1.mozilla.com: [] w.solitude:INFO transaction webpay:c131c336-53e5-4c3e-af3d-9bab449b12f3: billing config ID: 10154790; prices: [{'currency': 'USD', 'amount': '14.99'}, {'currency': 'CAD', 'amount': '14.99'}, {'currency': 'GBP', 'amount': '11.25'}, {'currency': 'EUR', 'amount': '14.19'}, {'currency': 'COP', 'amount': '31280.00'}] :/data/www/marketplace.allizom.org-webpay/webpay/lib/solitude/api.py:211

Comment 2

[Kumar McMillan [:kumar]]

Attachment: screenshot of price

Comment 3

[Andy McKay]

The price tiers here:

https://bug863491.bugzilla.mozilla.org/attachment.cgi?id=739664

Show that 14.99 USD should be 14.19 EUR.

And the price tiers on -dev and stage both reflect that for tier 15.

 ~ $ curl https://marketplace.allizom.org/api/v1/webpay/prices/15/ | python -m json.tool | more | grep EUR -B 1
            "amount": "14.19", 
            "currency": "EUR"
 ~ $ curl https://marketplace-dev.allizom.org/api/v1/webpay/prices/15/ | python -m json.tool | more | grep EUR -B 1
            "amount": "14.19", 
            "currency": "EUR"

Comment 4

[Andy McKay]

When bug 863491 went out a bunch of tier names changed because tiers were added and removed. So "Tier 15" is no longer that, it's now tier 12. Really we should be using that is not going to change, like the tiers primary pk or resource uri.

Comment 5

[Kumar McMillan [:kumar]]

according to the attachment, pricePoint 15 should be USD 29.99 and EUR 28.39. This app on stage seems to be correct: https://marketplace.allizom.org/app/pricetier15/?src=mkt-search So why would /api/v1/webpay/prices/15/ return the wrong price? Are you saying 15 does not mean Tier 15?

Comment 6

[Andy McKay]

 ~ $ curling https://marketplace.allizom.org/api/v1/webpay/prices/26/
{
  ...
  "name": "Tier 15", 
  "localized": {
    "locale": "$29.99", 
    "currency": "USD", 
    "amount": "29.99", 
    "region": "United States"
  }, 
  "resource_uri": "/api/v1/webpay/prices/26/"
}

15 is the name of the tier, 26 is the primary key. The app should be passing in the primary key of 26.

In the past tier name and primary key might have conveniently lined up, but now they don't. This is confusing for many things, what happens when we introduce a new tier, a 0.30c tier. Does that become tier 1b?

Actually I think the real problem here is naming of tiers. I think that adds to the confusion and gives little to no value. It's much easier to say "3.99 tier" rather than "Tier 3, 3.99" for example.

What I would suggest is:
- remove tier name completely
- use USD price as the key, so pricePoint=0.99

That's clear and simple to the developer that we aren't talking about Tier 15 or 26 and we aren't getting confused with primary key. It's still just a string that the server has to interpret, but its damn obvious to the developer what the price is.

Comment 7

[Wil Clouser [:clouserw]]

I like that, but let's hear how others' feel

Comment 8

[Andy McKay]

David, would you mind me removing names from tiers?

Comment 9

[Kumar McMillan [:kumar]]

The only thing I don't like about pricePoint=0.99 is it's very US centric. In Europe and many other countries, it will be confusing for developers to declare price points in dollar values. However, I see what you mean about using ID numbers.

Comment 10

[Andy McKay]

(In reply to Kumar McMillan [:kumar] from comment #9)
> The only thing I don't like about pricePoint=0.99 is it's very US centric.
> In Europe and many other countries, it will be confusing for developers to
> declare price points in dollar values. However, I see what you mean about
> using ID numbers.

Well we have to show something, I think its better than trying to localise it. Any better ideas welcome.

Comment 11

[David Bialer [:dbialer]]

I am not sure if you are saying the name of the tier would be "0.99", or we would be passing in a numeric value of the price.  One of the challenges is that many operators only support discrete prices that they enter into their systems.  So if say pricepoint=1.19 was entered, systems that don't support flexible pricing would either round it to the nearest supported tier, or reject it.  

The other challenge is to have the app show the price in a local currency.

I would think we want use names on price tiers, which could be anything, but conveniently names things like "Tier 4", with a mapping to local tables that mean .99 in USD, .89 in Euros, etc.

Comment 12

[Wil Clouser [:clouserw]]

He's saying the tier would be "0.99" and they'd have to think in USD.  The alternative would be tiers which are out of order.  For example:

> Tier 1 = $0.10
> Tier 7 = $0.33
> Tier 8 = $0.50
> Tier 2 = $0.99
> Tier 3 = $1.50

Perhaps a wording change would help?  Something instead of tiers?  Group?  Price Point?  US Price Point?  Neither solution is great. :(

Comment 13

[Wil Clouser [:clouserw]]

Alright, how about we space the tiers out to give us expansion room in the future?  Example:

> Tier 5 = $0.99
> Tier 10 = $1.99
> Tier 15 = $2.99
> Tier 20 = $3.99

That way the numbers are kind of meaningless and we have some wiggle room in the future.

Comment 14

[David Bialer [:dbialer]]

+1 to wil's suggestion.  Would start at price tier 10 = .99 and increment by 10 per $1

Comment 15

[Wil Clouser [:clouserw]]

(In reply to David Bialer [:dbialer] from comment #14)
> +1 to wil's suggestion.  Would start at price tier 10 = .99 and increment by
> 10 per $1

Perfect, let's do it

Comment 16

[Andy McKay]

Alright so let's:

- alter all the tiers
- alter the model so tier name just contains the unlocalised value "10" or "20" and the "Tier: 10" gets added on by model.tier_name or something
- included the name in the API as pricePoint, so it's pricePoint="10"[
- alter the marketplace API to filter by tier
- alter the webpay to lookup by tier

...then update our test apps.

Comment 17

[Kumar McMillan [:kumar]]

This works for me too. Andy, the main thing to support is when an in-app payment requests pricePoint: 10 that it gets the same price point as what an app would sell for. Sounds like your solution will implement that.

Comment 18

[Andy McKay]

https://github.com/mozilla/zamboni/commit/0774c9
https://github.com/mozilla/webpay/commit/491441

Note, the apps will need updating to send the right tier.

Comment 19

[Bram Pitoyo [:bram]]

Krupa and Andy sent me this bug last Saturday in reference to me asking why the tiers are displayed in increment of ten; so I am sorry for the overdue response.

While it might be too late , my response would be to do away with showing tier entirely and use local currency as a reference currency. “Reference currency” means “the currency that the price drop-down menu is formatted in”.

The benefits are twofold:

1. Reference currency is simply set according to the country selected in the Settings page, so user is less likely to be confused. This also solves the US-centric problem

2. We can add new tiers of arbitrary value without introducing awkward tier numbering gap.

For example, on the 10-increment tier system, let’s say that I want to add a new price with a value of USD 1.19. What should I name this tier? Given that USD 0.99 = tier 10, and USD 1.99 = tier 20, then USD 1.19 = tier 12. Easy.

The problem appears when I add two new price tiers with an increment of less than 10 cents. Let’s say that these two new tiers will have a value of USD 1.29 and USD 1.25. USD 1.29 = tier 13. This is easy. But what should USD 1.25 be? To name it tier 13 would break the 10-cent organization, but to name it tier 12½ would be silly.

Since tier values are arbitrarily assigned (though regular) and can’t handle uneven gaps elegantly, I think that using local currency value as reference will make price equivalence math less headache-inducing for our developers.

Remember that, unless user selects “United States” as a country on the Settings menu, the reference currency will not be USD.

Lastly, on the backend, we’re still going to have a reference table that associates one currency values with another. The difference is, we don’t show this table as “tiers”, but as straight up localized value.

I hope the feedback helps!

Comment 20

[Andy McKay]

Having drop downs for price tiers in localised currency is fine. I think the main issue that people had was the price tier (or pricePoint) is used in the in-app payment code as a string. That in-app payment code is created in the developers app and the developer will not interact with the Developer pages for that.

I would rather avoid trying to use localised price strings for that, as it would just increase confusion, not decrease it.

https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments#Set_up_your_server_to_sign_JWTs

https://developer.mozilla.org/en-US/docs/Apps/Publishing/Marketplace_Payments?redirectlocale=en-US&redirectslug=Apps%2FMarketplace_Payments#Price_points

Note also that documentation calls them price points not tiers.

Comment 21

[Wil Clouser [:clouserw]]

Comment 20 answers the question well.  We can keep evolving the designs, but at this point, let's use other bugs and lower priorities. :)

Comment 22

[Kumar McMillan [:kumar]]

I would like to use price points everywhere instead of tiers (if we have to show price points to developers, which is a separate issue). The new name price point was a change we made somewhat recently to align with mobile carriers where they use the term "price point"

Comment 23

[Andy McKay]

Agreed its not high priority, but once we go live its really, really hard to change the tiers - each time we do we break peoples in-app payments. If we can, coming to consensus now is easier than changing it later.

Comment 24

[David Bialer [:dbialer]]

To summarize - the change is to not use 'strings' like "Price Tier 1" but to use Price Points as a number that is not necessarily reflective of a particular currency, though will be mapped to other currencies.

Comment 25

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #20)
> Having drop downs for price tiers in localised currency is fine. I think the
> main issue that people had was the price tier (or pricePoint) is used in the
> in-app payment code as a string. That in-app payment code is created in the
> developers app and the developer will not interact with the Developer pages
> for that.

Thanks for the clarification. It turned out that I was trying to answer the wrong problem!

My worry was about the price that developers see in the interface (the design), not about the code or its implementation. I wanted to make sure that we don’t use strings that we will change later or has inconsistent gaps between each level.

But you were talking about the pricePoint that was used in the code, not anything user-facing. I’ve most definitely responded about the wrong subject, so I’m really sorry about that! We should still make the UI change, though.