- Toward an Ideal Web Payments Experience
- The Inputs to the Payments Standardization Process
- Lessons Learned from the Mozilla Marketplace
- General Discussion on the Ideal Payment Experiences
- Daniel Appelquist
- Evan Schwartz and Charles McCathie Nevile
- Daniel Appelquist, Evan Schwartz, Natasha Rooney, Manu Sporny, Kumar McMillan, Martin Hepp, Stéphane Boyera, Bryan Sullivan, Ernesto Jimenez, Dave Birch, David Ezell, Virginie Galindo, Ricardo Varela, Prakash Hariramani, Jeremy King, Giridhar Mandyam, Hannes Tschofenig, Jeff Jaffe, Erik Anderson, Charles McCathie Nevile, Jörg Heuer, Wendy Seltzer, Stan Stalnaker, Ori Eisen, Tobie Langel, Mountie Lee, Dave Raggett, and 78 others for a total of 103+ people
Evan Schwartz is scribing.
Note: These are minutes for an official W3C Workshop event that have been cleaned up and reformatted by the Web Payments Community Group. The Web Payments Community Group and the W3C are two different organizations, and it is the W3C that managed this event. These minutes may be handed over to the W3C to become the official minutes for the event, but that has not happened yet (and may not happen at all). Readers should understand that there is a difference between officially sanctioned W3C work, and the work done by the Web Payments Community Group (which is not officially sanctioned by W3C's membership).
Topic: Toward an Ideal Web Payments Experience
Topic: The Inputs to the Payments Standardization Process
USE CASE: Verify identity or assess trust of partners in a transaction.
USE CASE: Initiate / request payment.
USE CASE: Issue, transmit, validate proof-of-purchase / digital receipt.
USE CASE: Find and compare payment options for transaction.
USE CASE: Create a common digital receipt format.
Topic: Lessons Learned from the Mozilla Marketplace
USE CASE: App Stores - selling apps in mobile scenarios.
USE CASE: Prove ownership over a particular asset (proof of purchase / ownership).
USE CASE: Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account.
USE CASE: Billing through mobile operator (mobile billing) without hacks to HTTP.
USE CASE: Make it simple to register as a new customer (get rid of the registration step, if possible, or make it transparent).
Topic: General Discussion on the Ideal Payment Experiences
Denis: looking at the spec for web payments provider, it asks providers to be in a whitelist, what does it take to get in there?
USE CASE: Application of loyalty cards to purchases.
USE CASE: When doing a payment, need a way to assure the customer he is his payment service provider and is not subject to phising. Specially problematic in mobile when browser chrome is not available.
USE CASE: Tokenization mechanism that protects the buyer and merchant from theft of credentials.
Parslow says - there is not only stolen phones but a lot of stolen OTP are due to cloned SIM issued by the operators
Chaals wanted to ask what the relation is between digital receipts and EME, and to offer the counter-example of EV certificates and standardisation of UI
Some people think it's a good idea, a few think it's an awful idea
USE CASE: Payments / digital receipts should be applicable to Encrypted Media Extension authorization to show content.
Charles McCathie Nevile is scribing.
Stephane wanted to talk about merchant ideal experience - adding easily psps without changing a line
Chaals thinks a standard is a far better tool than an Open Library...
Wendy Seltzer wants to discuss privacy.
Tobie wanted to comment on non-normative UI/UX work.
USE CASE: Merchant and User reputation system accessible to the payments mechanism.
USE CASE: Reputation based selection of providers in a payment transaction, or info about merchants to help the user choose whether to complete the transaction.
Parslow says - now in France you can be charged for exchange rate between EUR and EUR...
USE CASE: Whitelisting of parties - users, merchants, payment providers without scalability / anti-compete issues.
End of session 2.