From 559a706a70cc68f47e1d7f15ec9bc5e609c1b369 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Tue, 29 Mar 2016 17:24:59 -0400 Subject: [PATCH] Update reference to issue #39. --- specs/paymentrequest.html | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index 170d0761..7704c895 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -459,18 +459,6 @@

show()

later be resolved by the user accepts the payment request algorithm through interaction with the user interface. - - -

- How do we support Web-based payment apps? These instruments require - a user to:
- 1. Start on the merchant website
- 2. Click buy
- 3. Select the web-based instrument
- 4. Navigate to a 3rd party website to approve the transaction
- 5. Return to the merchant website with a token, approval code, or - other proof that the transaction has been approved. -

@@ -1055,6 +1043,7 @@

User agent delegates payment request algorithm

only available for a limited amount of time. If the user does not accept the payment request within the allowed time period, then the request will be aborted.

+

A user agent may not always be able to abort a request. For example, if the user agent has delegated responsibility for the request to another app. To support this situation, @@ -1082,6 +1071,14 @@

User agent delegates payment request algorithm

+

+ The architecture document suggests that payment apps may take + numerous forms, including as web-based apps. This specification + should describe how the user-agent will pass the payment request + data and the complete signal to a web-based payment app and also how + it will receive the payment response from the payment app. +

+

We believe there are user agent configurations that can cause the UI to get into a state where cancellation by the web page during user interaction is difficult. Users should still