864677 - Indicate what payment methods are supported for the selected price tier

Status: VERIFIED FIXED

(Marketplace Graveyard :: Developer Pages, defect, P1)

Description

[krupa raj[:krupa]]

Supported payment options (carrier and credit card payments) depends on the price tier selected and regions supported.

For example, Price tier 4 is currently the minimum supported price tier for credit card purchases.

When the developer selects a price tier, we need to indicate what payments options are supported.

David needs to provide us the price tiers support info across regions.

Comment 1

[Bram Pitoyo [:bram]]

Since price tier 4 as for credit card support seems to only apply to USD, I would like to see the complete minimum-price-tier-for-credit-card-acceptance table in all currency before starting work.

By knowing these variables, I can design an interface with a logic that’s only as complex as necessary.

For example, if /all/ currency supports credit card payment when price tier is on or above 4, then the interface would be simpler than if /each/ currency has its own minimum tier.

If /some/ currency supports it on tier 4, others on tier 5, and others on tier 6, I might design a note where the rule is clearly marked.

Lastly, I would like to know if any other factor might impact price tier, because I’ll need to take all factors into consideration when designing. For example, carrier A might institute a minimum price tier of 4, carrier B doesn’t have a minimum price tier, etc.

Comment 2

[Wil Clouser [:clouserw]]

David will have price tier info

Comment 3

[Christopher Van Wiemeersch [:cvan]]

So is this different from bug 831137?

Comment 4

[Bram Pitoyo [:bram]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #3)
> So is this different from bug 831137?

Great point. This bug is a continuation to bug 831137, and as far as UI is concerned, should also take bug 864676 into account.

I am going to post my mockups on bug 831137, to keep the discussion going there.

Comment 5

[Bram Pitoyo [:bram]]

Please find the latest mockup for this problem on bug 868179 comment 3.

Comment 6

[Bram Pitoyo [:bram]]

Please find the latest mockup = on bug 868179 attachment 754311 [details].

Comment 7

[Wil Clouser [:clouserw]]

You cancelled the needinfo, but didn't provide any info. Did we miss your comment? :)

Comment 8

[David Bialer [:dbialer]]

I provided to Bram on Mana server.  Here https://mana.mozilla.org/wiki/download/attachments/23954315/Marketplace%20Pricing%20Master%20%20May%2013%202013.xls?version=2&modificationDate=1368578560826&api=v2

Comment 9

[David Bialer [:dbialer]]

(In reply to Bram Pitoyo [:bram] from comment #6)
> Please find the latest mockup = on bug 868179 attachment 754311 [details].

I like the design, though can see a lot of challenges as it gets somewhat complicated on corner cases.   

On scenario 1, it said free with in-app payment, but didn't see the in-app payment radio button checked. 

I think we need an expedient solution right now, and in fact, just to make it simple, perhaps only enable prices up to $9.99 (Price Point 70) to be entered for in-store rather than $49.99.  This would be for launch to keep it simpler and minimize the complications on maximum price - which is $30 for credit cards and varies by operator for direct billing ($6, $12.49, and up).

Comment 10

[Bram Pitoyo [:bram]]

Hi David,

(In reply to David Bialer [:dbialer] from comment #9)
> On scenario 1, it said free with in-app payment, but didn't see the in-app
> payment radio button checked.

That was my mistake. The mockup should have indicated that the in-app payment radio button is checked.

Whether in-app payment is set to enabled or disabled, the interface is not going to change. This is because we currently don’t have any interface for managing in-app payment. This is by design.

Quoting Wil on bug 868179 comment 6:
> 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.

We will have this interface later in the year. For launch, specifying in-app products and prices are all done from the manifest. the radio button is just a way for flagging Marketplace to mark the app as available for in-app payment.

To answer Caitlin’s question, we already have the interface to submit free apps with in-app payment -- we already have for a couple of months, actually -- but they’re only available on the dev server (allizom). Our developers can help make it available on the production site.


> I think we need an expedient solution right now, and in fact, just to make
> it simple, perhaps only enable prices up to $9.99 (Price Point 70) to be
> entered for in-store rather than $49.99.

This will work. The interface can be easily scaled down to only enable prices up to $9.99.

Comment 11

[Wil Clouser [:clouserw]]

Bug 868179 is already assigned and it seems like all this bug does is point to it, so I'm closing this bug.

Comment 12

[krupa raj[:krupa]]

closing as UX solution has been made available