UPI: покупатель вернулся в магазин, но можно ли выдавать заказ?

Клиент закрыл платёжное приложение и снова оказался в магазине. Для интерфейса путешествие закончено. Для заказа главный вопрос всё ещё открыт: получил ли мерчант проверяемое подтверждение нужного платежа? В UPI полезно проектировать две связанные цепочки: путь покупателя через Intent или QR и независимую проверку результата на стороне бизнеса.

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

Сначала разберитесь в механике

NPCI описывает UPI как систему мгновенных платежей и перечисляет способы интеграции мерчантов, включая QR и Intent. Это помогает понять термины, но не гарантирует доступность каждого исторически описанного варианта для конкретного бизнеса. Ответы NPCI о UPI.

• Intent: страница оплаты вызывает совместимое платёжное приложение с данными операции, где покупатель продолжает оплату.
• QR: покупатель сканирует закодированные платёжные сведения подходящим приложением.
• Collect: в модели запроса плательщику направляется запрос на его UPI-идентификатор для подтверждения.

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

Применимые правила нужно проверять отдельно. Например, PayU направляет новых мерчантов к Intent и QR, оставляя Collect для обозначенных исключений. Прежде чем строить интеграцию вокруг запроса, подтвердите поддерживаемый вариант у своего провайдера. Торговый приём платежей и личные P2P-переводы нельзя считать взаимозаменяемыми. Документация PayU.

Свяжите процесс с одним заказом

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

Например, инструкция Razorpay требует проверки платёжной подписи и описывает получение статуса через кабинет, уведомления или API. Рекомендация по исполнению заказа связана с состоянием captured. Это терминология Razorpay: для другого провайдера нужно определить соответствующий документированный статус завершения. Шаги интеграции Razorpay.

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

Предусмотрите запоздавший ответ

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

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

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

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

Не подменяйте проверку удобным свидетельством

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

Для возврата используйте установленную процедуру, а не запрос на «получение» денег. Вопросы статуса и обращения мерчанта NPCI рекомендует направлять банку-эквайеру. FAQ NPCI для мерчантов.

QR истёк, а деньги пришли позже

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

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

У одного заказа могут появиться два подтверждённых платежа

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

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

Из названия UPI нельзя вывести международную доступность, поддерживаемые источники средств или стоимость. Уточняйте конкретный продукт и договор. Хорошая интеграция сочетает понятный путь покупателя с независимо проверяемым результатом на стороне мерчанта.