In-Vehicle Payment UX: Why the Screen Is Only Part of the System
Quick Overview
Problem: Payment flows that behave well on a bench IVI unit routinely misbehave in the vehicle under mobility, network variability, and the cockpit's shared compute budget.
Common failure points: Identity that assumes a fresh session on every wake, SCA challenges that stall under intermittent LTE, ISO 15118-2 Plug & Charge falling back to card-tap without a clear reason, payment services sharing the cockpit's compute and memory budget with the perception and infotainment stacks, driving-state gating added at the end.
Where it appears: EV charging via Plug & Charge, in-car tolling and parking, drive-through and quick-service retail, subscription and feature-on-demand purchases.
Engineering focus: Credential lifecycle wired to the payment provider's own APIs, transaction-path budgeting across the cockpit hypervisor, offline-tolerant flows where supported by the PSP and rules, driving-state-aware HMI, and secure-element / HSM integration on the connectivity or gateway ECU.
In-vehicle payments are becoming a core layer of connected vehicle services, but their reliability depends on much more than the payment screen. On a reference cockpit, a driver can park, tap Pay, authenticate with the fingerprint on the steering-wheel sensor, and see a confirmation before letting go of the wheel. The demo feels effortless.
In vehicle integration, the same flow behaves less predictably. Parking sessions time out on entry to underground garages. Plug & Charge occasionally handshakes cleanly and occasionally falls back to card-tap on the same charge point. A tester on a road trial hits a session-expired screen mid-toll because the vehicle has spent a stretch under a bridge.
None of that is a UX defect. The screens have not changed. The assumption behind most in-vehicle payment programmes is that the payment flow is a screen problem — design the screen well and the flow works. That skips the part of the vehicle where in-car commerce actually lives. A payment request crosses the hypervisor from the HMI domain into a connectivity partition, hits a secure element or HSM for signing, traverses the LTE/5G modem, terminates on a payment service provider or an e-mobility service provider, comes back through the same path, and hands the driver a confirmation while the driving-state monitor decides whether the confirmation is allowed on screen at all. Under motion, variable signal, thermal and compute load, and across a fleet on rolling software revisions, that flow rarely holds together on the screen alone.
Why It Fails
Payment identity is a lifecycle, not a session. Payment identity in a vehicle is a chain — eSIM or iSIM in the modem, hardware-backed keystore in the connectivity or gateway ECU, factory-provisioned OEM identity, and credentials issued by external services. Each link has its own rotation policy and its own management path. Card credentials on the vehicle side are typically network-tokenised (see the EMVCo payment tokenisation framework), with provisioning, replenishment, suspension, and deletion handled through the token service's own APIs — a distinct lifecycle from firmware. What ties them together is the signed-update discipline the OEM already runs for firmware: the same rigor around signing, versioning, and audit has to extend to payment credentials, even though the transport and the API are different.
Transaction latency is measured on the bench, not across the cockpit. A payment SDK benchmark is a client-server round-trip on a stable network. In the vehicle, the same call traverses the cockpit hypervisor, contends for the memory bandwidth that also feeds display compositing, and rides a modem doing carrier aggregation over a variable signal. Field tail latency that matters for driver perception is materially higher than bench p50, and the gap widens under shared-compute contention in centralised architectures. UX that budgets against bench numbers ships timeout screens.
EV charging authentication is an ISO 15118 problem before it is a UX problem. Plug & Charge in production uses ISO 15118-2 today and is transitioning to ISO 15118-20 with bidirectional support. The flow depends on a contract certificate provisioned by an e-mobility service provider (eMSP), a valid V2G Root, a matching charge-point-operator side, and a Powerline Communication link over the Control Pilot line that has to survive cable-noise and pin-quality variance. When a driver sees "Plug & Charge unavailable, insert card", the fault is often not confined to the screen — it is upstream, in the contract-certificate chain, the PLC handshake, or the fallback to EIM (External Identification Means — RFID card, app, or credit card at the charger).
Strong Customer Authentication doesn't always survive intermittent connectivity. Under PSD2, in-car card payments require SCA where applicable, with defined exemptions (low-value, transaction risk analysis, and others); subsequent merchant-initiated transactions typically fall outside SCA scope rather than being an exemption. EMV 3-D Secure is a common way to deliver an SCA challenge, not an automatic per-transaction step. Where a challenge is triggered on a paired phone under intermittent LTE, timeouts drop transactions cleanly. The UX-only fix — "try again" — masks the missing engineering: using the exemptions where they apply, supporting pre-authorisation and deferred capture where the PSP and rules allow, and designing the SCA path to resume on network recovery. PSD3 and the PSR reached political agreement in November 2025, and the final compromise text was confirmed in April 2026; the application timeline depends on formal adoption and publication. The SCA obligation carries over and tightens, so the engineering approach hardens rather than relaxes.
Driving-state gating is architecture, not decoration. The set of constraints on what an HMI can show while the vehicle is moving is real, but the drivers are OEM HMI requirements, national driver-distraction rules, and platform-level restrictions built into Android for Cars — not one universal regulation. NHTSA driver-distraction guidance is voluntary. If the payment flow is architected without an integration point to the vehicle's driving-state signal and the driver monitoring subsystem (DMS) or occupant monitoring system (OMS), gating gets retrofitted — which is where flows that felt seamless in a lab suddenly show blocked screens, illegible confirmations under motion, or voice prompts firing at bad moments.
Hidden System Complexity
driver intent → HMI domain (Android Automotive / Linux) → cockpit hypervisor IPC → connectivity ECU → secure element / HSM signing → LTE/5G modem → PSP / eMSP / tolling operator → response → driving-state gate → confirmation
A Plug & Charge session adds a parallel path: cockpit HMI ↔ charging ECU, HomePlug Green PHY over the Control Pilot line to the charge point, the CPO backend, contract-certificate validation, and back. If the cockpit HMI polls the charging ECU over a SOME/IP service that shares priority with an infotainment stream on a saturated switch queue — the class of interaction described in deterministic in-vehicle Ethernet networking — a driver can watch an "authorising" screen for several seconds after the protocol handshake has already finished. The UX failure is downstream of a network-scheduling failure.
On the identity side, a hardware-backed key held in a secure element or an EVITA-class HSM has to be provisioned at factory, protected across the OEM's software-update and cybersecurity governance (including UNECE R156 where applicable), and correctly handled at change of ownership. A missed link surfaces as a payment method that quietly stops working years into ownership — a class of failure no HMI test would ever have caught.
Failure Patterns
Pattern 1 — Payment flows that assume connectivity for the full session. Parking, tolling, and drive-through flows that hold a session open across a garage entry, a tunnel, or a forecourt where signal is variable will drop under real-world modem behaviour. The architectural response — where supported by the PSP, the acquirer, and the applicable rules — is pre-authorisation, deferred capture, or risk-managed offline flows; UI copy alone cannot solve it.
Pattern 2 — Payment services contending for cockpit compute. On a centralised compute node running an Android Automotive HMI alongside perception under a hypervisor, a payment SDK's TLS handshake shares CPU and memory bandwidth with post-processing threads. Under heavy urban driving, tap-to-confirmation stretches long enough for drivers to tap a second time, generating duplicate authorisations that then have to be reversed. The fix is hypervisor scheduling and partitioning, not the button.
Cockpit and Connectivity Engineering for Payment-Enabled Services
Engineering Experience Across Cockpit and Connectivity Platforms
Solution Approach
Step 1: Treat payment credentials as a device-lifecycle artefact. Provision the hardware-backed root of trust at factory, tie payment credentials to it, and route each rotation event (SIM/eSIM swap, key rotation from a PSP or eMSP, change of ownership, revocation) through the correct dedicated channel — the token service's APIs for card tokens, contract-certificate provisioning for Plug & Charge, and the OEM's software-update process for anything embedded. These lifecycles are distinct, but they share the same discipline around signing, auditability, and rollback.
Step 2: Budget transaction latency across the cockpit, not against the payment SDK. Measure end-to-end tap-to-confirmation on target hardware with the perception stack running, the modem doing real-world carrier handoffs, and the cockpit under thermal load. Split the budget across HMI dispatch, hypervisor IPC, connectivity ECU, secure-element signing, modem round-trip, PSP or eMSP response, driving-state gate, and HMI confirmation. Any stage without an owned budget is an unbounded stage.
Step 3: Design the offline and resumption paths as first-class citizens. Where the PSP, acquirer, and applicable rules permit, parking, tolling, and low-value drive-through payments can use pre-authorisation, deferred capture, or risk-managed offline flows on entry to a geofence, reconciled on network recovery. Plug & Charge needs an explicit, well-signalled fallback to EIM instead of a silent card-tap prompt. SCA challenges that time out on the modem side should resume, not drop the transaction. Happy paths get assumed; offline and resumption paths are where UX credibility is earned.
Real Trade-Offs
Fully automated tolling and parking removes friction, but it moves consent management out of the moment of transaction and into a settings screen. Some jurisdictions do not accept that as informed consent for recurring financial actions. The design choice is where consent lives, not how many taps the flow uses.
Network tokenisation of card credentials reduces exposure to PAN data and may reduce PCI DSS scope for the OEM, depending on the architecture and compliance assessment. It also adds work: token replenishment, revocation on ownership change, and re-tokenisation on card reissue — all through the tokenisation provider's own APIs, on their own lifecycles.
AAOS-native card payments (an OEM payment service running natively on Android Automotive OS) and ISO 15118 Plug & Charge are separate credential domains. A vehicle may support both, but implementing one does not automatically enable the other. Phone-projected payments (CarPlay, Android Auto) keep card credentials on the phone — they travel with the user, which is cleaner at change of ownership — but they do not cover Plug & Charge and limit offline capability.
Voice-driven payment confirmation reduces glance time but introduces false-positive risk on ambient audio that has to be handled by explicit intent confirmation. The adaptive multi-modal HMI pattern that carries this well is not the pattern that ships fastest.
Attention gating against the DMS pipeline and driver-versus-passenger checks against an OMS or seat-occupancy sensor improve safety and the compliance argument, at the cost of a hard dependency on those subsystems being available at the moment of transaction — including under calibration or partial-fault modes.
Typical Cockpit and Connectivity Engineering Tasks
Secure Credential and Backend Integration
Integration of OEM- and PSP-provided SDKs, hardware-backed credential storage, and lifecycle hooks, implemented together with the client's payment provider. Separation of credential lifecycles from firmware OTA.
ISO 15118 Plug & Charge Integration
ISO 15118-2 and ISO 15118-20 stacks, HomePlug Green PHY / SLAC bring-up on the Control Pilot line, contract-certificate handling, V2G Root chain validation, and EIM fallback with clear UX signalling.
Transaction-Path Budgeting and Cockpit Scheduling
End-to-end tap-to-confirmation measurement across HMI, hypervisor IPC, connectivity ECU, and modem paths; SOME/IP prioritisation and hypervisor scheduling tuned so payment flows are not starved under infotainment or perception load.
Driving-State-Aware Payment HMI
Integration with DMS and OMS/seat-occupancy signals, driving-mode-aware simplification, voice + touch + steering-wheel multi-modal confirmation, aligned with OEM HMI requirements and Android for Cars driving-state restrictions.
Qualifying Symptoms
- Payment methods start to fail silently well into ownership, correlated with a token refresh or a certificate rotation.
- Duplicate authorisations appear when confirmation screens hang and drivers tap twice.
- Driver-distraction reviewers flag payment flows for glance-time or visual complexity even after HMI redesign, because the flow was not designed against a driving-state signal.
- Fleet or car-share change-of-ownership events leave orphaned payment credentials on the vehicle.
- Support triage cannot distinguish a modem timeout, an SCA drop, a certificate-chain failure, and a hypervisor scheduling stall — because none of them are traced at cockpit level.
Solution Context Link
At this stage the work is cockpit and connectivity architecture, not screen redesign — a credential lifecycle that survives OTA and change of ownership, a transaction budget owned across the hypervisor, an offline and resumption path for every payment scenario, and a driving-state integration point defined in architecture.
The context sits inside the shift to software-defined vehicle platforms and, at the network layer, in automotive connectivity firmware. The centralised-versus-zonal decision that drives all of it is covered in centralised versus zonal ECU architecture for software-defined vehicles; the middleware pattern is analysed in AUTOSAR Adaptive versus custom automotive middleware.
Promwad Micro Proof
Promwad's relevant experience covers the adjacent system layers rather than the payments platform itself: ISO 15118 and OCPP software on the charging infrastructure side, ASPICE-aligned IVI development on Linux and QNX cockpit programmes, and Android-specific APIs and motion-aware behaviour on Android Automotive. The engineering value in a payment programme sits in wiring these layers together, with the client's payment provider, not in building the payments platform.
FAQ
Why does a payment flow that works in the lab break in the vehicle?
What is ISO 15118 Plug & Charge and why does the UX depend on it?
How does PSD2 Strong Customer Authentication affect in-car payments in Europe?
How do we keep payment methods working over a ten-year vehicle lifecycle?
Related Engineering Cases
- Software Development for Charging Stations (ISO 15118 Plug & Charge with cloud offload): ISO 15118 protocol stack for EV charging with cloud-side execution. Adjacent to vehicle-side payment engineering; the direct relevance is on the charging infrastructure side.
- IVI System Software Development (ASPICE CL2): ASPICE CL2-compliant IVI software delivery for a luxury OEM cockpit programme. Demonstrates the engineering process framework payment services have to slot into.
- TV Application for Android Automotive: Android Automotive application development with Android-specific APIs and motion-aware behaviour. Demonstrates driving-state-aware HMI logic.