Automotive Web Payments Task Force

<Ian> https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer

<scribe> scribenick: ted

Ian: we are still in the process of building agenda for our F2F meeting at TPAC

<Ian> ---> https://github.com/w3c/automotive-pay/wiki/Agenda-20171019 Agenda

TPAC

<Ian> https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer

Ian: last call we asked people to flush out use cases they were interested in
... I took a pass at an explainer for pay at the pump
... ultimately I felt somewhat comfortable saying there are limitations in payment method implementations and fraud prevention that digital/web payments may help overcome
... taking a look from cost reduction, convenience and improve security

Adam: we have previously built an application with Shell
... some information about the user is stored in the vehicle regarding their account
... various systems like OCR for plates aren't integrated at this point for unlocking the pump

Ian: I have seen a prototype of an integrated solution from FirstData at a conference
... I was told the regulatory requirements are complex
... unsure if that applies when it is the phone versus the car

<AdamC> Whilst petrol stations have ANPR (not OCR), they are not directly linked to the users and their accounts, they are purely for security.

Matt: you should not engage in your phone in any way while vehicle is in motion. it could interact with the vehicle and internet in the background

<AdamC> It was also john_s, rather than myself

<Ian> IJ: I Wanted to separate "safety" from "how data flows"

<Zakim> Ian, you wanted to talk about First Data

Ian: after considering the problem statement, the opportunity is about streamlining, improving security etc
... we would have to treat poor or no connectivity differently

<Ian> http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/automotive-pay/gh-pages/flows/geolocation.pml

Ian: station owner (or chain) could have a site that phone or car could interact with it to complete payment

<Ian> http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/automotive-pay/gh-pages/flows/ble.pml

Ian: this UML shows the different paths for how the pertinent payment link is delivered. it can be done via NFC, BLE, GPS etc
... this raises some security issues

<Ian> Ted: to avoid eg a bogus beacon, your vehicle could send GPS so payment provider can align before letting payment proceed

Ian: FirstData limited the problem by having pre-existing relationships with stations elsewhere

s/AdamC:/JohnS:/

JohnS: there is a merchant certificate that is transferred to the device eg ApplePay at the outset

Ian: yes, our API aligns well with Apple with the exception of the merchant certificate part
... since on the web you may not have a previous relationship with the merchant. that can help and we have a proposal in the WG for addressing that
... there is business value in doing more on the web and not having heavy, constantly updating apps

Adam: we definitely want a standard payment process which can interact with any bespoke service provider we deal with
... having this genericized would definitely help

