Вопрос:
как обрабатывать параметры фильтрации в запросе выписки?В рамках пилота Т-Банк-Сбер у нас возник момент разной логики обработки входных параметров
fromBookingDateTimeиtoBookingDateTimeв сервисе обмена операциями ( GET /transactions ):Т-Банк рассматривает эти параметры как параметры фильтрации запроса операций, т.е.:
-- [границы консента определены] при неполучении одного из них, или обоих - мы просто не расставляем границы фильтрации операций, и ограничиваем список операций датами согласия
-- [границы консента определены] при выходе одного из параметров за границы согласия - мы не отдаем ошибку, и при составлении ответа ограничиваем список операций датами согласияСбер рассматривает эти параметры как параметры, определяющие границы запроса, жестко валидирующиеся относительно дат согласия:
-- [границы консента определены] при неполучении одного из них - коллеги отдают ошибку 403 "Errors/errorCode": "RU.CBR.Authenticate.InvalidConsent"
-- [границы консента определены] при выходе одного из параметров за границы согласия - коллеги отдают ошибку 403 "Errors/errorCode": "RU.CBR.Authenticate.InvalidConsent"На пилот такие разные обработки кажутся некритичными, т.к. интеграция 1-к-1, и проблем возникнуть не должно.
Однако, просим более подробно расписать как корректно обрабатывать эти параметры в запросе операций (как обычные параметры фильтрации, или же как параметры определяющие границы запроса, и требующие жесткой валидации относительно согласия).
Ответ:
Мы подразумевали фильтрацию.
При любых ситуациях, возвращается список транзакций за оставшийся валидный период. Является ли это выход за рамок согласия или существования счета или указана будущая дата. Это надо зафиксировать и прописать.
Для гарантии правильной интерпретации данных ППИУ может предоставить даты первой и последней доступных операций, как часть ответа в разделе "Meta" в полях firstAvailableDateTime и lastAvailableDateTime.
Вопрос обсудим если не будет возвражений.