RFID reader or NFC reader — and why EVSE teams ask for both
Most EV charger and EVSE programmes reach Ambimat with the same sentence: “we are building a charger and we need an RFID reader.”
It sounds like a component choice. It is actually an architecture decision, and it is usually settled by a question that nobody asks until the first technical call.
Why this page says RFID and NFC. Charge-point and EVSE teams almost always write this requirement down as an RFID reader, and that is the sourcing language this page uses too. It names the job rather than the credential: read what the driver presents, and hand the result to the charger. The part that does that job is usually described as an NFC or contactless reader. The two terms are not interchangeable — RFID is the wider family, and NFC is one contactless technology within it — but on an EV charger they very often point at the same component.
The question that decides it
How much of the NFC reader software stack does your charger’s host processor own?
Every contactless reader is the same three things in some combination: an RF front end, the software that drives it, and the key material that protects the credential. What changes between products is not capability but where those pieces sit — on your board and in your firmware, or inside a finished reader.
There are two sensible answers. Neither is more advanced than the other, and the difference is not price.
Route A — an NFC front-end module, with the stack on your host
You take the RF front end as a module and run the reader software on the charger’s own MCU or application processor.
driver’s credential → NFC front-end module → your host MCU running the reader software → your charge-point controller → your back office
AmbiTap is built for this route: a 42 mm × 42 mm board on the NXP CLRC66303HNY NFC front end, with SPI, UART and I²C-style multifunction host signals exposed alongside IRQ and PDOWN, a 2.5 V–5.5 V supply domain, and 5 V and 3.3 V board connections. It is designed and manufactured in India.
The host side is where the work lives. NXP publishes an NFC Reader Library for its NFC front ends — a multi-layer library written in C, covering the CLRC663 plus family among others, over I²C, SPI or UART, on RTOS and non-RTOS architectures. Your team obtains it from NXP, under NXP’s own licence and account terms. Ambimat does not own, licence or redistribute NXP software, and NXP does not endorse AmbiTap; the library is named here because it is the reference implementation for this class of front end.
What you gain: control of the reader layer, and a front end localised and supported in India.
What you take on: integrating that reader software into your firmware, and maintaining it for the life of the product.
Route B — a complete reader, with the stack inside it
You take a finished reader that already contains the front end, the antenna, the reader firmware and the key material, and you integrate its host interface instead.
driver’s credential → AmbiPay reader → defined host interface → your charge-point controller → your back office
The AmbiPay Secure NFC Reader supports ISO/IEC 14443 Type A and B, ISO/IEC 15693, ISO/IEC 18000-3 and ISO/IEC 18092, the entire MIFARE family including DESFire EV1 and EV2, the Sony FeliCa family and NFC Forum tag types 1–5. It provides up to five hardware SAM sockets, and connects over USB, serial RS-232, SPI or Android OTG.
This is not “no integration”. Your host still has to implement the reader’s communications and protocol. What moves off your plate is the NFC layer itself — polling, activation, anticollision, credential handling and, where a SAM is fitted, the key operations. The complexity does not disappear; it changes address.
Secure NFC or Dual Interface
Two AmbiPay readers suit different mechanical and credential requirements.
The Secure NFC Reader is the contactless reader with the longer reach — approximately 7–10 cm as an Ambimat positioning figure, not a measured specification — and up to five SAM sockets for key material. Its board and antenna together measure 82.0 × 100.0 × 15.0 mm.
The Dual-Interface Reader adds a contact ISO/IEC 7816 interface (Class A, Class B and synchronous cards) alongside the same contactless families, in roughly 5 × 3 cm, with an attached JCOP4 secure element performing SCP02 authentication. Choose it when a card must be inserted as well as tapped, or when panel volume is the binding constraint. Its host protocol is agreed per programme, and no certification of any kind is claimed for it — nothing is inherited from the other readers.
The comparison
| Question | AmbiTap | AmbiPay Secure NFC | AmbiPay Dual Interface |
|---|---|---|---|
| Your host integrates the NFC reader library | Yes | No — handled in reader firmware | No — handled in reader firmware |
| Host interface | SPI / UART / I²C-style signals exposed | USB, RS-232, SPI, Android OTG | Agreed per programme |
| Contact (ISO/IEC 7816) card | Not offered | Not positioned on this product | Yes |
| Contactless credential families | Discussed per application | MIFARE incl. DESFire EV1/EV2, FeliCa, NFC Forum 1–5 | Same families, plus NFC IP1 / IP2 |
| Key material held in hardware | Your design decision | Up to 5 SAM sockets | JCOP4 secure element, SCP02 |
| Footprint | 42 × 42 mm board | 82 × 100 × 15 mm with antenna | Approx. 5 × 3 cm |
| Best when | your team wants the reader layer | you want reach and SAM-backed keys | you need contact and contactless in a tight panel |
What is deliberately not in that table. Price, lead time, volume tiers, operating temperature, ingress rating and MTBF. Ambimat publishes no approved comparison of those figures across these three products, and a comparison table is the easiest place in the world to imply one by accident.
What the reader does not do
This page is about one subsystem inside the charger. The reader presents and authenticates a credential and hands the result to your controller. It does not provide, and Ambimat does not claim:
- OCPP, ISO 15118, Plug & Charge or EIM;
- IEC 61851 or IEC 62196 conformance;
- charge-point controller functionality, metering, billing or session management;
- EMVCo, PCI or payment-scheme certification;
- any outdoor, weatherproof, ingress or operating-temperature rating.
That last point is a real constraint, not boilerplate. No environmental rating is published for these readers, so they are supplied for mounting inside your own enclosure. If your design exposes the reader face to weather, say so early and we will review the mechanical arrangement before anything is specified.
Questions worth answering before you choose
- Does your host team want to own an NFC reader software stack for the life of the product?
- Which credentials must be accepted — and are they already deployed in the field?
- Does the system authenticate the credential, or only read its identifier? (See why reading a UID is not authentication.)
- If one charger is stolen and opened, what does the attacker learn?
- Must a card be inserted as well as tapped?
- What is the mechanical envelope behind the fascia, and is the reader face weather-exposed?
Frequently asked questions
Do I have to integrate NFC software if I use AmbiTap?
Yes. AmbiTap is an NFC front-end module, so the reader software runs on your host MCU or processor. NXP’s NFC Reader Library is the usual reference implementation for this front-end family, obtained from NXP under NXP’s terms.
When should I use AmbiPay instead of AmbiTap?
When you do not want your host application team integrating and maintaining an NFC front-end stack, or when you need hardware-held key material or a contact card interface.
Which option reduces host-side NFC integration?
An AmbiPay reader. Your host implements the reader’s communications protocol rather than the NFC layer beneath it.
Can AmbiTap be used in an EV charger?
Yes — EV charging is one of its primary applications, alongside kiosks, vending, access control, parking, lockers and other embedded OEM equipment. It is supplied for integration inside your enclosure.
What is the difference between an NFC front end and a complete reader?
A front end is the RF layer and needs host software to drive it. A complete reader contains that software, and often the key material, and presents results over a defined host interface.
Does Ambimat help with the integration?
Yes. Ambimat has designed and manufactured embedded electronics since 1982, and engineering support covers hardware integration, host interface, RF and antenna, firmware integration and volume planning, scoped per programme after technical review.
Talk to us about your charger
Tell us your host MCU or processor, the credentials you must accept, and the space behind the fascia — and we will tell you which of the three readers fits, including when the answer is the one that needs more work from your team.