Mobile Document (mDOC) lets a DynaFlex II reader read a verified digital identity document — a mobile driver's license (mDL), a mobile passport, or a simple age check — directly from a cardholder's phone. Instead of scanning a plastic card, the reader engages the phone over NFC or a QR code, retrieves the requested data over an encrypted link, and cryptographically verifies that the data came from a trusted issuer before handing results to the host.
This guide explains how an mDOC transaction works end to end and points to the reference pages for each command, property, and file operation involved. It is the orientation layer; the byte-level detail lives in the reference pages linked throughout.
Applies to: DynaFlex II Go.
mDOC supports credential-verification flows that need a real, issuer-signed government identity document rather than a self-reported value — for example age-restricted sales, identity checks at pickup or check-in, and onboarding. A transaction can return specific data elements (name, birth date, portrait, document number, and so on), or, when all you need is an age check, run a dedicated age-verification command.
Two standards families are supported:
— the mobile driver's license (mDL) standard, together with the data set used by U.S. jurisdictions.
— a second namespace for other mobile ID document types, including mobile passports.
Which data elements are available depends on the namespace you select. The full catalog of request items per namespace lives in the request-item tag tables (see Reference below).
An mDOC credential lives in the cardholder's mobile wallet. The phone hardware and OS versions required to hold a mobile ID or passport are set by the wallet providers and change over time, so this guide links to their documentation rather than restating requirements that would quickly go stale:
Check the relevant provider page for current device, OS, and regional requirements.
An mDOC transaction moves through four phases. The host starts it with (or for age-only checks) and follows progress through notifications.
Device engagement. The cardholder presents their phone by tapping (NFC) or by letting the reader scan a QR code shown on the phone. The data exchanged during engagement seeds the ephemeral session keys used to encrypt and decrypt the rest of the exchange, per the key-generation algorithm defined in ISO/IEC 18013-5. The reader reports engagement status back to the host through . If engagement fails, the transaction ends here.
User consent. The reader connects to the phone over BLE and sends the session-encrypted "mdoc request" it built from the request items you specified in the command. The phone then displays a consent message showing the ID holder exactly which data elements the reader is asking for. No data leaves the phone until the holder taps Accept; if they decline, the transaction ends without returning data.
Data retrieval. Once the holder consent, the phone releases the "mdoc response." The response is CBOR-encoded and decoded by the reader.
If the operation finishes – whether it timed out or was cancelled – the reader sends .
Use for a full transaction where you specify exactly which data elements to request across the ISO 18013-5 / AAMVA / ISO 23220-4 namespaces.
Use when you only need to check age. It is a subset of , supports the namespace only, and requests just the age-over item — 18, 21, or 25. The response format is identical to : the reader returns the requested data element, not a separate pass/fail flag (see Handling results and errors).
To cancel a transaction that is already running, send .
The host enables one or more ways for the phone to start engagement:
— the cardholder taps the phone to the reader.
— the reader reads a QR code presented on the phone.
At least one engagement method must be enabled for a transaction to start. Audio cues (start engagement, finish engagement, BLE transfer complete) can be left on automatic tones or driven explicitly by the host.
mDOC layers two independent protections:
Session security. The engagement exchange derives ephemeral keys that protect the request/response traffic between the reader and the phone (ISO/IEC 18013-5).
Issuer authentication and integrity. The reader hosts an internal of trusted IACA certificates — the issuer certificates supplied by the original credential issuers (states, Apple Wallet, Google Wallet, Samsung Wallet, and others). It validates the returned mDOC locally, on the reader itself, against those certificates and checks the SHA-256 hash of each item, so a response can be trusted to have come, unaltered, from a legitimate issuer without relying on any external service.
Separately, the data returned to the host can optionally be encrypted and MAC-protected (the 0xFD data container). mDOC uses the reader's for this — the same keys shared with the device's other features — so no mDOC-specific key provisioning is required. The container is secured with either a TDES or an AES key, depending on the DUKPT key type in use. See the guide for details.
Before a reader can run an mDOC transaction, all of the following must be in place:
Firmware. {{CONFIRM: minimum MagTek Reader firmware/image version that supports the mDOC commands.}} Note that certificate-store file IDs differ between older and newer reader images (see the Certificate Store reference), so confirm the image before scripting file operations.
A valid mDOC subscription. mDOC is a licensed capability. The device must hold a subscription () whose ValidFrom–ValidTo window includes the current date. Transactions are permitted only inside the subscription window. The subscription is provisioned with , delivered inside . Setting both dates to zero disables the subscription. To obtain or renew a subscription, {{CONFIRM: how customers request, purchase, and receive a subscription — business process still under development.}}
. The reader needs the issuer trust anchors used to authenticate documents: a
Optionally, configure with a number of "warning days." When the subscription is within that many days of its ValidTo date, the reader emits a subscription-warning notification (on ) reporting the configured warning-day threshold, the days remaining, and the ValidTo timestamp, letting your application prompt for renewal before transactions stop.
For a full read (), you choose which identity fields to request using the command's bit-mapped request items. The elements available for each namespace — for example family_name, birth_date, portrait, document_number, age_over_21 — are catalogued in the request-item tag tables:
request items — tags start from 0xDFB001
request items — tags start from 0xDFB041
Mobile passport (mPassport) request items — tags start from 0xDFB061
See in the Reference section for the complete lists.
On a successful read, the requested data elements are returned to the host. When output security is enabled, the data arrives as an encrypted string (the 0xFD data container) that the host decrypts; when it is disabled, the same data is returned in the clear. A requested portrait is returned as JPEG image data (encrypted along with the rest of the container when output security is on). The and responses share the same format.
Progress updates and successful results arrive on , carried under Payment Technology 0x40 (Mobile Document). The terminal state of the operation arrives on .
Common non-success conditions to handle — these behave like the equivalent events in a standard EMV transaction:
Session-data failure — the secure session with the phone could not be established or validated.
Timeout — the cardholder did not complete engagement within the configured timeout.
Host cancel — the host sent .
User cancel — the cardholder declined consent or cancelled from the phone (display-only reason).
The pages below hold the authoritative, byte-level detail for everything referenced in this guide. (Link targets in the site are wired to these destinations.)
Authentication and integrity. The reader validates the response locally on the reader itself against its pre-loaded issuer IACA certificates and verifies the SHA-256 hashes of every returned item to confirm the data has not been altered. On success, the results are delivered to the host through Notification 0x0101; on failure, a failure notification is sent instead.
A valid device RTC, so subscription and certificate validity windows can be evaluated.
At least one engagement method enabled (NFC and/or QR/BCR).
Subscription warning — the subscription is nearing expiration (see above).
Notification 0x0101 (PT 0x40, mDOC) - Transaction Information Update (Copy & paste this URL: )
This notification reports information about progress and state changes that occur during a transaction.
This notification reports the final result of a transaction the host initiated using Command 0x1001 - Start Transaction.
mDOC subscription — and expiration notification
Device properties used to configure Mobile Document functionality.
File operations 0xD811 / 0xD812 / 0xD821 / 0xD831; VICAL, individual certificates, Cert Store Table
How DynaFamily readers protect cardholder data and manage keys: encrypting data at the point of read, the keys and key-serial numbers behind DUKPT, verifying message integrity with MACs, loading keys with TR-31, and the PCI requirements deployers must meet.
DynaFamily readers with a contactless interface can exchange commands directly with NFC tags and MIFARE cards through pass-through commands and can present themselves as a card to another reader through NFC card emulation
