S&P Global Mobility spoke to Hans-Hendrik Puvogel, Parkopedia's Chief Operating Officer, to understand the in-car payments space as it stands today and how it is likely to evolve going forward.
In a wide-ranging chat with S&P Global Mobility's Vivek Beriwal, Puvogel expands on Parkopedia’s journey and highlights the significance of its in-house developed payment processing platform, which has become integral to the Parkopedia solution and its value proposition for B2B customers.
The following are edited excerpts of the conversation:
S&P Global Mobility: Location intelligence, navigation assistance and secure payment gateways, plus a number of in-vehicle commerce applications are enabling drivers to seamlessly make fast, contactless payments on the go, using the vehicle’s infotainment head unit as a digital wallet. It would be great if you can break this process down and explain how an in-car payment system actually works.
Hans-Hendrik Puvogel: The in-car payment system, in principle, is not too different from any other e-commerce system that you might be aware of or using. It typically has three core components. First is user account and user management. The second piece is the need for some sort of a shop system, so you need to connect inventory SKUs like in traditional e-commerce. It's part of the location and driving experience and the POI (point of interest) then becomes transactable. And then the third piece is the payment piece, which does require a scenario where you have a method of payment on file where you then provide the necessary information to actually capture a relevant amount from a payment card to the payment service provider of a merchant.
However, in the car it gets a little bit more complicated because we have the added complexity of the in-car infotainment system, and it needs to be an active part of the driving experience. So, here the inventory gets integrated and becomes part of the map, whether it's parking, charging, fuelling or any other service, it becomes a transactable POI. You either can put a layer on top of the map or you have it as a rich POI set provided by one of the dedicated mapping providers.
Then you have the navigation application itself sitting on top of the mapping layer. In addition to the navigation and map rendering application, you need a shopfront, which is essentially an application that allows the driver to, for example, click on a POI and then make a purchase for the service provided at such POI. Internally, we call that ‘nudging’ and that's a critical element because we see that a lot of the transactions are actually driven by nudging rather than the consumers actively looking to purchase parking or any other service. The vehicle needs to drive engagement with the driver and propose it actively.
We then have the inventory management platform to connect to different merchants. So, we have APIs that go into the backends of those merchants to look at the inventory they have, the availability of such inventory, the prices, etc. which enable us to actually generate live pricing quotes for the driver in the vehicle. In parking for instance, there are parking operators or companies that aggregate certain parts of the parking industry. We then aggregate those to create a more comprehensive offering for the driver in the vehicle and also for the OEM, the merchants, the parking operators, the charge point operators etc.
On the payments side, there are automotive OEMs (original equipment manufacturers) that already have wallet solutions, such as Mercedes Pay, Mercedes' own digital wallet. Then you have others who at present don’t have their own digital wallet and who use our wallet or the wallets provided by payment service providers to facilitate in-car payments.
S&P Global Mobility: What use cases in particular are driving the in-car payment space?
Hans-Hendrik Puvogel: In my discussions with senior management at OEMs, I'm always asking them one question which is, “you are developing the software-defined vehicle and you're changing your business model in terms of feature on demand, services on demand, overall subscription businesses etc. How are you going to monetise that?” So, you need to have a payment platform in the vehicle that people are used to in order to be able to actually monetise your feature-on-demand list, whether it's an ADAS (advanced driver assistance system) or AD (autonomous driving) feature or any other feature or services that you want to market to your customers as part of your [software-defined vehicle] monetisation strategy. You need payments in the car but for it to be successful and usable by drivers, they need to develop a habit of using it. So, it's like in every shopping centre you have anchor tenants that drive frequency. Feature on demand or services in the context of SDV (software-defined vehicle) monetisation are low frequency. You don't sell hands-free driving three times a month. You may sell it once a year or once every three years but that's it. But in terms of frequency, there are high-frequency services that are directly attached to the use and the operation of the vehicle. We see parking as a core element because it's one of the vehicle-centric services that are necessary to operate a vehicle. It's the service with the highest frequency of usage. Then you have charging, fuelling, and tolling, where frequency depends on consumer habits and the density of toll roads in an area.
S&P Global Mobility: How can OEMs drive in-car occupants to choose to pay for services sitting inside their vehicles?
Hans-Hendrik Puvogel: It's all about creating frequency of usage and building use cases around that. This will create habits and accustom people to using the service in the car because most buyers of vehicles today are from older demographics, who usually don't change their habits that easily. There are early adopters in all demographics and you need to show them clear benefits of convenience, of comfort, of safety etc. for them to adopt new technologies. This is not a hit-and-run business where you can change the world in a quarter. This is something for the long run where you have to subsequently add these features and give people the comfort that it's a safe and convenient way of using the service. Unfortunately, most OEMs are struggling to create reasons for people to subscribe to those services and across the board. So, the question is how do you create attractive offers for consumers that basically drive them or will drive up renewals for subscriptions? In-car payments is an element where you have a value in the bundle as opposed to what people can do on Apple CarPlay or Android Auto, and that's where they need to differentiate.
S&P Global Mobility: Are there any technical challenges that in-car payment companies encounter in their day-to-day functioning, i.e. when customers are trying to make various payments from their cars?
Hans-Hendrik Puvogel: There are obviously challenges that have to do more with regulatory requirements than with the technology as such. So, one of the things that is critical for the financial success of an in-car payment system is an optimisation of the so-called decline rates. You will have to make sure that the credit or debit card that you're using is actually a payment card that will not be declined or where the transaction will not be declined by the issuer behind it because there are insufficient funds or there is an issue in their fraud detection system. So, decline rates are very critical. They will never be zero, that's almost impossible, but you will need to keep them as low as possible. There also are challenges when we do rollouts where new methods of payment need to be added to a card. Other than that, you can always have technical issues that could pop up around connectivity but to date these are managed well.
S&P Global Mobility: From a user experience perspective, do you think in-car payment interfaces have become more intuitive? Do you see voice-based interfaces taking off for in-car payment applications going forward?
Hans-Hendrik Puvogel: There are different elements in the user experience. One thing is how do you nudge or notify a driver i.e. tell the driver that they can do a transaction at a specific location now. It could be a GUI (graphic user interface) push notification on a screen. You could also have a voice interface, with the vehicle telling you that this is happening. You could imagine when you drive through a toll entry that your steering wheel vibrates. That's a haptic interface. For some of those use cases you don't even notify the driver anymore but the vehicle does it automatically. So, voice is obviously the interface of choice in scenarios where the driver is actively looking for something. For instance, “please find bookable parking at my destination” while they're driving in the city centre.
That's an active scenario. You could also have a passive scenario in the sense that your vehicle gets closer to your destination and then actively proposes bookable parking locations close to your destination with live pricing quotes, etc. So, voice is the interface of choice and there are others, where graphical interfaces make more sense than voice, plus the preferences of individual drivers. But there's no doubt we need both in the vehicle to drive this.
S&P Global Mobility: Is there a role of AI and machine learning technologies in in-car commerce, say in nudging the customer?
Hans-Hendrik Puvogel: In certain nudging situations, you could call that AI but I would just simply call it an algorithm with a certain logic behind it. It gets more interesting when you start looking at recommendation engines and personal profiles. In terms of how you protect the personal data, what you use the data for in order to create personal recommendations etc. that is something where I definitely see an opportunity for AI and ML going forward, like when you have charging and parking connected to each other. For instance, asking your car “please get me to a charging location where I can charge my car up to 80% and have a business dinner at the same time.” Those are things where it gets really interesting because then you can direct people to certain locations and cater to specific needs using conversational AI.
S&P Global Mobility: Can you spell out for us the factors needed to be successful in the in-car payments space?
Hans-Hendrik Puvogel: I always say there are four success factors, the four E’s of in-car payment success. The first one is Enrolment. The enrolment needs to be simple and straightforward. The communication around it needs to be in a way that consumers understand the benefits of the service easily and it's easy to integrate the method of payment, user account details etc.
The second E is Engagement. This means you're not going to be successful unless you succeed in creating user engagement. How do you get them moving, how do you change habits, how do you make them take action? That's engagement. And that's why nudging is a critical element of it. Ease of use is the third E. Ideally, it's a one-click transaction, maybe two, but not more than that. There's a reason why Amazon took off after they created the one-click purchase. And then the last one is Entrepreneurship where the service is treated as its own independent business with focus and attention to nurture its success.
S&P Global Mobility: We have seen big names in the connected car data aggregation and in-car commerce space failing in the past. Are you wary of the scalability and sustainability side of this business?
Hans-Hendrik Puvogel: Well, personally I'm not. We've been in the space more than 10 years now. So, we started in-car payments in Europe in 2013 with Volvo. It was a specific solution that didn't really scale, and we went through a learning curve. It was something that at the time was leading from a technology perspective, but it didn't really take UX elements into account the way it should have to really scale and gain acceptance. So, we learned that UX is critical to scale the business and UX has two elements to it: how do you enrol people and continuous ease of use.
The sales teams at OEMs are doing a great job when it comes to other parts of the sales process, but they're usually not set up for this part. So, you have silos of connected services teams that are building something that has great potential but then there's nobody to really exploit that and reap the benefits of that potential, build it and drive it. That's the scalability problem. And then on the other hand, you have sales teams that are used to inheriting features that they then have to market. So, technically scalability is no problem whatsoever. The scalability problem is to a large extent, an internal OEM problem in terms of how you actually drive the service, how you manage it and how you turn it into a success.