# NFC chip verification

Source: https://help.didit.me/documents-coverage/nfc-chip-verification
Updated: 2026-08-19

NFC reads the signed chip in an ePassport or chipped ID with a phone, the strongest document check, judged by Spanish regulators as safe as an in-person check.

NFC reads the cryptographically signed chip in a passport or chipped ID and
verifies its signature chains back to the issuing country. It needs a phone with
NFC hardware, so it is delivered through a **native SDK** rather than a plain
browser page - and it always falls back to a normal photo check when the chip
can't be read. $0.15 per completed read, paid from your plan credit or balance.

[Video: NFC passport verification: reading ePassport and ID chips - Didit Academy](https://www.youtube.com/watch?v=43kCRJPXe6s)

## What NFC actually proves

An ordinary document check reads the printed surface. NFC reads the **chip**, and the chip is signed by the government that issued the document. That means NFC can prove two things a photo cannot:

- The data really came from the issuing authority, because the signature chains back to that country's certificate authority.
- The document has not been altered, because tampering breaks the signature - including tampering that is invisible to the eye.

It's the highest-assurance document check Didit offers. It also returns data the printed surface doesn't carry, including the chip's own portrait image.

> **Note:** After a year-long supervised test, Spain's Tesoro Público, Banco de España,
> SEPBLAC and CNMV concluded that Didit's NFC + liveness verification is **at least
> as safe as an in-person ID check** under anti-money-laundering rules. See
> [certifications and compliance](https://help.didit.me/data-privacy/certifications-and-compliance).

## Where NFC works, and where it doesn't

NFC needs the phone's NFC radio, which means it needs an app context that can use it:

| Delivery | NFC available? |
|---|---|
| Native mobile SDK (iOS, Android, React Native, Flutter) | Yes |
| A browser page on a phone | No - the chip cannot be read from a plain web page |
| Desktop | No |

If you want NFC in your flow, you need the verification running inside an app that embeds one of the [native SDKs](https://help.didit.me/integration/mobile-sdks). There is no consumer Didit app that a hosted web session hands users off to for the chip step.

## The fallback is automatic

When NFC isn't available - no chip in the document, no NFC hardware, the radio switched off, or the user can't hold the phone steady enough - the flow falls back to the standard photo-based document check plus face match. The session still completes; the NFC result array simply comes back empty.

That fallback is what makes NFC safe to enable broadly. It is also what you have to override if your policy is "chip or nothing": to require a chip read, configure the NFC step to decline when the chip is not verified, and remove the photo-capture path from the workflow. Otherwise a user who skips NFC still passes on the photo route.

## Reading the result

Each NFC attempt has its own status and its own warnings. The ones that matter:

| Warning | What it means | What to do |
|---|---|---|
| `NFC_NOT_READ` | The chip was never read - usually the phone moved | Let them retry; this is not a fraud signal |
| `NFC_BAC_FAILED` | The chip wouldn't open with the key derived from the printed data | Usually a bad OCR read of the MRZ; retry |
| `NFC_DATA_DOES_NOT_MATCH_OCR` | The chip and the printed data disagree | Treat as a tampered document. Do not approve |
| `NFC_PASSIVE_AUTHENTICATION_FAILED` | The chip's signature didn't chain to a trusted issuer | Stop the flow |
| `NFC_CHIP_CLONED` | Chip cloning signals detected | Stop the flow |
| `NFC_DOCUMENT_REVOKED` | The document has been revoked by its issuer | Stop the flow |

The distinction to internalise: `NFC_NOT_READ` and `NFC_BAC_FAILED` are *usability* failures and deserve a retry. The others are *integrity* failures and deserve a decline.

> **Tip:** Developers: the result field is the plural array `nfc_verifications[]`. Some early
> integrations looked for a singular `nfc_verification` key, which does not exist.

## Helping users actually read the chip

The chip is not in the middle of the document, and the antenna is not in the middle of the phone. The two most useful instructions to give a user:

1. Put the document flat on a table and rest the phone on it, rather than holding both.
2. Move the phone slowly around the document until it connects - on most phones the antenna is near the top edge on the back.

Cases and thick wallets between the phone and the document also block the read.

## What it costs

NFC is **$0.15 per completed verification** and is paid from your plan credit or balance. It's billed separately from ID verification, so a session that reads the chip and also runs a standard document check bills both. See [what counts as a billable check](https://help.didit.me/billing-credits/what-counts-as-billable).

## Which documents have a chip

Most passports issued in the last decade, and a growing number of national ID cards and residence permits. Coverage is narrower than OCR coverage precisely because it depends on the physical document. The current list is in the docs: [NFC supported documents](https://docs.didit.me/core-technology/nfc-verification/supported-documents-nfc-verification).