Web Payments Workshop - Session 4

Minutes for 2014-03-25

  1. Enhancing the Customer and Merchant Experience
  2. Merchants and Retailers - NACS
  3. Intent to Pay - Robin Berjon
  4. Transparency of Roles Affecting all Attributes of Price - Joseph Potvin
  5. Last-mile Payments in Africa - Trans-Africa Solutions
  6. General Discussion on Customer/Merchant Experience
Action Items
  1. Manu to reach out to MCX to try and get them involved in the W3C work on payments.
Daniel Appelquist
Bryan Sullivan
Daniel Appelquist, Bryan Sullivan, Dave Birch, Gray Taylor, Jeremy King, Mountie Lee, Wendy Seltzer, Ricardo Varela, Robin Berjon, Cyril Vignet, Dave Raggett, Joseph Potvin, Neil Mason-Jones, Stéphane Boyera, Michel Leger, Eric Tak, Manu Sporny, Ori Eisen, David Ezell, Ernesto Jimenez, Virginie Galindo, Tobie Langel, Emil Johansson, Alexander Gee, and 80 others for a total of 103+ people
Bryan Sullivan is scribing.

This page contains minutes for an official W3C workshop event that have been cleaned up and reformatted by the Web Payments Community Group. The W3C and the Web Payments Community Group are two separate organizations. Readers should understand that while the workshop was an official W3C event, the operation of the Web Payments Community Group is not officially sanctioned by W3C's membership. More information on joining W3C (membership fees) and/or the Web Payments Community Group (free) can be found on the respective websites.

Topic: Enhancing the Customer and Merchant Experience

Dave Birch: Kickoff on consumer and merchant experience with focus on the frontend
... people have asked why look at this? things work OK
... but they dont really work for consumers and merchants, basically
... how many paid for the dinner last night with cash (a few respond)
... the paypal payment method did not work, got locked out after three tries due to some suspicion
... puzzling as my paypal app knows who and where I am.
... the app could figure this out, and just do it since its only 30 euros. we would be moving to the right experience
... I use Hailo in london (taxi service). the app shows you the license # and picture of the driver. you tell them where you're going, you get there, and walk off. payment is automatic. there is no payment experience.
... no one looks forward to payment, they look forward to buying stuff. payment needs to be transparent, out of the loop
... all sorts of clever stuff will enable this experience. where is dave, is this activity normal, don't bother him.
... we should make the experience vanish, set the bar high.
... its not good to make it easy for me to type in a card . that's a hack.
... cards as the central metaphor for payment is anachronistic. we dont want to make cards work better on the web. its 1949 tech, and too dangerous now.
... knowing that use of cards is risky, and that eventually you will be attacked, please imagine further forward.
... starting with a merchant perspective now
USE CASE: Automatic payments, transparent to usage (subscriptions and safe pay-as-you-go w/o asking/annoying the customer)

Topic: Merchants and Retailers - NACS

