Аналитика платёжной маршрутизации: как сравнивать маршруты без смешивания GEO и банков

Редакция mevrica

Аналитика4 мин чтения

Обновлено 2 августа 2026 г.

Аналитика платёжной маршрутизации отвечает, какой допустимый путь лучше обрабатывает сопоставимый поток с учётом успешности, задержки, стоимости и риска. Сырая таблица approval rate часто вводит в заблуждение: один маршрут получает сложные банки и повторы, другой — первый чистый трафик.

Два grain

Payment intent описывает намерение пользователя. Attempt — конкретную отправку по маршруту. Итог считают по payment_id, техническую работу — по attempt_id.

Событийная схема

CREATE TABLE payment_attempts(
 attempt_id text PRIMARY KEY,
 payment_id text NOT NULL,
 route_id text NOT NULL,
 method_code text NOT NULL,
 issuer_group text,
 geo text NOT NULL,
 amount_minor bigint NOT NULL,
 currency text NOT NULL,
 attempted_at timestamptz NOT NULL,
 outcome_code text NOT NULL,
 latency_ms integer,
 route_rule_version text NOT NULL
);

Не храните лишние реквизиты

Аналитическому слою не нужны PAN, CVV или документы. Используйте токены и агрегированные issuer-группы, ограничивайте доступ и сроки хранения. Архитектуру соответствия подтверждают профильные специалисты.

Базовые метрики

• Payment success по уникальным payment_id
• Attempt approval
• Attempts per payment
• Time-to-success
• Стоимость на успешный payment
• Доли outcome categories

Сопоставимый mix

Стратифицируйте по GEO, method, issuer group, amount band, device, часу и номеру попытки. Для причинного вывода используйте routing experiment среди действительно eligible маршрутов.

WITH ranked AS(
 SELECT *,row_number() OVER(
  PARTITION BY payment_id ORDER BY attempted_at,attempt_id) n
 FROM payment_attempts)
SELECT route_id,geo,method_code,issuer_group,
 count(*) first_attempts,
 avg((outcome_code='approved')::int) approval
FROM ranked WHERE n=1
GROUP BY 1,2,3,4;

Fallback — последовательность

Второй маршрут получает только не прошедшие первый платежи, поэтому его raw approval несопоставим. Оценивайте policy целиком: success within N attempts, time-to-success, cost и прекращение пути.

Reason taxonomy

Разделяйте timeout, route unavailable, issuer decline, insufficient funds, invalid data, policy и unknown. Retry выполняется только там, где допускается правилами и безопасностью.

Эксперимент маршрутизации

1. Определить eligible set
2. Рандомизировать по payment_id
3. Сохранить allocation version
4. Установить safety limits
5. Считать зрелый payment success
6. Проверить refunds и reversals

Не оптимизируйте только первый approval

Учитывайте зрелый результат, стоимость, reversal и ограничения.

Источники и границы применимости

PCI SSC Tokenization Guidelines: https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf

Стандартизация результата

Чтобы сравнить маршруты при разном mix, выберите эталонное распределение GEO × issuer group × method × amount band. Для каждого маршрута оцените условный success внутри ячейки, затем примените одинаковые веса. Raw и standardized показатели показываются рядом: расхождение между ними объясняет преимущество состава.

standardized_success(route) =
  sum_segment(reference_weight_segment
              * success_rate_route_segment)

Ячейки без достаточной поддержки не экстраполируются молча.

Последовательные эффекты fallback

Первая неудачная попытка может изменить вероятность следующей: пользователь исправляет данные, банк применяет ограничение, истекает сессия или повтор выглядит подозрительно. Поэтому анализ sequence policy учитывает порядок, интервал и outcome предыдущего шага. Независимое умножение средних approval маршрутов даёт неверную оценку.

Reconciliation с финансовым слоем

Approved response ещё не равен settled движению. Свяжите attempt с payment ledger и поздними reversal/refund, не перезаписывая исходный outcome. Для каждой валюты сверяйте count, amount_minor, fee и settlement date. Только зрелая сверка подходит для сравнения фактической стоимости маршрутов.

Безопасная эксплуатация эксперимента

• Рандомизировать только между реально допустимыми маршрутами
• Исключить чувствительные реквизиты из experiment log
• Остановить ветку при росте технических ошибок
• Не повторять необратимый или запрещённый outcome
• Сохранить route_rule_version в каждой попытке
• Проверить возвраты после полного окна зрелости

Если маршрут имеет мало данных в редкой ячейке, объединяйте только бизнес-сопоставимые группы и показывайте неопределённость. Агрессивное pooling банков или GEO создаёт уверенность за счёт чужого потока и переносит решение туда, где оно не проверялось.

Вывод

Корректная routing analytics разделяет намерение и попытку, сравнивает одинаковый mix и оценивает fallback policy. Токенизированный ledger и стабильные reason codes позволяют улучшать маршрут без лишних данных и ложных лидеров.