EMV chip reads, BIN lookups, and a card vault — integrating Credit Card : Wallet & NFC

Tap an EMV card to the back of an Android phone and the chip answers a fixed conversation: SELECT the payment directory, GET PROCESSING OPTIONS, then READ RECORD down the Application File Locator. Credit Card : Wallet & NFC is built on exactly that exchange. It reads the public records a contactless chip will hand over, runs the digits through a BIN and IBAN check, and files the card in an on-device vault locked by PIN or fingerprint — features taken from its Play Store listing. For an integrator, the interesting work is not the wallet UI. It is the protocol read and the classification layer underneath it.

The honest summary: this is a read-and-classify problem, not a server-portal problem. The chip is the source of the card identity; a maintained BIN dataset and an IBAN checker turn six-to-eight raw digits into an issuer, a scheme and a country. We deliver that as runnable source — the contactless read module and the lookup endpoints — so a scanned card arrives already typed and validated instead of as a bare PAN.

What the chip gives up, and what a lookup adds

Contactless EMV exposes only public records — no CVV2, no PIN, no full magnetic-stripe track. Within that boundary, here is what is reachable and where each field actually originates.

Two working routes

The data sits in two different places, so the build has two distinct pieces of engineering.

Route A — EMV contactless protocol implementation

Read the chip directly over ISO-DEP. Reachable: card identity, application data, and the transaction log where a card exposes it. The effort is moderate and the durability is high — the EMVCo contactless flow has been stable for years, so a read module written against it does not rot when an app updates its UI. We set this up against a reference set of cards spanning Visa, Mastercard and a regional scheme, driven by a test harness that replays captured APDU exchanges so the parser is exercised without a live card every run.

Route B — BIN and IBAN classification

Turn the digits into meaning. Low effort; the durability question is dataset freshness rather than protocol change, since BIN ranges shift as issuers migrate to eight-digit BINs. We wire the lookup to a maintained BIN source and the IBAN checker to current country structures, with a re-validation pass scheduled so a stale range does not quietly mis-classify a card.

Route C — vault export (optional)

Where the goal is moving users off the app, the local encrypted vault can be read under the user's consent and emitted as a portable record set. This only matters for a migration; most buyers never need it.

If you are choosing where the budget goes: the contactless read is the part worth paying for. It is fiddly to get right and dependable once it is, and the BIN/IBAN layer is cheap to add on top of it. The vault export earns its place only when you are pulling people across to another product.

A read, end to end

The shape of the contactless read and the classify call that follows it. Illustrative, and confirmed against reference cards during the build.

# Contactless EMV read over Android IsoDep, then a BIN classify call.

select_ppse = "00A404000E325041592E5359532E444446303100"   # SELECT 2PAY.SYS.DDF01
resp = nfc.transceive(hex_to_bytes(select_ppse))            # AID(s) returned in tag 4F

gpo = "80A80000028300"                                       # GET PROCESSING OPTIONS
afl = parse_tlv(nfc.transceive(hex_to_bytes(gpo)))["94"]     # Application File Locator

card = {}
for sfi, first, last in read_afl(afl):
    for rec in range(first, last + 1):
        apdu = bytes([0x00, 0xB2, rec, (sfi << 3) | 4, 0x00])  # READ RECORD
        tlv  = parse_tlv(nfc.transceive(apdu))
        card["pan"]    = tlv.get("5A",   card.get("pan"))    # PAN
        card["expiry"] = tlv.get("5F24", card.get("expiry")) # expiry, YYMM
        card["name"]   = tlv.get("5F20", card.get("name"))   # often blank contactless

meta = http_get("/v1/bin/" + card["pan"][:8])   # issuer, scheme, country, card level
# CVV2 and PIN are not present in these records; the PAN is masked before storage.
      

What lands in the repo

Each deliverable maps to a real surface above, not a generic checklist.

• A runnable EMV read module (Python or Kotlin / Android): SELECT PPSE, GPO, AFL parsing, READ RECORD, and a BER-TLV decoder for the tags the card returns.
• An OpenAPI / Swagger spec for the BIN and IBAN lookup layer, with request and response schemas and error codes.
• A protocol and TLV report: which tags appear, how the AFL is walked, and how the transaction-log SFI is probed when present.
• Automated tests built on a fixture set of captured APDU dumps, so the parser is verified offline.
• Interface documentation plus card-data handling guidance: PAN masking, what must never be stored, and a retention default.

What we engineer around

Two things on this app reliably need real handling, and both are ours to manage rather than yours to pre-solve.

The log file is not guaranteed. Many issuers expose a transaction-log SFI; many do not, and the format varies by card range. We probe for it per range during the build and design the read so a card that withholds the log still returns clean identity data — the absence is handled, not treated as a failure.

