827986 - Expose API for price tables for use with in-app payments

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, enhancement, P2)

Description

[Matt Basta [:basta]]

We need an API that can be CORS'd by apps that implement in-app payments. It will accept:

- User's region
- Preferred currency
- User's persona email (?)
- A price in a specified currency

It should provide:

- The localized price for the user's region

This will be based on the price tables (yet to be written?). It will allow developers to show in app purchases in the proper default currency.


This feature could be an abstraction (or clone) of Bango's "dynamic price buttons".

Comment 1

[Andy McKay]

(In reply to Matt Basta [:basta] from comment #0)
> - User's persona email (?)

What would we use that for?

> - A price in a specified currency

Would this be a price or a price tier?

Comment 2

[David Bialer [:dbialer]]

This would also imply that the app is able to specify its region.  Do we need an API to get the region for an app?  Or just let the server figure that out - but it would need some clue like the IP address.

Or possibly it should take:
price tier, region or IP_address (depending on which is better)
and return currency and amount (

possibly also currency character or then a call to format a price using currency currency and amount - as the format of a price would depend on the currency character.

Comment 3

[Matt Basta [:basta]]

(In reply to Andy McKay [:andym] from comment #1)
> (In reply to Matt Basta [:basta] from comment #0)
> > - User's persona email (?)
> 
> What would we use that for?

If the user is a user on Marketplace, we should default to the region that they have specified.

> 
> > - A price in a specified currency
> 
> Would this be a price or a price tier?

Presumably a price tier (not sure whether we use price tiers for in-app payments).

Comment 4

[Andy McKay]

(In reply to Matt Basta [:basta] from comment #3)
> (In reply to Andy McKay [:andym] from comment #1)
> > (In reply to Matt Basta [:basta] from comment #0)
> > > - User's persona email (?)
> > 
> > What would we use that for?
> 
> If the user is a user on Marketplace, we should default to the region that
> they have specified.

Hmm interesting. It would be nice to avoid it for the scalability and cachability on the client. We would have to default to returning US for everyone, so its harder for spammers to harvest valid emails from the API, although it would still allow someone to find an email if it has a non-US region setting.

I wonder if we could pass in a region without asking the marketplace and once the request hits webpay compare the requested region and the users region, if any:

"We showed you the amount for Brazil, but you said you are in Afghanistan, so we are showing you that instead. Here's the choice for Brazil if you want that."

> Presumably a price tier (not sure whether we use price tiers for in-app
> payments).

We use price tiers.

Comment 5

[David Bialer [:dbialer]]

We could also use the geolite database referred to in Bug 774746 to implement a get user location.  Maxmind website says their country resolution is 99.8% accurate.

I'm not sure if email address is the best for determining location.  The question is what we want for location to base pricing on:
a) the user's current location from IP address
b) the billing address (I don't think we have access to this)
c) any setting on the device for location
d) the user's Marketplace account regional setting (if there is a Marketplace and there is a region set)
e) location based on geolocation (GPS) - would need to be a privileged app.
f) current location based on where Bango thinks you are (from network information)

There is also no guarantee that the user has a Marketplace account (if they download a freemium app anonymously and then use in-app payment, which could be a large use case).  

So I think the preference in order would be d, f, e, a, f, c, b.

Comment 6

[Wil Clouser [:clouserw]]

(In reply to Matt Basta [:basta] from comment #0)
> We need an API that can be CORS'd by apps that implement in-app payments. It
> will accept:
> 
> - User's region
> - Preferred currency
> - User's persona email (?)
> - A price in a specified currency
> 
> It should provide:
> 
> - The localized price for the user's region
> 
> This will be based on the price tables (yet to be written?). It will allow
> developers to show in app purchases in the proper default currency.

Why don't we just expose our price tiers via an API?  Like, GET /services/payments/tiers?currency=euro .  That will get you the whole list of USD<->Euro tiers and their related tax/fee and net developer info.  Would be way easier and doesn't involve geolocation at all.

Comment 7

[Matt Basta [:basta]]

We could do that, but for an app developer, we're putting a lot of heavy lifting on their shoulders. If I'm a developer and I want to have my list of in-app purchases:

- Super Berries $1
- Cheat Mode $5
- Super Cheat Mode $15

How do I know what currency to list each of those in? I don't know where the user is, or have any knowledge of the cultural or geographic boundaries which segment currencies and regions.

We need a way for the developer to say, "Here's my user, here's the list of things I know about them" and get back an appropriate currency. We could return the whole price tier, but the point is to know what to show the user rather than what the prices are.

Comment 8

[Andy McKay]

(In reply to Wil Clouser [:clouserw] from comment #6)
> Why don't we just expose our price tiers via an API?  Like, GET
> /services/payments/tiers?currency=euro .  That will get you the whole list
> of USD<->Euro tiers and their related tax/fee and net developer info.  Would
> be way easier and doesn't involve geolocation at all.

We already do: http://zamboni.readthedocs.org/en/latest/topics/api/payment.html#pay-tiers - web pay needs this so we just exposed it to the world.

I think doing the lookup is a valuable idea, I just don't want to send the users email.

Comment 9

[David Bialer [:dbialer]]

I still don't think this solves the problem, and perhaps the title of the bug is not stating the problem correctly.  The issue for the developer is getting back the right price and the right currency unit that is appropriate for the region the user is in for 1 or more tiers.   This needs to be based on an understanding of the user's region as well as the available price tiers.  Otherwise the heavy lifting, the selection of the right region (or column in a table) would be left for the developer to figure out.  They can get back all these prices in different currencies, but they don't have any idea as to which one to put on the "buy" button.

Perhaps the right bug title should be "Tell the app what the correct amount and currency is for a given price tier" in order to support in-app payments. 

I also think this is P1.

Comment 10

[Wil Clouser [:clouserw]]

P1s as currently marked in bugzilla are representing work that needs to be done before apps can be bought - a p0 if it existed.  P1s for the rest of the quarter are sitting as P2s right now.  Apologies for the confusion.

Comment 11

[Kumar McMillan [:kumar]]

I think we can launch in-app payments without this feature. However, it means that devs will have to hard-code prices in a single currency or make a rudimentary guess based on http accept-language. Adding an API for them will be a good enhancement to avoid user confusion and to help improve purchase conversion.

Comment 12

[Andy McKay]

Zamboni middleware already does all this work so see: https://github.com/andymckay/zamboni/commit/48957c#L0R65. As we add in more regions, geoip, currencies mappings, the API will get it all.

Comment 13

[Andy McKay]

https://github.com/mozilla/zamboni/commit/f80dc3

Comment 14

[Kumar McMillan [:kumar]]

The API is documented for end users here http://zamboni.readthedocs.org/en/latest/topics/api/payment.html#pay-tiers