# Возвраты с проверяемым результатом и правами Источник: https://quicklanding.ru/services/development/commerce/refunds/ Менеджер нажал «вернуть», но запрос ещё не завершён. Клиент ждёт результат, а повторное нажатие может создать путаницу. Разработаем управление возвратами с проверкой исходного платежа, доступной суммы и фактического состояния операции. Компания: QuickLanding Стоимость: 2 900 ₽/час Сроки: По согласованному плану ## Как контролировать возврат и состояние платежа - Запрос принят за окончательный результат: Разделим отправку, обработку и подтверждение по доступным состояниям провайдера. - Возвраты не связаны с исходной оплатой: Сохраним идентификаторы и проверим сумму, чтобы сотрудник действовал по нужной операции. - Повторное действие трудно отследить: Предусмотрим контроль уже созданной операции и согласованный порядок следующей попытки. ## Что добавим в управление оплатами - Схема возврата и состояний: Опишем доступные действия, данные платежа и проверку результата выбранного провайдера. - Управление для сотрудника: Подготовим интерфейс, права и серверные проверки перед выполнением операции. - История и проверка ошибок: Покажем связь с оплатой, актуальное состояние и сведения для разбора проблемного случая. ## Последние проекты QuickLanding и команды Последние проекты QuickLanding покажут работы нашей команды. Логику возврата проверим на вашем процессе с доступными тестовыми операциями и согласованными правами. - [MP CMS — платформа интернет-магазинов](https://quicklanding.ru/projects/mpcms/) - [Магнитоф — магазин неодимовых магнитов](https://quicklanding.ru/projects/magnitof/) - [LP CMS — визуальный редактор лендингов](https://quicklanding.ru/projects/lpcms/) ## Результат возврата виден отдельно Покажите оплату, заказ и действия сотрудника. Уточним полный или частичный возврат, права и нужные состояния. Проверим возможности сервиса и оценим управление операциями. - Сумма не превышает доступную: Учтены исходный платёж и уже подтверждённые возвраты. - Операция имеет исполнителя: Право на действие и необходимый журнал заданы явно. - Запрос не объявлен завершением: Принятие операции и подтверждённый результат различаются. ## Этапы разработки возвратов - Разбираем порядок: Уточняем действия сотрудника и правила согласования. - Проверяем провайдера: Подтверждаем доступные полные и частичные операции. - Создаём управление: Подключаем суммы, права и платёжный запрос. - Проверяем результат: Проходим подтверждение, отказ и неопределённый ответ. ## Стоимость платёжных состояний Разработка возвратов стоит 2 900 ₽/час. Объём зависит от провайдера, частичных операций, структуры заказа, прав сотрудников и проверки состояний. ## Что происходит между запросом и подтверждением Разберём платёжного провайдера, данные заказа и действия сотрудника. Определим доступные операции и состояния, которые нужно показывать в интерфейсе. ## Отмена заказа и возврат являются разными действиями Изменение записи в магазине само по себе не выполняет операцию у платёжного провайдера. Согласуем, как сотрудник выбирает исходную оплату и начинает возврат. Доступность полного или частичного сценария проверим по нужному способу платежа. Бизнес-условия возврата вы определяете отдельно от технического подключения. ## Перед отправкой проверим исходные данные Операция должна относиться к существующему подтверждённому платежу. Уточним сумму и учёт ранее выполненных возвратов. Если заказ был изменён, данные покупки и платёжный результат могут различаться. Предусмотрим понятную проверку, чтобы сотрудник видел основание операции до её запуска. ![Тематическое изображение: Разработка возвратов и статусов платежей](/assets/images/stock-commerce.webp) ## Права проверяются на сервере Определим, кто может просматривать сведения, запрашивать возврат и подтверждать действие, если такое согласование нужно. Интерфейс покажет доступные операции, но ограничения будут проверяться и при обработке запроса. Для важных действий подготовим подтверждение с суммой и ссылкой на исходную оплату. ## Статусы должны отражать ответ провайдера Покажем отправленную, ожидающую и завершённую операцию там, где такие состояния доступны. При ошибке сохраним полезные сведения для разбора. Не будем сообщать клиенту о завершённом возврате только потому, что магазин принял запрос сотрудника. Обновление статуса должно следовать проверенному результату. ## Повтор после сбоя начинается с проверки Если ответ не пришёл, операция могла быть создана на стороне сервиса. Согласуем доступный способ узнать её состояние и допустимые повторы. Журнал поможет связать действия сотрудника и результат, не раскрывая ключи подключения. Кассовые сценарии при необходимости рассмотрим через [интеграцию чеков](/services/development/commerce/receipts/). ## Стоимость реализации Программные работы стоят 2 900 ₽/час. Для оценки нужны провайдер, модель заказа и выбранные операции. Проверим обычный результат, отказ, повтор и доступную частичную обработку. Правила уведомления клиента, документы и дальнейшее сопровождение включим в состав проекта только после отдельного согласования. ### Наведём порядок в операциях после оплаты ## Эксперт Владимир Николаев Владимир Николаев проверит связь возврата с платежом и уже возвращёнными суммами. Отдельно разберём повторный запрос и неопределённый ответ сервиса, прежде чем разрешать новое действие. ## Частые вопросы ### Можно ли добавить возвраты без переделки оплаты? Иногда да. Посмотрим, хранятся ли нужные идентификаторы и доступен ли интерфейс провайдера. Если исходные сведения неполные, потребуется сначала доработать их хранение или обработку. ### Поддерживается ли частичный возврат? Это зависит от провайдера и способа исходной оплаты. Проверим текущую документацию и согласуем доступный сценарий. Частичную операцию не будем считать поддерживаемой только по наличию поля суммы. ### Когда показать клиенту, что возврат завершён? После получения проверяемого результата по согласованному способу провайдера. Принятый запрос и окончательное подтверждение могут быть разными состояниями. Сообщения подготовим с учётом этого различия. ### Как предотвратить случайное повторное действие? Перед запуском проверим уже созданные операции и доступный остаток суммы. Для сбоя с неизвестным результатом предусмотрим проверку состояния. Конкретный механизм зависит от возможностей API. ### Можно ли ограничить возвраты отдельным сотрудникам? Да. Определим права и необходимые подтверждения. Проверка будет выполняться на сервере, чтобы скрытая кнопка не оставалась единственным ограничением действия. ### Возврат автоматически меняет статус заказа? Только по согласованному правилу. Частичный возврат и полный отказ от заказа могут означать разные дальнейшие действия. Разберём связь платёжного результата с вашим процессом отдельно. ## Связанные услуги - [Интеграция онлайн-кассы и чеков](https://quicklanding.ru/services/development/commerce/receipts/index.md) - [Подключение оплаты через СБП](https://quicklanding.ru/services/development/commerce/sbp/index.md) - [Подключение интернет-эквайринга Альфа-Банка](https://quicklanding.ru/services/development/commerce/alfabank/index.md) ## Наведём порядок в операциях после оплаты Покажите текущую систему, провайдера и примеры возвратов. Обсудим полный или частичный сценарий, права и необходимые проверки.