EMV Acceptance

EMV acceptance is how your host runs a chip (contact) or contactless EMV sale on a DynaFamily reader. The reader runs the EMV kernel and communicates with the card; your host orchestrates the transaction over the MMS command set — starting it, responding to the reader's prompts, forwarding the ARQC to your processor, and returning the result. This guide walks the full flow on the MMS command path and links to the commands, notifications, and data objects that implement each step.

How EMV acceptance works

The work is split between the reader and your host:

• The reader runs the EMV kernel, talks to the card, and encrypts cardholder data at the point of read (SRED).

• Your host starts the transaction, answers the reader's requests, forwards the ARQC to your processor, and returns the response.

There are two integration surfaces for this same flow. This guide covers the MMS command set directly. The Universal SDK wraps the identical flow in method calls and events — if you integrate through the SDK, the steps below still describe what happens underneath. (The .NET EMV Transaction Flow sample in the iDynamo manual shows the SDK surface.)

One behavior to note up front: readers with a display (e.g., the PED's touch screen) show cardholder prompts themselves. Readers without a full display, including the DynaFlex II Go, delegate those prompts to your host by sending ; your host shows the message or collects the selection. Watch for that difference throughout.

• The reader is connected over USB or Bluetooth LE.

  • See

• Keys are injected and you can decrypt output.

A typical contact or contactless sale runs as follows. Your host drives it with Start Transaction and reacts to the reader's notifications:

1. (Optional) Early card presentation. If the cardholder taps or inserts before you start, the reader sends to tell your host to start a transaction now.

2. Host starts the transaction. Send with the amount and type (transaction TLV, tag 86: 9C, 9F02, 5F2A), the interfaces to enable (Reader Options, tag A3), a timeout (tag 82), and the flow-control bitmask (tag 84).

Use this when the issuer must authorize online in real time.

• Your host processes the ARQC, sends it to the processor, receives the ARPC, and returns it to the reader with .

• The reader applies the issuer response, finishes with the card, and sends reporting the kernel outcome (Approved or Declined).

• The result shows on-device on a display reader; on the the reader sends so your host can display it.

The recommended flow for most retail — it minimizes how long the card stays in the reader.

• The reader builds its own internal ARPC (tag 8A = Z3) and completes immediately with ("Quick Chip Deferred"), so the cardholder can remove the card right away.

• Your host then processes the ARQC, sets the final amount, and coordinates with the processor out-of-band. The reader is not involved in the final approve/decline, so you display the result yourself (via on a display reader, or your own UI on the Go).

The transaction carries EMV data as TLV objects, each documented once in Data types & shared TLV objects. The ones you'll handle most:

When you take a transaction online, you forward the ARQC to your processor and return the ARPC via . Two things to know:

• Parts of the data are encrypted. Portions of the EMV ARQC and EMV Batch Data objects are SRED-encrypted. To use them, your host must first determine which key was used, then decrypt.

  • See .

• You can avoid handling clear PAN. Magensa's service lets you send the encrypted transaction straight to a processor without exposing cardholder data in your environment

Both run the flow above; enable each interface in Reader Options (tag A3) on .

• Contactless payments (tap-to-pay, mobile wallets) follow the same ARQC/ARPC flow.

• NFC tags (non-payment) are different: the reader reports the card type and UID via and produces no ARQC or Batch data — you continue with pass-through commands.

  • See .

The kernel's behavior is controlled by configuration files you load onto the device:

• , , and control the contact and contactless kernels.

• enable Offline Data Authentication.

• Load them using the file-operations commands and the file-type definitions in the data-object pages above.

Your device and payment application must be L3-certified with each processor. Dyna-family readers share a common EMV kernel, so certifying one family member can carry to the others, and Quick Chip is included in .

• For the full strategy and the discovery questions to scope your certification, see .