When submitting a SEPA XML payload (e.g., generated via nemiah/phpSepaXml) using SendSEPATransfer::create() or SendSEPADirectDebit::create(), the resulting FinTS string leaves the segment sum field empty (e.g., ++N+urn?:iso...).
While this was historically tolerated by many banks, the Atruvia data center now strictly enforces this field, especially during the new Verification of Payee (VoP) confirmation steps. If the field is empty, Atruvia rejects the request with:
HIRMS:5:2:3+9010::Summenfeld nicht vorhanden.
To Reproduce
Generate a valid SEPA XML (pain.001.001.03 or pain.008.001.02) including .
Pass the XML to SendSEPATransfer::create($account, $xml).
Check the generated FinTS string in the logs.
The HKCCM segment looks like this: HKCCM:3:1+DE88...::280:35060386++N+urn?:iso... (Notice the empty ++ before N).
Expected behavior
The internal parser should successfully extract the from the XML payload and inject it into the segment header, resulting in: ...+17955.54+N+urn....
Technical Analysis
The issue seems to stem from the library's internal XML parsing/regex failing to extract the due to specific formatting, line breaks, or namespaces introduced by standard SEPA XML generators. Because the extraction fails, the segment property for the amount remains null or empty.
Proposed Solution(s)
Improve XML Parsing: Robustly parse the XML to find ignoring specific namespace prefixes or whitespace formatting.
Add Explicit Parameter (Preferred): Allow developers to bypass the internal parser by providing the control sum explicitly in the factory methods. For example:
PHP
public static function create(SEPAAccount $account, string $painMessage, ?float $controlSum = null)
If $controlSum is provided, the library should use it directly for the segment header instead of attempting to parse the XML.
Environment:
PHP Version: 8.5
phpfints Version: dev-master
Bank: Atruvia (e.g., Volksbanken Raiffeisenbanken)
VoP active: Yes
When submitting a SEPA XML payload (e.g., generated via nemiah/phpSepaXml) using SendSEPATransfer::create() or SendSEPADirectDebit::create(), the resulting FinTS string leaves the segment sum field empty (e.g., ++N+urn?:iso...).
While this was historically tolerated by many banks, the Atruvia data center now strictly enforces this field, especially during the new Verification of Payee (VoP) confirmation steps. If the field is empty, Atruvia rejects the request with:
HIRMS:5:2:3+9010::Summenfeld nicht vorhanden.
To Reproduce
Generate a valid SEPA XML (pain.001.001.03 or pain.008.001.02) including .
Pass the XML to SendSEPATransfer::create($account, $xml).
Check the generated FinTS string in the logs.
The HKCCM segment looks like this: HKCCM:3:1+DE88...::280:35060386++N+urn?:iso... (Notice the empty ++ before N).
Expected behavior
The internal parser should successfully extract the from the XML payload and inject it into the segment header, resulting in: ...+17955.54+N+urn....
Technical Analysis
The issue seems to stem from the library's internal XML parsing/regex failing to extract the due to specific formatting, line breaks, or namespaces introduced by standard SEPA XML generators. Because the extraction fails, the segment property for the amount remains null or empty.
Proposed Solution(s)
Improve XML Parsing: Robustly parse the XML to find ignoring specific namespace prefixes or whitespace formatting.
Add Explicit Parameter (Preferred): Allow developers to bypass the internal parser by providing the control sum explicitly in the factory methods. For example:
PHP
public static function create(SEPAAccount $account, string $painMessage, ?float $controlSum = null)
If $controlSum is provided, the library should use it directly for the segment header instead of attempting to parse the XML.
Environment:
PHP Version: 8.5
phpfints Version: dev-master
Bank: Atruvia (e.g., Volksbanken Raiffeisenbanken)
VoP active: Yes