Dave Birch introduces Gray Taylor of National Association of Convenience Stores (NACS) - @grayotaylor
Gray Taylor: Represent PCATS & NACS, attached to convenience stores in the US, involved in system data exchange
... payments is 30% of our effort. mobile commerce will increase that, so we are focused on this work today
... where are we? the system is broken. in the 70s there was no need for data visibility, data was static, magstripe based
... a lot of people are being hacked. 1.6B cards, 1.5B have been reissued.
... this is about a 10$B problem in the US, just the cost of fraud to banks
Gray Taylor: Fraud cost is 6 basis points... that's just due to fraud. [scribe assist by Manu Sporny]
... another problem is segmentation of the customer to the merchant. knowing your customer is important.
... e.g. walmart needs to know who is buying what, and they don't want to get that data from mastercard
... due to data security, we are moving to EMV
... we are last getting on this tech, and it's not a good feeling.
... what can we do? we wish that mobile was ready, because we feel like a real late comer to an old tech
... major oil companies have no plans to implement EMV, due to poor ROI
... incrementalism in the card business creates heartburn. todays system is based upon the account, more important than the person.
... the system is moving toward the person, who can select the card. card companies don't like that, banks are ambivalent
... W3C's job is to boil this ocean. this is a critical subset of global commerce, and shouldn't be a walled garden for the web
... tech has the ability to overturn monopolies
... US Payments SOI 2016 slide
... debit is the single largest thing going forward, driven by the banking crisis in 2008
... people are living in their means more now
... 2006-7 we hit equilibrium with paper on the way out
... cstore profile vs card fees graph shows fees pulling away from pretax profit
... the fees are passed onto consumers, $1B of subsidization
... the only higher cost is labor
Gray Taylor: If you pay cash, you pay over $400 a year to subsidize the card industry. [scribe assist by Manu Sporny]
... re cost/liter, 2/3 of margin is gross profit
... much is cost of unauthenticated card use
... focusing on business and consumer in the payments ecosystem
... customers get steered to where discounts are offered
... re method of payment, they are changing, polluting the card handling environment
... we have to enable these methods but not have them affect the card vendor environment.
Gray Taylor: It's helped a little, but didn't affect one of our biggest problems.
... we are turning a battleship here. PCI has helped re a finite set of things to look at
Mountie Lee: PCI === Payment Card Industry
Mountie Lee: They do DSS === Data Security Standard
Gray Taylor: Becoming PCI compliant is a huge science project. Our #1 threat vector (dispenser skimming) was excluded from PCI, it didn't really help us.
Wendy Seltzer: More on PCI here - https://www.pcisecuritystandards.org/
Gray Taylor: Now, in defense of PCI, it provided a clearinghouse to mitigate risk
... when it comes to trust, banks are #1, the crisis dipped that, but they are still #1 going forward
... payments in flux - the perfect storm
... for profit without competition is bad
... bank brick and mortar infratstructure is a cost holding them back
... it will be difficult to get the profit margin from the banks
Ricardo Varela: For reference, PCI DSS docs are at https://www.pcisecuritystandards.org/security_standards/ [scribe assist by Ricardo Varela]
... a consumer focus will be required, mobile and online banking will be changed by focus on the consumer
Gray Taylor: We need to re-think how we do digital identities and security. [scribe assist by Manu Sporny]
... mobilization will rise, mobile wallets are will become the mobile briefcase. Digital identities and megabit encrypted PINs are where we need to get to
Dave Birch: Digital ID problem is underlying many of these problems
Gray Taylor: With trust credentials, we can take ACH from Zimbabwe and be reasonably assured for it
USE CASE: Digital credentials that can be used for financial transactions, that provide plausible deniability to payment processors ("we vetted the customer and they lied to us in a sophisticated way, here's proof").
Gray Taylor: With the appropriate trust credentials floating around, I could bank w/ different people and decrease fraud. [scribe assist by Manu Sporny]
... re tokenization, there are about 6 standsards
... we need to kill standards as readily as we create standards - look at what's out there to leverage it, that will ease globalization
... Digital Identity
... counterfit IDs are easily obtained. transaction auth is similar to the boarding process
... all of the financial system is depending upon authentication of the individual
Gray Taylor: Digital identity will preserve our freedom online, not take it away. [scribe assist by Manu Sporny]
... this is something that will preserve freedom
Gray Taylor: There is still no way to digitally sign any contract, how dumb is that? [scribe assist by Manu Sporny]
... guiding access, medical records, etc...
USE CASE: Digitally signed contacts that are born and executed digitally.
Erik Anderson: +1 Passport is one of the weakest areas in need of security enhancements and digital ID's
Gray Taylor: I believe in standards - that's the way forward. [scribe assist by Manu Sporny]
... i believe in standards, you need to come up with building blocks. any safe system has not reached volume yet
... we need plausible deniability of risk
... what are the best practices systems should be following? consumers are just kicking the tires, and hacks can take wind out of the sales
... uniform datasets; at the end of the day, moving money is not rocket science; datasets need to be flexible and amended per the payment type
... re digital receipt standards, look to fiscal receipt standards
Gray Taylor: Important to bring more data into the digital receipts, look to people that need fiscal reporting in their receipts. [scribe assist by Manu Sporny]
... "out of the box" use cases; data security is about minimizing value and maximizing effort; hacking ROI needs to be low
... we need to look to how we can keep credentials in a small ecosystem and use tokens outside it
USE CASE: Theft of payment details results in very low return on investment.
Gray Taylor: We should keep credentials in a small ecosystem, use tokens/intermediaries. [scribe assist by Manu Sporny]

