Personal tools


From MozillaWiki

Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed
ID Summary Priority Status
767818 Implement navigator.mozPay P1 VERIFIED

Open; Resolved; Total (0% complete)

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

The goal of the Web Payments architecture is to allow Open Web Apps to initiate a payment (or a refund) from the user for a virtual good via the navigator.mozPay function.

The normal usage is as follows:

  • The app initiates a payment by signing a JWT request and calling navigator.mozPay().
  • This starts the buyflow in a content iframe inside a trusted dialog ("chrome dialog").
  • A purchasing flow is served from the Payment Provider's server as an HTML5 document inside the trusted dialog.
  • The buyer is authenticated by the Payment Provider (via the network (radio) or BrowserID assertion in the B2G scenario).
  • The buyer completes or cancels the purchase. (Note that the Payment Provider might require an authorization step).
  • The app receives a Javascript callback when the buyer accepts or cancels the purchase.
  • The app serser receives a signed POST request with a Payment Provider transaction identifier indicating that the purchase was completed successfully.

See the following pages for further detail:

What solutions/approaches were considered other than the proposed solution?

  • marketplace to proxy other payment providers

Why was this solution chosen?

  • Transfer risk to payment providers, rather than in the client or Mozilla managed services.

Any security threats already considered in the design and why?

Threat Brainstorming

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)

pauljt:: Review trusted modal dialog js ::asap
dchan:: Investigate marketplace JWT generation code (have to review at the spec level, app servers can generate tokens as well)

pauljt :: Prevent from the background:: Bug raised


Apps (Marketplace)
Tracker Bug">bug 767818</a>
Status Green (Green, Yellow, Red?)
Release Target
Health -
Status Note


Product manager Andreas Gal?
Feature manager -
Engineering lead Fernando Jiménez Moreno
Security lead Raymond Forbes
Privacy lead
Localization lead -
Accessibility lead -
QA lead -
UX lead -
Product marketing lead -
Additional members -

Open issues/risks

Stage 1: Definition


Include brief summary of feature/project, and link back to core feature/product pages. Links:

Use Cases

See specification document above.

Data Types

Data Flows

  • <a href="L.png">Developer registration flow</a>
  • <a href="L.png">High level data flows</a>
  • [todo add detailed data flows]


Architecture Diagram

Stage 2: Design

Threat Model

Security Recommendations / Open Issues