Indicate what payment methods are supported for the selected price tier

VERIFIED FIXED in 2013-06-13

Status

P1
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: krupa.mozbugs, Assigned: bram)

Tracking

(Blocks: 1 bug, {uiwanted})

2013-06-13
uiwanted
Points:
---
Dependency tree / graph

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Whiteboard: [UX wanted]
(Assignee)

Comment 1

6 years ago
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
Flags: needinfo?(dbialer)
Keywords: uiwanted
Priority: -- → P1
Whiteboard: [UX wanted]
So is this different from bug 831137?
(Assignee)

Comment 4

6 years ago
(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.
(Assignee)

Comment 5

6 years ago
Please find the latest mockup for this problem on bug 868179 comment 3.
(Assignee)

Comment 6

6 years ago
Please find the latest mockup = on bug 868179 attachment 754311 [details].
Assignee: bram → dbialer
Blocks: 828090
Flags: needinfo?(dbialer)
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).
Assignee: dbialer → bram
(Assignee)

Comment 10

5 years ago
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
(Reporter)

Comment 12

5 years ago
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.