Topic: Intent to Pay - Robin Berjon

Robin Berjon: Hi, my name is Robin and I work for W3C, editing the HTML5 specification.
... We're in an acronym blizzard ... things are sinking in; from the perspective of the web platform, these thoughts are about how we can work together for payments on the web
... it would be easy to standardize what is done today; APIs would be easy. but they would not be conducive to innovation
... a better approach is an "intents" based approach; like HTTP, when you ask for something you don't know what will result, you just get something back
... we can reproduce a similar system for payments, avoiding the "nascar" problem, i.e. that user have to choose among a lot of logos for providers e.g. socnet "share" buttons; this hurts the small players
... "intents" on the android platform indicates something the user wants to do; the user is allowed to pick among services that are available to them
... we can include payment in the intents architecture as an "intent to pay"
... intents can provide a very simple flow for the web platform, that is orthogonal to the underlying payment system
Bryan Sullivan: I think I said the same thing yesterday, and it was in the discussion of web intents earlier
Dave Birch: We didn't test the notion of being able to pay without any understanding of the underlying payment system; to decouple it sounds great but it is real;
Robin Berjon: Domain experts need to help us with the mapping to the payment level
... we need to avoid locking ourselves into what payment is today, and move to decoupling at the design level
USE CASE: Decouple payments as much as possible. Base on an intent-to-pay mechanism
Slides for this talk are available here: http://www.w3.org/2013/10/payments/slides/session4_bpce.pdf
Cyril Vignet: I work for BPCE, a bank in France; I have worked in payment systems for 25 years
... focusing on one point from the paper, the SEPAmail project
... we have clients, merchants, cardholders, etc; B2B, B2C... there is a lot of savings that could be made, Euro billions, to be saved
... the idea of SEPAmail was to define not only a protocol but how actors interact
Slide 2: Trusted Third Party Processors
Cyril Vignet: TTPP Trusted Third Party Processors
... ABC Inc talks to TTPPs in a trapezoid arch to Alice
... SEPAmail is based upon web standards, ISO 20022 or XML data formats
Tom, on IRC, notes - Intent is nice but might be preventing the user to discover new services, no ?
Dave Raggett: SEPAmail uses web/internet standards to encapsulate ISO20022 or XML data format for payments via trusted third party processors.
Cyril Vignet: The protocol is mandatory between the TTPPs, optional between the endpoints and TTPP
... what we want to avoid; one party must be connected to the TTPP of the other party (thus the trapezoid arch)
... each client can choose their TTPP
... we also want to avoid subject-specific protocols, and use encapsulation for that
... we also want to avoid ACH or CSM; these are not very well regulated; ACH is quite expensive; much less than manual but still expensive
... it was important not to have a central monitoring point, enabling freedom to do what you want
... experience with SEPAmail; based upon ISO 20022, with different layers for bill presentment, direct debit e-mandates, IBAN control, data along payments
... we will launch this in 2014 a network for TTPPs
Cyril Vignet: The launching banks are: Crédit Mutuel, Crédit Agricole, Société Générale, BPCE, BNP Paribas - all banks in France
... design is in progress, "families for TTPP than may not be PSP" (someone explain if possible...)
... SEPAmail is an "overal arch that solves (part) of the auth problem"
... example of the "SAPPHIRE family", implemented this three years ago. it's very simple from the banks' view; self-care for the user
... the corresponding private keys is in the mobile, in the secure element or NFC card
... if the payment is low, you may not need very high security
... with this generic approach we have demonstrated ability to support more things beyond payment
... SEPAmail is CC-SA licensed
Ricardo Varela: Link is wrong in the slide, should be http://documentation.sepamail.eu/ [scribe assist by Ricardo Varela]
USE CASE: Allow multiple levels of security based on the type of transaction being performed. No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.

Topic: Transparency of Roles Affecting all Attributes of Price - Joseph Potvin

