[Slide 1]
"ISO 8583 + Oil"
scribe: the things on the diagram have been working for 25 yars
[Slide 2]
scribe: this architecture is one
of five deployed architectures today
... oil companies don't want to give up information about site
locations
... site name/number and what facilities are available was
information they did not want to share with each mobile
provider.
P2F=POS to FEP
MPPA = Mobile Payment Processing Application
CHP = Central Host Processor
scribe: in Shell, the CHP is called the "site integration platform"
FEP = Front End Processor
P2H = POS to Host
scribe: but whoops, that should be H2H
FDC = Forecourt Device Controller
POS = Point of Service
[Slide 3]
the diagram is simplified, e.g., does not show geolocation data
scribe: various interfaces,
security, etc.
... loyalty not shown here either
... if you want to implement Web Payments.
... it would happen in the interface between the MPPA and the
CHP
[Shell Fill and Go]
scribe: you arrive at the
station
... you have an app on your phone
... customers did not like having apps pop up automatically
upon approaching the station
... now you arrive at the pump and park
... you click on the app to launch it
... defaults are shown: (e.g., payment method, maximum fueling
value [required by law])
... there also used to be a "fuel grade" default
... but it was inconvenient to change it when using someone
else's car
... user is then prompted to enter the pump number
... there was a version where the user pointed a camera at a QR
code, but that did not last long (due to weather,
inconvenience)
... so now we ask them for a pump number, which is confirmed by
a button
... that let's people correct mistakes as well
... then there's a review and confirm screen
... the dispenser is configured (may take 3-6 seconds)
... and then the user is prompted to start fueling
... then there is a receipt screen (total pumped, cost,
etc.)
... and a receipt is emailed to the consumer
... but it's not a VAT receipt
... due to VAT rules, there is only one of those ,and you'd
have to collect it in the shop
... that was the "happy path"
... but of course lots of things can go wrong
... when it goes right, it's simple:
[Prerequisites]
scribe: to make dialog
simple
... if you don't know where the user is, then you need to enter
the site ID manually, which is subject to error
... everything has to be working
... and it has to be resistant to power failures at every
moment of the protocol
... you need to recover from errors; need to (for example) not
reserve a pump for a customer forever
... need to release it after a timeout
... or power failure might happen after authorization but
before you've told the user the amount
... you may park next to the dispenser but the grade of fuel
you want from that pump might not be available
... or the pump might not be working for some reason
... in the UK we allow two transactions to stack on the
dispenser
... you can fill up and go get coffee without having paid
... and another user can pump gas in the meantime
... in Italy they allow stack of 12
... in Japan stack of 4
... in case of these mobile payments, you need to configure the
dispenser for stack of 1
... also, after months of research, I concluded you can't in
practice uniquely identify the selected fueling point
... you might park near pump 1 and use pump 2 to fill up a
can
... this is problematic for autonomous vehicle fueling
... might be solvable by communicating pump information upon
connection of the nozzle to the car
[API Summary]
scribe: small number of
messages!
... they are between CHP and the site
... doesn't matter whether the data came from a mobile app or a
browser
reserveFP(<pumpnb>,<maxfuelamount>)
scribe: another param which is a token to link reserved pump with approved pump
two failure messages:
* Free Fueling Point
* Cancel Fueling Transaction
scribe: user or cashier cancels
transaction
... the reason that people don't want people to use phones near
a pump is no longer due to electricity
... it's related to distraction
... and if distracted people can spill fuel on themselves,
creating a hazard
... batteries in phones no longer a risk to falling out and
creating a spark
[When something goes wrong]
John: 95% of current transactions
follow the "happy path"
... there are at least 22 sad paths and those need thorough
testing
... a web app would like through a proxy server to the site
integration platform
[Security issues]
scribe: hackers sending millions
of reservePump requests
... some of the preventative mechanisms include
geolocation
... phone must be within X meters of the pump otherwise won't
authorize
... the API messages are secured via HTTPS certificates
... application on a site runs in its own sandbox
... on a dealer site, for example, IFSF provided a computer
with systems and software in it since they would not run on
their backoffice
... we provided a box that linked to their pump
controller.
... the MPAA box can be on a separate server
IJ: Let's walk through "the web version" of this at the next call
John: This architecture is
becoming prevalent in real-world implementations
... it is modular, suits the oil company architecture, ....
(since they don't want to share site information with some other parties)
scribe: the info that comes from
the mobile payment processor, just sends the location
coordinates
... just sends the coordinates..the SIP looks into the site
database to find which site it is, the IP address of that site,
etc.
... it can look at the message and determine the payment
method
29 March