Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара

Данный сценарий описывает инициализацию перевода денег юридическим лицом (Отправитель денег) на счет физического лица (Бенефициар).

Перевод денег осуществляется со счета Отправителя денег в Банке отправителя денег на счет Бенефициара в Банке бенефициара. Перед проведением перевода денег выполняется верификация принадлежности банковского счета бенефициару по номеру телефона бенефициара.

Для обеспечения возможности проверки принадлежности счета бенефициар предоставляет согласие на доступ к данным о его номере счета по номеру телефона. В случае невозможности проверки принадлежности банковского счета перевод денег не осуществляется.

Методы API (endpoint), которые необходимо реализовать

При реализации участниками информационного взаимодействия данные API должны быть идемпотентны (получив повторный запрос с теми же параметрами, должен выдаваться в ответе результат исходного запроса).

Схему успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара» отображает рисунок ниже.

Схема процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара»

Примечание: На схеме темно-зелеными квадратами отображены методы (endpoint), которые должны быть реализованы на стороне соответствующего участника для реализации данного сценария. Описание методов приведено в электронном формате в https://transfers-openapi.npck.kz/.

Для обеспечения возможности проверки принадлежности счета бенефициар предоставляет согласие на доступ к данным о его номере счета по номеру телефона. Описание подпроцесса «Регистрация согласия на проверку принадлежности счета» приведено ниже в разделе «Описание процесса»

Методы API (endpoint), которые необходимо реализовать каждому участнику на своей стороне в рамках процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара», приведены в таблице ниже.

Метод API (endpoint)	Банк отправителя денег	Банк бенефициара
Запрос верификации наличия счета клиента (POST /v1/transfers/iso20022/acmt.023.001.03)		+
Результат верификации наличия счета клиента (POST /v1/transfers/iso20022/acmt.024.001.03)	+
Запрос на перевод денег (POST /v1/transfers/iso20022/pacs.008.001.11)		+
Статус обработки запроса перевода денег (POST /v1/transfers/iso20022/pacs.002.001.13)	+	+

Взаимосвязь идентификаторов сообщений

Процесс «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с верификацией номера счета» построен на обмене сообщениями, основанными на стандарте ISO20022, которые логически связаны между собой.

Логическая схема взаимосвязи идентификаторов сообщений

Описание процесса

Описание успешного сценария процесса «Инициализация перевода денег от ЮЛ на счет ФЛ (B2C2I) с проведением идентификации бенефициара»:

Регистрация согласия на проверку принадлежности счета

1. Для того, чтобы перед отправкой денег Отправитель денег (ЮЛ) мог выполнить проверку принадлежности счета Бенефициару (ФЛ) необходимо получение согласия на это от Бенефициара. Регистрация согласия на проверку принадлежности счета производится посредством сервисов Центра обмена идентификационными данными (ЦОИД).

При успешном предоставлении согласия Бенефициаром (ФЛ) Отправителю денег будет предоставлен подтверждающий это токен, который используется при верификации наличия счета клиента.

Подпроцесс «Регистрация согласия на проверку принадлежности счета»

1. Система отправителя денег получает URL-адрес для перенаправления бенефициара на сервис ЦОИД. Описание метода «Получить URL-адрес для перенаправления клиента» (POST /v1/auth/generate-user-url) приведено в https://auth-openapi.npck.kz/#tag/Auth/operation/generateUserUrl

То какая услуга ЦОИД должна быть предоставлена определяется значениями, указанными в параметре scoped при запросе URL-адреса для перенаправления клиента в ЦОИД.

Для регистрации согласия на проверку принадлежности счета используется значение b2c2i.

Значение b2с2i, может использоваться совместно со значениями scopes для персональных данным и верификации физического лица (см. Сервисы ЦОИД)

1. Для проведения двухфакторной аутентификации Система отправителя денег перенаправляет бенефициара на полученный URL-адрес.

Время действия URL-адреса для перенаправления (время «жизни») составляет 15 минут

Если в ОС Android при проведении liveness-сессии не отображается изображение клиента, то потенциальным решением проблемы может являться применение следующих параметров:

webView.settings.allowContentAccess = true;

webView.settings.mediaPlaybackRequiresUserGesture = false;

webView.settings.domStorageEnabled = true

WebKit в Android, позволяет видео компонентам запускаться только по действию пользователя, при этом для корректной работы сервисов ЦОИД камера запускается программными средствами (autoplay), WebKit блокирует данное действие и выдает ошибку. Чтобы избежать этого, необходимо в компоненте webView указать данную настройку.

В IOS необходимо использовать SafariWebView. WKWebView не поддерживается.

