NAB ISO 8583 0100 Santander 0200 MXN DE55 ICC ARQC TSYS dialect FDY_ERR_NOT_IMPLEMENTED
Paying.co · Foundry · Processor Castings · a living roster

Castings. The processors
built against the mold.

Doc 04 defined the contract — fdy_processor_adapter_vtbl_t, canonical in, canonical out. This doc inventories the processors cast against it, the shared building blocks they lean on, and exactly what it takes to add the next one. The roster is living: new processors join continually, so adapters are tracked by status — shipped in the native C engine, or planned as an aspirational target not yet in the source tree.

roster living shipped NAB · TSYS · Santander C99 · vtable additive · no engine change
Shipped · live in the C engine

Each adapter is a single authorize() over the canonical transaction, sealed in its own src/<name>/ directory with no shared dependency graph. All are registered in the foundry-processors CMake bundle and reachable through foundry-demo --processor <id>.

NABISO 8583
stub · approves
North American Bancard
Translates canonical → NAB ISO 8583 MTI 0100 → AuthResponse. The casting runs end-to-end and returns a stub APPROVED (response code 00) so the seam is provable; the ISO build/parse and live host send land at the documented TODO. Carries the DE 55 tag list in NAB ICC Data Requirements order.
formatISO 8583 · MTI 0100
currencyUSD (840)
transportNAB host (not yet wired)
coversreversal · advice · partial-auth · pre-auth · completion · refund
TSYSISO 8583
stub · approves
TSYS / Global Payments
Canonical → TSYS dialect → AuthResponse on the shared vtable. Like NAB, it returns a working stub APPROVED to prove the casting runs, with the processor specifics confined to the build/parse seams so the routing layer never sees them.
formatISO 8583
transportTSYS host (not yet wired)
coverspurchase · refund · void · auth-only · completion
SantanderISO 8583 · MX
not yet implemented
Santander · Mexico acquiring
Canonical → Santander ISO 8583 0200 → AuthResponse. authorize() derives the DE 55 view (proving the seam works) then returns FDY_ERR_NOT_IMPLEMENTED pending Santander's host spec and test endpoint — the engine maps this to the error-96 path. Install the mock adapter for integration testing in the meantime. DE 55 tags in Santander cert-guide order.
formatISO 8583 · 0200
currencyUSD (840) · MXN (484)
transportawaiting host spec + test endpoint
coversreversal · advice · pre-auth · completion
mocktest
shipped
development & integration testing
The reference casting used to exercise the engine and stand in for any adapter whose host isn't wired. It's the default target of foundry-demo and the integration-test stand-in for Santander.
formatin-process
coversfull canonical verb set
Planned · aspirational targets, not yet in the source tree

These castings are designed against the same contract but are not present in the current C engine. They represent the direction of the roster — each lands as a sealed src/<name>/ directory when its engagement is funded, following the three-touch add path below.

GP-APIREST · JSON
planned
Global Payments · Unified Commerce Platform
Global Payments' modern RESTful platform. Token-based access auth, JSON request/response — no ISO assembly, just structured JSON mapped from canonical. The cleanest target on the wire.
authBearer access token from app credentials
transportHTTPS REST
TransITgateway
planned
TSYS · TransIT Gateway
TSYS's gateway with a manifest/device-token flow. Classic gateway dialect — the processor specifics confined to the build/parse seams so the routing layer never sees them.
authManifest + device token
transportGateway API
EPGgateway
planned
Elavon · Payment Gateway
Elavon's Payment Gateway, chosen over the legacy viaConex platform for the newer integration surface. Standard credit set on the shared vtable, same canonical contract as the rest.
authGateway credentials
transportEPG API
CybersourceISO · VPC
planned
Cybersource · Visa Platform Connect
Cybersource / Visa Platform Connect, targeted for the Bank of America certification path. ISO-format messaging behind the same canonical interface — the dialect never leaks into the engine.
authVPC credentials / key ceremony
transportVPC endpoint
Shared building blocks · what the castings stand on

The shipped adapters don't reimplement common concerns. They lean on engine-level modules so each casting stays thin.

money.hcurrency
exponent-aware minor-unit formatting
Replaced per-adapter local formatters and fixed a real bug where the engine hardcoded currency_exponent = 2 regardless of currency. fdy_money_format_minor() now covers 0-decimal (JPY), 2-decimal (USD/EUR/MXN), and 3-decimal (BHD/KWD) correctly.
API facadeengine
authorize · void · refund · completion
The C facade now exposes fdy_api_void() and fdy_api_refund(), and fdy_api_completion() was rewired to actually invoke the adapter through the engine rather than mirroring. All transaction verbs route to the active casting through one path.
Adding the next casting · the mechanical path

The package was structured so a new processor is additive, never a restructuring. Three touches, no engine change.

1

Create the directory

Add src/<name>/ with the adapter's vtable implementation and its two build/parse seams. The processor dialect lives entirely here.

2

Register in the build

Add one line to the PROCESSORS list. The build picks up the new casting automatically.

3

Expose the header

Add one #include to processors.h. The registry can now resolve the new adapter at runtime.

Verified. The engine test suite runs green under CMake, clean under AddressSanitizer, UndefinedBehaviorSanitizer, and LeakSanitizer. Coverage spans TLV/normalizer/registry semantics, the engine's online/offline/timeout/cancel/error branches with adapter call-count assertions, the view engine, and the end-to-end + API idempotency paths including void, refund (full/partial/over-refund), currency mismatch, and over-capture.
Open items · what is not in this drop yet

Stated plainly so the next phase is unambiguous. The C drop lands first; Android wiring follows after sign-off.

Carried forward:
  • Each adapter has two TODO seams — the ISO 8583 / schema build and parse functions — where live host wiring goes. These are pure functions isolated from routing and I/O, safe to upgrade later without restructuring.
  • No live HTTP transports yet.
  • No credential / config store or adapter factory.
  • No Android wiring yet — C-only first, then the Kotlin wrapper after the C drop is validated.