Ian: [typing on the wiki

<Ian> https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer

Ian: there might not need a prior relationship with the service station

JohnS: while that makes sense the OEM wants to retain control to its app market
... they may want to limit based on partnerships

Ian: even without partnerships you can monetize and direct to preferred stations without discarding others
... there are other ways to monetize

JohnS: we can implement the various steps in your UML up to 6 readily
... security issues are reduced when you have the previous merchant relationships

<Ian> John: We can enhance security based on database of locations and relationships (can be monetized)

<Ian> John: We could start with subset of merchants, then allow them to onboard easily

<Ian> Ted: John touched on part of what I wanted to say

<Ian> ...OEMs will control the app marketplace and have the opportunity to establish partnerships

<Ian> ...while you do want to leverage partnerships, you will also want to enable some additional relationships

<Ian> (IJ adds to fraud mitigation section: "OEMs may have partnerships with some merchants, and can increase security through an onboarding process. In this case, OEMs will also want to account for situations where users wish to get fuel from merchants that are not yet OEM partners.")

<scribe> scribenick: ted

JohnS: on the merchant side you want to standardize processing
... OEM may want to provide a bespoke experience
... what needs to be returned to the merchant as part of the payload before proceeding
... I am keen to think about what information is necessary for this and other use cases like parking

Ian: in the vision outlined in the explainer the user is interacting directly with eg Shell
... Shell can ask me to provide any necessary information through their web service including pump number
... we can also make strides in streamling beyond just the payment piece

JohnS: in that scenario you are working with the merchants page and data needed

<Ian> JohnS: Might be interesting to bundle other data relevant to the transaction (e.g., pump number) with the payment payload

<Ian> Ted: This is HTML but is not necessarily a "page" that loads

<Ian> ..people are mixing and matching various technologies in practice

<Ian> ...I note payment request API is being implemented in webkit

Ian: I am looking for some validation that people are interesting in persuing this use case

+1 I think this is the highest profile use case

(perhaps the most complicated as well)

Ian: the starting off point is how to get the device (phone or car) the URL
... I hear it is a regulatory and liability problem
... everyone here is welcome to edit this wiki page and contributions are welcome

JohnS: how does the UX operate under 2FA?

Ian: in some sense the ecosystem consists of merchant with buy button on their website
... it returns credentials, shipping address etc. browsers are starting to ship with ability to integrate with payment apps
... some data may be stored in browser and relayed to merchant and defer to the app for the transaction
... there is discussion in the Web Payments WG around 3d secure without further user verification
... we expect the strong auth to come from underlying payment app and send tokens through encrypted pipe

<Ian> https://w3c.github.io/webpayments-methods-tokenization/index.html

Matt: we recognize tokenization isn't universal yet but we're moving that way

<Ian> Ted: We could work on more than one use case.

<Ian> ...do people want to focus on this one or start to explore others like parking or tolls?

Adam: as a team here at JLR we are looking at the other use cases as well

John: I think it comes down to the payment types, fuel needs to be pre-authorized
... if we segment the workflow then common components will apply to other use cases such as parking

Ian: what we have done so far in web payments is streamline checkout
... there are a number of things in our queue such as recurring payments, preauth and those are on agenda for F2F
... cards on file get stale. through API it can know when you update your credit card and could as a convenience communicate that out to recurring service needs
... Tolls and parking are of interest

Toll roads

Adam: there are a couple interesting use cases for handling Tolls
... they vary widely across the world
... some use ANPR and give owner N days to make payment
... others can be handled with a toll and credit card

John: some have card on file and use RF and create charge automatically

Ted: here I keep 40US on my RF account, if there is an issue eg stale card I get flashing yellow at toll

Ian: what is broken today?

<Ian> Ted: One thing that's broken is "wide variety" around the world

Ian: two main cases are prepaid/card on file or pay within N days

<Ian> Ted: What user confirmation is required for transaction?

Ian: web payments doesn't require user confirmation but PCI in some cases prevents storing of CVV and considers entry as confirmation
... there could be logic in the payment app for a certain type of payment (toll) to proceed
... it is possible

(avoid distracting driver)

Adam: what about use case of paying tolls at the end of your journey? user can choose which payment method they wish for all the tolls incurred on the trip

Ian: I like and that is a good UX

<Ian> +1 to a consistent user experience where the car helps me manage interactions with different merchants (e.g., pre-order food, buy fuel, pay tolls)

<Ian> ..the car helps me manage my merchant needs.

John: what is the value on doing this from car instead of just from someone's phone?

Ian: from user perspective I can see both, from car point of view the partnerships

Adam: apps can be preinstalled. user might not want to download an app to complete a transaction

Ian: app on phone can know you have pending tolls and you can pay that while waiting in queue at movie theater...

<Ian> [Discussion of "phone" v. "head unit"]

Ted: both and pairing and being able to get to pending and completed transactions from either has many advantages to the user

Ian: I encourage people to work on UML mockups and contribute to wiki
... the BT folks have a proposal that came out this week

Next meeting

<Ian> IJ: Let's hammer on this over the next week and see if we can refine it / raise issues

<Ian> Next meeting - 26 October at 9am ET

Ted encourages JLR to open up use cases they're working on

John: will do