Оплата на сайте: что решить до разработки
Какие способы оплаты, статусы, повторные попытки и возвраты описать до разработки магазина. Как проверить путь заказа без ложного подтверждения платежа.
До подключения оплаты на сайте нужно определить не только способы платежа, но и весь путь заказа: когда проверяется наличие, какая сумма подтверждается, что видит покупатель при ожидании и кто разбирает ошибки. Кнопка «Оплатить» — лишь один шаг. Если остальные решения оставить на конец разработки, менеджеру придётся вручную сопоставлять заказы и платежи.
Ниже — технические вопросы для подготовки интернет-магазина на 1С-Битрикс. Конкретные условия подключения, расчётов и работы с чеками согласуйте с платёжным провайдером и бухгалтером. Здесь речь о поведении сайта, а не о выборе финансового продукта или юридической схеме торговли.
Определите момент оплаты и состав суммы
Начните с обычного заказа. Товар точно есть на складе или менеджер сначала подтверждает наличие? Доставка рассчитывается сразу или после согласования адреса? Можно ли заменить отсутствующую позицию? Ответы определяют, когда сайт предлагает оплату и какую сумму считает окончательной.
Составьте один понятный сценарий: покупатель выбирает товары, указывает доставку, видит итог, подтверждает заказ и переходит к оплате. Если бизнесу нужны другие пути, опишите их отдельно. Например, заказ с предварительным подтверждением менеджером не должен случайно предлагать немедленную оплату неподтверждённой суммы.
Для каждого способа платежа укажите, где покупатель завершает действие и куда возвращается. Не включайте все доступные способы только потому, что они есть в интерфейсе провайдера. Сначала подтвердите их необходимость для ваших покупателей и доступность в вашем подключении.
В техническом задании зафиксируйте, откуда берётся итоговая сумма и когда она перестаёт изменяться. Если после создания платежа меняются товары или доставка, нужен согласованный сценарий пересчёта. Менеджер не должен править заказ так, что в магазине отображается одна сумма, а в платёжной системе — другая.
Разделите статус заказа и статус платежа
«Заказ принят», «оплачен» и «передан в доставку» — разные события. Отдельно храните состояние оплаты и этап обработки заказа. Тогда товар можно собрать после согласованного подтверждения оплаты, а не после любого возвращения покупателя на сайт.
Например, в API ЮKassa pending означает ожидание, succeeded — успешное завершение платежа, canceled — отмену. При двухстадийной схеме есть waiting_for_capture: деньги авторизованы и ожидают списания. Поддержку такой схемы и конкретные переходы нужно сверять с выбранным способом оплаты.
Возврат браузера на страницу магазина сам по себе не подтверждает результат. Покупатель может закрыть вкладку или вернуться раньше, чем сайт получит окончательный статус. Для экрана ожидания подготовьте честный текст: платёж проверяется, номер заказа сохранён, повторять оплату пока не требуется.
Опишите, что разрешено менеджеру в каждом состоянии. Кто может подтвердить сборку, отменить заказ или инициировать возврат? Как он увидит, что данные ещё проверяются? Эти правила особенно важны, когда с заказом одновременно работают сайт, учётная система и сотрудник.
Предусмотрите повторы, уведомления и возвраты
Серверные уведомления провайдера позволяют обновлять статус без открытой вкладки покупателя. В ЮKassa обработчик должен проверять актуальность и подлинность полученных сведений по рекомендациям документации. Повторное уведомление не должно создавать вторую отгрузку или повторно отправлять одно и то же поручение менеджеру.
При сетевой ошибке нельзя считать платёж неуспешным только потому, что сайт не дождался ответа. Сначала требуется проверить результат операции. В ЮKassa для повторов запросов используется ключ идемпотентности: одинаковые данные с прежним ключом распознаются как повтор в течение 24 часов после первого запроса. Новый ключ означает новую операцию; это не универсальная защита на уровне всего заказа.
Отдельно опишите отмену и возврат. В API ЮKassa платёж в waiting_for_capture можно отменить, а после succeeded оформляют возврат. В интерфейсе магазина эти действия не следует объединять в кнопку с неясными последствиями. Согласуйте полный и, если нужен, частичный возврат, ответственного сотрудника и отображение результата.
Условия для покупателей вашего магазина готовятся под вашу деятельность. Опубликованные на моём сайте условия возврата оплаты за услуги разработки относятся к моим услугам: их нельзя переносить в товарный магазин как готовый шаблон.
Проверьте сценарии до запуска
Для приёмки подготовьте не только успешный платёж, но и ситуации, в которых покупатель не знает, что произошло:
- он отменил действие на платёжной странице;
- закрыл вкладку после подтверждения;
- нажал кнопку повторно при медленной сети;
- вернулся на сайт до обновления статуса;
- уведомление пришло повторно;
- сотрудник оформил согласованный возврат.
Для каждого теста запишите ожидаемые данные в заказе, сообщение покупателю и действие менеджера. Сверяйте результат с платёжной системой, а не только с надписью на экране. Проверки проводятся в предусмотренном провайдером тестовом режиме; реальные операции требуют отдельного согласования.
Чтобы оценить разработку, достаточно описать обычный заказ и исключения из него. Я уточню доступное подключение, обмен статусами и работу сотрудников, затем подготовлю оценку оформления заказа. Это позволяет обсуждать конкретный процесс, а не абстрактную «интеграцию оплаты».