1. Бенефициару отображается форма аутентификации ЦОИД. Пользователь проходит двухфакторную аутентификацию личности.

2. Бенефициар должен дать согласие на проверку принадлежности счета Отправителем денег.

Бенефициар может отклонить согласие на доступ к его данным.

Если Бенефициар отклоняет согласие на доступ к его данным или происходит ошибка, то клиент будет перенаправлен на указанный на шаге 1 redirectUri, с указанием кода ошибки, по следующему шаблону:

[redirectUri]?errorCode=[error code]&state=[state]

В таком случае процесс завершается, код авторизации не предоставляется.

1. После того, как Бенефициар выполнит все действия на стороне ЦОИД, осуществляется его возврат в приложение отправителя денег.

Если аутентификация Бенефициара проходит успешно и он дает согласие на доступ к его данным, то Бенефициар перенаправляется обратно в приложение Отправителя денег (на указанный в запросе redirectUri) с одноразовым кодом авторизации (code), по следующему шаблону:

[redirectUri]?code=[authorization code]&state=[state]

Код авторизации является одноразовым.

Время действия кода авторизации (время «жизни») составляет 300 секунд

Редирект из webview в случае SafariWebView нужно перехватывать через диплинк (deeplink)

1. Система Отправителя денег получает токен доступа (в формате JWT), который необходим для верификации наличия счета клиента, используя полученный на предыдущем шаге код авторизации. Описание используемого для этого метода приведено в https://auth-openapi.npck.kz/#tag/Auth/operation/getOauthToken

Срок действия токена составляет 3 часа

Верификация наличия счета клиента

1. Отправитель денег инициирует перевод денег из Банка отправителя денег Бенефициару по номеру телефона. При этом Отправитель денег предоставляет Банку отправителя денег токен, подтверждающий, что Бенефициар предоставил согласие на верификацию принадлежности счета, полученный на предыдущем шаге.

Срок действия токена составляет 3 часа

Информационное взаимодействие между Отправителем денег и Банком отправителя денег выходит за рамки данной спецификации.

Должно быть обеспечена безопасная передача токена доступа из системы Отправителя денег в Банк отправителя денег для инициализации перевода.

1. Банк отправителя денег направляет Платформе запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его своим ЭЦП.

В HTTP-заголовке запроса в параметре Authorization передается токен доступа из шага 1.

При отсутствии токена, передачи некорректного или недействительного токена будет возвращена ошибка с HTTP-статусом 401.

В сообщении передается:

• в теге <Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения

• в теге <Document::Vrfctn:Id> – сгенерированный уникальный идентификатор запроса верификации, который будет выступать в качестве сквозного идентификатора для всей цепочки сообщений в рамках данной операции перевода

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.

2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.

2. Процесс завершается неуспешно.

3.1. Платформа, получив запрос, проводит его обработку и валидацию, в том числе:

• проверяет подпись Банка отправителя денег

• проверяет корректность заполнения полей

• проверяет, что сквозной идентификатор <Document::Vrfctn:Id> не использовался

• проверяет срок действия токена доступа и область действия токена (scope)

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1. Платформа направляет в Банк бенефициара запрос верификации наличия счета клиента по номеру телефона (сообщение acmt.023), подписывая его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::Assgnmt:MsgId> – сгенерированный уникальный идентификатор сообщения

• в теге <Document::Vrfctn:Id> – сквозной идентификатор для всей цепочки сообщений в рамках данной операции перевода, полученный на шаге 2

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

2. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.

3. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

4. Процесс завершается неуспешно.

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.

2. Платформа завершает процесс, получив сообщение с информацией об ошибке.

3. Платформа направляет в Банк отправителя сообщение acmt.024 с ошибкой.

4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

5. Процесс завершается неуспешно.

4.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

1. Банк бенефициара проверяет наличие счета по указанному в запросе номеру телефона.

2. Банк бенефициара направляет результат верификации наличия счета клиента Платформе (сообщение acmt.024), подписав его своим ЭЦП.

В сообщении передается:

• в теге <Document::Rpt:OrgnlId> – сквозной идентификатор из тега <Vrfctn:Id> исходного запроса (из acmt.023)

• При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.

2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом.

2. Банк отправителя денег завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

3. Процесс завершается неуспешно.

• Сведения о счете клиента не найдены:

1. Банк бенефициара направляет негативный результат верификации наличия счета клиента Платформе (сообщение acmt.024).

2. Платформа направляет негативный результат верификации наличия счета клиента Банку отправителя денег (сообщение acmt.024).

3. Процесс завершается неуспешно.

6.1. Платформа, получив запрос (сообщение acmt.024), проводит его валидацию, в том числе:

