[TECH-DEBT] Integration — Infakt payment_method hardcoded and inconsistent between issueInvoice/issueCorrection

[norbert-kulus-blockydevs]

Problem / Context

InfaktInvoicingAdapter (libs/integrations/infakt/src/infrastructure/adapters/infakt-invoicing.adapter.ts) hardcodes payment_method independently at each call site, and the two values disagree with each other:

• issueInvoice sends payment_method: 'transfer' unconditionally (line 184).
• issueCorrection sends payment_method: 'cash' unconditionally (line 341).

Neither value is derived from any order-level signal. 'transfer' was verified live to 422 unless the seller has a bank account configured on the Infakt side (bank_account / bank_name), and OL has no way to know or configure that per-connection today — which is presumably why issueCorrection was left on the safer 'cash' default while issueInvoice was switched to 'transfer' in a later fix, without reconciling the two.

There is no neutral paymentMethod field on IssueInvoiceCommand or IssueCorrectionCommand in libs/core/src/invoicing at all (confirmed via grep) — core carries no payment-method signal from the order to any invoicing adapter today. This isn't a bug in the Infakt adapter's mapping logic; it's a missing piece of the core contract.

"Cash" vs "transfer" (gotówka vs przelew) carries real fiscal meaning in Poland — affects how the invoice is read/reported — so silently mislabeling orders, and doing so inconsistently between the two call sites, is a real, if currently low-impact, correctness gap.

Proposed Solution

One of two directions (not scoped yet — this issue captures the gap, the implementer picks the direction):

1. Add a neutral paymentMethod field to IssueInvoiceCommand (and IssueCorrectionCommand) in libs/core/src/invoicing, populated from whatever order-level payment signal core has available. Each InvoicingPort adapter (InfaktInvoicingAdapter, KsefInvoicingAdapter, SubiektInvoicingAdapter) maps the neutral value to its own vocabulary instead of hardcoding.
2. Make the payment method configurable per-connection (operator picks a default payment method when setting up the Infakt connection), independent of any core contract change.

Whichever direction is chosen, issueInvoice and issueCorrection in infakt-invoicing.adapter.ts must agree with each other, and the bank_account / bank_name prerequisite for 'transfer' must be documented or checked before that value is used.

Classification

Type: CORE / Integration
Layer: Domain (contract) / Infrastructure (adapter)
File(s):

• libs/core/src/invoicing/ (IssueInvoiceCommand / IssueCorrectionCommand types)
• libs/integrations/infakt/src/infrastructure/adapters/infakt-invoicing.adapter.ts

Dependencies

• None to start. If option 1 is chosen, every InvoicingPort adapter (KSeF, Subiekt) receives the new field and needs a mapping decision, even if only Infakt currently needs it to vary.

Assumptions

• The choice between option 1 (core contract field) and option 2 (per-connection config) is left open, per the original report — resolving it is part of implementation, not prejudged here.
• Scope is limited to the 'cash' vs 'transfer' distinction; other Infakt payment methods (e.g. card) are out of scope until requested.

Acceptance Criteria

• A decision is documented on whether payment method comes from a core-level order signal or a per-connection Infakt setting
• InfaktInvoicingAdapter.issueInvoice and issueCorrection send a consistent, correctly-derived payment_method instead of two disagreeing hardcoded values
• The 'transfer' value's bank-account prerequisite is either enforced/validated or the adapter falls back safely when the seller has no bank account configured on Infakt
• Tests added or updated for non-trivial logic
• No architecture boundary violations (CORE ↔ Integration)

[norbert-kulus-blockydevs]

🤖 claimed for work by branch 1303-infakt-payment-method at 2026-07-01T22:56:00Z