Contactless reads are physical. Antenna position, ISO-DEP timeouts and partial records are normal on real hardware. We build in transceive retries, ISO-DEP reconnection, and a graceful path for a half-completed read, so a fumbled tap retries instead of corrupting a record. Access to a small reference card set and a consenting test device is arranged with you during onboarding; the harness runs against those plus replayed captures.

Card-data handling, the way card data has to be handled

This is cardholder data, so the standards are not optional. Under PCI DSS, full track contents and sensitive authentication data (CVV, PIN) must never be stored — and conveniently, the contactless public records this app reads do not contain them in the first place. We mask the PAN at rest, keep only the fields a given use case needs, and document a retention default. The app's own listing states it does not store or transmit full card numbers; the integration mirrors that posture rather than widening it.

Cardholder data is also personal data under GDPR, so the same handling carries a data-minimization and consent obligation: the EMV read happens on a card the user physically taps, the vault export only runs on the user's own consented store, and access is logged. We operate authorized and documented, work under NDA where the engagement needs it, and keep consent and access records for the protocol work. There is no bank-account login or open-banking consent flow here — this is a device-side read of a card the holder presents — so the governing frame is PCI DSS and data-protection law, not an AIS regime.

Cost and cadence

A runnable EMV read module plus the BIN and IBAN lookup layer lands in one to two weeks. Source-code delivery starts at $300 — the read module, the lookup endpoints, tests and interface docs, yours to run, and you pay after delivery once it does what you need. If you would rather not host anything, call our endpoints instead and pay per call, with no upfront fee. The app name and what you want out of its card reads are all we need to start; access to a test device and any compliance paperwork are arranged with you as part of the work. To scope it, tell us what you are building and we will come back with the route and the shape of the deliverable.

From the app

Screenshots from the Play listing — the card vault, the reader and the validation views.

Neighbours in the card-reading space

Apps and tools that read, hold or validate cards in the same territory. Named for context; an integration desk often unifies reads across several.

• Credit Card Reader NFC (EMV) — reads EMV-compliant card data over NFC by tapping a card to an Android device, the same contactless surface.
• NFC TagInfo by NXP — inspects the contents of NFC tags and cards, exposing IC type and data sets rather than payment fields.
• NFC Tools — a general NFC read / write utility for tags, useful for the raw transceive layer beneath an EMV read.
• Samsung Wallet — holds cards and credentials in a secured wallet on Samsung devices, a vault parallel to this app's card store.
• Google Wallet — stores payment cards and passes for tap-to-pay, holding tokenized card references rather than raw chip records.
• SumUp — an EMV-certified reader app accepting chip, magstripe and contactless, on the acceptance side of the same protocol.
• Square Point of Sale — takes EMV chip and NFC payments through a reader, holding transaction records merchant-side.
• Clover Go — accepts magstripe, EMV chip and contactless and syncs to the wider Clover stack.

Questions integrators ask us

Which card fields come off the chip, and which come from a lookup?

The PAN, expiry and the application data (AID, label, issuer country) are read directly off the contactless chip via READ RECORD. The cardholder name appears only where the issuer personalized tag 5F20, which is often blank on contactless. Everything richer — issuing bank, scheme, card level, IBAN structure — comes from a BIN or IBAN lookup keyed on the digits the chip returned.

Can the transaction log be read, or only the card identity?

It depends on the card. Some issuers expose a transaction-log SFI you can walk with GET DATA and READ RECORD to pull the last several entries; many gate it entirely. We probe for the log file per card range during the build and design the read so a card that withholds it still returns clean identity data instead of failing.

There is no CVV or PIN in any of this, correct?

Correct. The contactless public records do not carry CVV2 or the PIN, and full track or sensitive authentication data must never be stored under PCI DSS. The read module captures only the public records, masks the PAN, and the app itself describes not storing or transmitting full card numbers — we mirror that posture.

Does the card vault live on the device or sync to a server?

As the listing describes it, the vault is an on-device encrypted store locked by PIN or fingerprint, with access across devices. If you need to migrate users off the app, we read that local store under the user's consent and emit a portable record set; if you only need fresh reads, the EMV module never touches the vault at all.

How this was checked

Card domains and the vault behaviour are read from the app's Play Store listing; the contactless flow and the readable records were cross-checked against EMV reference material and BIN / IBAN validation documentation on 27 June 2026. Primary sources opened: the EMV-NFC-Paycard library for the read flow, a write-up on reading EMV SFI records for the log-walk, the PCI SSC data-storage guidance for what must never be stored, and BIN Checker API documentation for the classification fields.

Mapped by the OpenBanking Studio integration desk, June 2026.