• проверяет подпись Банка бенефициара

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1. Платформа направляет результат верификации наличия счета клиента в Банк отправителя денег (сообщение acmt.024), подписав его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::Rpt:OrgnlId> – сквозной идентификатор из тега <Vrfctn:Id> исходного запроса (из acmt.023)

• При наличии счета бенефициара передается его ФИО и IBAN для счета бенефициара

Возможные неуспешные сценарии

• Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

7.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

1. Банк отправителя денег предоставляет Отправителю денег информацию о бенефициаре, чтобы Отправитель денег мог удостовериться в корректности получателя.

2. Отправитель денег подтверждает перевод.

Возможные неуспешные сценарии

• Отправитель денег не подтверждает перевод в приложении Банка отправителя денег:

1. Процесс завершается неуспешно.

Транзакция по переводу денег

1. Банк отправителя денег проводит проверку счета клиента на:

• валидность статуса для его дебетования

• отсутствие наложенного ПТП/ РПРО/ ареста и т.п.

• достаточности средств для списания суммы операции

Возможные неуспешные сценарии

• Проверка счета не прошла успешно:

1. Банк отправителя денег уведомляет клиента о невозможности проведения операции.

2. Процесс завершается неуспешно.

1. Банк отправителя денег блокирует сумму операции по счету клиента и формирует платежное поручение (pacs.008).

2. Банк отправителя денег направляет Платформе запрос на перевод денег (сообщение pacs.008), подписав его своим ЭЦП.

В сообщении передается:

• в теге <Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document::PmtId:EndToEndId> – сквозной идентификатор из тега <OrgnlId> из сообщения acmt.024

• в поле <Document::PmtId:TxId> – сгенерированный уникальный идентификатор новой транзакции

• указывается IBAN для счета Отправителя денег

• указывается IBAN для счета Бенефициара

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк отправителя денег должен считать, что запрос не доставлен.

2. Банк отправителя денег выполняет попытку повторной отправки корректного запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет Банку отправителя денег ответ с соответствующим ошибке HTTP статусом.

2. Процесс завершается неуспешно.

12.1. Платформа, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Банка отправителя денег

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1. Платформа обрабатывает запрос на перевод денег (сообщение pacs.008), в том числе:

• выполняет проверку позиций участников и лимитов;

• выполняет блокирование средств для проведения транзакции;

• выполняет поиск результата верификации наличия счета клиента по <EndToEndId> (acmt.024).

Возможные неуспешные сценарии

• Обработка запроса на перевод денег pacs.008 Платформой не проходит успешно:

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).

2. Процесс завершается неуспешно.

1. Платформа направляет в Банк бенефициара запрос на перевод денег (сообщение pacs.008), подписав его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::GrpHdr:MsgId> – сгенерированный уникальный идентификатор нового сообщения

• в теге <Document::PmtId:EndToEndId> – сквозной идентификатор из тега <OrgnlId> из сообщения acmt.024, соответствует <EndToEndId> из сообщения pacs.008 Банка отправителя денег

• в поле <Document::PmtId:TxId> – идентификатор транзакции из тега <TxId> из сообщения pacs.008 Банка отправителя денег

• указывается IBAN для счета Отправителя денег

• указывается IBAN для счета Бенефициара

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

3. Платформа завершает процесс, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

4. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.

5. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке.

6. Процесс завершается неуспешно.

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Банк бенефициара направляет ответ Платформе с соответствующим ошибке HTTP статусом.

2. Платформа устанавливает статус транзакции RJCT (отклонена).

3. Платформа направляет в Банк отправителя сообщение pacs.002 с ошибкой.

4. Банк отправителя денег завершает процесс, получив сообщение с информацией об ошибке, устанавливает статус транзакции RJCT (отклонена).

5. Процесс завершается неуспешно.

14.1. Банк бенефициара, получив запрос, проводит его обработку, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

1. Банк бенефициара проверяет счет бенефициара на возможность зачисления денег.

2. Банк бенефициара направляет статус обработки запроса перевода денег Платформе (сообщение pacs.002), подписав его своим ЭЦП.

В сообщении передается:

• <Document::OrgnlEndToEndId> – сквозной идентификатор из тега <EndToEndId> исходного запроса (pacs.008)

• <Document::OrgnlTxId> – идентификатор транзакции из тега <TxId> исходного запроса (из pacs.008)

• Статус транзакции PDNG (в обработке)

Возможные неуспешные сценарии

• Платформа не отвечает:

1. Если Платформа не направляет ответ, то Банк бенефициара должен считать, что запрос не доставлен.

2. Банк бенефициара выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

