Use case: streamlined payment for fuel with receipt. Questions? Ian Jacobs <ij@w3.org>.

Terminology

• Merchant: Example: a company that sells fuel (e.g., gasoline, electricity).
• Service: Merchant-offered service, namely providing fuel and a receipt.
• Merchant PSP: The Merchant's Payment Service Provider
• User: A person (or other entity) that wishes to use the Service.
• User Device: A mobile phone (or car or other device) that the User uses to interact with the Service.
• Pump: Merchant device used to carry out the Service.

Requirements

Requirements as Expressed by Ian

• The system must not require the User to have created an account with the Merchant in order to use the Service.
  • Rationale: To be useful in practice, the system should involve no more friction than using a credit card.
• The system must not get data from User Device without some form of initial User consent.
  • Different actions might constitute consent in some settings (e.g., connecting the Pump to the User Vehicle).
• The System must not require that the user share personally identifying information prior to consent to engage the Service.
• The System must not required information about the User other than that required to fulfill the payment method selected by the User.
• The system must align with Web architecture.

Notes on Ways to Restrict the user Device

The User Device may be limited in a variety of ways (e.g., due to business relationships):

• The User may only have access to certain Merchants
• The User may only have access to certain Payment Apps
• The User may not be able to change Payment App settings (e.g., for fleet management).

These limitations can be layered on top of the underlying protocols and standards.

Requirements as Expressed by IFSF Device Integration WG (Editor=JohnC)

Background High Level Description This use case describes how an autonomous vehicle refuels. The vehicle application authorises a fuelling (e.g. electricity, petrol, diesel, LPG, Hydrogen, etc.,) and enables payment (when required) and receives loyalty rewards (when required). The vehicle in this architecture initiates the transaction on a W3C called Vehicle Infotainment System (VIS), which in this simplest case may be a web browser application on the VIS console, or even running separately on a smart phone (when the vehicle is occupied). Clearly for an autonomous vehicle no user interaction is possible and this is the default situation. By implication an autonomous vehicle parking (i.e. stationary) alongside a refuelling point it can be assumed the vehicle requires refilling - in this situation if the vehicle requires a cable connection, service personnel are available to make the connections. Otherwise contactless recharging is assumed.

At this point in time the technology maturity is such that it cannot be assumed contactless charging nor that geo-location service are sufficiently reliable to unambiguously determine which service delivery point is to be utilised. A vehicle operator or forecourt attendant is assumed present although the use case described below can have pre-set defaults to enable autonomous contactless refuelling.

Where payment (or deferred payment – on account) is required for the fuel, the account information is held within host applications (e.g. the Central Host Processor in IFSF module naming convention). No PCI-relevant data is transferred between the vehicle and host [MPPA], nor between host [CHP] and fuel dispenser (electric vehicle charger or liquid fuel dispenser).

Confirmation of the fuel delivered and (if required) the payment receipt is returned to the vehicle (VIS console) /smart phone either as a digital receipt and/or an email receipt.

In this use case example the vehicle and service delivery point deliver location based services so the correct (and adjacent – within 5 meters?) re-fuelling point is reserved (and then subsequently authorised). Where the location services aren’t provided, additional dialogue is required to a) select the dispensing device (called a fuelling point in IFSF terminology) and (dependent upon Location services availability) b) the site location.

Scope

The scope of this use case covers all the entities and/or devices involved to process an autonomous vehicle fuelling transaction. The entities are described in the IFSF Engineering Bulletin #23.

1. Vehicle Infotainment System (IFSF name = Mobile Payment Application (MPA))
2. Host System (IFSF name = Mobile Payment Processing Application (MPPA) and Central Host Processor (CHP))
3. Site System (IFSF name = Unattended Forecourt Device Controller)
4. Service Delivery Point (IFSF Name = Fuelling Point (FP))
5. Payment Front End Processor (PFEP or Switch) - Conditional (If Payment necessary)
6. Loyalty Front End Processor (LFEP or Switch) - Conditional (If Loyalty Offer or Redemption)

Actors

