Сервис Midgard отвечает за клиринг. Кли́ринг (англ. clearing — очистка) — безналичные расчёты между странами, компаниями, предприятиями и банками за поставленные, проданные друг другу товары, ценные бумаги и оказанные услуги, осуществляемые путём взаимного зачёта, исходя из условий баланса платежей. Клиринг используется в банковском деле, как «очищение» взаимных обязательств, часто работая циклически, а для выполнения этих функций банки часто используют клиринговые центры. В этом случае клиринг выступает формой безналичных двусторонних или многосторонних расчётов в системе платежей.
В общем случае алгоритм работы сервиса выглядит следующим образом:
- от внешней системы поступает команда на выполнение клиринга;
- клиринговый сервис формирует актуальные транзакции в группы и передает их в клиринговый адаптер, который формирует клиринговый файл и отправляет его в банк;
- по результату клиринга адаптер возвращает статус клирингового события и внешняя систума может получить информацию о его статусе.
Клиринговый сервис отвечает за взаимодействие с внешней системой, получение и обработку транзакции, а так же отправку их клиринговому адаптеру.
API взаимодействия с внещней системой подразумевает:
- запуск нового клирингового события (внешнаяя система передает ID внешнего события и ID провайдера);
- получения его статуса по ID внешнего события.
Получение данных происходит следующим образом. В режиме реального времени получаем события из топика kafka. Как только приходит какое-то сообщение со статусом "captured" для payment или "succeseeded" для refund сервис идет в HellGate (далее HG) и запрашивает данные по инвойсу. После получения происходит анализ данных на предмет соответствия провайдера необходимому и если находится соответствие, то в таблицу midgard.clearing_transaction или midgard.clearing_refund добавляется новая запись со статусом "READY". В противном случае запись пропускается.
Особое внимание стоит уделить статусам транзакций (midgard.transaction_clearing_state). Всего на данный момент их 6:
- CREATED - статус новой транзакции;
- READY - транзакция готова к клирингу;
- ACTIVE - транзакция уже участвует в клиринговом событии;
- FINISHED - транзакция успешно прошла клиринг;
- FAILED - транзакция по каким-либо причинам не прошла клиринг;
- FATAL - с транзацкией возникли ошибки на этапе импорта (данный тип ошибок требует ручного разрешения ошибки и такие транзакцтт в клиринг не попадут).
После того как от внешней системы получена команда на запуск клиринга происходит создание нового клирингового события, после этого запускается процедура, которая по таблицам с платежами и возвратами подготовит транзакции, которые должны попасть в клиринг, а так же переведет их и клиринг в статус ACTIVE.
Всего у клирингового события midgard.clearing_event_status может быть 6 статусов:
- STARTED - клиринговое событие запущено;
- EXECUTE - клиринговое событие выполняется;
- COMPLETE - клиринговое событие успешно выполнено;
- FAILED - клиринговое событие не выполнено;
- ADAPTER_FAULT - ошибка при взаимодействии с адаптером;
- COMPLETE_WITH_ERRORS - клиринговое событие выполнено, но присутствуют ошибки;
Через определенный промежуток времени запускается процесс, который проверяет готовые к взаимодействию с клиринговым адаптером события и если таковые присутствуют, то происходит передача данных в адаптер.
API взаимодействия с адаптером включает в себя следующие этапы:
- Команда на запуск клирингового эвента на стороне адаптера (от него получаем ID события генерации файла);
- Отправка данных в клиринговый адаптер (происходит передача ID события генерации файла и пакетов данных в клиринговый адаптер; финальный пакет содержит соответствующий признак; от адаптера получаем TAG сохраненных данных, который заносится в отдельный список для обеспечения целостности данных);
- Команда на завершение клирингового эвента на стороне адаптера (в адаптер передается ID события генерации файла и список TAG'ов);
- Получение ответа по клиринговому эвенту от банка.