Intent to implement: PaymentRequest
256 views
Skip to first unread message
Rouslan Solomakhin
Feb 18, 2016, 5:15:02 PM2/18/16
to blink-dev, Zach Koch, haav...@opera.com, Rachel Blum
Contact emails
Spec
Summary
An API that allows browsers to act as an intermediary between the three key parties in a financial transaction: the merchant (e.g. an online web store), the buyer (e.g. the user buying from the online web store), and the Payment Method (e.g. credit card). Information necessary to process and confirm a transaction is passed between the Payment Method and the merchant via the browser with the buyer confirming and authorizing as necessary across the flow.
Motivation
Buying things on the web, particularly on mobile, is a frustrating experience for users. Every web site has its own flow and its own validation rules, and most require users to manually type in the same set of information over and over again. Likewise, it is difficult and time consuming for developers to create good checkout flows that support various payment schemes.
Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals
Compatibility risk
New API that does not break old features.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
rek...@gmail.com
Feb 29, 2016, 1:40:12 PM2/29/16
to blink-dev, zk...@chromium.org, haav...@opera.com, gr...@chromium.org
I have some similar "Compatibility risk" concerns here to what I have with the Remote Playback API- PaymentRequest is an abstract API made available to web pages, but is responsible for coordinating external services (in Payment Request API, a coordination with a payment service, in Remote Playback, coordination with an remote media device).
At present there don't seem to be well defined, payment methods ("supportedMethods") to interoperate around, and that poses a significant risk to adoptability. "The API described in [the Payment Request API] document forms part of the Payment Request system described in the Payment Request Architecture document," yet if we go into Payment Request Architecture and look at 2.4 Payment Request Transaction Messages, we read,
"The abstract Payment Request API specification has no intrinsic knowledge of the payment methods available. When a transaction is enacted by the user through the API a JSON object containing the relevant information necessary to process the transaction is returned. The format of this "message" is defined specifically for the payment method and might be private to that method.",
(http://wicg.github.io/paymentrequest/specs/architecture.html#payment-transaction-message-specifications),
and we are linked to an open issue to create common payment methods (https://github.com/WICG/paymentrequest/issues/20). This pretty clearly establishes that at present, there are no standard payment transaction messages that can be transacted via the Payment Request API, and that seems like a very high compatibility risk hazard that I'd like to see this Intent to Implement speak to.
What does this Intent to Implement intend to offer? What supportedMethods will the PaymentRequest support? Will any other browsers be able to implement those same payment methods? Will other payment vendors be able to create extensions to offer their own payment methods, or how if at all are they provided for? (this is a lower priority question to me than knowing whether the supported methods will be directly implementable by others) In the spec there are two completion routes: is the delegated payment algorithm intended to be supported? Is the non-delegated payment algorithm intended to be supported?
Like Push API, and Remote Playback API, the Payment Request API presents in my mind a clear and significant compatibility risk, in that each specify an interface for the front-end while not specifying anything about back end implementation. I'd like to see this Intent to Implement- as these other front-end APIs have- speak some to what the corresponding back-end effort looks like, and how compatibility might be insured there too. Link to a similar discussion in Remote Playback:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Sf1C6blXmUo
At present there don't seem to be well defined, payment methods ("supportedMethods") to interoperate around, and that poses a significant risk to adoptability. "The API described in [the Payment Request API] document forms part of the Payment Request system described in the Payment Request Architecture document," yet if we go into Payment Request Architecture and look at 2.4 Payment Request Transaction Messages, we read,
"The abstract Payment Request API specification has no intrinsic knowledge of the payment methods available. When a transaction is enacted by the user through the API a JSON object containing the relevant information necessary to process the transaction is returned. The format of this "message" is defined specifically for the payment method and might be private to that method.",
(http://wicg.github.io/paymentrequest/specs/architecture.html#payment-transaction-message-specifications),
and we are linked to an open issue to create common payment methods (https://github.com/WICG/paymentrequest/issues/20). This pretty clearly establishes that at present, there are no standard payment transaction messages that can be transacted via the Payment Request API, and that seems like a very high compatibility risk hazard that I'd like to see this Intent to Implement speak to.
What does this Intent to Implement intend to offer? What supportedMethods will the PaymentRequest support? Will any other browsers be able to implement those same payment methods? Will other payment vendors be able to create extensions to offer their own payment methods, or how if at all are they provided for? (this is a lower priority question to me than knowing whether the supported methods will be directly implementable by others) In the spec there are two completion routes: is the delegated payment algorithm intended to be supported? Is the non-delegated payment algorithm intended to be supported?
Like Push API, and Remote Playback API, the Payment Request API presents in my mind a clear and significant compatibility risk, in that each specify an interface for the front-end while not specifying anything about back end implementation. I'd like to see this Intent to Implement- as these other front-end APIs have- speak some to what the corresponding back-end effort looks like, and how compatibility might be insured there too. Link to a similar discussion in Remote Playback:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Sf1C6blXmUo
Rouslan Solomakhin
Feb 29, 2016, 2:51:51 PM2/29/16
to rek...@gmail.com, blink-dev, zk...@chromium.org, haav...@opera.com, gr...@chromium.org
We are working on the Basic Card Payment document to specify how raw credit cards can be passed to merchants. Chrome can use its autofill data here. This will help us bootstrap the payment method ecosystem.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/gbSs15ZSWtA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages