Payment operations currently have one or two deterministic happy-path vectors per op. The gaps below represent known areas where coverage is thin, vectors are unverified, or entire test categories are missing.
1. No independent vector verification for Vendor-aligned ops
Most payment operations are classified Vendor-aligned (see PAYMENT_RECIPES.md Validation Status). Their test vectors pass internal round-trip consistency but have not been validated against independent HSM output or a second reference implementation. Highest-risk ops:
AS2805 Generate KEK Validation — Test helper; no known-good external referenceEMV Generate ARPC — no independent cross-check documentedDUKPT Derive TDES Key — documented as Externally cross-checked but the external source and exact vectors are not recorded
2. No edge-case or error-path tests
Current vectors are all valid, well-formed inputs. Missing tests for:
- Wrong key length (e.g. 15-byte key where 16 is required)
- Mismatched format/PAN (Format 0 with missing PAN, Format 1 with PAN supplied)
- Non-hex input where hex is required
- Empty input
- KSN shorter than expected
3. PIN block formats 1 and 3 not deterministically covered
Format 0 has a solid deterministic vector. Formats 1 and 3 use randomized fill by default, so they can only be tested deterministically with randomizeFill=false. No test currently exercises these formats with randomizeFill=false.
4. No recipe chain integration tests
No test exercises a full Generate → Verify chain end-to-end (e.g. VISA PVV Generate output piped into VISA PVV Verify). The input/arg swap work done in this fork makes chaining the expected user pattern, but the test suite doesn't verify it.
5. HSM parse ops use only synthetic inputs
HSM Parse Thales Command and HSM Parse Futurex Command tests use hand-crafted hex/ASCII strings, not real captured HSM command/response samples. Real command samples would catch field-offset or framing bugs that synthetic inputs would miss.
6. TR-34 parse uses a minimal synthetic frame
The TR-34 Parse Key Transport test uses a 24-byte synthetic B9 frame. A real B9 envelope from an actual TR-34 key exchange would exercise the ASN.1 CMS parsing path more completely.
7. AES DUKPT derivation lacks a published test vector
DUKPT Derive AES Key (ANSI X9.24-3) was implemented against AWS semantics. ANSI X9.24-3 test vectors exist in the standard appendix; confirming at least one matches would upgrade this from Vendor-aligned to Verified.
Suggested priority order
- Formats 1 and 3 deterministic PIN block tests (low effort, clear gap)
- AES DUKPT known-vector cross-check (moderate effort, highest value for correctness confidence)
- Edge-case / error-path tests for input validation (moderate effort)
- Generate → Verify chain tests for PVV, IBM 3624, ARQC (low effort once chain is confirmed working)
- Real HSM command samples for Thales/Futurex parsers (requires sample capture, deferred)
Payment operations currently have one or two deterministic happy-path vectors per op. The gaps below represent known areas where coverage is thin, vectors are unverified, or entire test categories are missing.
1. No independent vector verification for Vendor-aligned ops
Most payment operations are classified Vendor-aligned (see
PAYMENT_RECIPES.mdValidation Status). Their test vectors pass internal round-trip consistency but have not been validated against independent HSM output or a second reference implementation. Highest-risk ops:AS2805 Generate KEK Validation— Test helper; no known-good external referenceEMV Generate ARPC— no independent cross-check documentedDUKPT Derive TDES Key— documented as Externally cross-checked but the external source and exact vectors are not recorded2. No edge-case or error-path tests
Current vectors are all valid, well-formed inputs. Missing tests for:
3. PIN block formats 1 and 3 not deterministically covered
Format 0 has a solid deterministic vector. Formats 1 and 3 use randomized fill by default, so they can only be tested deterministically with
randomizeFill=false. No test currently exercises these formats withrandomizeFill=false.4. No recipe chain integration tests
No test exercises a full Generate → Verify chain end-to-end (e.g.
VISA PVV Generateoutput piped intoVISA PVV Verify). The input/arg swap work done in this fork makes chaining the expected user pattern, but the test suite doesn't verify it.5. HSM parse ops use only synthetic inputs
HSM Parse Thales CommandandHSM Parse Futurex Commandtests use hand-crafted hex/ASCII strings, not real captured HSM command/response samples. Real command samples would catch field-offset or framing bugs that synthetic inputs would miss.6. TR-34 parse uses a minimal synthetic frame
The
TR-34 Parse Key Transporttest uses a 24-byte synthetic B9 frame. A real B9 envelope from an actual TR-34 key exchange would exercise the ASN.1 CMS parsing path more completely.7. AES DUKPT derivation lacks a published test vector
DUKPT Derive AES Key(ANSI X9.24-3) was implemented against AWS semantics. ANSI X9.24-3 test vectors exist in the standard appendix; confirming at least one matches would upgrade this from Vendor-aligned to Verified.Suggested priority order