Платежная интеграция: что проверить перед запуском?

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

Подготовка к проверке

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

Шесть обязательных сценариев приемки

1. Успешная оплата: сумма совпадает, покупатель видит подтверждение.
2. Отказ: заказ не становится оплаченным, сообщение понятно.
3. Прерванный процесс: покупатель закрыл окно, команда может проверить состояние.
4. Позднее подтверждение: промежуточный статус корректен до получения результата.
5. Повторное уведомление: та же операция не создает второй заказ или повторное исполнение.
6. Расхождение статусов: успешная операция у провайдера сопоставляется с записью сайта.

Возврат браузера и подтверждение сервера

Открытие страницы благодарности само по себе не доказывает оплату. Подтверждение проверяется по правилам серверного уведомления или запроса статуса выбранного провайдера. Например, документация Stripe объясняет проверку источника webhook, повторные события и доставку уведомлений. Это пример архитектуры, а не рекомендация банка или утверждение о доступности сервиса. Документация Stripe о webhook.

Повторная попытка

После обрыва связи покупатель может нажать кнопку еще раз. Заранее определите связь существующей операции с новой попыткой. Подход к безопасному повторению действия называется идемпотентностью; смысл ключа и срок хранения зависят от поставщика. Описание идемпотентных запросов Stripe показывает один вариант. Не переносите его правила на другого провайдера без проверки.

Нужен ли возврат средств?

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

Протокол приемки

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

Материалы по теме

• Интеграция платежной системы
• План запуска магазина
• Обмен заказом между системами
• Требования к платежному проекту

Дополнительная проверка перед решением

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

Сохраняйте тестовые идентификаторы без персональных карточных данных. При расхождении команда должна понять этап остановки операции.

Пример сценария

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

Следующий шаг по теме

• Интеграция платежной системы
• Система управления e-commerce заказами
• План запуска интернет-магазина: от товара до заказа
• Сайт, CRM и склад: как передается заказ?