Joseph Potvin: I am an economist, 15 years in the IT domain
... re the UI for digital payments, how many of you paid in something other than Euro to get here? How many of you got to choose your conversion rate? Put your hand up.
... leave it up if you clicked on conversion options in paypal's screen (everyone's hands go down)
... amounts were quoted in local and Euros; this illustrates and underlying assumption, that there is only one exchange rate option; this example though showed other options e.g. between paypal and mastercard/visa, the diff being whether you know the rate at the time of the transaction
... I chose the credit card, due to fewer intermidiaries, rather than use paypal then intermediaries
... re philosophy of money; the tokenization of human obligations; a means of accounting them
... if we did UML for the payment process, three use cases for money
... unit of account; medium of exchange (communications); value aspect (descriptors or standard of deferred payment, stored value - I call it a value benchmark)
... doing the use case and relationship diagrams in UML; who are the stick figures?; who gets to choose the value benchmark etc?
... we are used to those choices; but not for this example (the exchange rate options showed earlier)
... in this paypal example, who got to choose the value benchmark? there were two parties in the transaction, did either get to choose?
... happy that paypal provided this choice, but whose role is it?
... example of a taxi and porter to the check-in. if the porter opens the bags and takes something "it's my business model to take something" - it's not the intermediary's role to determine aspects of price, rather to define service fees
... conversion rate is not a service fee, it's a component of the money
... there is a lot more to this example choice than is apparent
... in the WWW, we need a way to code these things
... thinking about this in the UML terms, where do the lines go and what roles do the actors have, this is a direct line to the theory of money
USE CASE: USE CASE: Enable the customer and the merchant to determine the inter-currency valuation benchmarks, given that this is a core attribute of price. Require that any restrictions on choice related to core attributes of price be made transparent and explicit.
Ricardo Varela: Small highlight over Josephs comments: many payment providers, including paypal, do not call this a conversion but mention it specifically as "cross border and currency conversion fees", as there are both variable and fixed costs associated with the networks they use to move money ... so yes, they are fees and you accept them as so on the payment terms and conditions

Topic: Last-mile Payments in Africa - Trans-Africa Solutions

Neil Mason-Jones: I represent Trans-Africa Solutions, a South Africa startup; bringing the emerging market / unbanked perspective
... the market is very difficult to authenticate
... we are trying to meet them in the way they want to transact; mostly cash
... in South Africa we have a huge divide in economic capability
... re the unbanked, in South Africa as much as 80%, scenarios such as this occur; in the living in city center, traveling back to home is very expensive
... outside the city center, you can spend a lot just going to buy a ticket
... we find that there is a resistance to putting cash anywhere, in wallets or savings
... we are trying to bridge the last mile, using the mobile devices, libraries or cafes to access the product, gain a token and make a payment in a physical location
... tokens can be barcodes, QR codes, etc
... this is slightly different use case; between request and receipt, it can take days
... its easy to expect all to be online; that the offline are not that large a subset; that may be but we need other options and fluidity to support them
... also there's a large opportunity for tech to help; but in Africa charges are obscene re the service bring provided; people thus distrust the banks; in the UK it is very different, the cost factors are so low
... tech talked about in this meeting e.g. crypto currencies can have large impact in emerging economies
... though banks etc resist on every possible level, we need tech competition to bring about change
USE CASE: Allow a physical version of a digital receipt that can be verified, perhaps by printing out a QR Code on a slip of paper with some additional information.
Dave Birch: Summing up; Gray established the merchant needs
... Robin suggested a web framework for this
... Cyril suggested a standard way to move around the data
... Joseph pointed out that we have collapsed unit of accounts, building upon other work
... Neil made the point that the medium of exchange needs to be extended into cash
... e.e. walmart has a capability to buy online and pay in cash
USE CASE: Allow for a settlement that is based on a cash transfer.

Topic: General Discussion on Customer/Merchant Experience

