Инициализация выставления счета на оплату ФЛ от ЮЛ (C2B2_RTP)

Данный сценарий описывает инициализацию процесса выставления счета на оплату от одного юридического лица (ЮЛ) в одном БВУ (Банк Бенефициара) другому физическому лицу (ФЛ), обслуживаемому в другом БВУ (Банк отправителя денег).

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

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

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

Схема процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2_RTP)»

Схема процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2_RTP)».pdf

PDF · 148KB

Open

Схематичное отображение процесса

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

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

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

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

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

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

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

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

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

Описание успешного сценария процесса «Инициализация выставления счета на оплату ФЛ от ЮЛ(C2B2_RTP)»:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.12. Бенефициар подтверждает выставление счета в приложении Банка бенефициара.

1. Выставление счета на оплату

2.1. Бенефициар (ЮЛ) инициирует выставление счета с указанием суммы платежа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6. Банк отправителя денег принимает сообщение pain.013 и отображает информацию о счете клиенту–отправителю денег (ФЛ) через мобильное приложение.

2.6.1. Уведомление клиента и срок действия счета:

• После успешной обработки сообщения pain.013 Банк отправителя денег инициирует направление клиенту–отправителю денег (ФЛ) push-уведомления о выставлении счета Бенефициаром (ЮЛ).

• С момента получения Банком отправителя денег сообщения pain.013 запускается таймер срока действия счета.

• Срок действия счета составляет 24 часа. В течение указанного времени клиент–отправитель денег может подтвердить оплату счета.

• По истечении 24 часов с момента выставления счета, при отсутствии подтверждения оплаты со стороны клиента–отправителя денег, счет автоматически переводится в неактивный статус и становится недоступным для оплаты.

2.7. Отправитель денег просматривает выставленный счет и подтверждает согласие на его оплату.

2.8. Отказ оплаты выставленного счета

2.8.1. Отправитель денег отклоняет счет на оплату:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.8.2. Отправитель денег не совершает оплату в течение 24 часов с момента выставления счета:

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

1. Транзакция по проведению платежа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ HTTP 200 подтверждает приём сообщения Платформой; итоговый результат транзакции приходит отдельным сообщением pacs.002 от Платформы.

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

• Платформа не отвечает или возвращает HTTP 500 (5xx):

1. Банк отправителя денег повторяет отправку того же сообщения не чаще одного раза в 3 секунды до получения ответа HTTP 200. Повторная отправка безопасна: Платформа обрабатывает повторный pacs.002 идемпотентно.

• Платформа возвращает HTTP 429:

1. Повтор отправлен раньше минимального интервала. Необходимо выдержать 3 секунды с момента предыдущей попытки. Для pacs.028 интервал иной: первые две попытки — через 3 секунды, третья и последующие — не чаще одного раза в 10 секунд.

• Платформа возвращает HTTP 408, код TRANSACTION_TIMEOUT_EXCEEDED:

1. Истёк таймаут стадии (30 секунд, см. пункт 17.1), транзакция переведена в статус «истекла». Повторные отправки бесполезны и должны быть прекращены. Банку необходимо запросить статус обработки транзакции (pacs.028) и обработать транзакцию как несостоявшуюся.

• Платформа возвращает HTTP 400:

1. Сообщение не принято Платформой. Повторные отправки прекращаются; банку необходимо запросить статус обработки транзакции (pacs.028) и действовать в соответствии с полученным статусом. Если код ошибки указывает на некорректное содержимое сообщения (FIELD_INVALID, HEADER_INVALID, HEADER_MISSING), банку дополнительно необходимо устранить причину на своей стороне — иначе ошибка повторится на последующих операциях.

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

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

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

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

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

• Не получен pacs.002 ACSC от Банка отправителя денег:

1. Если Платформа в течение 30 секунд не получает сообщение pacs.002 (ACSC) от Банка отправителя денег, то транзакция завершается со статусом RJCT и при получении pacs.002 ACSC от Банка отправителя денег будет возвращен HTTP 408.

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

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

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

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

2. Если Банк бенефициара не направляет ответ, то Платформа считает запрос не доставленным, при этом транзакция не отклоняется и остается в состоянии ожидания сообщения pacs.002 с финальным статусом от Банка бенефициара.

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

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

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

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

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

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

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

Сообщение направляется после получения от Платформы уведомления из пункта 18. Ответ HTTP 200 подтверждает приём сообщения Платформой.

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

• Платформа не отвечает или возвращает HTTP 500 (5xx):

1. Банк бенефициара повторяет отправку того же сообщения не чаще одного раза в 3 секунды до получения ответа HTTP 200. Повторная отправка безопасна: Платформа обрабатывает повторный pacs.002 идемпотентно. Отдельный таймаут на этой стадии не применяется.

• Платформа возвращает HTTP 429:

1. Повтор отправлен раньше минимального интервала. Необходимо выдержать 3 секунды с момента предыдущей попытки.

• Платформа возвращает HTTP 400, коды FIELD_INVALID / HEADER_INVALID / HEADER_MISSING:

1. Сообщение не прошло проверку содержимого. Транзакция при этом не отклоняется и остаётся в обработке. Банку бенефициара необходимо проанализировать код и описание ошибки, скорректировать сообщение и направить исправленный pacs.002 повторно.

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

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

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

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

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

3.18. Платформа направляет уведомление pacs.002 со статусом ACSC до Банка отправителя денег и Банка Бенефициара с информацией о дате обработки транзакции (Processing Date) и информацией о размерах комиссий, подписав его ЭЦП Платформы.

3.19. Банк отправителя завершает транзакцию и уведомляет клиента о завершении операции.

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

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

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

Рекомендуется: Банку отправителя денег начинать направлять запрос статуса обработки транзакции (pacs.028) через 5 секунд после успешной отправки pacs.002.