Routing & Cascading в PayStar: бизнес-кейсы и настройка

1) Что даёт Routing & Cascading

Routing & Cascading — это “движок управления трафиком”, который позволяет:

Повышать конверсию: направлять платежи туда, где выше approval/скорость/качество.

Соблюдать требования PSP: лимиты по попыткам, объёму и качеству трафика.

Снижать риски: квоты на “недоверенные” PSP, ограничение оборота, пилотирование.

Повышать устойчивость: fallback при деградации, росте processing/failed, быстрое отключение каналов без переписывания интеграции.

Сегментировать трафик: FTD/STD, продуктовые витрины, время, суммы, валюта, issuer и т.д.

2) Топ кейсов (готовые рецепты)

Anti-spam: PSP не хочет “спама” неуспешными попытками

Идея: много failed/processing за короткое окно → ведём в альтернативный PSP.

Рекомендуемые настройки в Payment details:

aggregationType = CountUnSuccess

property = payeerIdentifier

period = 1 hour

operation >=

value = 3

Ветки:

CountUnSuccess >= 3 → PSP-B

CountUnSuccess < 3 → PSP-A

Пример

PSP принимает пользователя не больше 3 раз в день

PSP принимает пользователя на 5000 USD за неделю

Разделение трафика: FTD (первичный) vs STD (повторный)

Пересекающиеся диапазоны сумм у PSP (50–500 и 100–700)

Деградация PSP: растёт processing/failed

“Недоверенная” PSP: лимитируем по квоте/обороту

Пилотирование PSP на сегменте

3) Где это настраивается в UI

3.1 Раздел Merchants

3.2 Карточка мерчанта и список пайплайнов

4) Конструктор условий: Add pipeline condition (таблица полей + примеры)

Зачем нужен: вы задаёте “правило отбора” (условие), по которому платёж попадёт в ветку/маршрут.

4.1 Поля условия (Attribute / Operation / Value)

Поле	Что это	Как заполнять	Пример
Attribute	Что проверяем (сумма, валюта, время, issuer и т.д.)	Выберите из списка (см. таблицу ниже)	`Payment amount`
Operation	Как сравниваем	`>`, `>=`, `<`, `<=`, `==`, `!=`, диапазоны `(a-b)` / `[a-b]`	`<=`
Value	Порог/значение для сравнения	Зависит от Attribute: число, код валюты, диапазон, окно времени	`500`

4.2 Attribute: список доступных параметров (с пояснением и примером)

Attribute (UI)	Смысл	Формат Value	Типовой бизнес-кейс	Пример условия
Payment amount	Сумма текущего платежа	Число (в основных единицах) или диапазон	Развести PSP по диапазонам сумм	`Payment amount` `>=` `100`
Payment currency	Валюта платежа	ISO-код: `USD`, `EUR`, `INR` и т.п.	Разные PSP под разные валюты	`Payment currency` `==` `USD`
Payment created at — time	Окно времени суток	Время/диапазон времени (как в UI)	“Дневной”/“ночной” провайдер, SLA по времени	`time` в диапазоне `10:00–17:00`
Payment created at — day, time	Окно по дате+времени	Два timestamp (как в UI)	Промо-период / пилот на конкретные даты	`2026-01-01 10:00 … 2026-01-30 17:00`
Product code	Код продукта/витрины, который передаёт мерчант	Строка	Разделение трафика по продуктам	`Product code` `==` `CASINO`
Card issued bank	Банк-эмитент карты	Строка/enum (как в UI)	PSP-A лучше по конкретному issuer	`Card issued bank` `==` `HDFC`
Card issued payments processing	Платёжная система карты (scheme)	Enum/строка (как в UI)	Разные PSP под Visa/Mastercard	`processing` `==` `VISA`
Card issued country	Страна эмитента карты	ISO-код страны / enum	GEO-ограничения/правила по стране эмитента	`country` `==` `IN`
Telecom operator	Оператор связи (carrier)	Строка/enum	Правила под мобильные сценарии/методы	`operator` `==` `Airtel`
Payment details	Условие по истории платежей (агрегация)	Отдельная форма (см. раздел 5)	Anti-spam, лимиты по попыткам/объёму, FTD/STD	`CountUnSuccess >= 3 за 1 час`