In this use case an actor is defined as a software application (including applications that may reside in people). The following actors are relevant for this use case:

1. Vehicle or Mobile Payment Application
2. Mobile Payment Processing Application
3. Central Host Processor Application
4. Site Systems - Forecourt Device Controller [FDC] Application
5. Service Delivery Point Application (IFSF name = Fuelling Point)
6. Switch, Acquirers and Issuers Applications (existing payment infrastructure applications)
7. Conditional - Driver, Operator, Cashier / Attendant (Specifically where Trading Standards Conditions require Operator Consent to fuelling)
8. Conditional - Payment Application
9. Conditional - Loyalty Application

Architecture Partitioning

Applications are partitioned to Architectural Components as follows (other partitioning is possible and some architectural components can be combined into one physical device)

1. Vehicle or Mobile Payment Application == Vehicle or Smart Phone/Tablet
2. Mobile Payment Processing Application == Mobile Payment Processor
3. Central Host Processor Application == Central Host Processor
4. Site Systems - Forecourt Device Controller [FDC] Application == Forecourt Controller (also called Site Controller)
5. Service Delivery Point Application (IFSF name = Fuelling Point) == Fuel Dispenser or Electric Vehicle Charger
6. Switch, Acquirers and Issuers Applications (existing payment infrastructure applications) == A variety of Payment Processors
7. Driver, Operator, Cashier / Attendant (Specifically where Trading Standards Conditions require Operator Consent to fuelling) == People
8. Payment Application == Payment Processor (see also Switch, Acquirers and Issuers)
9. Loyalty Application == Loyalty Processor

Real-World implementations often combine the MPPA and CHP Applications onto one physical device (e.g. Cloud services), however other implementations place the MPPA in the cloud and the CHP application on-premise.

Stakeholders and Interested Parties

The key stakeholders and interested parties are listed below:

• Vehicle Manufacturers
• Smart Phone Manufacturers
• POS Vendors
• EPS Vendors (possibly only when a different architecture called Site Level Authorisation is required - This architecture implementation is not considered in this use case)
• Mobile Wallet Providers
• Web Browser Providers
• Mobile Payment Application Vendors
• Site Controller and Forecourt Device Controller Vendors
• Fuel Dispenser and Electric Vehicle Charger Vendors
• Mobile Payment Processing Application Vendors
• Weights and Measures Organisations (OIML – Legal Metrology)
• Trading Standards Organisations
• Safety and Environmental Organisations (e.g. BASEFA)

The stakeholders shown in Italic are new to IFSF (and Conexxus) and the precise interest is to be determined.

Trigger

An autonomous vehicle parks alongside a re-fuelling point and the Off-vehicle Refuelling Application (called Mobile Payment Application in IFSF and Conexxus documentation) is activated. Activation is fully automatic where there is no ambiguity about the adjacent service delivery point.

Where ambiguity exists user intervention is necessary to select the service delivery point (IFSF Fuelling Point) which in some cases may also the site location. This only occurs where location services aren’t available for whatever reason.

Assumptions

This use case simplifies the interactions between site systems (i.e. POS, EPS, FDC, Dispensers and payment terminals as these are already fully defined and operating within existing IFSF and Conexxus applications standards).

Globally the most common path through the Use Case is:

• Vehicle and Service Delivery Point know where they are located (GPS co-ordinates) but not sufficiently accurate to know the precise service delivery point unambiguously.
• Vehicle or Smart Phone have an operator (complete autonomous vehicles are rare)
• Vehicle requires an operator to physically connect charging cable (electricity) or Fuel Hose (Liquid fuels) between the Service Delivery Point and the Vehicle

Conditional and Exceptions from this path are highlighted in the Use case but not yet fully specified.

Pre-Conditions

For fully autonomous re-fuelling and for absolutely minimum user interaction during the refuelling a number of pre-conditions exist. Operational experience of Mobile Payment solutions in USA and Europe provides evidence that every additional dialogue step is a potential barrier to successful customer uptake.