• Валидация сообщения не прошла успешно:

1. Валидация сообщения не проходит успешно, Платформа направляет ответ Банку бенефициара с соответствующим ошибке HTTP статусом. Банк бенефициара устанавливает статус транзакции RJCT (отклонена).

2. Платформа устанавливает статус транзакции статусом RJCT (отклонена).

3. Банк отправителя денег, не получив ответ в срок в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов), устанавливает статус транзакции RJCT (отклонена).

4. Процесс завершается неуспешно.

• Транзакция отклонена (статус транзакции RJCT):

1. Банк бенефициара направляет Платформе статус обработки запроса перевода денег (сообщение pacs.002) - RJCT (отклонена).

2. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы, со статусом транзакции RJCT (отклонена).

3. Процесс завершается неуспешно.

16.1. Платформа, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Банка бенефициара

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Платформа направляет ответ с HTTP статусом 200.

1. Платформа направляет статус обработки запроса перевода денег в Банк отправителя денег (сообщение pacs.002), подписав его ЭЦП Платформы.

В сообщении передается:

• в теге <Document::OrgnlEndToEndId> – сквозной идентификатор из тега <EndToEndId> исходного запроса (pacs.008)

• в теге <Document::OrgnlTxId> – идентификатор транзакции из тега <TxId> исходного запроса (из pacs.008)

• Статус транзакции PDNG (в обработке)

Возможные неуспешные сценарии

• Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

17.1. Банк отправителя денег, получив запрос, проводит его валидацию, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

1. Платформа успешно завершает транзакцию (commit transaction).

2. Платформа направляет в качестве уведомления об успешной транзакции в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

Возможные неуспешные сценарии

• Банк бенефициара не отвечает:

1. Если Банк бенефициара не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

19.1. Банк бенефициара, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк бенефициара направляет ответ с HTTP статусом 200.

Примечание: Если Платформа направляет в Банк бенефициара сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк бенефициара не производит (не производит повторное зачисление денег на счет бенефициара и т.д.), а лишь отправляет ответ с HTTP статусом 200

Возможные неуспешные сценарии

• Банк бенефициара не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):

1. Банк бенефициара ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк бенефициара в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов) завершает транзакцию неуспешно (RJCT) по тайм-ауту, зачисление средств бенефициару не производится.

3. Платформа производит откат транзакции, устанавливает статус транзакции - RJCT (неуспешно). Банк отправителя денег, получив статус транзакции RJCT (неуспешно), разблокирует средства Отправителя денег, списание средств не производится.

Примечание: перед завершением транзакции Банк бенефициара может проверить статус транзакции на Платформе, отравив сообщение pacs.028 (см. Сервис получения статуса обработки транзакции)

19.2. Банк бенефициара производит зачисление денег на счет бенефициара и уведомляет об этом бенефициара.

1. Платформа направляет в качестве уведомления об успешной транзакции в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, подписав его ЭЦП Платформы.

Возможные неуспешные сценарии

• Банк отправителя денег не отвечает:

1. Если Банк отправителя денег не направляет ответ, то Платформа должна считать, что запрос не доставлен.

2. Платформа выполняет попытку повторной отправки запроса в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

20.1. Банк отправителя денег, получив сообщение pacs.002 со статусом транзакции, проводит его валидацию, в том числе:

• проверяет подпись Платформы

• проверяет корректность заполнения полей

Если валидация запроса проходит успешно, Банк отправителя денег направляет ответ с HTTP статусом 200.

Возможные неуспешные сценарии

• Банк отправителя денег не получил сообщение pacs.002 с финальным статусом транзакции (ACSC или RJCT):

1. Банк отправителя денег ожидает получение сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT) в соответствии с установленным регламентом (см. Тайм-ауты и логика повторных запросов).

2. Не получив сообщения pacs.002 с финальным статусом транзакции (ACSC или RJCT), Банк отправителя денег направляет запрос статуса транзакции Платформе (сообщение pacs.028, см. Сервис получения статуса обработки транзакции), подписав его своим ЭЦП.

3. Платформа, успешно выполнив обработку запроса, направляет ответ с HTTP статусом 200.

4. Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции, подписав его ЭЦП Платформы.

Примечание: Если Платформа направляет в Банк отправителя денег сообщение pacs.002 со статусом транзакции ACSC, и им уже был получен такой же запрос (повторно отправлен pacs.002), то дополнительных действий Банк отправителя денег не производит (не производит повторное списание денег со счета отправителя денег и т.д.), а лишь отправляет ответ с HTTP статусом 200

20.2. Банк отправителя денег производит списание денег со счета отправителя денег и уведомляет его о завершении операции.