Parkopedia and ParkMobile, both part of the mobility platform Arrive, are enabling in-car parking payments across more than 80,000 US locations, combining ParkMobile’s national footprint with Parkopedia’s in-vehicle integration work. Against a national network of over 500,000 total locations, that is a meaningful slice rather than full coverage, and Parkopedia supports OEMs with bespoke wallet arrangements regardless of the automaker’s existing payment setup.
Coverage is the headline. The more consequential detail for anyone responsible for parking payment economics is that phrase about wallet flexibility, because it is where the interchange question lives.
Why the channel changes the economics
A parking transaction’s cost is not a single number. It depends on how the card is presented, who the merchant of record is, and which network the transaction routes across. The same $12 parking session can carry materially different processing costs depending on the answers.
In-car payment is a genuinely new presentment context, and it does not map neatly onto the existing categories. It is not card-present in the traditional sense — there is no terminal reading a chip. It is not quite the same as a mobile app transaction either, because the credential lives in a vehicle secure element or an OEM wallet rather than on a phone the cardholder is holding.
How a given implementation is characterised determines the interchange category it qualifies for, and that characterisation is set by the token provisioning and authentication path, not by the user experience. Two in-car payment products that look identical on the dashboard can price differently.
The merchant-of-record question
This is the question most operators do not ask early enough, and it determines nearly everything else.
When a driver pays for parking through the car’s infotainment system, who is the merchant of record? Three arrangements are common across mobility platforms, and they have different consequences.
The parking operator is MOR. The platform acts as a gateway or facilitator. The operator holds the processing relationship, sees the interchange detail, owns chargeback exposure, and can negotiate rates. This gives the most control and the most administrative burden.
The mobility platform is MOR. The platform processes the transaction and remits net proceeds to the operator, usually on a schedule with a commission or per-transaction fee deducted. The operator’s cost is the platform’s fee, and the underlying interchange is the platform’s business, not visible to the operator.
The OEM or wallet provider is MOR. Less common for parking, but present in some connected-vehicle commerce arrangements, and it pushes the operator a further step from the transaction economics.
None of these is inherently wrong. The error is not knowing which one applies, because the second and third arrangements convert a variable, negotiable interchange cost into a fixed platform fee that may be better or worse than what the operator could achieve directly, depending on volume and mix.
Routing, tokenisation, and what you can actually influence
In-car credentials are tokenised. The token is provisioned by the network through the OEM’s or platform’s wallet, and the routing decision for that token is made upstream of the operator in every arrangement except direct MOR.
That has a practical consequence worth stating plainly: for most operators, in-car payment volume is volume you cannot route. If your processing strategy depends on least-cost routing or on a particular network relationship, transactions arriving through this channel sit outside it.
Whether that matters depends on volume. At single-digit percentages of transactions it is a rounding error. If in-car payment grows into a double-digit share of a facility’s sessions, an unroutable and opaquely priced channel becomes a real line item.
What to ask before enabling the channel
Which entity is the merchant of record, and is that stated in the contract? Not in the sales conversation — in the contract.
What is the all-in cost per transaction, and how is it structured? Percentage, fixed fee, or blend. Ask for a worked example at your average ticket, which for parking is small enough that fixed-fee components dominate.
How does settlement timing work? Platform-as-MOR arrangements typically settle on a cycle rather than daily, and the float has a cost.
Who owns the chargeback? Small-ticket parking disputes are rarely worth contesting individually, so the question is really who absorbs them and whether that is priced in.
What customer data do you receive? Session data, vehicle or account identifier, and whether you can recognise a repeat customer. For operators with loyalty or monthly-conversion programmes, an anonymous channel has a strategic cost beyond the processing fee.
Is there rate parity language? Some platforms require that the price offered through their channel match or beat your on-site rate. That constrains your pricing latitude, and it is easier to negotiate before signing.
The read
In-car payment is arriving because drivers want it — Parkopedia’s own user research reports that surveyed US drivers uniformly value easy in-car payment functionality — and because OEMs want differentiated connected services. Operators will not be the ones deciding whether it happens.
What operators can decide is whether they enter the channel understanding its economics or discover them from a settlement report. The small-ticket nature of parking makes this more consequential than it would be in higher-average-ticket retail: on a $4 session, a fixed per-transaction component of 30 cents is a different business than 30 basis points. Get the structure in writing, model it at your actual average ticket, and revisit it when the channel’s share of volume changes.



