РАЗРАБОТКА ПРОГРАММНОГО ЭМУЛЯТОРА ПЛАТЁЖНОГО ШЛЮЗА ДЛЯ ТЕСТИРОВАНИЯ УСТАРЕВШИХ ПЛАТЁЖНЫХ API

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

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

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

В технической практике для подобных задач применяются подходы API mocking и service virtualization, которые позволяют имитировать поведение внешних сервисов и тестировать систему при недоступности реального API [1; 2]. Однако универсальные mock-инструменты чаще всего возвращают заранее заданные HTTP-ответы. Для платёжного сценария этого недостаточно, поскольку он включает последовательность связанных действий: регистрацию заказа, формирование идентификатора платежа, создание ссылки на оплату, отображение страницы оплаты, изменение статуса операции и возврат пользователя во внешнюю систему.

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

Ссылка на страницу оплаты формируется по правилу:

FormUrl = X + Y + Z,

где X — базовый адрес эмулятора платёжного шлюза, Y — путь к странице оплаты, Z — параметр запроса, содержащий идентификатор платежа orderId.

После регистрации сведения о платеже сохраняются в базе данных SQLite. Для каждой операции фиксируются идентификатор платежа, сумма, адрес успешного возврата, адрес неуспешного возврата, статус операции, дата создания и дата обновления записи. Использование SQLite обосновано локальным характером эмулятора, так как система предназначена для тестирования и не требует сложной серверной базы данных [3].

При переходе пользователя по ссылке formUrl эмулятор получает orderId, находит соответствующую запись в базе данных и формирует HTML-страницу оплаты. На странице отображаются сведения о платеже и доступны варианты успешного или неуспешного завершения операции. При успешном сценарии статус изменяется на paid, при неуспешном — на failed. После этого пользователь перенаправляется на соответствующий адрес возврата.

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

Архитектура программного продукта построена по модульному принципу. В системе выделены точка входа приложения, модуль конфигурации, контейнер зависимостей, HTTP-обработчики, модуль парсинга и валидации данных, модуль генерации идентификатора платежа, модуль доступа к хранилищу и HTML-шаблоны. Такое разделение упрощает сопровождение программы и отделяет бизнес-логику платёжного сценария от инфраструктурных задач.

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

Таким образом, программный эмулятор платёжного шлюза позволяет безопасно тестировать устаревшие платёжные интеграции. В отличие от универсальных mock-сервисов, он воспроизводит не только отдельный HTTP-ответ, но и основную последовательность платёжного процесса. Использование такого решения снижает риски модернизации, уменьшает зависимость от внешнего провайдера и позволяет проверять работу платёжной логики без выполнения реальных денежных операций.