Диспатчинг

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

Блок dispatching задаётся в определении правила и содержит следующие поля:

list — список алиасов гейтов из настроек мерчанта, между которыми распределяются запросы.
method — алгоритм распределения: "queue", "limit" или "conversion".
rate — окно измерения, только для "conversion".
accepted_only — учитывать только попытки, по которым были выданы реквизиты, только для "conversion".
min_conversion — минимальная конверсия гейта в процентах, ниже которой гейт не рассматривается, только для "conversion".

{
  "list": ["TEST1", "TEST2", "TEST3"],
  "method": "queue" | "limit" | "conversion"
}

Настройка правил

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

Для сеттинга с тремя гейтами (TEST1, TEST2, TEST3) нужно завести три правила:

Правило 1 — TEST1

{
  "header": {
    "mid": "81",
    "acq_alias": "TEST1"
  },
  "body": {
    "status": {
      "sum": {
        "1#approved#amount": [0, 2000000]
      }
    }
  },
  "routing": null,
  "action": null,
  "dispatching": {
    "list": ["TEST1", "TEST2", "TEST3"],
    "method": "queue"
  }
}

Правило 2 — TEST2

{
  "header": {
    "mid": "81",
    "acq_alias": "TEST2"
  },
  "body": {
    "status": {
      "sum": {
        "1#approved#amount": [0, 2000000]
      }
    }
  },
  "routing": null,
  "action": null,
  "dispatching": {
    "list": ["TEST1", "TEST2", "TEST3"],
    "method": "queue"
  }
}

Правило 3 — TEST3

{
  "header": {
    "mid": "81",
    "acq_alias": "TEST3"
  },
  "body": {
    "status": {
      "sum": {
        "1#approved#amount": [0, 2000000]
      }
    }
  },
  "routing": null,
  "action": null,
  "dispatching": {
    "list": ["TEST1", "TEST2", "TEST3"],
    "method": "queue"
  }
}

Метод `queue`

Итеративно обходит гейты из list по порядку. Первый запрос направляется на TEST1, второй — на TEST2, третий — на TEST3, четвёртый — снова на TEST1 и так далее по кругу.

Метод `limit`

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

Метод `conversion`

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

{
  "header": {
    "mid": 81,
    "acq_alias": "TEST1",
    "currency": "INR"
  },
  "body": {},
  "routing": null,
  "action": null,
  "dispatching": {
    "list": ["TEST1", "TEST2", "TEST3"],
    "method": "conversion",
    "rate": "1d#approved"
  }
}

Поле rate задаётся как [окно][s|h|d|w|m|y]#[успешный_статус] — 30s#approved, 12h#approved, 3d#approved, 2w#approved. Число без суффикса означает дни, по умолчанию — 1d#approved.

В отличие от счётчиков count и sum, это окно смещается с каждым запросом, а не сбрасывается в полночь по таймзоне, поэтому суффикс таймзоны принимается, но игнорируется.

Оценка

У гейта, который ещё ничего не завершил, конверсии нет, а у гейта с одной завершённой транзакцией она равна 0% или 100% — ни на то, ни на другое опираться при маршрутизации нельзя. Поэтому оценки считаются по формуле:

оценка = (approved + 1) / (всего + 2)

Гейт без истории оказывается на отметке 50% — выше слабого гейта и ниже хорошего. Этим решается ситуация, когда гейт с ужасной конверсией в 10% принимает все операции и не даёт другим шанса проявить себя.

При равных оценках приоритет отдаётся порядку, в котором гейты перечислены в list.

Что учитывается

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

Что сделал гейт	По умолчанию	С `accepted_only`
Выдал реквизиты, платёж завершился успешно	конверсия	конверсия
Выдал реквизиты, платёж позже отклонён или просрочен	неудачная конверсия	неудачная конверсия
Отказал сразу, реквизиты не выдал	неудачная конверсия	не учитывается

Каждый гейт оценивается внутри группы, заданной теми ключами заголовка, которые содержат обычное значение — в примере выше это mid и currency, поэтому конверсия считается по мерчанту и валюте, а не по всей платформе. Ключи заголовка, содержащие массив или объект-оператор ({"range": [...]}, {"gte": ...}), участвуют в отборе правила, но не разделяют группу.

`accepted_only`

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

"dispatching": {
  "method": "conversion",
  "list": ["TEST1", "TEST2", "TEST3"],
  "rate": "1d#approved",
  "accepted_only": true
}

`min_conversion`

По умолчанию выключен. Задаёт порог конверсии в процентах: гейты с оценкой ниже порога исключаются из выбора, платёж уходит в лучший из оставшихся. Гейт с оценкой, равной порогу, остаётся в выборе.

"dispatching": {
  "method": "conversion",
  "list": ["TEST1", "TEST2", "TEST3"],
  "rate": "1d#approved",
  "min_conversion": 30
}

Если ниже порога оказались все гейты, платёж отклоняется сразу, без обращения к какому-либо гейту. Например, при "min_conversion": 30 и лучшей оценке 29% мерчант получает отказ с причиной antifraud: Conversion of every alias is below 30%.

Такой отказ сохраняется как попытка гейта, на который пришёл платёж, но не учитывается в его конверсии: гейт платёж не получал. Иначе каждый отклонённый платёж добавлял бы гейту свежую неудачную попытку, и гейт уже никогда не поднялся бы выше порога.

Значение задаётся числом или строкой с числом от 0 до 100. Некорректное значение ("abc", 150) игнорируется, и порог не применяется.

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

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

{
  "header": { "mid": 81, "acq_alias": "TEST1" },
  "body": { "status": { "not_in": ["declined"] } },
  "routing": { "status:not_in": { "dispatching": true } },
  "action": null,
  "dispatching": {
    "list": ["TEST1", "TEST2", "TEST3"],
    "method": "conversion",
    "rate": "1d#approved"
  }
}

{ "dispatching": true } находит гейт с лучшей конверсией из тех, через которые платёж ещё не проходил. Если задан min_conversion, гейты ниже порога пропускаются; когда подходящих гейтов не осталось, платёж завершается отказом гейта.

Это заменяет цепочку из отдельного правила на каждый переход, которая нужна при статическом routing: порядок определяется конверсией в момент отказа, а не прописывается в правилах.

Диспатчинг

Настройка правил

Метод queue

Метод limit

Метод conversion