Открытые вопросы

Места, где база пока не может дать точный ответ. Список живой: закрытый вопрос переезжает в соответствующую страницу, новый добавляется сюда, а не замалчивается.

Карточные поля в колбеке мерчанту

Тело исходящего уведомления, судя по коду, может содержать номер карты и имя держателя; в коде эти поля помечены как подлежащие удалению. Нужно понять, это действующее поведение или остаток. Вопрос выходит за рамки документации и касается области PCI.

Где живёт проверка учётных данных мерчанта

Оба публичных шлюза обращаются к сервису авторизации, но сами ручки проверки реализованы в репозитории PCI-шлюза, при этом отдельный сервис авторизации в системе тоже есть. Нужно понять, что стоит за этим адресом в проде.

Повторная отправка колбека

Задача с исчерпанными попытками удаляется из очереди. Существует ли административный способ отправить уведомление мерчанту заново — не выяснено.

Номер карты в запросе к антифроду

В обращении к антифроду передаётся поле с номером карты, но значение приходит из PCI-шлюза, и по коду ядра не видно, маскированный это номер или полный. Вопрос важен: от ответа зависит, попадает ли антифрод в область PCI. На странице механики написано обобщённо — «данные карты».

Снятие роллинга

Обработчик задачи на возврат роллинга в доступный баланс в ядре есть, а кода, который эту задачу ставит, найти не удалось. Возможно, роллинг снимается иначе или вручную. До выяснения страница говорит нейтрально: «возвращается отдельной операцией».

Влияет ли внешний скоринг на решение

Оценка внешнего поставщика сохраняется на транзакции, но нигде дальше не читается — отсюда вывод, что платёж он не останавливает. Прямого подтверждения в коде нет, и стоит уточнить, задумано ли так.

Антифрод при регистрации транзакции

Вызов при создании транзакции возвращает готовую категорию отказа, но ни один вызывающий её не использует. Нужно подтвердить, что шаг задуман как регистрация попытки, а не как потерянная проверка.

Режим наблюдения у проверки адресов мерчанта

Проверка списка разрешённых адресов в ядре при несовпадении пишет предупреждение и пропускает запрос; в коде рядом стоит пометка, что это временно. Нужно понять, это осознанное текущее состояние или незакрытая раскатка — и если второе, то что мешает включить отклонение.

Антифрод в операциях, кроме платежа

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

Как к нам приходит оспаривание

Чарджбэк появляется в системе как отметка на исходном платеже, но каким путём приходит сама информация — уведомлением от банка, выгрузкой или руками операционной команды — нигде не зафиксировано. На диаграмме нарисована обобщённая стрелка от банка-эмитента.

Ответ провайдеру на уведомление

Некоторые провайдеры повторяют уведомление, пока не получат ожидаемый ответ. Что именно мы возвращаем и одинаково ли это для всех интеграций — не выяснено, поэтому на диаграмме входящего колбека ответной стрелки банку нет.

Персональные учётки в ClickHouse и Postgres billing

Политика доступа требует персональную учётку у каждого разработчика, и для MongoDB это подтверждается списком реальных пользователей. Для ClickHouse и Postgres billing такого списка не нашлось — не выяснено, выдаются ли туда персональные учётные записи или общая на всех, кто прошёл через bastion.

Полный список данных, которые реплицируются в ClickHouse и Postgres

Конвейер MongoDB → Kafka → ClickHouse/Postgres существует и работает, но какие именно коллекции и поля попадают на другую сторону, задаётся настройкой и не задокументировано. На странице про хранилища данных это описано только как принцип, без перечня.

Идемпотентность

Поведение системы при дублирующем уведомлении банка, повторном запросе мерчанта и одновременной проверке статуса описано не полностью: часть гарантий выведена из кода, часть нуждается в подтверждении команды.