With the right tune up, in-car payments can take off

Technologies associated with IoT are inexpensive, low powered and frequently based on common soft- ware platforms. Recent rapid development in the automotive/haulage industries allows the integration of this tech into cars/trucks.

These developments have coincided with the simultaneous rise in fintech with the use of technology supporting financial services such as payments, fostering a commonality of innovative development across these domains.

Modern cars generally include an in-vehicle infotainment (IVI) system. These systems usually combine multimedia, navigation, radio and telephony functions. Software to execute these functions requires a sophisticated operating system (OS) to provide underlying services.

IMAGE: Bloomberg News

Rather than develop a fully custom OS, automotive manufacturers (OEM) and Tier 1 suppliers tend to adopt existing, licensed OSs, such as Linux, Windows or QNX on which to build IVI systems. Such OSs require significant processor power to execute applications and services at an appropriate level of performance. Suitable System-on-Chips (SoC) for such applications are provided by semiconductor companies such as Intel, Renesas, NVIDIA and Qualcomm. Each SoC typically includes multiple CPU cores, a DSP and a GPU, in addition to an array of on-chip peripheral hardware.

This combination of application software, complex OS and SoC is similar to the approach taken to build mobile phones. Application software such as Apple Pay, Android Pay and Samsung Pay in combination with Near Field Communication (NFC) or Bluetooth Low Energy (BLE) peripheral hardware and techniques like Host Card Emulation (HCE) and QR codes allow a mobile to be used as a payment device.

It is therefore possible to build payment technologies into automotive IVI systems using a similar approach, enabling the car to become a payment device.

Note that although NFC is commonly used in mobile phones to facilitate payments, it may be impractical for automotive use cases. The range for NFC communication is 20 cm at most with most systems working at a range of less than 4 cm between receiver and transmitter. Reliably positioning a car with this proximity to an NFC reader is difficult. BLE has a much larger range, so requires less accuracy; QR codes are based on cameras, and have a still larger range, but require “line of sight;” wired solutions are the most reliable and secure, but may be considered less “user friendly. None of these alternatives are yet standardized for payment use cases.

Some IVI systems, when combined with specific mobile phones, provide support for “projection” type functionality, based on Android Auto and Apple CarPlay. With these systems, application software running on a mobile phone and connected to the IVI system renders onto the IVI system; the application is fully usable using the IVI system only. In this use case, the car may use the phone as a payment device. This use case is not considered in this paper; here we focus only on integrated solutions.

Additionally, there are specific variants of Android available for use in IVI systems – O.Car is a recent version. As these variants present the same Application Programming Interfaces (API) for developers, existing software will be readily portable to these devices. However, the underlying hardware or software enablers are not available in IVI devices at present.

A car is of little use as a payment device, if there are no devices available capable of accepting payments from them. Some devices such as toll road booths are already able to accept payment without human intervention. Other use cases, such as fuel payment at the pump and fast food drive-throughs are equipped for the use of card readers. Relatively simple changes are required to support IVI based payments.

The most significant software work required is porting and enabling of existing OS features and hardware support for the target devices. It is possible that device drivers for specific hardware modules may be unavailable directly, e.g. NFC, encryption, DSP hosted algorithms, MMU schemes, TEE. However, in such cases, it is likely that the semiconductor vendor will provide a base driver for a reference platform.

Application software may need to be developed from scratch, depending on the underlying APIs and the nature of existing applications. At a minimum, applications will require porting from existing mobile platforms, considering different input methods, display geometry, hardware platforms and safety requirements.

Software to be deployed in cars is subject to strict engineering process. There is likely to be significant additional software test work associated with the deployment of these features. Similarly, all software handling financial transactions is subject to regulation. This may lead to additional certification work.

Note that it is common to deploy software in a virtualized environment within an IVI system. This may imply an additional level of system validation, at both OS and fully integrated system levels.

Where open source software supporting payment use cases is deployed in an IVI system, there are also additional policy and procedural aspects of the software to consider: Is the license suitable and acceptable?; How will 3rd party changes to the software be handled (down streaming)?; And will changes to the software deployed in the IVI system be made available to 3rd parties (upstreaming)?