Как снизить операционную нагрузку в процессинге платежей

Платёжная инфраструктура редко становится нестабильной из-за одной крупной проблемы. Гораздо чаще сложность накапливается постепенно:

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

По отдельности такие ситуации могут казаться незначительными. Но со временем именно они создают нагрузку на интеграции, поддержку, risk-команды и самих мерчантов. Последние обновления Checkout и Gateway infrastructure сфокусированы именно на этих слоях платёжной инфраструктуры — не на добавлении новой сложности, а на переводе большей части этой сложности в предсказуемое поведение системы.

Более гибкая работа с данными транзакций

В запросах на создание токена, а также в Gateway (payment, payout, authorization) теперь можно использовать до трёх дополнительных пользовательских полей. Технически это небольшое обновление. Но с операционной точки зрения оно закрывает очень распространённую проблему PSP.

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

Теперь такую информацию можно передавать напрямую внутри транзакционного запроса. Для платежей через виджет также появилась возможность собирать дополнительную информацию от покупателя на этапе подтверждения оплаты через специальные поля на странице платежа.

Для PSP и банков-эквайеров из Центральной Азии это особенно важно, поскольку локальные платёжные сценарии и требования бизнеса часто требуют более гибкой передачи данных внутри транзакционного потока.

Более прозрачная диагностика ошибок провайдеров

Ещё одно обновление касается логики обработки ошибок и диагностики транзакций. Ранее, если для ошибки провайдера отсутствовал маппинг, система возвращала код F.0999, параметр message содержал стандартный ответ, а оригинальный текст ошибки провайдера часто оставался недоступным.

Для PSP это создавало типичную ситуацию: транзакция не прошла, но реальная причина оставалась скрытой где-то между логикой провайдера и внутренней обработкой системы. Теперь логика изменилась.

Большинство мерчантов даже не заметят это обновление напрямую. Но для операционных и технических команд PSP оно значительно ускоряет анализ проблем. Когда PSP работают одновременно с несколькими банками, локальными методами оплаты и различными processing channels, универсальные ошибки быстро создают «слепые зоны». Передача оригинального контекста ошибки напрямую внутри транзакционного потока делает диагностику быстрее и предсказуемее.

Новая логика каскадинга для H2H-транзакций

Ключевое обновление этого релиза — новое решение для каскадных host-to-host карточных транзакций. Ранее платформа уже поддерживала каскадные платежи: мерчант мог вручную повторить неуспешную транзакцию, исключив failed gateway через additional_data.excluded_gateways. Для платежей через виджет также уже существовали автоматические retry-механизмы.

Теперь логика каскадинга стала частью самой платформы. Если для магазина активирована опция «Включить каскадные платежи (h2h)», а также подключено несколько карточных шлюзов, система сможет автоматически повторить оплату через другой доступный gateway без дополнительных запросов со стороны мерчанта.

При этом:

• мерчант получает только финальный результат транзакции;
• покупатель получает только одно итоговое email-уведомление;
• все попытки транзакций сохраняются в back office и отчётности.

Почему это важно

Это важно, потому что каскадинг — это не просто retry-механизм. Для многих PSP, особенно работающих в high-risk сегментах, маршрутизация платежей существует внутри постоянно меняющейся среды:

• одни каналы теряют стабильность под нагрузкой;
• approval rates меняются в течение дня;
• отдельные банки начинают отвечать медленнее в peak-hours;
• некоторые шлюзы становятся нестабильными для определённых BIN, регионов или типов карт.

В таких условиях ручное управление retry-логикой быстро превращается в хрупкий слой дополнительной операционной нагрузки вокруг платёжного потока. Новая h2h cascading logic позволяет платформе автоматически забирать часть этой нестабильности на себя.

Управление приоритетом шлюзов через Smart Routing

Если PSP необходимо задать приоритеты шлюзов, последовательность обработки можно настроить через Smart Routing. Для этого используется:

тип потока правил: Object
метод:            Sequential

После этого PSP может выстроить последовательность gateway rules в нужном порядке и задать собственную routing-логику. Даже простых условий достаточно для настройки последовательного каскадинга, хотя при необходимости можно использовать и более сложные сценарии маршрутизации. На текущий момент решение поддерживает:

• карточные payment-транзакции;
• рекуррентные платежи;
• транзакции с 3-D Secure и без него.

Зрелость платёжной инфраструктуры строится не только на новых функциях

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

• делают диагностику прозрачнее;
• маршрутизацию — стабильнее;
• интеграции — чище;
• retry-логику — менее хрупкой;
• а операционные процессы — более предсказуемыми.