- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 12 Apr 2016 06:17:16 +0200
- To: Tony Arcieri <bascule@gmail.com>
- Cc: Web Payments IG <public-webpayments-ig@w3.org>
On 2016-04-11 22:26, Tony Arcieri wrote: > On Sun, Apr 10, 2016 at 10:16 PM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > Since all of these new P2P systems are "App" based, it makes it kind > of obvious that creating a "bridge" from the Web to the App world would > be a tremendous (and still relatively simple) > > > As I understand it, the Web Payments API is already designed to support > a Payment App intenting into a native mobile app to complete a payment Disregarding the fact that this part of the plot is pretty poorly defined, there are other hurdles making this particular issue unimportant. Why is that? AFAICT, the Web Payment API builds on that it orchestrates both payment method selection and execution, effectively requiring a *complete rewrite* of these parts of a Web shop. if you to that add the new browser registration step required for "legacy" payment systems, you (IMO) have a surefire foundation for failure. What I have proposed would only make a Wallet appear as a yet another payment option, leaving existing checkout/payment system code essentially intact. Although Apple have indicated support [1] for the Web Payment API, I'd be more than surprised if their much anticipated Web adoption of Apple Pay doesn't rather follow the scheme I just outlined. Anders Rundgren 1] https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0073.html > -- > Tony Arcieri
Received on Tuesday, 12 April 2016 04:17:52 UTC