Как задаются стратегии для каждого платежа: через API или иначе
Что проверяют
Где живёт решение о поведении конкретного платежа (через какого провайдера провести, как повторять попытки, нужна ли 3-D Secure), кто его задаёт и как это устроено в коде. Вопрос обычно звучит при разборе вашего проекта, а следом спрашивают, как менять правила без деплоя и как не списать деньги дважды.
Как отвечать
Сначала о том, откуда берётся решение:
- явно в API: клиент передаёт параметр в запросе, например режим списания (одностадийный или с холдированием) или способ оплаты. Так стоит отдавать только то, что действительно решает клиент. Маршрутизация и лимиты это внутренняя политика, её через API не выставляют;
- правила на сервере: движок маршрутизации выбирает стратегию по атрибутам платежа: сумма, валюта, BIN карты, страна, мерчант, текущая доля отказов у провайдера. Правила лежат в базе, версионируются и перечитываются без рестарта;
- комбинация: API задаёт намерение, сервер выбирает реализацию.
В коде на Go это паттерн «стратегия» через интерфейс, например type Strategy interface { Process(ctx context.Context, p Payment) (Result, error) }, реестр map[string]Strategy и селектор, который по правилам возвращает реализацию. Выбранную стратегию и версию правил записывают в сам платёж: повторы, возвраты и разбор инцидентов идут по тому же пути.
Обязательно скажите про надёжность: ключ идемпотентности в запросе и уникальный индекс в базе, машина состояний платежа (создан, авторизован, списан, возвращён), повторы с экспоненциальной задержкой только для безопасных операций, переключение на запасного провайдера при мягком отказе.
Если в вашем проекте стратегия просто жёстко привязывалась к мерчанту, так и скажите и объясните, что меняли бы при росте.
Где спотыкаются
Отвечают про подключение SDK провайдера и HTTPS. Вопрос не про транспорт, а про то, где и кем принимается решение.
Держат выбор стратегии в огромном switch внутри обработчика. На старте это нормально, но каждое новое правило тогда означает правку кода и деплой.
Не фиксируют стратегию в платеже. При возврате правила уже другие, запрос уходит не тому провайдеру и падает, а при повторе без ключа идемпотентности клиент получает двойное списание.