Skip to content

1. Introduction

Informative section

This section is informative. It provides context, motivation, and scope for the specification. Normative requirements begin in Section 2.

1.1 Purpose

Open-loop contactless payment — paying for a ride, a scooter, a parking session, or a ferry crossing by tapping a bank-issued card or mobile wallet directly on a validator — has become a baseline expectation in modern mobility. Yet implementing it remains disproportionately hard.

Each new deployment tends to start from a blank page. Operators, integrators, gateways, and acquirers negotiate, from scratch, questions that recur in every project:

  • What data must travel from the validator's tap into the back-office?
  • Which fields are sensitive and must be protected, and which are operational and may be used freely?
  • Where are the trust boundaries, and who is responsible for what?
  • How do mobility-specific operational models map onto standard payment authorization and clearing flows?

The result is a landscape of bespoke, point-to-point integrations that are expensive to build, difficult to audit, and hard to reuse. Knowledge does not transfer between projects, and each integration reinvents the same plumbing with subtle, undocumented differences.

The purpose of the Open Mobility Payment Framework (OMPF) is to provide a common, vendor-neutral baseline for this plumbing: a shared vocabulary, a canonical data model, an explicit division of responsibilities, and a set of conformance profiles that let independent parties interoperate without renegotiating fundamentals each time.

OMPF aims to reduce initial uncertainty, shorten integration timelines, and raise the security baseline of mobility payment deployments — without constraining the commercial or operational freedom of any party.

1.2 Scope

OMPF specifies the technical contract for exchanging EMV contactless payment data across the mobility payment chain. Concretely, OMPF defines:

  • A canonical transaction object (ompfMessage) produced by a validator after a contactless tap, and consumed by downstream systems.
  • A set of roles and their responsibilities across the chain.
  • A data classification model separating sensitive, operational, and non-sensitive data.
  • Conformance profiles specifying how sensitive data is cryptographically protected in transit and at rest within the message.
  • Encoding, transport, and security requirements governing the exchange.

OMPF is designed to be modular (capabilities are organized into profiles and clearly separated concerns), extensible (new profiles and fields can be added without breaking existing implementations), and incremental (an operator can adopt a minimal conformant subset and grow from there).

1.3 Out of scope

To remain focused and vendor-neutral, OMPF deliberately excludes the following. These exclusions are intentional and are not anticipated to change in future versions.

OMPF does not:

  • Replace or redefine EMV, PCI DSS, or any card network's rules, programs, or certification requirements.
  • Define fare calculation, tariff models, or pricing logic of any kind, including time-based, distance-based, capped, or zone-based fares.
  • Define clearing, settlement, reconciliation, or accounting between financial parties.
  • Specify back-office business logic, customer service workflows, refund policies, or dispute adjudication procedures.
  • Mandate a specific system architecture, deployment topology, vendor, acquirer, processor, or operator.
  • Define the internal interface between a validator's hardware and its embedded software; OMPF begins at the point where a conformant message is produced.

Note

OMPF describes what a conformant message contains and how it is protected and exchanged — not how an operator prices a journey or how a back-office reconciles its ledgers. Those remain the proprietary domain of each implementer.

1.4 Audience

This specification is written for the technical and product stakeholders who design, build, or operate mobility payment systems:

Audience What they get from OMPF
Mobility operators A clear definition of what their validators must produce and what their back-office should expect, reducing dependence on any single vendor.
System integrators A documented, reusable data model that lowers integration risk and effort across projects.
Gateway providers A canonical input contract that reduces per-operator customization.
Acquirers and processors A view of how mobility operational models map to standard authorization and clearing flows.
Validator and terminal manufacturers / SDK developers A stable target to implement once, rather than per-customer.
Card networks A neutral reference for how their transit and mobility programs are realized in practice.
Security and compliance teams An explicit data classification and trust-boundary model to support PCI scoping and risk assessment.

Readers are assumed to have working familiarity with contactless EMV payments, basic cryptographic concepts (symmetric and asymmetric encryption, key derivation), and JSON. Where OMPF relies on external standards, it references them rather than reproducing them.

1.5 Relationship to existing standards

OMPF is explicitly a complement to existing standards, not a competitor to them. It occupies the integration layer between established payment standards and the operational reality of mobility deployments.

EMV (EMVCo)

The EMV Specifications define how contactless cards and mobile wallets interact with acceptance devices and how chip data is produced. OMPF consumes EMV data — it carries selected EMV tags within its transaction object — but does not modify, reinterpret, or replace EMV processing. A validator's EMV kernel and certification remain governed by EMVCo and the relevant networks.

PCI DSS (PCI SSC)

The Payment Card Industry Data Security Standard governs the protection of cardholder data. OMPF is designed to support PCI compliance objectives — in particular, by enabling architectures that minimize where the Primary Account Number (PAN), Track 2 data, and Sensitive Authentication Data (SAD) appear in cleartext. OMPF does not certify compliance, define a PCI scope, or substitute for a Qualified Security Assessor's judgment.

Note

OMPF's conformance profiles describe cryptographic protection mechanisms that can help reduce the PCI scope of intermediary systems (for example, by ensuring a gateway or back-office never receives PAN in cleartext). Whether a given deployment achieves a particular PCI scope reduction is a determination for the implementer and their assessor — not a claim made by OMPF.

Card network rules

Visa, Mastercard, American Express, Discover, JCB, and UnionPay each publish operational rules and, in many cases, transit- or mobility-specific programs (such as transit aggregation, deferred authorization, and fare-capping support). OMPF references the operational models these programs enable, but the rules themselves remain authoritative and are not reproduced here. Where OMPF and a network rule appear to conflict, the network rule prevails.

Key management and cryptography

OMPF's conformance profiles reference established key-management and cryptographic standards — including ANSI X9.24 (DUKPT) and IETF cryptographic primitives — rather than defining new ones. Profiles specify which mechanisms apply and how they are reflected in the transaction object, not the internals of the algorithms themselves.

Transport and encoding (IETF)

OMPF uses widely adopted IETF standards for transport and encoding: TLS for channel security, JSON for message structure, base64url for binary encoding, and RFC 3339 for timestamps. These are referenced normatively in Section 6.

Adjacent mobility data standards

OMPF is payment-focused and is designed to coexist with mobility data standards that address other concerns — for example, scheduling and real-time data specifications used across transit. OMPF does not overlap with or depend on those