Paying.co · Foundry · Design Guide
Foundry.
A reusable EMV L3 framework.
One core, built once, that accelerates both development and certification for every ID TECH contactless reader and validator we take on. The reusable engine carries across devices and acquirers — only thin adapters are cast per engagement.
The thesis
One reusable core
~75% of the system — engage, capture, parse TLV, normalize, provision, complete — is identical on every engagement. Built and validated by hand, once. It speaks only canonical, never raw TLV or a processor's dialect.
Adapters cast to fit
The ~25% that varies — the acquirer/processor link — is cast against the canonical mold. Santander first, then Global Payments, JPMC, EverTec. Each is a sealed module with its own libraries, leaving the core untouched.
The seven sections
01
Architecture
The system shape — core, seam, adapter. The reusable/variable split mapped to the 162 real IDT_NEO2 methods.
→
02
Flow & Hierarchy
Provisioning hierarchy and the universal transaction lifecycle, with the processor boundary drawn hard.
→
03
Canonical Model
The mold — field by field. What the lifecycle produces and every adapter consumes.
→
04
Adapter Spec
How a processor casting is built — the ProcessorAdapter interface, with Santander as the worked example.
→
05
Provisioning & Config Feed
The manifest, the reconcile loop, and check-value verification that keep the kernel correct.
→
06
Crypto & Key Management
The line between what the kernel computes and what Foundry provisions. DUKPT, CAPK, ARQC/ARPC.
→
07
API Surface
The REST layer integrators drive — auth, transactions, config, status. v1: sale, pre-auth, completion.
→
How to read this: the sections run in build order — architecture down to the public API — but each stands alone. Use the left nav to jump anywhere. This is a design draft (v0.1) built against the real ID TECH NEO SDK, intended for review before the canonical model is implemented.