the future of e commerce is more web like
play

The Future of E-Commerce is More Web-like Ian Jacobs W3C I. What - PowerPoint PPT Presentation

The Future of E-Commerce is More Web-like Ian Jacobs W3C I. What the Web Means for Commerce Source: merchandisingmatters.com New Zealand E-Commerce Source: Nielsen New Zealand E-Commerce Report 2016 E-Commerce Rising Proportion of Retail


  1. The Future of E-Commerce is More Web-like Ian Jacobs W3C

  2. I. What the Web Means for Commerce Source: merchandisingmatters.com

  3. New Zealand E-Commerce Source: Nielsen New Zealand E-Commerce Report 2016

  4. E-Commerce Rising Proportion of Retail (NZ) Source: Bank of New Zealand (2016)

  5. Similar Trend in the US Source: US Dept of Commerce

  6. E-Commerce Used to Be More Linear Research Shop Purchase Loyalty Card Paper Merchant Online OR payments Coupons Content Offline via form

  7. Now Customers Expect a Web Experience Online Payment Fast, Security and choice, Effortless Privacy Fast clearing Discoverable Digital loyalty, Cross-device, Customization, Ubiquitous, Social Integrated

  8. Mobile a Key Enabler (US)

  9. Mobile is Lagging in NZ? Source: Nielsen New Zealand E-Commerce Report 2016

  10. What Can Retailers Do? For retailers to attract consumers today, they need to put themselves in their shoppers’ shoes. Fast tracking the consumers’ experiences on their mobiles and allaying delivery concerns means online retailers could enjoy double digit growth over the year ahead. -- Nielsen New Zealand E-Commerce Report 2016

  11. Poor Experience Leads to Abandonment  Usability challenges on mobile  Small screens, keyboards  Mobile wallet fragmentation  Complex check-out  User payment preference not offered  Different experiences on all sites  Different experiences in-app, proximity, Web Source: Capital Numbers

  12. Poor Security Leads to Lost Loyalty…  Passwords are inadequate "After a security breach,  Multi-factor authentication not well-integrated 12% of loyal shoppers  User interface complexity creates attack stop shopping at that opportunities (e.g., phishing) retailer, and 35% shop  Distributed applications create attack at the retailer less opportunities (e.g., cross-site scripting) frequently.”  Standard crypto primitives not available to Web applications - Forrester Research

  13. …and Increased Costs Source: Lexis Nexis

  14. Merchants (and Web) Need to Adapt  Web intended to enable humanity to connect and communicate  Powerful enough for 1.5 trillion USD of E-Commerce annually  But the Web was not designed as an E-Commerce platform  Evolving expectations driving new requirements

  15. Web Scale Improvements Call For Standards  Many standards bodies exist  ISO, EMV, PCI, X9, IEEE, NIST, …  Interfaces between Web stack, applications, underlying payment systems not generally standardized  Inadequate integration. Specifically, no standard APIs for wallet access, raising implementation costs for payment services providers; tokenization not part of the Web, biometrics not yet part of the Web

  16. II. Who is W3C? The World Wide Web Consortium (W3C) is an international community that develops open standards to ensure the long- term growth of the Web.

  17. Key Facts  Founded in 1994 by Web inventor Tim Berners-Lee  ~425 Members; full-time staff ~80  Community of thousands  Liaisons to drive interoperability  ISO TC 68, ISO 20022, IETF, …  Hundreds of specifications (royalty-free)

  18. W3C is Building an Open Web Platform  The Open Web Platform is a full- fledged programming environment for rich, interactive, cross-platform applications  HTML5 is the cornerstone  Most interoperable platform in history  A billion Web sites  Millions of developers

  19. Including Built-In Payments Capabilities “ We are long overdue for a payments user interface for the web .” -- Tim Berners-Lee What if ‘One Click’ Buying Were Internetwide? New York Times, 25 September 2016

  20. III. The Road to More Web-Like E-Commerce Payment Streamlined Enhanced method Checkout Security innovation Browser as Loyalty and ubiquitous Marketing platform

  21. Streamlined Checkout Source: yachtboatnews.com

  22. Demo  Demo by Adrian Bateman (Microsoft)

  23. Chrome/Android Beta Available  “Payment Request API Guide” (Google)

  24. Key Ideas for “Payment Request API”  Replace forms with native browser UI for payment info (card, address, etc.)  Browser chrome is fast  Improves security -- harder to spoof than Web page  Simplify user experience (UX), especially on mobile  User reuses data without re-typing  Browser only shows matching payment methods, so less noise  User can find preferred payment method without scanning page  Browsers distinguish themselves through optimized UX (e.g., 1-click)

  25. Please Note  Neither Payment Request API nor browser submits payment for processing  Data returned by API depends on payment method (e.g., PAN, EMV token)  Goal of API is to facilitate information collection and return to merchant  Merchant (or gateway) still needs to handle data they receive  Authentication is handled by another W3C group  Web Authentication Working Group

  26. Open Ecosystem of 3 rd Party Payment Apps  Payment Request API only supports browser-stored card credentials  A complementary API will enable third party payment apps  User registers payment apps from many sources: banks, merchants, mobile operators, etc.  Merchant may recommend payment apps during checkout  Note this is a new way for users to learn about and register (payment) apps  Payment apps support different payment methods (e.g., cards, credit transfers, proprietary methods, distributed ledgers, etc.)  Payment apps will distinguish themselves through services  Usability, strong authentication, tokenization, location services, loyalty programs, etc.

  27. Merchant Perspective  Consistent, simpler UX should increase conversions  Enables a branded, harmonized experience across channels through (retailer) payment apps  Merchant payment apps can integrate loyalty and points  Facilitates adoption of payment method improvements (e.g., to improve security)  Increased support for user preferred payment methods

  28. Payment Gateway Perspective  Cross-device interoperability at lower cost (benefit of using the Web)  Lower cost to build checkout  Can support more payment methods without more complex UX  Thanks for browser “match making”

  29. Flow

  30. Who’s Involved

  31. Status  Microsoft, Google have announced publicly their goal that the API be available for holiday season 2016  Implementations underway  See Google’s evolving Payment Request API Integration Guide  Apple announced “Apple Pay on the Web” and stated goal within Web Payments Working Group of convergence to a “solid, cross-browser framework for payments.”  Mozilla, Opera have begun work  Gathering feedback from experiments with merchants, E-Commerce providers, proprietary payment app providers

  32. Enhanced Security Source: allblacks.com

  33. Data Protection  Crypto primitives for Web apps:  Hashing, signature generation and verification, and encryption and decryption, key management.  Widely supported in browsers; gaining broad interoperability.  For:  Secure messaging  Multi-factor authentication  Protected document exchange  Cloud storage  Document signing  Data integrity

  34. Strong Authentication  Passwords weak  Phishing, data loss, liability  Replace them with logins via USB key or smartphone.  Collaboration with FIDO Alliance, who brought 2.0 specs to W3C  Launched 17 Feb 2016  First Working Draft published in May Source: fidoalliance.org

  35. Application and Communication  Protect apps against injection of unwanted or malicious code  Assure the integrity, authenticity, and confidentiality of Web interactions  Includes:  Secure communication channels  Apps delivered without spoofing, injection, eavesdropping  Numerous specifications at different maturity levels, such as  Cross-Origin Resource Sharing, Content Security Policy, Subresource Integrity, Credential Management, …

  36. Hardware Security  Access to secure element and other hardware from Web apps  More general than Strong Authentication work  Identity use cases (e.g., government issued identifiers) raise interesting privacy issues.  Hardware Based Secure Services Community Group now:  Clarifying use cases  Documenting technical requirements  Planning to write draft API  Then will propose clearer charter Source: Merchant Advisory Group

  37. Verifiable Claims  Problem statement from Credentials Community Group: “ There is currently no widely used self-sovereign and privacy-enhancing standard for expressing and transacting verifiable claims (aka: credentials, attestations) via the Web.”  CG wrote use cases for several industries. Includes for financial services:  Lowering KYC costs  Money transfer  Setting up bank account from home  Next steps: W3C Management to review draft charter for a Verifiable Claims WG and decide whether to propose to W3C Membership

  38. Payment Method Innovation Source: aliexpress.com

  39. Interledger Payments (ILP)  Ripple brought to W3C (see white paper)  Moving money between payment systems is costly and cumbersome  Users want payments to be simple, whatever the underlying systems  Interledger bridges payment systems  Very Web-like vision  Anyone with accounts on two ledgers can connect them (and charge a fee)  Protocol ensures everyone paid, or no one  ILP Community Group developing plan for specifications  Some specs likely to advance to a W3C Working Group

Recommend


More recommend