Открыть меню

Стек KAL / Kalignite / Multivendor

Создано 2 июн. 2026 г. Обновлено 2 июн. 2026 г. 2 мин чтения

Сценарий ATM-стека: Стек KAL / Kalignite / Multivendor.

Стек KAL / Kalignite / Multivendor

Кратко

Это вариант внедрения, где банк или процессинговая организация стремится унифицировать terminal application поверх ATM разных производителей. KAL/Kalignite в таком сценарии рассматривается как независимый multivendor ATM software layer, а не как признак конкретного банковского стека.

Когда такой вариант встречается

  • В разнородном ATM-парке с NCR, DN/Wincor, Hyosung, GRG и другими устройствами.
  • При миграции от vendor-native terminal apps к единому terminal software.
  • Когда важны единые сценарии, UI, remote deployment и поддержка разных host protocols.

Слои стека

СлойТиповой вариант
HardwareATM разных производителей
Device layerXFS/J/XFS/SP adapter layer
ATM applicationKalignite terminal software
Host protocolISO 8583, NDC, DDC или project-specific adapter
ProcessingWAY4, TranzAxis, BASE24 или иной switch/host
EMS/logsKalignite Enterprise или интеграция со сторонним EMS

Типовой flow

  1. Kalignite terminal app управляет customer flow и XFS/HAL-интеграцией.
  2. Protocol layer адаптирует терминальный сценарий к host/switch protocol.
  3. Switch/issuer обрабатывает authorization, reversal и clearing/reconciliation.
  4. Device events и EJ используются для evidence package при no dispense/partial dispense.

Что видно в логах

  • Важны Kalignite application logs, EJ, XFS device events и protocol adapter logs.
  • В host/switch нужны STAN/RRN, terminal ID, response code и reversal/advice status.
  • Конкретные EJ/export formats и поддерживаемые модели требуют KAL documentation или документации внедрения.

Сильные стороны

  • Multivendor abstraction как основной замысел.
  • Может снижать зависимость от одного hardware vendor.
  • Полезен для унификации UI, сценариев и deployment.

Ограничения

  • Поддержка конкретного ATM зависит от модели, XFS SP и версии Kalignite.
  • Edge cases остаются hardware-specific.
  • Заявления о Linux/локальных ОС, EJ и adapters требуют актуальных vendor sources.

Что требует проверки

  • Hardware support matrix.
  • OS build and certification context.
  • Protocol adapters: NDC/DDC/ISO profiles.
  • Journal/export and reconciliation integration.

Связанные заметки

Источники

Ссылаются на эту заметку

Источник: публичный слой Obsidian Vault.