Оплата через СБП на сайте: как устроен путь заказа и что проверить

Почему списание денег ещё не закрывает задачу магазина

Деньги списались, а заказ на сайте всё ещё ждёт оплаты — что делать покупателю? В рабочем магазине такой вопрос должен решаться по номеру заказа и данным платежа. Для подключения СБП мало разместить QR-код: нужно связать оплату с заказом, показать человеку результат и дать сотруднику способ разобраться в задержке. Разберём этот путь от кнопки оплаты до возврата.

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

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

За QR-кодом начинается обмен сведениями о платеже. Даже идеально читаемое изображение не объясняет, как магазин узнает о поступлении денег, если покупатель закроет браузер сразу после подтверждения в банке.

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

Что видно до подтверждения в банке

На странице оплаты покупатель сначала сверяет заказ: товары, итоговую сумму и получателя. Затем переходит к оплате. В описании НСПК для интернет-магазина перечислены номер заказа, состав покупки и сумма, а способы перехода включают QR-код, платёжную кнопку и ссылку в приложение банка. Это указано в ответах об оплате через СБП.

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

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

НСПК различает код с суммой и статический код со свободной суммой, которую вводит плательщик. Этот факт объяснён в справке для бизнеса. Выбор вида кода нужно обсуждать с банком применительно к оформлению заказов, а не переносить на сайт первую попавшуюся платёжную наклейку.

Телефон и компьютер требуют разного перехода

На компьютере QR-код удобно отсканировать телефоном. На смартфоне покупатель уже смотрит на экран, с которого нужно перейти в банк, поэтому одна большая картинка заставляет его искать обходной путь. Здесь полезны кнопка и ссылка. НСПК описывает сценарий с кнопкой «Оплата через СБП»: пользователь выбирает банк, переходит в его приложение и подтверждает операцию.

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

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

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

Подключение начинается с договора и возможностей партнёра

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

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

У кода есть срок действия. Для динамического QR-кода НСПК указывает диапазон от 5 минут до 90 дней и значение по умолчанию 3 дня. Конкретное решение интернет-магазина может задавать более узкие условия, поэтому исполнитель называет срок из документации выбранного банка или партнёра и показывает поведение после его окончания. Истёкший код не отменяет заказ автоматически. Магазин отдельно выбирает, сколько держит резерв товара и когда прекращает ожидание оплаты. Если код уже истёк, а заказ ещё хранится, покупателю нужно объяснить дальнейшее действие: разрешена ли новая попытка оплаты, сохраняется ли резерв товара и требуется ли заново подтвердить цену, которая могла измениться за время ожидания. Такое правило лучше определить до подключения, пока оно не затронуло реальную покупку.

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

Когда сайт вправе показать «Оплачено»

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

Повторное уведомление допустимо. Повторная отгрузка — нет.

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

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

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

Возврат связывают с исходной покупкой

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

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

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

Статусы заказа и возврата могут отличаться. Заказ частично выполнен, часть товаров возвращена, деньги ещё обрабатываются — человеку нужны понятные пояснения, а не одно слово «Отменён». Исполнитель показывает, где менеджер увидит ход операции и что будет написано покупателю. Требования к документам и кассовому учёту магазин отдельно согласует со своим бухгалтером и поставщиком кассового решения.

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

Что произойдёт, если испытать только удачную оплату

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

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

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

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

Если ограничиться удачным показом QR-кода, каждое отклонение станет ручным расследованием: менеджер ищет деньги, клиент опасается повторной оплаты, заказ ждёт отправки. Связь заказа, платежа и возврата нужно построить заранее, пока её можно спокойно испытать без очереди недовольных покупателей.