• The VIS Console (or smart phone) has established a reliable communications link with the host application (in IFSF and Conexxus terminology this is called the MPPA)
• The Site Systems (and or directly to the fuelling point “calculator”) has established a communication link with the HOST application (in IFSF terminology this is called the CHP and in Conexxus this is on the same physical device as the MPPA).
• Fuel Re-fuelling Point (called Fuelling Point in IFSF terminology) is in “Idle state with Nozzle up” and there are “no locked transactions in FP memory” (See IFSF Dispenser Application Protocol Standard for definition of states).
• If there is an outdoor payment terminal (called CRIND, COPT or OPT in IFSF terminology) it is in “idle” state (see COPT Application Standard) and “prompting for customer to enter card or perform a starting action” (e.g. press a button to initiate a transaction).
• The vehicle knows where it is (Geo-Location services enabled)
• Conditional - Where payment is required an account is known in advance (that can be checked in order to approve the subsequent transaction)
• Conditional - Where a loyalty redemption or offer is to be made the loyalty account is known in advance
• Conditional - The product grades for fuelling the vehicle are known (used to prevent incorrect fuelling, called crossovers in Petrol stations) - Note it is anticipated electricity grades, similar to fuel grades are widely implemented. E.g. Clean Electricity (made from renewal resources might be charged a different unit price to "dirty" electricity.
• Conditional - The maximum amount (always cash) of fuel to be taken is provided. For electric vehicle charging this may also be a time (e.g. 40 minutes).
• The fuelling point and/or site knows where it is. If the fuelling point location is ambiguous then an operator (usually driver) must resolve the ambiguity by either inserting the refuelling nozzle into the vehicle or manually inserting a “point identify (e.g. pump number) into the MPA (resident on the smart phone or VIS console.

Success Criteria

Vehicle has been refuelled (either partially or fully). Payment, where required, has been acknowledged and/or a receipt issued confirming received product and payment. Fuelling point has returned to idle state (with Nozzle back) and transaction has been cleared from it’s memory. Any loyalty reward and associated digital offer has been redeemed or collected for next transaction. Vehicle is disconnected from Service Delivery Point (electric charging cable or fuel hose removed from vehicle and placed back in vehicle or service point holster )

Normal Use Case

Normal is hereby defined to be > 95% of Mobile Payment re-fuelling operations that have been successful.

• 1. Vehicle parks (i.e. is stationary) alongside a fuelling point that delivers the grade of product required. The vehicle knows (geo-locations services enabled) that it is at a particular refuelling site.The vehicle operator triggers the refuelling by entering the Service Device Id (pump number or side identification (A or B)).

<Alternate Flow - Future Technology- No Service Point Dialogue> No user confirmation of Service Point ID (IFSF = Fuelling Point ID) is required as the service point has broadcast its ID.

<Alternate Flow - Automatic Detection of Service Point> The vehicle refuelling point is connected to the vehicle by a charging cable and or hose which automatically detects the service point ID in use. This is currently only applicable to Electric Vehicle Chargers.

<Alternate Flow - Location Services on Vehicle are not enabled> An Operator is required to confirm (Prior to selection of Service Point) the site location identifier.

<Alternate Flow - Enter payment Method> No default set. Vehicle operator selects desired payment method.

<Alternate Flow - Enter maximum Fuelling Limit> No default set. Vehicle operator must set maximum fuelling amount/time.

<Alternate Flow - Enter Allowed Product Grade> No default set. Vehicle operator must set allowed product grades identification

<Alternate Flow - Enter Loyalty Account ID> No default set. Vehicle Operator must set loyalty account identification

• 2. Vehicle (or Smart Phone) Mobile Payment Application requests Fuelling Point is reserved for it’s sole use for a subsequent re-filling transaction.

<Exception Flow> The Fuelling Point is unable to be reserved and the request is denied (this can be for multiple reasons, like pump already in use or broken).

<Exception Flow> Vehicle aborts the transaction prior to any fuel being taken.

<Exception Flow> the customer/driver/operator or cashier aborts the transaction before any fuel is taken.

<Exception Flow> Product grade not available on this Service Point.

• 3 In Parallel with 2 – Where account/payment is required an Account/Payment authorisation request is sent to the Payment Service Provider

<Alternate Flow> Where no account authorisation is necessary (e.g. fuel is provided free-of-charge) this is not required.

<Exception Flow> If payment authorisation is declined then FP reservation is cancelled

• 4 When Payment is necessary and Authorised (e.g. by the Switch out to Card Issuer via the acquirer) then the CHP sends a Fuelling Point Approved message to the site to enable fuel delivery.

<Alternate Flow> A validation code must be entered into the Fuel Point CRIND to confirm vehicle is adjacent to and correct Fuelling Point is reserved.

<Alternate Flow> Due to local trading standards a site operator (cashier or attendant) is required to consent transaction is safe and valid (e.g. driver not smoking and aged over 18)

• 5. Vehicle Operator connects an electric charging cable or selected liquid fuel hose to vehicle.

<Alternate Flow - Future Technology > The vehicle refuels either robotically (liquid hose) or automatically (Contactless charging point). No manual cable connection or hose connection is necessary.

<Exception Flow> Product grade incompatible with vehicle allowed grade.

<Exception Flow> Dispensing is aborted, by operator or vehicle or cashier or dispensing system (e.g. internal error detected)

• 6 Refuelling commences. Vehicle starts refuelling - Under current OIML legislation after 3 volume pulses a fuelling transaction is non-reversible. This is similar for electricity - I doubt whether the electricity can be returned.

<Exception Flow> Dispensing is aborted, by operator or vehicle or cashier or dispensing system (e.g. internal error detected)

• 7 Vehicle (Operator) Ends Re-fuelling by disconnecting cable or hose from vehicle and returning it to holster. Vehicle Infotainment Console detects when its tank/battery is full or when fuelling transaction needs to be terminated (amount limit reached - either volume or time).

<Alternate Flow> Where robotic or contactless charging is available - This step is not required. Transaction completion is either when requested max volume is delivered, vehicle full or fuelling aborted by operator, vehicle, device or cashier.

<Alternate Flow> Loyalty Award is sent to the MPPA to enable the MPPA to offer additional real-time offer. This message is sent only when the amount dispensed is known.

<Exception Flow> Vehicle, operator or attendant/cashier aborts transaction after some fuel has been taken. Transaction is payable.

• 8 Transaction Completion. The Fuelling Point sends a final transaction message to the MPPA which issues a receipt confirming the Fuel taken and (optionally) any payment/account transaction information. This receipt information contains sales information and is sent to the vehicle account.

<Alternative Flow> A receipt is printed at site (e.g. on the CRIND, COPT or OPT) or another printing device available on the site.

<Alternative Flow> Where payment is required for the fuel and/or fuelling service the MPPA sends the final registered sales information to the PSP for processing. The final payment information is added to the receipt

<Alternative Flow> Where a loyalty account has is known then a reward and or offer is made this information is also sent to the site and/or or neither, to the Vehicle Infotainment System. Additional dialogue is required depending on type and nature of loyalty offer/redemption.

Alternate Flow(s)

To be extracted from Normal Case given above and defined

<Alternate Flow - Future Technology- No Service Point Dialogue>

<Alternate Flow - Automatic Detection of Service Point>

<Alternate Flow - Location Services on Vehicle are not enabled>

<Alternate Flow - Enter payment Method>

<Alternate Flow - Enter maximum Fuelling Limit>

<Alternate Flow - Enter Allowed Product Grade>

<Alternate Flow - Enter Loyalty Account ID>

Exception Flow(s)

To be extracted from Normal Case given above and defined

Other Issues

• QR Codes are optional (required only if geo-location services cannot uniquely identify service delivery point (Fuelling Point)) and may be used in event of network or connectivity failure.
• In some contexts, Merchants may require some additional user actions before enabling the Pump (e.g., first time users may need to watch an education video). Merchants may limit these actions to first-time visitors.

Other Considerations

• Limitations on Web content / JavaScript

High Level Flow as Expressed by Ian

At a high level, the flow can be described this way:

• In parallel (potentially):
  • User provides payment credentials to Merchant PSP. Merchant PSP authorizes payment
  • User reserves Pump
• Merchant enables Pump
• User uses Pump
• Merchant delivers receipt

Goals

Streamline how the following information is exchanged:

• User access to Merchant Web site. (Part of Web Architecture)
• Provision of Payment Credentials
• Provision of Pump Information

Web Site Access

A number of technologies could be used:

• Physical Web ("Beacons"). The beacon sends a notification (with a URL) to the User Device. No prior permission grant from the User required. User interaction with the notification opens the Merchant Web page.
  • Note: Today this may require the user to be using the User Device, but at some point user agents may support letting the User know about the notification.
• Web NFC. The User places the User Device on an NFC tag and receives a notification with a URL.
  • Note: Need to determine what permission is required to interact with an NFC tag via Web NFC, or if mere proximity constitutes consent.
• Geofencing. Assumes the user previously visited the Merchant site and granted permissions.
  • Note: this work is currently stalled.
• As a last resort, the User can visit the site manually (e.g., it has been bookmarked or is available through a search engine).

Provision of Payment Credentials

• The Merchant site uses Payment Request API to request payment. The User selects a payment method and authorizes sending a response to the Merchant.

Provision of Pump Information

After the Merchant PSP authorizes payment, a number of technologies could be used to identify the relevant Pump and communicate that to the Merchant.

• Physical Web.
  • Note: While it may be possible to use one beacon per Pump, that may not work in practice if Pumps are numerous, close together, etc.
• Web Bluetooth. The Merchant site needs to request permission from the user to communicate with a device using the Web Bluetooth API.
  • Apparently the plan is that once there has been a connection through a Web Beacon, that also grants permission for Web Bluetooth access, but that is not yet part of the Physical Web.
• Web NFC. Assumes Pump NFC-enabled.
• As a last resort, the User can provide a pump identifier to the Merchant site manually

Notes

• In some of these cases (e.g., Web NFC) it may be able to communicate the information without additional user action (e.g., the user puts the nozzle in the vehicle and the nozzle and car communicate Pump information).
• The Merchant can provide information to the User browser (via Web sockets, for example) that can be used as a "key" to unlock the pump. This might include information that could be reused in future transactions (e.g., to be able to skip watching an intro video).

More Detailed Flow as Expressed by Ian

• User drives into service station; assume User Device is on and available.
• Using Beacon, Merchant sends notification with URL to User Device.
• User clicks on notification, which opens Merchant site. Merchant site prompts User to provide payment credentials.
• Merchant PSP authorizes payment.
  • EXCEPTION: Payment Not Authorized
• User Device provides information about pump (through Web NFC or Web Bluetooth) / unlocks pump.
• Merchant enables Pump.
  • EXCEPTION: Pump Not Activated (e.g., broken, wrong fuel type, etc.)
• User connects vehicle to Pump.
  • EXCEPTION: User Abandons Service. (This can occur at any time prior to the next step)
• User starts Pump.
• User stops Pump.
• User disconnects vehicle from Pump.
• PSP pursues payment processing.
• Merchant delivers receipt (with both "delivery" and "payment" information) to user. (Could be printed, delivered by email, etc.).

Notes

• Summary of User actions
  • Respond to initial notification
  • Select payment method and push button to authorize payment
  • Communicate Pump identifier to Merchant. This may be automatable (e.g., related to nozzle/car interaction, or in future Web Bluetooth permission model).

Exceptions

Payment Not Authorized

• Merchant does not enable Pump and displays an error message (e.g., "Try again")

Pump Not Activated

• Merchant does not enable Pump and displays an error message (or "Wrong fuel type")

User Abandons Service

• After a timeout, Merchant returns Pump to "not enabled" state and displays "Ready" message

Acknowledgements

• Thanks to JohnC for starting this off and explaining the automotive perspective. Thanks to Dom for info about options.