We develop, really

Sometimes, people think we only use a SDK provided by the reader manufacturer and they can do all the work themselves. Of course they can it's not magic, but it will take longer (and cost more) that they think. I don't blame them, it's never fully wrote in some sentences, only the transmission protocol explains clearly the actors, or you have to read several hundred of pages. I want to clarify the architecture in a single short post.

First, you have the reader (the PCD). It support some ISO specification (ISO 15693, ISO 14443) at the transmission protocol, or a specific one. It also provide a way for developers to access this reader, through PC/SC, or specific API for example.

What you get when you buy a reader, is only the way to access this reader. Sometime you don't even have a document for PC/SC compliant reader, just go to the Microsoft website. But at this stage you can't do so much yet. Sometimes you have to implement yourself the transmission protocol.

You have to communicate with the card now (the PICC). The chip on the card also support some ISO specification for the communication level. The same one that the PCD and they can communicate between them. You need the chip command set to be able to do something on the card. Sometimes you can only do that through the specific reader API. Sometimes the chip allow different ways for the same behavior: specific command set for the chip, and ISO 7816-4 or ISO 15693-3 (with optional commands) compliant commands.

For example, internally we draw the full architecture for DESFire chip and associated reader like this schematic. Each block represents an implementation. This give us modularity and flexibility.

We spent months on reader and chip integration. We spent weeks on user interface creation.