Возврат оплаты через сайт: кто запускает операцию и как проверить её результат

Отмена заказа и возврат денег выполняют разные задачи

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

Рассмотрим магазин с оплатой через ЮKassa и сервисом «Чеки от ЮKassa». Возможность запустить возврат с сайта зависит от того, как сайт связан с платёжным сервисом. Если такой функции нет, просьбу покупателя всё равно нужно связать с конкретным платежом, а сотруднику поддержки — дать сведения о том, что уже сделано с деньгами и кто продолжает работу. Покупатель обращается по заказу, но движение денег выясняют по оплате этого заказа. Для других платёжных сервисов и касс потребуется свой порядок: особенности ЮKassa помогают поставить задачу для этого подключения, а не описывают любую систему оплаты.

Номер заказа помогает найти покупку. Для движения денег нужны сведения именно о выбранном платеже.

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

Решение, запуск и контроль результата разделяются

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

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

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

Отправленную заявку на возврат в кабинете ЮKassa отменить нельзя. Поэтому выбранные платёж и сумму подтверждают до запуска. После отправки история обращения должна показывать, кто уже выполнил действие и кому передана дальнейшая работа, особенно если клиент пишет разным сотрудникам.

Сумма привязана к платежу и возвращаемой части покупки

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

Ниже учебный расчёт частичного возврата. Пример показывает остаток после выполненной операции и не описывает покупку клиента.

Если раньше часть оплаты уже возвращали, сотруднику нужна эта история. В ЮKassa общая сумма частичных возвратов не превышает сумму исходного платежа. Без этой истории новая сумма будет сравниваться с первоначальным платежом, хотя завершённые частичные возвраты уже уменьшили остаток, который можно вернуть. При возврате отдельных позиций важно связать сумму с их составом или с принятым способом расчёта, чтобы операция с деньгами и документ описывали одно изменение покупки, а не два разных решения по одному заказу. Оставшиеся деньги сохраняются в учёте как невозвращённая часть. Поэтому отметка о частичном результате должна помогать следующему сотруднику продолжить работу, не создавая впечатления, что вся оплата уже возвращена.

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

Как отличить принятие запроса от завершения возврата

Принятие запроса и завершение возврата — разные события. В кабинете ЮKassa сообщение об отправке заявки подтверждает действие сотрудника. Результат выясняют по заявке на странице возвратов и по обновлённому состоянию платежа. Сайт сохраняет связь с нужной операцией.

Обновление статуса и получение денег различаются. Первое показывает сведения сервиса, второе зависит и от дальнейшего зачисления покупателю.

В кабинете ЮKassa обновление статуса иногда занимает до 20 минут. Это время отображения данных, а не обещание банковского зачисления. Если сотрудник сообщит покупателю тот же интервал как срок получения денег, внутреннее ожидание обновления превратится в неверное обещание, хотя магазин ещё не получил сведения о завершении операции или о дальнейшем ходе зачисления. В ответе полезно назвать подтверждённое состояние и объяснить, кто продолжает выяснение. Конкретный срок получения нельзя выводить из времени обновления кабинета.

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

Повторять зависший возврат без выяснения опасно

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

Повторное обращение клиента продолжает существующую работу. Оно не должно выглядеть для другого сотрудника как первая просьба вернуть деньги.

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

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

Чек и состояние денег проверяют раздельно

Чек сопровождает операцию с деньгами, но не подменяет её результат. В выбранном сервисе «Чеки от ЮKassa» полный возврат использует данные исходного платежа. Поэтому для него важно содержание сведений, переданных при первоначальной оплате.

При частичном возврате данные чека передаются вместе с запросом. Они описывают ту часть покупки, по которой магазин принял решение.

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

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

Испытайте завершение, ожидание и частичную сумму

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

• Полномочия соответствуют работе. Запуск доступен выбранному сотруднику, а коллега видит сведения, нужные для ответа. Помощь с заказом не даёт лишнего права распоряжаться деньгами.
• Возврат связан с оплатой. Видны конкретный платёж, выбранная сумма и прежние возвраты. Общий итог заказа не скрывает историю денег.
• Ожидание остаётся под контролем. Сотрудник видит, что запрос принят, но результат ещё выясняется, и знает ответственного за продолжение.
• Частичная сумма сохраняет остаток. Деньги, состав возвращаемой части и документ относятся к одному расчёту. Заказ не выглядит полностью возвращённым после одной частичной операции.
• Повтор не создаёт новую операцию по тому же решению. Существующий запрос виден до новой отправки, включая действия из кабинета ЮKassa.
• Причина отмены или ошибки передана ответственному. Поддержка может объяснить дальнейшую работу, вместо сообщения о завершении по внутренней отметке.
• Конечный результат согласуется с учётом. Сведения сервиса и состояние на сайте описывают одну операцию, а документ рассматривается отдельно.

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

Откройте возврат, по которому клиент ещё ждёт ответ

По возврату, о котором клиент снова спрашивает, видно, какой запрос уже отправлен? Понятно, кто продолжает работу и что подтверждено сервисом? Запросите сведения конкретной операции.

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

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