The install button for a paid app turns into "free" when payments fails

RESOLVED FIXED in 2013-06-27


6 years ago
6 years ago


(Reporter: jlong, Assigned: cvan)




(Whiteboard: [qa+])



6 years ago
This is connected to bug 886951. I'm currently getting "payments are temporarily disabled" when trying to install a $0 app that uses in-app payments. For some reason, if I purchase it from the detail page, and the payment is cancelled, the button changes from "$0" to "Free", which really seems like a bug. Check this video for the bug:


6 years ago
Summary: The install for a paid app turns into "free" when payments fails → The install button for a paid app turns into "free" when payments fails

Comment 1

6 years ago
The button doesn't seem to change when I try to install it from the listing page.

The two APIs are returning different values for "price". Apps that are free (or free with inapp) should ALWAYS have a falsey value for "price". Notice in the second API response the price is "0.00".
Component: Consumer Pages → API
Priority: -- → P1

Comment 3

6 years ago
I'm changing this to return 0.00 in both cases. The app is not free, its premium with in-app at price point 0, or 0.00.
So do we still trigger mozpay for those apps?

That change is going to cause Fireplace to make all free with inapp apps be paid (we test `app.price_locale if app.price else _('Free')`). If we aren't triggering payments, we'll have to test for `app.price_locale if app.price and app.price != '0.00' else _('Free')` in multiple places, which seems silly.

Comment 5

6 years ago
* test premium_type: if premium_type is in free, or free-inapp, do not call mozpay
* test price:
  * if price is 0.00, call receipt creation
  * if price is greater than 0.00, call mozpay

I've been working with @cvan on this patch and am holding off on the commit till after the tag so we've lead time to clean up the clients.

Having the server do less magic eg: price = None when it should really be 0.00 would be good in my opinion.

Comment 6

6 years ago
After chatting to cvan, adding in a payment_required field which should tell whether to call mozpay or not (although some of these other checks should be done).


6 years ago
Assignee: nobody → cvan
Target Milestone: --- → 2013-07-04

Comment 7

6 years ago
Landed bug 886582, if there's anything I can do to help on this, let me know.

Thanks, Andy! =)
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: 2013-07-04 → 2013-06-27


6 years ago
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.