Малый концентратор ведет к чтению:
Автор дает идеи и схемы, давайте посмотрим, как это делают другие, ха-ха
Мой общественный номер:MarkerHub, веб-сайт Java:markerhub.com
Чтобы увидеть больше избранных статей, нажмите:Java Notes Daquan.md
Автор: Безумный принц
Источник: cnblogs.com/cjsblog/p/14516909.html.
Обзор
На рисунке показан упрощенный процесс заказа, который начинается с отправки заказа и последующей оплаты. Для оплаты обычно проходят через платежный шлюз (платежный центр), а затем платежный центр взаимодействует со сторонними платежными каналами (WeChat, Alipay, UnionPay).После успешной оплаты платежный центр асинхронно уведомляется, и платеж центр обновляет статус своего платежного поручения, а затем уведомляет об этом бизнес-приложение, и каждое предприятие обновляет статус своего платежного поручения.
Проблема, с которой часто можно столкнуться в этом процессе, это сброс заказа, будь то таймаут без получения уведомления об обратном вызове, или программа сама сообщает об ошибке, короче по разным причинам уведомление не приходит как запланировано, а последующие действия обрабатываются правильно. Логика и т. д. приведет к тому, что пользователь успешно заплатит, но статус заказа на стороне сервера не будет обновлен. В это время могут возникнуть жалобы, или пользователь может сделать повторные платежи.
Отброшенные заказы, вызванные ③⑤, называются внешними отброшенными заказами, а отброшенные заказы, вызванные ④⑥, называются внутренними удаленными заказами.
Чтобы предотвратить сброс ордеров, здесь можно обработать так:
1.Добавить в платежку промежуточный статус "оплата".При оплате того же заказа сначала проверьте есть ли поток оплаты со статусом "оплата".Конечно, нужно добавить блокировку при оплате( предоплата). После завершения платежа при обновлении статуса потока платежей он будет изменен на статус «платеж прошел успешно».
2. Платежный центр должен определить время ожидания (например, 30 секунд).Если обратный вызов об успешном выполнении платежа не получен в течение этого периода времени, он должен вызывать интерфейс для активного запроса результата платежа, например, каждые 10 секунд, 20 с и 30 с. Если в рамках максимального количества запросов результат не найден, следует выполнить обработку исключений.
3
4. Будь то платежный центр или бизнес-приложение, при получении уведомлений о результатах платежа необходимо учитывать идемпотентность интерфейса, сообщение обрабатывается только один раз, остальные игнорируются.
5. Бизнес-приложения также должны активно запрашивать результаты платежей с течением времени.
Для упомянутого выше активного запроса тайм-аута вы можете поместить эти платежные поручения в таблицу при инициировании платежа и использовать временные задачи для сканирования
Чтобы предотвратить повторную отправку заказа, его можно обработать следующим образом:
1. При создании заказа используйте информацию о заказе для расчета хэш-значения, чтобы определить, есть ли ключ в redis, если он не позволяет повторную отправку, если нет, сгенерируйте новый ключ, поместите его в redis, чтобы установить срок действия время, а затем создать заказ. Фактически, одну и ту же операцию нельзя повторять в течение определенного периода времени.
Прикрепите рекомендации по оплате микроканалов:
PS: Если вы считаете, что я делюсь хорошим, вы можете поставить лайк и посмотреть его.
Рекомендуемое чтение
Слишком много, этот веб-сайт Java, какие предметы! https://markerhub.com