# Выбор платёжной системы: какие требования собрать до подключения

Источник: https://quicklanding.ru/knowledge/payment-provider-choice/

Как выбрать платёжную интеграцию для сайта: сценарии заказа, возвраты, уведомления, готовый модуль и стоимость сопровождения. Требования до оценки разработки.

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

## Разберите реальный путь заказа

![Оплата смартфоном через терминал](/assets/images/knowledge/payment-provider-choice.webp)

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

Представьте мастерскую, где клиент выбирает ремонт, но точный объём становится известен после диагностики. Оплата предварительной записи, аванс и окончательный расчёт здесь разные действия. Не объединяйте их в один статус только потому, что на сайте будет одна кнопка. У каждого действия должно быть понятное назначение и связь с заказом.

## Составьте обязательные сценарии

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

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

## Оцените готовый модуль на вашем сайте

Проверьте совместимость с версией CMS, темой, страницей оформления и другими расширениями. Смотрите, кто сопровождает модуль и как выпускаются изменения. Для нестандартного заказа может понадобиться доработка даже при наличии официального плагина. Запишите, какие действия уже покрыты модулем, а какие останутся отдельным кодом.

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

## Учитывайте сопровождение после подключения

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

| Вопрос при выборе | Что получить до разработки |
| --- | --- |
| Нужный сценарий оплаты | Подтверждение доступности и документацию |
| Возврат | Порядок действий и связь с заказом |
| Уведомления | Способ подтверждения результата на сервере |
| Сопровождение | Ответственного за модуль и изменения |

## Подготовьте критерии приёмки

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

До передачи задачи согласуйте данные для расчётных документов с ответственным сотрудником и требования провайдера. Разработчик реализует согласованный состав, но не должен угадывать назначение платежа и правила бизнеса. Удобный результат выбора выглядит как короткое техническое задание с проверяемыми сценариями, а не как обещание подключить любую оплату за одинаковый срок.

## Связанные материалы

[Проверка оплаты: успешный платёж, отказ, повтор и возврат](/knowledge/payment-test-scenarios/)

[Оплата прошла, заказ не обновился: как сверять состояния](/knowledge/payment-status-reconcile/)

[Регулярные платежи: какие правила согласовать до разработки](/knowledge/subscription-payment-scope/)

## Частые вопросы

### Достаточно сравнить только комиссию платёжных систем?

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

### Если есть готовый плагин, доработка точно не понадобится?

Готовый модуль покрывает определённые сценарии. Особая логика заказа, нестандартное оформление или интеграция с учётной системой могут потребовать отдельной работы.

### Почему нужно проверять оплату без возврата покупателя на сайт?

Покупатель может закрыть вкладку после платежа. Магазин должен узнать результат через предусмотренный серверный механизм и сопоставить его с заказом.

Автор: Владимир Николаев