Closed Bug 794651 Opened 11 years ago Closed 10 years ago

[meta] implement Marketplace payment provider for navigator.mozPay()

Categories

(Marketplace Graveyard :: Payments/Refunds, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kumar, Assigned: kumar)

References

Details

(Keywords: meta)

When an app initiates payments with navigator.mozPay() and their JWT points to Marketplace, Marketplace should host the payment flow. Spec: https://wiki.mozilla.org/WebAPI/WebPaymentProvider

For UX flows and info: https://wiki.mozilla.org/Apps/ID_and_Payments
Summary: [meta] back navigator.mozPay() with Marketplace server → [meta] implement Marketplace payment provider for navigator.mozPay()
This was built once before in bug 742056 and we can re-use the backend (and some frontend?) because the JWT interaction is the same
Depends on: 794697
Depends on: marketplace-payments
No longer depends on: 794697
Blocks: marketplace-payments
No longer blocks: basecamp-payments
No longer depends on: marketplace-payments
I don't know if this is the place for these comments (if not, just let me know)

After reviewing the UX flows, some comments:
- having to confirm the app installation in the last Gaia screen looks redundant for paid applications, as the user has previously acknowledged the operation with a PIN and clicked the Buy button. Don't know if it is feasible to skip this last step in v1, but the resulting UX would be better.
- more importantly, if the user clicks cancel in the last screen after having successfully paid for the app download, what happens if she clicks download again in the app details page? I guess we will follow the free app flow in order not to charge the user twice, won't we?
- finally, just to remember that it should be nice to be able to ask for the PIN right after presenting the payment details (I know this fully depends on the tech integration details)
(In reply to David Lozano from comment #2)
> - having to confirm the app installation in the last Gaia screen looks
> redundant for paid applications, 

Yep, this is tricky to address so it will probably remain as is for V1

> - more importantly, if the user clicks cancel in the last screen after
> having successfully paid for the app download, what happens if she clicks
> download again in the app details page? 

she will be able to install the app immediately

> - finally, just to remember that it should be nice to be able to ask for the
> PIN right after presenting the payment details (I know this fully depends on
> the tech integration details)

We're working this out with the payment processor. It will probably remain as is for V1
Assignee: nobody → kumar.mcmillan
blocking-basecamp: --- → +
Depends on: 795127
Depends on: 795137
Depends on: 795140
Depends on: 795143
Meta bugs do not block ship, as they are not quantifiable units in themselves for implementation work. Please nom/+ bugs that are actual units of work (aka the bugs under this bug could be candidates).
blocking-basecamp: + → ---
Keywords: meta
Depends on: 797518
Depends on: 797511
Depends on: 797917
Depends on: 797608
Depends on: 797926
Depends on: 797927
Depends on: 797991
Depends on: 756979
Depends on: 765044
Depends on: 765097
Depends on: 782746
Depends on: 798059
Depends on: 798064
Depends on: 798428
Depends on: 799150
Depends on: 799204
Depends on: 801085
Depends on: 801108
Depends on: 801766
Depends on: 802127
Depends on: 802875
Depends on: 804362
Depends on: 807131
Depends on: 807157
Depends on: 810286
Depends on: 810287
Depends on: 817883
Depends on: 817886
Depends on: 820192
Depends on: 820198
Depends on: 820586
Depends on: 820870
Depends on: 821465
Depends on: 821511
Depends on: 822495
Depends on: 823764
Blocks: 824836
Depends on: 825270
Blocks: 825353
Depends on: 826474
Depends on: 826813
Depends on: 827472
Depends on: 828513
Depends on: 829750
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.