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.
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>.
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.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.foundry-demo and the integration-test stand-in for Santander.POST /ucp/transactions; void and capture hang off the prior transaction reference threaded down by the engine. Request build and response parse are complete; the transport rides a caller-supplied fdy_io_engine_t, with foundry_io_curl as the reference desktop engine and a Kotlin HTTP executor on Android.epx_response_codes.h) mapped to outcomes. The transport is wired through the same fdy_io_engine_t seam as Global Payments, and --processor epx compiles and runs — but that seam is HTTP-shaped plumbing, not EPX's real link.portico_response_codes.h) mapped to outcomes, over the same fdy_io_engine_t seam as Global Payments. Unlike EPX, Portico's real wire protocol genuinely is one HTTPS POST/response per transaction, so this is a faithful transport, not plumbing over an unrepresentable handshake.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.
The shipped adapters don't reimplement common concerns. They lean on engine-level modules so each casting stays thin.
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.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.The package was structured so a new processor is additive, never a restructuring. Three touches, no engine change.
Add src/<name>/ with the adapter's vtable implementation and its two build/parse seams. The processor dialect lives entirely here.
Add one line to the PROCESSORS list. The build picks up the new casting automatically.
Add one #include to processors.h. The registry can now resolve the new adapter at runtime.
Stated plainly so the next phase is unambiguous. The roster is a mix now: two castings carry full request/response implementations, three remain at documented seams.
FDY_ERR_NOT_IMPLEMENTED, pending Santander's host spec and test endpoint. Use the mock casting for integration testing meanwhile.foundry_io_curl on desktop, a Kotlin executor on Android. The one open item is the card-present / chip EMV request fields, which await Global Payments' card-present spec.