Тайм-ауты и логика повторных запросов
Ограничения по времени обработки (тайм-ауты)
На стороне Банка отправителя денег
На стороне Банка отправителя денег должны быть предусмотрены следующие тайм-ауты:
Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (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-коду в рамках электронной коммерции (C2B2E)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009, 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.008.
Для процесса “Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)” - 30 секунд на получение pacs.002 со статусом PDNG после успешной отправки сообщения pacs.004.
Если Банк отправителя денег получает сообщение о статусе платежа/перевода pacs.002 со статусом PDNG (т.е. транзакция была успешно начата и находится в обработке) – он не должен разблокировать средства самостоятельно до получения от Платформы сообщения pacs.002 с финальным статусом транзакции (RJCT или ACSC).
Если, Банк отправителя денег не получает сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 секунд после получения pacs.002 со статусом PDNG, то он должен направить запрос статуса транзакции pacs.028 Платформе.
Банк отправителя денег должен соблюдать следующие временные ограничения обработки сообщений:
обработка полученного сообщения и формирование ответа c HTTP кодом 200 в случае успеха или HTTP кодом 400 в случае ошибки - не более 10 секунд;
обработка полученного сообщения admi.010 и формирование сообщения pacs.008 - не более 180 секунд;
обработка полученного сообщения acmt.024 и формирование сообщения pacs.008 - не более 180 секунд;
формирование сообщения pacs.004 с момента успешной отправки admi.010 - не более 180 секунд;
обработка полученного сообщения admi.009 и формирование ответного сообщения admi.010 - не более 10 секунд.
На стороне Банка бенефициара
На стороне Банка бенефициара должны быть предусмотрены следующие тайм-ауты:
Для процесса “Инициализация перевода денег от отправителя денег к другому ФЛ в приложении Банка отправителя денег (C2C2)” - 200 секунд на получение pacs.008 после успешной отправки сообщения acmt.024.
Для процесса “Инициализация оплаты по QR-коду (C2B2)” - 200 секунд на получение pacs.008 после успешной отправки сообщения admi.010.
Для процесса “Инициализация оплаты по QR-коду в рамках электронной коммерции (C2B2E)” - 200 секунд на получение pacs.008 после успешной отправки сообщения admi.010.
Для процесса “Возврат денег по проведенной ранее оплате за товар/ услугу (C2BR)” - 30 секунд на получение admi.010 после успешной отправки сообщения admi.009 и 200 секунд на получение pacs.004 с момента получения admi.010.
Если Банк бенефициара не получает от Платформы сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) в течение 30 сек после успешной отправки pacs.002 со статусом PDNG, то он завершает транзакцию неуспешно (RJCT) по тайм-ауту, начисление денег бенефициару не производится.
Если Банк бенефициара завершает транзакцию по тайм-ауту и после этого получает запрос с pacs.002 с финальным статусом ACSC, то он должен ответить на этот запрос HTTP кодом 400 с ошибкой INVALID_TRANSACTION_STATUS
Банку бенефициар должен соблюдать следующие временные ограничения обработки сообщений:
обработка полученного сообщения и формирование ответа 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 секунд.
Отправка повторных запросов
Для всех запросов, кроме запроса статуса транзакции pacs.028, запроса выписки camt.053 (см. Получение выписки):
Если получатель сообщения возвращает следующие HTTP-статусы - 500, 502, 503, 504 или при разрыве TCP-соединения по независящим от клиента причинам, отправитель сообщения должен повторно отправить запрос через 3 секунды.
Общее количество повторных попыток отправки запроса может быть не более 2, после чего операция завершается неуспешно.
При подсчете попыток повторной отправки сообщения используется комбинация следующих полей: тип сообщения, сквозной идентификатор, идентификатор банка отправителя сообщения (идентификатор Платформы).
При превышении количества повторных попыток отправки сообщения будет возвращен HTTP-статус 429
Для запроса статуса транзакции pacs.028:
Повторные запросы pacs.028 направляются по следующим правилам:
первые две попытки – интервал 3 секунды;
третья и последующие попытки – интервал определяется отправителем сообщения, но не менее 10 секунд.
Повторные попытки отправки запроса необходимо направлять не более чем в течении суток, до получения информации о состоянии транзакции из выписки, направляемой при смене операционного дня
pacs.028 направляется в случаях, когда:
Платформа не отвечает
Платформа отвечает следующими HTTP статусами - 500, 502, 503, 504, при разрыве TCP-соединения по независящим от клиента причинам
Не получено сообщение о статусе платежа/перевода pacs.002 с финальным статусом транзакции (RJCT или ACSC) согласно установленных временных регламентов
Логика повторной отправки pacs.002 со статусом ACSC Платформой
В случае, если при отправке платформой 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), в которых указывается информация о возникшей ошибке (причина неуспешности запроса).
Last updated