RBKmoney Clearing Service
Go to file
Anatoly Cherkasov 40d24fafad
JD-365: Added skip for adding transaction for AFT (#132)
* JD-365: Added skip for adding transaction for AFT
2021-06-16 16:05:08 +03:00
build_utils@24aa772730 JD-171: Fix processing empty TransactionInfo (#128) 2021-04-20 19:16:49 +03:00
src JD-365: Added skip for adding transaction for AFT (#132) 2021-06-16 16:05:08 +03:00
.gitignore PROX-257: МТС-клиринг. Реализация storage части клиринга (#1) 2018-12-28 16:14:10 +03:00
.gitmodules PROX-266: Clearing MTS Bank. Testing and debugging application 2019-01-18 19:06:19 +03:00
Jenkinsfile JD-171: Bump damsel 1.485-78ccbad. Add service-parent-pom (#125) 2021-03-25 16:26:45 +03:00
LICENSE Let's make it opensource 2019-09-20 00:16:53 +03:00
pom.xml JD-365: Added skip for adding transaction for AFT (#132) 2021-06-16 16:05:08 +03:00
README.md BJ-662: Refactoring. Delete unusual functionality (#92) 2019-12-03 12:56:43 +03:00

Сервис Midgard

Сервис Midgard отвечает за клиринг. Кли́ринг (англ. clearing — очистка) — безналичные расчёты между странами, компаниями, предприятиями и банками за поставленные, проданные друг другу товары, ценные бумаги и оказанные услуги, осуществляемые путём взаимного зачёта, исходя из условий баланса платежей. Клиринг используется в банковском деле, как «очищение» взаимных обязательств, часто работая циклически, а для выполнения этих функций банки часто используют клиринговые центры. В этом случае клиринг выступает формой безналичных двусторонних или многосторонних расчётов в системе платежей.

В общем случае алгоритм работы сервиса выглядит следующим образом:

  • от внешней системы поступает команда на выполнение клиринга;
  • клиринговый сервис формирует актуальные транзакции в группы и передает их в клиринговый адаптер, который формирует клиринговый файл и отправляет его в банк;
  • по результату клиринга адаптер возвращает статус клирингового события и внешняя систума может получить информацию о его статусе.

Клиринговый сервис отвечает за взаимодействие с внешней системой, получение и обработку транзакции, а так же отправку их клиринговому адаптеру.

1. Взаимодействие с внешней системой

API взаимодействия с внещней системой подразумевает:

  • запуск нового клирингового события (внешнаяя система передает ID внешнего события и ID провайдера);
  • получения его статуса по ID внешнего события.
2. Получение и обработка данных

Получение данных происходит следующим образом. В режиме реального времени получаем события из топика 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 - клиринговое событие выполнено, но присутствуют ошибки;

Через определенный промежуток времени запускается процесс, который проверяет готовые к взаимодействию с клиринговым адаптером события и если таковые присутствуют, то происходит передача данных в адаптер.

3. Взаимодействие с клиринговым адаптером

API взаимодействия с адаптером включает в себя следующие этапы:

  • Команда на запуск клирингового эвента на стороне адаптера (от него получаем ID события генерации файла);
  • Отправка данных в клиринговый адаптер (происходит передача ID события генерации файла и пакетов данных в клиринговый адаптер; финальный пакет содержит соответствующий признак; от адаптера получаем TAG сохраненных данных, который заносится в отдельный список для обеспечения целостности данных);
  • Команда на завершение клирингового эвента на стороне адаптера (в адаптер передается ID события генерации файла и список TAG'ов);
  • Получение ответа по клиринговому эвенту от банка.