From 48f6d6e233db8129b8a159e3d595be4fe440d878 Mon Sep 17 00:00:00 2001 From: mountainhippo Date: Sun, 20 Mar 2016 15:41:49 +0000 Subject: [PATCH] Adding issue marker to issue #38 to architecture spec instead of API spec --- specs/architecture.html | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/specs/architecture.html b/specs/architecture.html index 19dff920..fde82336 100644 --- a/specs/architecture.html +++ b/specs/architecture.html @@ -79,7 +79,7 @@

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web.

- +

The group is chartered to develop multiple technologies. The current document describes a set of technologies —the Payment Request Architecture— that, together, provide merchants with a consistent way to request payment information @@ -108,7 +108,7 @@

This specification was derived from a report published previously by the - Web Platform Incubator Community Group and + Web Platform Incubator Community Group and A Payments Initiation Architecture for the Web developed within the Web Payments Working Group, and a blog post on the Working Group's work. @@ -129,12 +129,12 @@

Overview of Anticipated User Experience

  • Depending on the payment method, this data will either enable the merchant to be paid, or signal that the merchant has already been paid.
    • - +

    Components

    - The following are key components of the Payment Request Architecture. These + The following are key components of the Payment Request Architecture. These components would normally sit between the Payment Service Providers (PSPs) of the payer and payee. Different implementations of this architecture may result in components running on entirely @@ -146,7 +146,7 @@

    Components

    Payment Apps

    - +

    A Payment App is software used to pay. Banks, merchants, mobile operators, and anyone else who wants to will make these available. User agents are also likely to act as basic @@ -188,6 +188,15 @@

    Payment Apps

    Host, as an execution environment for the app, and the Payment Mediator, that mediates all interactions between the Payment App and other components.

    + +

    + When a user registers a new payment instrument, how is that payment + instrument shared between different browser brands? For example, if I + register a Visa debit card issued by my bank in Google Chrome on my + laptop, when I go to purchase something using my mobile phone, is + that same debit card available to me via my Firefox web browser + (assuming I've authenticated in some way with both browsers)?

    +