See also: IRC log
<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
<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: station owner (or chain) could have a site that phone or car could interact with it to complete payment
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
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
<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