Stéphane Boyera: You make a good point re the notion of decoupling payment systems with intent of payment
... this is a critical point; we need layer separation;
... having an easy way for merchants to support multiple systems and a method for user to select...
Dave Birch: Between the phone and a payment terminal, there is a lot of chance for complex options to take place; standards may need to address the complex negotiations that will occur
Cyril Vignet: Part of standards is to define the value chain of payments
Gray Taylor: Taking into account foreign exchange, what I care about in the end is what I will get charged for
... quoting the final ticket price will let the user choose
Michel Leger: There's no breakout that makes it possible to know what cut was taken by whom;
... re transparency and seamlessness, they don't correlate; the more choices are offered, the more complex the UX
Gray Taylor: Customers will never read those screens
Eric Tak: What about point-of-sale (POS) terminals, how do we integrate what we come up with here?
Gray Taylor: Fees added happen in the back office, not the POS. pricing queues at the POS are philosohically great, but impossible
... if we can present the final ticket across multiple vendors and give choice that would be great
... our POS challenge is painting the screen as the user is using it; we have to keep it simple for the user
... moving the POS screen down to the phone, you can see exactly what's going on
USE CASE: Move the point of sales terminal off to the users mobile .
Michel Leger: Need for customer choice may be based upon size of the transaction. For small amounts, you probably don't care.
Cyril Vignet: Is is possible to automate options at the POS, for POS with web-based presentation
Dave Birch: Existing systems do limit us, so we mustn't limit our standards efforts to the existing card system, but look to more options, with the understanding that one implementation of the standard may ultimately be card-based
Michel Leger: Should a standard be explicit about roles? would it be acceptable for intermediaries to propose components of price?
... in multiple currency transactions, the intermediary does define components of price
Manu wanted to ask about entry points for change being merchants (MCX, could we deploy web payments in fuel industry?)
Manu Sporny: It's good to think past cards; who will be the early adopters? probably not the banks unless fees are preserved
... convincing consumers may also be difficult
Dave Birch: Successful wallets are from retailers
Manu Sporny: Exactly; retailers will push this into the market; W3C will need to figure out how to work with them
Dave Birch: We do need to build those bridges
Ori Eisen: What is the problem we are trying to solve?
Michel Leger: If the banks are changing, they will change with the game also if the economics are right
Dave Birch: Banks also have an interest in driving down costs
Gray Taylor: The litmus test for retailers will be can they get banks to change from the interbank model
... retailers want online and POS to work the same
ACTION: Manu to reach out to MCX to try and get them involved in the W3C work on payments.
Dave Birch: Retailers will incentivize customers to opt for MCX
David Ezell: MCX == Merchant Customer Exchange, a movement to build a Visa/MasterCard alternative network with far lower transaction fees.
Ernesto Jimenez: Re the point about negotiation on the payment process, users may need to choose manually since you can't always know what balances are on the different payment methods
... availability of options will also depend upon location
Dave Birch: What I am saying is there can be a wider set of possibilities
Virginie Galindo: More about MCX here : http://www.mcx.com/
Ernesto Jimenez: Range of payment service providers can be loaded into the wallet in the short term, but balances may not be known
... user behavior/preferences can also drive automated choices
Dave Birch: Policies can be set and downloaded from many sources and executed at the POS
Tobie Langel: This is typically where user agents compete
Ricardo Varela: API integrations in browsers will likely cause Visa/MC to cooperate; so we shouldn't expect them to resist this. The standards won't say anything about fees so that will change on its own
... is we assume that we have to tell intermediaries what they have to do we are already making some assumptions
Joseph Potvin: What I was saying was that the role that intermediaries are taking needs to be visible in the standard
Ricardo Varela: There you are already supposing there will be intermediaries, and how many there are is unclear
Emil Johansson: Question re SEPAmail; trust is important, what will be the consumer protections?
Cyril Vignet: Consumer protection will be provided by the TTPP; the payload will define terms etc; the payment request will have all the data, the idea is to have all the info at the customer side so they can make decisions
Dave Birch: Under the current systems, these aspects are all bundled. A system like SEPAmail will allow unbundling of those elements, which can then become part of a negotiation.
... Specialist Intermediaries may arise who can provide that role; Visa/MC may actually fulfill that role
Alexander Gee: We have draft legislation that payer should have the final word on which payment service should be used
End of session 4.