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