Примечание по времени: условия Payment created at — time / day, time применяются в часовой зоне организации/команды.

4.3 Operation: доступные операции сравнения (с примерами)

Operation	Смысл	Пример (на сумме)	Когда использовать
`>`	строго больше	`amount > 500`	VIP/High-value ветка
`>=`	больше или равно	`amount >= 100`	минимальный порог
`<`	строго меньше	`amount < 100`	микроплатежи
`<=`	меньше или равно	`amount <= 500`	верхний предел
`==`	равно	`currency == USD`	точное совпадение
`!=`	не равно	`currency != EUR`	исключение
`(a-b)`	между, без границ	`amount (100-500)`	когда границы исключаются
`[a-b]`	между, включая границы	`amount [100-500]`	когда границы включаются

4.4 Пример “простого” правила (без истории)

Кейс: PSP-A работает для сумм 50–500, PSP-B для 100–700.
Решение: создайте ветки по Payment amount, а в перекрытии добавьте каскад.

Пример веток:

amount < 100 → PSP-A

100 <= amount <= 500 → PSP-A → PSP-B

amount > 500 → PSP-B

5) Payment details (агрегация истории): подробная таблица полей + примеры

Зачем нужен: “смотреть назад” и принимать бизнес-решение по истории плательщика: anti-spam, лимиты по попыткам, лимиты по объёму, FTD/STD.

5.1 Поля Payment details (каждое поле простыми словами)

Поле	Смысл (простыми словами)	Формат/значения	Пример
Aggregation type (`aggregationType`)	Что именно считаем по истории	`Count` или `Sum` (см. таблицу ниже)	`CountUnSuccess`
Property (`property`)	По какому “ключу” объединять историю (кого считаем одним плательщиком)	`payeerIdentifier`, `email`, `ip`, `cardToken`, `phoneNumber`, …	`payeerIdentifier`
Period (`periodSeconds`)	За какой период назад смотреть историю	Секунды или человекочитаемый выбор в UI	`3600` (1 hour)
Direction type (`directionType`)	Какие операции учитывать	`Deposit`, `Withdrawal`, `Inherit`	`Deposit`
Entity type (`entityType`)	Где искать историю	`Pipeline` (только текущий) или `Partner` (все пайплайны партнёра)	`Partner`
Operation (`operation`)	Как сравнить метрику с порогом	`>`, `>=`, `<`, `<=`, `==`, `!=`, диапазон	`>=`
Value (`value`)	Порог сравнения	Для `Count` — число попыток, для `Sum` — сумма	`3`

Важно:

текущий платёж в расчёт не включается;

если истории нет — метрика считается 0.

5.2 Aggregation type: что означает каждая метрика

aggregationType	Что считает	Простое объяснение	Пример кейса
`CountTotal`	Кол-во всех (success + failed + processing)	“Сколько раз пытались платить”	лимит попыток в сутки
`CountSuccess`	Кол-во успешных	“Сколько раз получилось”	FTD/STD, trust level
`CountFailed`	Кол-во failed	“Сколько явных отказов”	анти-ретрай по отказам
`CountUnSuccess`	failed + processing	“Сколько не доведено до успеха”	anti-spam + ловля подвисаний
`SumTotal`	Сумма всех	“Сколько всего оборота (любые статусы)”	редкий сценарий
`SumSuccess`	Сумма успешных	“Сколько реально прошло”	лимит 5000 USD/нед
`SumFailed`	Сумма failed	“Сколько отказов на сумму”	риск-правила
`SumUnSuccess`	Сумма failed + processing	“Сколько зависло/неуспешно на сумму”	деградации/риски

6) Webhooks: Callbacks

