From 31cd1350d20366ee781955b3569434dd84bce1f5 Mon Sep 17 00:00:00 2001 From: Ade Bateman Date: Tue, 19 Apr 2016 09:56:18 -0700 Subject: [PATCH] Removing references to closed issues #47 and #56. --- specs/paymentrequest.html | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/specs/paymentrequest.html b/specs/paymentrequest.html index e7a3c6de..461d5b2d 100644 --- a/specs/paymentrequest.html +++ b/specs/paymentrequest.html @@ -351,12 +351,6 @@

PaymentRequest constructor

currently described in the specification. -
- There is an open issue about whether the payment request should - be a programmable object or should be just pure data that can be - operated on by methods. -
-
There is an open issue about whether the API should handle occasions when a site wants to request a payment method but not actually make a charge immediately. These may include identification validation, pre-auth @@ -454,16 +448,6 @@

show()

user accepts the payment request. Some kind of user interface will be presented to the user to facilitate the payment request after the show method returns.

- -

- It may help users understand what they are accepting if the web site - is able to label the "accept" button. For example, if a user is about - to "Buy" something, "Reserve" something, "Subscribe" to something, - etc. That said, this may create payment interface/experience issues - and accidentally lead to customers thinking they're performing - actions like a one-time purchase, when they are in fact signing up - for a subscription. -

The show method MUST act as follows: