Skip to content

Open Mobility Payment Framework

Status — Working Draft v0.1

OMPF v0.1 is the first public working draft. Breaking changes may occur between minor versions until v1.0. Feedback and proposals are welcome via the GitHub repository.

What is OMPF?

The Open Mobility Payment Framework is a vendor-neutral, open specification that defines how EMV contactless payment data should flow from field validators to gateways, acquirers, and operator back-offices in mobility environments.

OMPF defines:

  • A canonical transaction object (ompfMessage) that field validators produce after a tap.
  • Roles and responsibilities across the mobility payment chain.
  • Conformance profiles for cryptographic key handling and field protection.
  • Security and interoperability requirements that minimize PAN exposure and reduce PCI scope for intermediaries.

The problem OMPF solves

Mobility operators across transit, micromobility, parking, and ferries want to accept contactless EMV payments in open-loop environments. Today, every project starts from a blank page:

  • What data must travel from the validator's tap into the back-office?
  • What data must be protected and what data is operational?
  • How are responsibilities split between validator, gateway, acquirer, and back-office?
  • How do operational models (MTT, KFT, PAYG, retail-like, deferred authorization, aggregation, negative lists, retries, chargebacks) align with the payments chain?

These questions are answered today through bespoke integrations between operators, gateways, and acquirers. OMPF provides a common language and data model so that new projects can start from a shared baseline rather than reinventing the same wiring every time.

What OMPF is not

OMPF intentionally does not define or replace:

  • EMV specifications, PCI DSS, or card network rules (Visa, Mastercard, American Express, Discover, JCB, UnionPay).
  • Tariff calculation, internal clearing, accounting settlement, or operator-proprietary business logic.
  • AFC (Automatic Fare Collection) back-office products or fare engines.
  • Any specific vendor, acquirer, processor, or operator implementation.

OMPF focuses on technical interoperability, data classification, and the canonical flow from validator to gateway, acquirer, and back-office.

Who should read this

Audience Why it matters
Mobility operators Understand what data your validators must produce and what your back-office should expect.
System integrators Reduce integration risk with a shared, documented data model.
Gateway and acquirer providers Align your APIs and reduce per-operator customization.
Validator/terminal manufacturers and SDK developers Implement once against a stable specification.
Card networks and processors See how mobility-specific operational models map to standard payment flows.

How to read this specification

The specification is organized into ten normative sections, plus supporting documentation:

  • Sections 1–4 establish foundations: purpose, terminology, roles, architecture.
  • Sections 5–7 define the data model, transport, and security requirements.
  • Sections 8–10 describe conformance profiles, conformance claims, and versioning.

Start with the Specification Overview or jump directly to a section using the navigation.

Principles

OMPF is guided by the following principles:

  1. Complement, don't replace. OMPF builds on EMV, PCI DSS, and network rules. It does not override them.
  2. Vendor-neutral, acquirer-neutral, operator-neutral. No specific product or company is privileged in the normative text.
  3. Mobility-native. Designed for tap-based, no-PIN contactless payment — not retail POS.
  4. Minimize sensitive data exposure. Implementations SHOULD reduce where PAN, Track 2, and SAD are visible in cleartext.
  5. Separate sensitive, operational, and non-sensitive data.
  6. Modular and extensible. Profiles and extensions are first-class concepts.

License

Editor

  • Carlos Rivera — Editor of the Open Mobility Payment Framework.

Get involved

Read the Specification → View on GitHub →