# Тайм-ауты и логика повторных запросов ## Ограничения по времени обработки (тайм-ауты) {% file src="/files/YSG91yWDDNYF6s5XAlBC" %} Схематичное отображение тайм-аутов {% endfile %} ### На стороне Банка отправителя денег На стороне Банка отправителя денег должны быть предусмотрены следующие тайм-ауты: > * Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (C2C2)” - 30 секунд на получение acmt.024 после успешной отправки сообщения acmt.023, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008. > * Для процесса “Возврат полученного перевода (C2CR)” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004. > * Для процесса “Инициализация оплаты по QR-коду (C2B2)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008. > * Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2) в рамках целевой модели” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 , 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008. > * Для процесса “Инициализация оплаты по QR-коду в рамках электронной коммерции (C2B2E)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008. > * Для процесса “Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004. > * Для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_V2) в рамках целевой модели” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004. ***! Применимо ко всем процессам, кроме целевой модели (C2B2\_V2/ C2BR\_V2):*** Если Банк отправителя денег получает сообщение о статусе платежа/перевода pacs.002 со статусом PDNG (т.е. транзакция была успешно начата и находится в обработке) – он не должен разблокировать средства самостоятельно до получения от Платформы сообщения pacs.002 с финальным статусом транзакции (RJCT или ACSC). ***! Применимо ко всем процессам, кроме целевой модели (C2B2\_V2/ C2BR\_V2):*** Если, Банк отправителя денег не получает сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 секунд после получения pacs.002 со статусом PDNG, то он должен направить запрос статуса транзакции pacs.028 Платформе. {% hint style="warning" %} Банк отправителя денег должен соблюдать следующие временные ограничения обработки сообщений: * обработка полученного сообщения и формирование ответа c HTTP кодом 200 в случае успеха или HTTP кодом 400 в случае ошибки - не более 10 секунд; * обработка полученного сообщения admi.010 и формирование сообщения pacs.008 - не более 180 секунд (адаптационная модель (C2B2); * обработка полученного сообщения admi.010 и формирование сообщения pacs.008 - не более 60 секунд (целевая модель (C2B2\_V2); * обработка полученного сообщения acmt.024 и формирование сообщения pacs.008 - не более 180 секунд; * формирование сообщения pacs.004 с момента успешной отправки admi.010 - не более 180 секунд (адаптационная модель (C2B2); * формирование сообщения pacs.004 с момента успешной отправки admi.010 - не более 120 секунд (целевая модель (C2B2\_V2); * обработка полученного сообщения admi.009 и формирование ответного сообщения admi.010 - не более 10 секунд; * обработка полученного сообщения pacs.002 (PDNG) и формирование сообщения pacs.002 (ACSC) - не более 10 секунд (целевая модель (C2B2\_V2). {% endhint %} {% hint style="info" %} ***Примечание:*** *Для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_\_V2)” в рамках целевой модели- Если, Банк отправителя денег не получает сообщение о статусе платежа/перевода pacs.002 PDNG в течение 30 секунд после успешной отправки pacs.004, то банк завершает процесс по таймауту и направляет в Платформу сообщение pacs.002 (RJCT) до тех пор пока не будет получен ответ HTTP 200.* {% endhint %} ### На стороне Банка бенефициара На стороне Банка бенефициара должны быть предусмотрены следующие тайм-ауты: > * Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (C2C2)” - 200 секунд на получение pacs.008 после успешной отправки сообщения acmt.024. > * Для процесса “Инициализация оплаты по QR-коду (C2B2)” - 200 секунд на получение pacs.008 после успешной отправки сообщения admi.010. > * Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2) в рамках целевой модели ” – 60 секунд на получение pacs.008 после успешной отправки сообщения admi.010. > * Для процесса “Инициализация оплаты по QR-коду в рамках электронной коммерции (C2B2E)” - 200 секунд на получение pacs.008 после успешной отправки сообщения admi.010. > * Для процесса “Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 и 200 секунд на получение pacs.004 с момента получения admi.010. > * Для процесса “ Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR\_\_V2) в рамках целевой модели ” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 и 120 секунд на получение pacs.004 с момента получения admi.010. ***! Применимо ко всем процессам, кроме целевой модели (C2B2\_V2/ C2BR\_V2):*** Если Банк бенефициара не получает от Платформы сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 сек после успешной отправки pacs.002 со статусом PDNG, то он завершает транзакцию неуспешно (RJCT) по тайм-ауту, начисление денег бенефициару не производится. {% hint style="danger" %} Если Банк бенефициара завершает транзакцию по тайм-ауту и после этого получает запрос с pacs.002 с финальным статусом ACSC, то он **должен ответить на этот запрос HTTP кодом 400 с ошибкой INVALID\_TRANSACTION\_STATUS** {% endhint %} {% hint style="warning" %} Банку бенефициар должен соблюдать следующие временные ограничения обработки сообщений: * обработка полученного сообщения и формирование ответа c HTTP кодом 200 в случае успеха или HTTP кодом 400 в случае ошибки - не более 10 секунд; * обработка полученного сообщения admi.009 и формирование ответного сообщения admi.010 - не более 10 секунд; * обработка полученного сообщения acmt.023 и формирование ответного сообщения acmt.024 - не более 10 секунд; * обработка полученного сообщения pacs.008 и формирование ответного сообщения pacs.002 - не более 10 секунд; * обработка полученного сообщения pacs.004 и формирование ответного сообщения pacs.002 - не более 10 секунд. {% endhint %} {% hint style="info" %} ***Примечание:*** *Для процесса “Инициализация оплаты по QR-коду (C2B2\_V2)” в рамках целевой модели- Если, Банк бенефициара не получает сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 секунд после отправки pacs.002 PDNG, то банк завершает процесс по таймауту и направляет в Платформу сообщение pacs.002 (RJCT) до тех пор пока не будет получен ответ HTTP 200.* {% endhint %} ## Отправка повторных запросов **Для всех запросов, кроме запроса статуса транзакции pacs.028, запроса выписки camt.053 (см.** [#poluchenie-vypiski](#poluchenie-vypiski "mention")**):** * Если получатель сообщения возвращает следующие HTTP-статусы - 500, 502, 503, 504 или при разрыве TCP-соединения по независящим от клиента причинам, отправитель сообщения должен повторно отправить запрос через 3 секунды. * Общее количество повторных попыток отправки запроса может быть не более 2, после чего операция завершается неуспешно. {% hint style="info" %} При подсчете попыток повторной отправки сообщения используется комбинация следующих полей: тип сообщения, сквозной идентификатор, идентификатор банка отправителя сообщения (идентификатор Платформы). {% endhint %} {% hint style="danger" %} При превышении количества повторных попыток отправки сообщения будет возвращен HTTP-статус 429 {% endhint %} **Для запроса статуса транзакции pacs.028:** Повторные запросы pacs.028 направляются по следующим правилам: * первые две попытки – интервал 3 секунды; * третья и последующие попытки – интервал определяется отправителем сообщения, но не менее 10 секунд. {% hint style="warning" %} Повторные попытки отправки запроса необходимо направлять не более чем в течении суток, до получения информации о состоянии транзакции из выписки, направляемой при смене операционного дня {% endhint %} {% hint style="info" %} pacs.028 направляется в случаях, когда: * Платформа не отвечает * Платформа отвечает следующими HTTP статусами - 500, 502, 503, 504, при разрыве TCP-соединения по независящим от клиента причинам * Не получено сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) согласно установленных временных регламентов {% endhint %} ## Логика повторной отправки pacs.002 со статусом ACSC Платформой {% hint style="danger" %} Данный раздел применим ко всем процессам, кроме целевой модели (C2B2\_V2/ C2BR\_V2). {% endhint %} В случае, если при отправке платформой pacs.002 со статусом ACSC в банк бенефициара возникают ошибки соединения или серверные ошибки, применяется следующая логика: * Если банк бенефициар возвращает HTTP-статусы 500, 502, 503, 504 либо происходит разрыв TCP-соединения по причинам, не зависящим от платформы - платформа выполняет две повторные попытки отправки через 3 и 6 секунд. * Если платформа не получила однозначного ответа от банка бенефициара (HTTP-статус 200 или 400) - выполняются дополнительные три повторные попытки через 60, 90 и 120 секунд. * При отсутствии успешного ответа после всех повторных попыток - транзакция фиксируется в системе со статусом COMMITTED, в банк отправителя направляется сообщение pacs.002 со статусом ACSC. * Дальнейшее получение статуса обработки транзакции банком бенефициаром осуществляется посредством - запроса статуса обработки транзакции (pacs.028) или получением информации о статусе транзакции из выписки (camt.053). ## Получение выписки В случае неполучения выписки по счету camt.053 по запросу camt.060, повторный запрос выписки camt.060 Платформе можно направлять не ранее, чем через 2 минуты после предыдущей попытки. ## Информирование об ошибках Ошибка направляется в ответе на запрос (синхронно), если она возникает при валидации запроса/ В случае возникновения ошибок при обработке сообщения, связанных с бизнес-процессом (контроль лимитов, антифрод и т.д.) на стороне Платформы, Платформа направляет соответствующие ответные сообщения (acmt.024, pacs.002, admi.010), в которых указывается информация о возникшей ошибке (причина неуспешности запроса). В случае возникновения ошибок при обработке сообщения, связанных с бизнес-процессом (контроль лимитов, антифрод и т.д.) на стороне БВУ, БВУ направляет соответствующие ответные сообщения (acmt.024, pacs.002, admi.010), в которых указывается информация о возникшей ошибке (причина неуспешности запроса). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.npck.kz/mezhbankovskaya-sistema-perevodov-i-platezhei/taim-auty-i-logika-povtornykh-zaprosov.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.