W3C home > Mailing lists > Public > public-payments-wg@w3.org > March 2016

RE: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66)

From: <Joerg.Heuer@telekom.de>
Date: Mon, 14 Mar 2016 16:05:39 +0100
To: <reply+00f16b1ca8518a08a17d551baf6114ae45feac025476377592cf0000000112f1907192a16>, <paymentrequest@noreply.github.com>
CC: <public-payments-wg@w3.org>
Message-ID: <FB5E170315856249A4C381355C027E4502B299DEAAE5@HE100041.emea1.cds.t-internal.com>
Well said. Our user concept tests clearly indicate that users won’t support multiple such apps.


From: mattsaxon [mailto:notifications@github.com]
Sent: Freitag, 4. März 2016 19:06
To: WICG/paymentrequest
Cc: webpayments
Subject: Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66)


I maybe wrongly reading between the lines, but 'The user picks the Payment App' suggests a model in which the user picks a payment app registered in the browser, then picks a payment instrument registered in the payment app. I suggest skipping a step by registering (a link to) payment instruments directly in the browser, so that users can pick an instrument directly and implicitely select the corresponding payment app.

Whilst that may work in simple cases and provide a better user experience in those, how might this work when multiple payment application have the same payment instrument registered? For example a single card may be registered with MasterPass and Google Payments. This could get quite confusing, particularly if a Website support payments from both of those and say Visa, there could be 3 different apps that could present the Visa card information.


In the demo http://github.adrianba.net/paymentrequest-demo/ when the users selects a card, are they selecting a payment instrument or a payment application?

Reply to this email directly or view it on GitHub<https://github.com/WICG/paymentrequest/issues/66#issuecomment-192386021>.
Received on Monday, 14 March 2016 15:06:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 14 March 2016 15:06:14 UTC