With micro-payments the lower set of price tiers won't be available for credit card purchases. This means that these apps won't even get listed for purchase in countries where carrier billing is not supported. We need a way to convey this to developers when they are selecting price tiers from the devhub. I'll file a separate bug for not listing apps with price tiers(1-4) for countries which don't support carrier billing.

CCing UX and Adora. Where should this go and what should it look like?

I had worked on an iteration last week, but today, Tony had found out that we /can/ have different prices for different regions. This ability solves a lot of the problems that the interface have. He has sent some feedbacks on my interface, and we’ll have something to post tomorrow. Having the ability to set different price for each region might generate a big repercussion for everything. What’s our thoughts on this?

http://cl.ly/0k1H3i2x2W2T/price-country-payment-method-v6.pdf By allowing each country to have its own price, we solve all problems caused by the fact that, previously, one price must be set across all country. The mockup presents two different ways of visualizing information and editing prices: one with maps, one with tiles. It is designed to support two features: 1) Variable pricing: different country, different price 2) Adding in-app purchases through the UI, and propagating it across countries Here are two problems I haven’t solved in the interface: 1) Erasing in-app payment or editing it for later. What happens if set an in-app payment value, then decide that I don’t want it? The change must be propagated across all country. The change must also be reviewed. 2) Erasing country. What happens if I want to cancel my choice in making my app available in a country? I believe that these two problems can be solved easily, though. Currently, in-app payment is called “Item 1”, “Item 2”, “Item 3” and so on. This is bad, but we cannot infer that information from the manifest, so there’s nothing I can do beyond naming it something sequential. I recommend requiring in-app payment to be set from the manifest (ie. not manually like this), so we can simply infer that information and offer compatible country and price levels.

Bram, I love the squares representing the countries instead of the map. We could even put a little of the country flag in them to make them feel a little more representative (getting ahead of myself though). A couple things I'd like to offer up. It would be good to show how many in-app purchasable items are entered in each square, so developers can see if they have any dependencies between countries quickly. As far as dealing with entering IAPs, I agree with you that if it's possible, allowing devs to submit something (manifest or otherwise) that would have all that info would be ideal. It's a realistic use case, based on apps in the iOS and Android stores, that some apps will have as many as 50 or more things available for purchase in-app. (e.g. "Jewel pack -- 10 jewels $0.25, Jewel pack -- 50 jewels $1.99, etc, etc) My question on this is just as much a technical one as it is a usability one, and that is, how to we handle it when devs want to change the prices of their IAPs? Bulk submission is good for adding, but having the IAPs listed and editable in the Dev Dashboard might make things like putting certain IAPs "on sale" easier for the devs, and could realistically drive more sales. We also need to support full text names for each IAP, to make them easily distinguishable from each other. This is a great start :)

Adding a visual representative of countries seems like a good idea. Showing the number of in-app purchasable items is also good, but I worry that, when a developer go above a certain number of IAPs (like, say, 10), each box would contain so many numbers in it that it becomes cluttered and unbearable. Do you have any suggestion to solve this problem? SUPPORTING FULL TEXT NAME ------------------------- If developer is able to declare IAP items on the manifest, we can simply query that file and make the UI list the IAP products it contains. All we need is a name and a mapping of that name to the item ID used within the app. We then say “This application has 50 IAP items. Here are their names. Please select the price for each”. By comparison, inputting IAP item names manually is very tricky. When a developer use the UI to input a name like “10 jewels”, the system doesn’t know what “10 jewels” means. So we have to have a way to link IAP name with the item ID used from within the app. And not to mention, the difficulty of adding many IAPs at once. However, I also understand that we need to design for something that could be implemented soon, and that means manual input. So what we can do is ask developers for an item ID name in addition to a “shorthand” name for an IAP. Then we do a check to make sure that the item ID name matches the name found inside the app. If the item matches, then it qualifies as an IAP item and can be given a price. CHANGING IAP PRICES: A PROPOSAL ------------------------------- To my knowledge, no other app store supports changing IAP prices for the purpose of putting IAPs on sale. What I would suggest we do is encourage developers to do this: 1. Before submitting, think carefully of the various permutations of IAP prices 2. When submitting, input every IAP item in the manifest, including discounted ones * unicorn * unicorn.discount * panda * panda.discount * etc. 3. After submitting, input the prices of all IAP items in every country using the UI. For some countries, discounted means 25% or 50% off, for others, it means free. It’s up to them * unicorn: USD 0.50, BRL 1.00 * unicorn.discount: USD 0.25, BRL 0.00 * etc. 4. To prevent users from seeing discounted IAP item when there’s no promotion running, the developer need to remove that item from the list of purchasable products inside the app. There is an additional benefit to this method, which is the fact that a reviewer can look at all the possible IAP values in one go and notice discrepancies/dishonest plays.

I'm confused why we're talking about discounts on in-app purchases and particularly with having developers maintain a database of IAPs in the marketplace - something we've specifically avoided up until now. The mockup looks nice, but I feel like we've veered off course (not just the regular course, but the realization that we need to ship a v1 of this in a few weeks). Should we have a meeting?

This mockup describes what we talked about on last week’s May 22nd meeting, and should fill all the requirement for v1 release. Notable features: * Reference currency can be toggled between the 3 currencies that Bango can pay out to developers ($, £, €) * Reference currency would determine price level * Price levels are displayed as currency values, not tier numbers * Even though price for each country is set in local currency, the “you earn” field is either $, £ or € * The full list of country is displayed at all times, but is grayed out/disabled when the check box cannot be clicked * When a country cannot be selected, a reason is displayed. For example, Venezuela is grayed out when the selected price is $0.99 because it “only supports credit cards”

Hi Bram, this looks great!. A couple feedback points: * All prices should appear localized and with currency symbols (where applicable) for clarity. For example: when selecting a EUR payout, instead of 0.10 in the dropdown and in the price earned column, we should display it as €0,10 in both places. * For a region such as Brazil where there are multiple carriers (Movistar and Vivo) would the payout list each carrier on a new line? Do we need that? Maybe because the payout could be different per carrier? This list could get long (like 6 per region, I think) * What happens to the region price grid when the app is free and the in-app payments toggle is set to Yes? In this scenario, the developer will write the price of each product in code and could have multiple products. Thus, they will want to look up prices earned per region to decide how to price their items. Could we perhaps re-use the grid for this? For a first iteration we could hide the grid and file a separate bug to address it.

(In reply to Kumar McMillan [:kumar] from comment #8) > * All prices should appear localized and with currency symbols (where > applicable) for clarity. For example: when selecting a EUR payout, instead > of 0.10 in the dropdown and in the price earned column, we should display it > as €0,10 in both places. Good idea. Labeling payout price will clarify it, and will also allow us to not label the table with words like “You earn (USD)/(EUR)/(GBP)”. Table labels are small and can be missable. > * For a region such as Brazil where there are multiple carriers (Movistar > and Vivo) would the payout list each carrier on a new line? Do we need that? > Maybe because the payout could be different per carrier? This list could get > long (like 6 per region, I think) The whole reason for multi-line carrier list is because the payout price could be different for each, and we want to let developers know how the math works out. If the payout price is the same across carriers and payment methods, there’s no need to have the last column and elongate the table. We can simply list the payout price under “you earn” price without any further labeling. Developers will understand that this value applies no matter what method it involves. In summary, if the price is different, then show the carriers/credit card. If the price is the same, don’t show the label at all. > * What happens to the region price grid when the app is free and the in-app > payments toggle is set to Yes? In this scenario, the developer will write > the price of each product in code and could have multiple products. Thus, > they will want to look up prices earned per region to decide how to price > their items. Could we perhaps re-use the grid for this? For a first > iteration we could hide the grid and file a separate bug to address it. I was thinking that this table is informational, so it will only need to appear when user clicks “yes” on in-app. There are two ways that it could show up: * Link element that expands the table * Open in a new window Because developers will need to decide amongst many prices, this table could potentially be complex, so I recommend opening it up in a new window. This is similar to how many online apparel stores opens their sizing charts. I wrote “potentially” because I don’t know how complex this table will be. I do have the pricing table, and would imagine that the table that we will use will be a subset of this full pricing table. I made a simpler version of the table for my own use. Maybe it could serve as a starting point. I’ll attach it in the next comment.

Thanks Bram!

The first cut of the implementation for this is here: https://github.com/mozilla/zamboni/commit/6f8b459c343bb862f274c36f6294448e932aa962 The grouping of options is coming up in a separate bug, bug 882836 - as it required additional data. The data for currency of the tiers themselves is not currently available so we'll need to deal with that separately at a later stage. The data for payout is not currently available so that's also not in this version. I'll mark this as fixed and raise other bugs for the remaining issues so they can be prioritised independently.