Дай обложку моему собачьему брату~
Всем привет, я младший черный брат внизу~
В сегодняшней статье мы продолжаем тему прошлого раза и продолжаем рассказывать о решении нештатной платежной системы.
В предыдущей статье "Нестандартное решение для просроченных заказов», мы в основном имеем в виду сценарий, когда заказ отбрасывается во время процесса оплаты. Пользователь явно успешно оплатил, и банковская карта была списана, но заказ все еще показывает ожидающий платеж.
В сегодняшней статье речь пойдет о ненормальности повторной оплаты, то есть при одном и том же заказе пользователь списывается дважды.
Кроме того, упомянем еще об одном исключении, когда пользователь успешно списывает платеж, но оплата заказа не проходит.
Для двух вышеупомянутых исключений пользовательский опыт крайне плохой для дебетованного пользователя, и заказ не был успешным после оплаты большего количества денег. Так что, если вы вовремя не разберетесь с этими двумя типами аномалий, вы действительно ждете жалоб.
Добро пожаловать, чтобы обратить внимание на мою официальную учетную запись: общение программы, ежедневный толчок галантерейных товаров. Если вам интересен мой рекомендуемый контент, вы также можете подписаться на мой блог:studyidea.cn
Исключение повторного платежа
ненормальная сцена
Исключения повторных платежей, как правило, распространены в платежах онлайн-банкинга, платежах WeChat, Alipay и других платежных сценариях, которые требуют перехода на страницу платежного шлюза (платежи онлайн-банкинга) или перехода к приложению кошелька (Alipay, WeChat), чтобы завершить вывод асинхронно.
В этом платежном сценарии результат платежа можно узнать, только приняв асинхронное уведомление, которое обычно называется асинхронным платежом.
PS: что такое синхронный платеж с асинхронным платежом?
Фактически синхронный платеж означает, что после вызова платежного интерфейса результат платежа может быть возвращен немедленно, например, такой платеж, как ярлык/удержание банковской карты, является синхронным платежом.
Конечно, есть и замечательные каналы оплаты банковскими картами: синхронный результат платежа принимается успешно, и только асинхронное уведомление или запрос возвращает результат платежа.
Поскольку платеж банковской картой должен возвращать четкий результат платежа, для этого типа канала он может быть только внутренне разработан для преобразования асинхронного в синхронный.Если вам интересно, вы можете прочитать предыдущие исторические статьи:
Проектирование архитектуры|Как синхронно обрабатывать асинхронные запросы?
Процесс фоновой оплаты выглядит следующим образом:
Изображение из предыдущей статьи:Принцип оплаты банковской картой
Почему повторяются платежи?
Основная причина на самом деле та же, что и в последнем исключении отбрасывания внутреннего заказа, которое связано с дизайном бизнес-таблицы.
Как мы упоминали в прошлый раз, структура основной таблицы платежной системы выглядит следующим образом:
В соответствии с этой структурой таблицы, пока платежное поручение не выполнено, продавец может повторно использовать один и тот же внутренний номер заказа для вызова платежного интерфейса.
Предполагая такой сценарий, пользователь выбирает China Merchants Bank для совершения платежа через онлайн-банкинг при оплате в кассе.Когда он нажимает на платеж, система продавца вызывает интерфейс онлайн-банкинга платежной компании.
В это время платежная система создаст платежное поручение и соответствующий канальный заказ и вызовет интерфейс системы China Merchants Bank.
Затем страница браузера пользователя откроет новую страницу, а затем перейдет на веб-сайт China Merchants Bank.
В это время, если пользователь снова нажмет на оплату в кассе в это время, снова будет вызван интерфейс платежной системы. В это время, поскольку платежное поручение уже существует, будет создана только еще одна запись заказа канала, и будет вызван интерфейс системы China Merchants Bank. В это время браузер пользователя снова откроет веб-сайт China Merchants Bank.
Если пользователь завершает платеж на обеих страницах онлайн-банкинга CMB, происходит двойной платеж.
Приведенный выше сценарий может показаться глупым, но реальные действия пользователя действительно происходят. В дополнение к этому друзья в блоге Garden также упоминали следующие ситуации:
Решение
Есть два основных решения проблемы аномальной двойной оплаты, которые делятся на до и после события.
Основная цель заранее — максимально предотвратить повторные платежи пользователями, главное решение — максимально оптимизировать платежную страницу и делать подсказки.
Первый метод оптимизации, страница оплаты напрямую переходит на страницу онлайн-банкинга стороннего/банка, не открывайте новую страницу для перехода.
Этот метод может предотвратить случайное открытие пользователями двух платежных страниц онлайн-банкинга, что приведет к повторным платежам.
Однако здесь возникает проблема: после того, как платеж на странице онлайн-банкинга банка прошел успешно, как пользователь узнает, что статус заказа на стороне продавца также успешен?
На самом деле все очень просто, теперь интерфейс оплаты онлайн-банка вообще имеет параметрreturn_url: адрес синхронного перехода.
Пока этот адрес передается в интерфейсе, при успешном платеже страница в конечном итоге перейдет к входящему адресу, и сторона продавца может отображать по адресу, успешно ли оплачен заказ.
Выше мы упоминали, что пользователи могут использовать резервную функцию браузера для перехода на страницу оплаты, что приводит к повторным платежам.
В этом случае мы можем сначала проверить результат оплаты заказа в фоновом режиме, когда он вернется на страницу оплаты, и, если оплата прошла успешно, страница успеха будет отображаться напрямую.
Вторая оптимизация, для такого рода повторного открытия страницы и перехода на веб-сайт банка, мы можем добавить на страницу всплывающую подсказку, чтобы спросить пользователя, был ли платеж завершен.
Например, в приведенном выше методе обработки, когда пользователь нажимает «Подтвердить», чтобы завершить пополнение счета, он может немедленно инициировать запрос статуса заказа в фоновом режиме.
Давайте поговорим о решении после мероприятия,На самом деле решение очень простое: инициировать внутренний возврат и вернуть обратный возврат излишне уплаченной суммы..
В платежной системе может быть запланированная задача, которая регулярно сканирует записи нескольких успешных заказов канала в рамках платежного поручения, а затем инициирует возврат средств для повторяющихся заказов канала оплаты.
Этот метод является внутренней операцией системы платежной компании и не требует от продавца инициирования инструкции.
исключение аннулирования заказа
ненормальная сцена
Этот сценарий обычно распространен при покупках в электронной коммерции, всплесках и других сценариях покупок. После того, как пользователь разместит заказ, на странице начнется обратный отсчет, и пользователю необходимо будет успешно оплатить заказ в течение срока действия.
Предположим, пользователь нажимает, чтобы перейти на Alipay, но он не платит сразу, а остается в течение длительного времени, и завершает оплату в течение последней секунды заказа, но в это время заказ уже был автоматически отменен из-за истечения срока действия. времени.
Таким образом, вычет пользователя прошел успешно, но заказ не выполнен или закрыт.
В другой ситуации пользователь успешно провел платеж в течение срока действия, но из-за проблем с сетью, внутренним приложением и другими проблемами асинхронное уведомление о результате платежа было получено спустя долгое время, в этот раз внутренний заказ был отменен из-за к истечению времени.
Решение
Первое решение — отправить срок действия в платежный канал.
Как правило, платежный интерфейс будет иметь поле срока действия платежа, указывающее последнее время, когда платеж может быть оплачен. Если платеж не будет произведен в установленный срок, платеж будет закрыт.
Конечно, при нормальных обстоятельствах, если он не загружен, обычно в этом поле будет указан период действия по умолчанию, например, 3 дня, что относительно долго.
Таким образом, при вызове платежного интерфейса вы можете передать в платежный интерфейс оставшийся срок действия заказа. Таким образом, если пользователь не совершит платеж в течение периода ожидания, платеж не будет выполнен.
Второе решение — инициировать возврат внутри компании.
Это решение все еще является запоздалым решением: для случая, когда платежное поручение закрыто, но платеж прошел успешно, инициируется внутренний возврат средств, и деньги возвращаются пользователю.
Внутри может быть запланированная задача, которая регулярно сканирует ситуацию, что платежное поручение было закрыто, но платеж прошел успешно, а затем инициирует инструкцию по возврату средств.
Наконец
Наконец, используйте интеллект-карту, чтобы обобщить аномалии, с которыми может столкнуться платежная система.
Исторические статьи по теме платежной системы
- Коллекционный артефакт! Интерпретация принципа агрегированного платежного кода | Оригинал
- В чем смысл совершения платежей, даже если мобильный телефон не в сети? |Оригинал
- Слегка проведите по нему, и деньги будут немедленно вычтены.Вы не хотите знать принцип платежного кода? |Оригинал
- История развития системы маршрутизации платежных каналов
- Разработайте систему согласования с нуля