[ArlindNocaj]

Builds on top of #210. Three improvements to the Verification of Payee (VoP) flow:

1. VoP polling (FinTS spec E.8.3.1): When the bank returns HIVPP with a polling_id but no vop_id, re-send HKVPP with polling_id + aufsetzpunkt (extracted from HIRMS 3040) until the VoP check resolves and a vop_id is returned. This is required by banks like Consorsbank that perform asynchronous VoP verification.

2. Broader 3945 response code detection: Check all HIRMG/HIRMS segments for the 3945 code, not just tan_seg responses, since some banks attach it to different segments.

3. TAN fallback in approve_vop_response: After VoP approval, check command_seg and global HIRMG/HIRMS segments for 0030/3955 TAN-required codes. This mirrors the Fix 4 pattern from Fix Consorsbank compatibility (3 issues found via hbci4j comparison) #210 but in the VoP approval path, handling banks that attach the TAN challenge to the command segment rather than HKTAN.

All changes are backwards-compatible.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[mankind806]

This PR (and #210, #223) handles 0030/3955 attached to the command segment for payments, in _send_pay_with_possible_retry. The read path has the same gap and none of the open PRs touches it. Adding it here instead of opening a new issue, since it is the same problem.

Cause

_send_with_possible_retry (fints/client.py:1418-1440), used by every read (get_sepa_accounts, get_balance, statements and holdings via _fetch_with_touchdowns):

• lines 1425-1426: for resp in response.responses(tan_seg): / if resp.code in ('0030', '3955'): - only the answer to HKTAN is checked. responses(ref) (fints/message.py:35-39) keeps only HIRMS that refer to that segment, so a code on the read segment or on HIRMG is not seen.
• lines 1437-1438: when no HKTAN was sent (else branch), 0030/3955 are not checked at all.

Impact

resume_func runs on an unfinished read: get_balance returns None, get_holdings returns [], statements return an empty list. No exception and no NeedTANResponse, so the caller cannot tell an empty account from a read that waits for approval.

Affected versions

5.0.1 (tag v5.0.1, commit eda20b4) and master at the same commit, checked 2026-11-09.

Reproduction

Synthetic, no bank: the library's own parser output fed into _send_with_possible_retry with a stub dialog, read segment HKSAL.

3955 on the HKTAN answer            -> NeedTANResponse
3955 on the HKSAL answer            -> resume_func result None
0030 on the HKSAL answer            -> resume_func result None
3955 on HIRMG                       -> resume_func result None
3955, no HKTAN sent                 -> resume_func result None

Not checked

• Not seen with a real bank for a read; the third-party evidence is the reports in this PR and Fix Consorsbank compatibility (3 issues found via hbci4j comparison) #210 that some banks answer on the command segment.
• Only HKSAL was run end to end; HKKAZ/HKWPD use the same function but were not run.

Solution

One helper that looks for 0030/3955 in the answers to tan_seg and command_seg and in HIRMG/HIRMS, used at fints/client.py:1426, :1485 and :1521 so the three copies cannot diverge, returning NeedTANResponse only when a HITAN segment exists; in the else branch raise a clear exception instead of returning an empty read. This could go into this PR or a follow-up. I can send a tested PR for the read path if that helps; I did not want to open a fourth PR on the same topic without asking.

AI disclosure: an AI assistant (Claude, Anthropic) helped find and write this; the line references were checked against the source at eda20b4 and the reproduction was run on 5.0.1.