Skip to content

Commit

Permalink
Merge pull request #92 from adrianba/gh-pages
Browse files Browse the repository at this point in the history
Removed references to "browser"
  • Loading branch information
zkoch committed Mar 17, 2016
2 parents 3c52892 + 604ee48 commit e6d521f
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions specs/architecture.html
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@
<p>The group is chartered to develop multiple technologies. The current document describes a set of
technologies &mdash;the Payment Request Architecture&mdash; that, together,
provide merchants with a consistent way to request payment information
from the user, aided by a browser or other user agent.</p>
from the user, aided by a user agent.</p>

<p>The focus of the Payment Request Architecture is to provide
an abstract interface between a web page and a <a>Payment
Expand Down Expand Up @@ -123,9 +123,9 @@ <h2>Overview of Anticipated User Experience</h2>
<ul>
<li> At the end of shopping on a merchant site, the user pushes the “buy” button.</li>
<li>The merchant site calls the payment API with purchase amount, currency, accepted payment methods (e.g., Visa, Paypal, Bitcoin), and any custom data for those payment methods.</li>
<li>The browser (or other user agent) determines the intersection of merchant-accepted payment methods and user-registered payment methods. The merchant can (optionally) use the API to capture shipping information through the same user experience.</li>
<li>The user agent determines the intersection of merchant-accepted payment methods and user-registered payment methods. The merchant can (optionally) use the API to capture shipping information through the same user experience.</li>
<li>The user selects a payment app to pay, and carries out any app-supported activities as needed, such as authentication.</li>
<li>Assuming the payment is authorized, the payment app returns payment method-specific data through the browser to the merchant site.</li>
<li>Assuming the payment is authorized, the payment app returns payment method-specific data through the user agent to the merchant site.</li>
<li>Depending on the payment method, this data will either enable the merchant to be paid, or signal that the merchant has already been paid.</li>
</ul>
</section>
Expand All @@ -149,7 +149,7 @@ <h2>Payment Apps</h2>

<p>A Payment App is software used to pay. Banks, merchants,
mobile operators, and anyone else who wants to will make
these available. Browsers are also likely to act as basic
these available. User agents are also likely to act as basic
payment apps, storing some information on behalf of the
user, as they already do today with passwords. We expect
payment apps will increase security and privacy by giving
Expand Down Expand Up @@ -214,7 +214,7 @@ <h2>Payment Mediators</h2>
<li> It passes payment request data to the payer's selected Payment App.</li>
</ul>

<p>We expect that browsers will primarily act as payment mediators in this architecture.</p>
<p>We expect that user agents will primarily act as payment mediators in this architecture.</p>
</section>
</section>

Expand Down

0 comments on commit e6d521f

Please sign in to comment.