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.
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.
David will have price tier info
Assignee: nobody → bram
Priority: -- → P1
Whiteboard: [UX wanted]
So is this different from bug 831137?
(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.
Please find the latest mockup for this problem on bug 868179 comment 3.
You cancelled the needinfo, but didn't provide any info. Did we miss your comment? :)
(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).
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.
Bug 868179 is already assigned and it seems like all this bug does is point to it, so I'm closing this bug.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-06-13
closing as UX solution has been made available
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.