Ключевые моменты:

callbackUrl можно передавать динамически в запросе (приоритет над статическим);

“задним числом” коллбеки не отправляются, если URL/события не были настроены заранее;

ретраи — Fibonacci backoff с шагом 7 минут, до ~27 часов.

можно настроить типы уведомлений - о мене статуса (created, processing, success, failed) и об изменении суммы платежа (актуально в ряде случаев)

Callbeck tech doc

Подробнее о Callbacks можно прочитать здесь: https://apidoc.paystar.uk/callbacks

7) Интеграция: Keys, Required fields, cURL example

7.1 Keys

Ключевые моменты:

вызываются в модальном окне по клику на "замочке" на строке пайплайна;

можно сгенерировать заново - старые ключи перестанут действовать;

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

API Key tech doc

Подробнее о Authorization key можно прочитать здесь: https://apidoc.paystar.uk/authorization

7.2 Обязательные поля

Ключевые моменты:

точный список обязательных полей зависит от настроек пайплайна - фактически, это супер-позиция полей, запрашиваемых банками и платежнвми шлюзами из данного пайплайна;

обязательные поля передаются в теле запроса в поле Additional Fields.

Additional Fields tech doc

Подробнее о Additional Fields можно прочитать здесь: https://apidoc.paystar.uk/additionalfields

7.3 cURL example

Ключевые моменты:

для простоты интеграции, вы можете получить пример готового запроса, с уже собранными объзательными полями и вторизационным токеном

8) Диагностика

8.1 Платёж не проходит из-за правил/лимитов

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

9) Best practices (коротко)

Всегда держите альтернативную ветку для fallback.

Для anti-spam и деградаций удобно использовать CountUnSuccess.

Для FTD/STD используйте CountSuccess == 0.

Для пилота — сегмент по сумме/времени/FTD или отдельный Pilot pipeline.

Для Sum* правил избегайте смешения валют.

Мавршрутизация и Каскады

1) Что даёт Routing & Cascading#

2) Топ кейсов (готовые рецепты)#

3) Где это настраивается в UI#

3.1 Раздел Merchants#

3.2 Карточка мерчанта и список пайплайнов#

4) Конструктор условий: Add pipeline condition (таблица полей + примеры)#

4.1 Поля условия (Attribute / Operation / Value)#

4.2 Attribute: список доступных параметров (с пояснением и примером)#

4.3 Operation: доступные операции сравнения (с примерами)#

#

4.4 Пример “простого” правила (без истории)#

5) Payment details (агрегация истории): подробная таблица полей + примеры#

5.1 Поля Payment details (каждое поле простыми словами)#

5.2 Aggregation type: что означает каждая метрика#

6) Webhooks: Callbacks#

7) Интеграция: Keys, Required fields, cURL example#

7.1 Keys#

7.2 Обязательные поля#

7.3 cURL example#

#

8) Диагностика#

8.1 Платёж не проходит из-за правил/лимитов#

9) Best practices (коротко)#

1) Что даёт Routing & Cascading

2) Топ кейсов (готовые рецепты)

3) Где это настраивается в UI

3.1 Раздел Merchants

3.2 Карточка мерчанта и список пайплайнов

4) Конструктор условий: Add pipeline condition (таблица полей + примеры)

4.1 Поля условия (Attribute / Operation / Value)

4.2 Attribute: список доступных параметров (с пояснением и примером)

4.3 Operation: доступные операции сравнения (с примерами)

4.4 Пример “простого” правила (без истории)

5) Payment details (агрегация истории): подробная таблица полей + примеры

5.1 Поля Payment details (каждое поле простыми словами)

5.2 Aggregation type: что означает каждая метрика

6) Webhooks: Callbacks

7) Интеграция: Keys, Required fields, cURL example

7.1 Keys

7.2 Обязательные поля

7.3 cURL example

8) Диагностика

8.1 Платёж не проходит из-за правил/лимитов

9) Best practices (коротко)