Foundry · build sequence 01 Architecture → 02 Flow & Hierarchy → 03 Canonical Model
Paying.co · Foundry · EMV L3 Framework · Architecture Model

Foundry — one reusable core,
adapters cast to fit.

A reusable EMV L3 framework for ID TECH contactless readers and validators — built once to accelerate both our development and our certification on every future ID TECH engagement. The core carries across devices and acquirers; only thin adapters are cast per engagement.

This is the build-time architecture model, mapped to the 162 real IDT_NEO2 methods in the uploaded SDK package — not generic EMV. Tap any module to see the exact SDK calls it wraps.

SDK 1.00.190 pkg 80152803-001-B device class IDT_NEO2 162 methods contactless-first
Reusable core (~75%) Variable / agentic-generation target (~25%) Hardware & SDK boundary Cryptography & key management

v1 target scope · everything else is data or a future casting

canonical data · not branches
Currency & Language
USD 840 & MXN 484 (ISO 4217). Locale EN / ES carried as ISO 639 en/es — distinct from currency-840 so the two never conflate. Both are transaction attributes the adapter reads; no per-processor currency logic.
first casting · one-to-many
Santander, then N more
Santander is adapter #1. Global Payments, JPMC, EverTec follow as further castings from the same mold. Each adapter is its own module and may bundle its own processor library — host dialect, comms, HSM client — referenced only inside that adapter, never by the core.
two layers · do not conflate
Crypto Abstraction
Kernel-insulated crypto (CAPK auth, DUKPT, P2PE) stays behind the SDK — we provision, never implement. Above it, a distilled common crypto interface the core speaks; processor-specific key/HSM specifics live in the adapter.
crypto Where cryptography lives — and where it must not
▼ kernel / SDK insulated
CAPK offline-auth, DUKPT key derivation, P2PE encryption, secure key storage. ID TECH owns this in firmware. We never touch the primitives — we load CAPK/CRL and read KSN.
◆ distilled common interface
The core's single crypto vocabulary: provision key, get KSN, request authenticated completion, surface check-values. Processor-neutral. This is the abstraction ID TECH distills to a common point — and the seam the core speaks to.
▲ adapter-owned specifics
Per-processor key ceremony, HSM/zone-key handling, ARQC/ARPC message crypto framing, working-key rotation. Santander's scheme here; EverTec's there. Bundled in the adapter, behind the common interface.

▲ third-party integrators · MDM · clients

stable public contract
core Integration API Layer the only thing outsiders touch
Semi-Integrated Interface stable
start / cancel / status / result. The contract third parties build against — never changes when devices or acquirers do.
startTransaction()getResult()
MDM Integration core+hooks
Surfaces reader firmware / RKI / RRC / config to the Headwind-managed host, so device and reader management live in one pane.
device_updateFirmwaredevice_startRKIdevice_rrc*
calls canonical operations only
core Transaction Engine speaks canonical — never raw TLV
Contactless State Machine ~20%
Orchestrates start → async callback events → online auth → completion. Owns cancel / reset / timeout. The beating heart.
ctls_startTransactionctls_displayOnlineAuthResultdevice_resetTransaction
Canonical Model ~15%
Normalizes IDTEMVData TLV into one internal representation. The engine speaks only this — the seam that makes reuse real.
IDTEMVDatacreateFastEMVData
Observability ~8%
PCI-secure logging, event stream, audit trail. Feeds Velo downstream. No PAN/track data ever persisted.
log_setSaveLogEnablelog_setVerboseLoggingEnable
canonical ⇄ TLV translation boundary
◆ The Seam Above this line: pure canonical, device- and acquirer-agnostic. Below & beside it: everything that varies. Keeping this line clean is the entire reuse thesis — and the two go/no-go checkpoints test exactly this.
configure on-device kernel · drive lifecycle
core Configuration & Key Management pushes parameters into the on-reader kernel
Parameter Loader ~12%
AID application data, terminal data, config groups, transaction parameters — pushed to the kernel, then read back & check-value verified.
ctls_setApplicationDatactls_setTerminalDatactls_setConfigurationGroupemv_setTransactionParameters
Cryptography & Keys ~10%
CAPK lifecycle, CRL, remote key injection, CA certs, KSN retrieval. Online-auth crypto handshake into kernel completion.
ctls_setCAPKemv_setCRLdevice_startRKIdevice_loadCertCAdevice_getKSNemv_authenticateTransaction
thin HAL — wrap & normalize, do not drive
boundary Hardware Abstraction (thin HAL) the SDK is most of the HAL
IDT_NEO2 Wrapper ~10%
Connect / lifecycle / transport behind one stable internal interface. Wraps the async OnReceiverListener callback model.
device_connectdevice_setPollModedevice_setNEOGenOnReceiverListener
Device Specifics variable
VP3350 first, Kiosk V second. Per-device quirks kept here, never in the core. Checkpoint B proves this stays contained.
device_setDeviceTypedevice_getProductType
USB / BLE / RS232 / audio

▼ ID TECH reader — L1 hardware + L2 kernel in firmware (we never touch it)

variable · agentic Acquirer / Processor Adapter the one thing the SDK can't give us
Online-Auth Adapter ~25%
Take canonical → format host message (ISO 8583 / 20022) → send → parse response → feed kernel completion. Built per-processor against the canonical contract. This is what the agent generates.
emv_completeTransactionctls_displayOnlineAuthResult
Business Rules / Config variable
Contactless CVM policy, floor limits, receipt & flow config. Per-deployment, never compiled into the engine.
emv_setTerminalMajorConfiguration

Contactless lifecycle · the async spine

01 · setup
Load parameters
ctls_setApplicationData
ctls_setCAPK · setTerminalData
AIDs, keys, terminal config pushed to kernel; verified by check-value.
02 · connect
Bind reader
device_connect
device_setPollMode
Transport up, NEO gen set, listener registered.
03 · start
Begin transaction
ctls_startTransaction
Amount + type handed to kernel; tap awaited.
04 · callback
Kernel emits data
emvData / ctlsEvent
TLV lands in IDTEMVData → normalized to canonical at the seam.
05 · auth
Online authorization
↳ acquirer adapter
Canonical → ISO message → processor → response. The variable seam.
06 · complete
Finish & display
emv_completeTransaction
ctls_displayOnlineAuthResult
Result fed back to kernel; outcome shown; audit written.

How AI generates the variable layer

01Hand-build the core once

The canonical model, state machine, HAL, config & crypto loaders are written and lead-engineer validated by hand. They define a canonical contract — the stable target everything generates against.

02Cast adapters from the contract

Give the agent the canonical contract + a processor's ISO 8583/20022 spec. It casts the adapter: canonical → host message → canonical. Bounded problem, well-supported language (Java/Kotlin), testable in isolation. The contract is the mold; each adapter is a casting.

03Validate at the two checkpoints

Checkpoint A: second acquirer adapter — does the engine stay closed? Checkpoint B: Kiosk V as second driver — contained, or core surgery? These prove reuse is real, not illusory.

Blocks the build can't start without

OPEN #1First-target acquirer / processor. Defines the first adapter — the canonical-seam proof at step 04 of the sequence. Everything upstream can proceed; this gates the adapter.
OPEN #4Where the online-auth boundary sits. Confirm host integration is via our adapter vs. any gateway in the path — changes what canonical must carry.
OPEN #3Contactless CVM scope for unattended. No-CVM / CVM-limit behavior differs Kiosk V vs. VP3350 — lands in business rules, not the engine.
OPEN #5Cert target. Which brands, which processor first, for the initial contactless LOA.