## 支付接口筆記
創建支付寶收銀臺時如果檢測到已登錄則會直接創建支付訂單,否則不會直接創建支付訂單。
同一商戶訂單號可以創建多個支付寶收銀臺(訂單認證ID),但只能創建唯一一個支付訂單,支付訂單與收銀臺是一對多的關系,如果檢測到支付訂單已支付則會提示已支付。
手機網頁版支付(沒有調起支付控件時)再輸入支付密碼支付時才會創建支付訂單,也就是說創建支付訂單和支付完成很大可能會是一個步驟,甚至是在同一個過程中完成的,當然余額不夠,支付未完成這種情況也有可能,但這種情況應該會創建支付訂單的。
即使訂單信息相同,每次生成的支付寶收銀臺(訂單認證ID)也不相同,但是創建的支付訂單卻是唯一與訂單信息對應的。
如果一個訂單設置了超時支付,那么每次創建的不同收銀臺還是使用同步(沿用第一次的收銀臺)的超時時間,如果超時則會關閉該訂單對應的所有收銀臺,超時后再次創建新的收銀臺則會重新初始化超時時間(未生成支付訂單時),如果生成了支付訂單,超時關閉的話,再次創建收銀臺會提示訂單已關閉,不能為此訂單繼續創建收營臺了,估計12306就是出于這個考慮,所以才維護了兩套訂單號的。
同一個商戶訂單號,不論創建多少次收銀臺,后來的收銀臺是否設置了超時等,都會以首次創建的收銀臺為準,盡管收銀臺頁面可能不是這么顯示的而是按照當前收銀臺顯示的,但實際上創建訂單卻是以首次的收銀臺為準的。
這樣支付寶通過檢測商戶訂單號就不會導致重復支付的問題。
支付寶支付訂單不能被用戶手動關閉,只能被刪除,刪除不是關閉,所以不影響交易,而永久刪除必須在訂單完成后,而訂單完成這個狀態是:交易成功或者交易關閉。交易關閉是自動的,默認未完成的支付訂單超過十五天后會自動關閉,用戶并不能操作訂單狀態,商戶那邊可能可以關閉訂單。
但是12306的商戶訂單號卻與訂單編號不同,一個訂單編號(訂單E00000)每次支付時竟然會請求不同的商戶訂單號W000000000,這就導致了12306同一訂單可以重復支付的問題。
不知道12306為什么要這樣,我重復支付的也不知道在哪里申請退款。
估計12306是維護了兩套訂單號,給用戶看的和提交到支付寶的
支付是個麻煩的事情,最好還是要像12306那樣設計一個支付流水號,這個流水號與業務訂單號對應,而不應該將業務訂單號直接傳給支付平臺作為“商戶訂單號”,不然有的平臺比如支付寶同一“商戶訂單號”它是能區分開的,這就導致如果12306也這樣做那么會出現用戶好不容易搶的一張票,應為一次失誤的用一個沒有錢的支付寶支付失敗,在想用別的支付寶就不行了,所以12306才會維護自己的“支付流水號”。這個支付流水號只作為系統使用,用戶沒請求一次支付接口就生成一個,并與業務訂單號關聯,可以不對用戶展示。這樣在處理重復支付和支付平臺重試問題時也很容易了。
* * * * *
#### 第三方重試/多渠道支付/重復支付?
防止重復支付,不能夠依賴于第三方平臺,建立退款機制,回調接口建立嚴謹完善的支付狀態檢查就可以保證支付安全了(需要用到事務和鎖),所以支付訂單和訂單可以分開,而不一定要用訂單號來請求第三方。
> 對于統一平臺,比如alipay,不管是調用掃碼支付還是PC/wap支付接口,只要時同一商戶訂單號,返回得都是同一支付信息,商戶訂單號在渠道那里是唯一的,而不論是具體哪個支付接口。(待實驗)
**怎么判斷回執重試?**
這需要接口保證,對于同一個商戶的相同的支付請求數據所生成的支付信息,僅能付款成功一次(不論是具體的哪個付款方式接口)
* * * * *





(只要請求支付信息的訂單號相同,都是這樣的,哪怕收銀臺二維碼不一樣,收銀臺地址每次請求支付信息都會不一樣的)
前一個用戶掃碼,什么都不做就到賬單中去了(待支付),第二個人再掃碼就不行了。
雖然這兒也可以找人代付,但是也并不方便,需要加好友(所以12306那樣有意義)。
支付寶會保證不會重復支付,就算會,支付寶渠道也會自己處理,對于我們商戶來說,對于同一訂單號生成的支付信息可以理解為不會發生重復支付就可以了。
*****
last date:2019-04-10 07:58:59
- 開始
- 公益
- 更好的使用看云
- 推薦書單
- 優秀資源整理
- 技術文章寫作規范
- SublimeText - 編碼利器
- PSR-0/PSR-4命名標準
- php的多進程實驗分析
- 高級PHP
- 進程
- 信號
- 事件
- IO模型
- 同步、異步
- socket
- Swoole
- PHP擴展
- Composer
- easyswoole
- php多線程
- 守護程序
- 文件鎖
- s-socket
- aphp
- 隊列&并發
- 隊列
- 講個故事
- 如何最大效率的問題
- 訪問式的web服務(一)
- 訪問式的web服務(二)
- 請求
- 瀏覽器訪問阻塞問題
- Swoole
- 你必須理解的計算機核心概念 - 碼農翻身
- CPU阿甘 - 碼農翻身
- 異步通知,那我要怎么通知你啊?
- 實時操作系統
- 深入實時 Linux
- Redis 實現隊列
- redis與隊列
- 定時-時鐘-阻塞
- 計算機的生命
- 多進程/多線程
- 進程通信
- 拜占庭將軍問題深入探討
- JAVA CAS原理深度分析
- 隊列的思考
- 走進并發的世界
- 鎖
- 事務筆記
- 并發問題帶來的后果
- 為什么說樂觀鎖是安全的
- 內存鎖與內存事務 - 劉小兵2014
- 加鎖還是不加鎖,這是一個問題 - 碼農翻身
- 編程世界的那把鎖 - 碼農翻身
- 如何保證萬無一失
- 傳統事務與柔性事務
- 大白話搞懂什么是同步/異步/阻塞/非阻塞
- redis實現鎖
- 淺談mysql事務
- PHP異常
- php錯誤
- 文件加載
- 路由與偽靜態
- URL模式之分析
- 字符串處理
- 正則表達式
- 數組合并與+
- 文件上傳
- 常用驗證與過濾
- 記錄
- 趣圖
- foreach需要注意的問題
- Discuz!筆記
- 程序設計思維
- 抽象與具體
- 配置
- 關于如何學習的思考
- 編程思維
- 談編程
- 如何安全的修改對象
- 臨時
- 臨時筆記
- 透過問題看本質
- 程序后門
- 邊界檢查
- session
- 安全
- 王垠
- 第三方數據接口
- 驗證碼問題
- 還是少不了虛擬機
- 程序員如何談戀愛
- 程序員為什么要一直改BUG,為什么不能一次性把代碼寫好?
- 碎碎念
- 算法
- 實用代碼
- 相對私密與絕對私密
- 學習目標
- 隨記
- 編程小知識
- foo
- 落盤
- URL編碼的思考
- 字符編碼
- Elasticsearch
- TCP-IP協議
- 碎碎念2
- Grafana
- EFK、ELK
- RPC
- 依賴注入
- 開發筆記
- 經緯度格式轉換
- php時區問題
- 解決本地開發時調用遠程AIP跨域問題
- 后期靜態綁定
- 談tp的跳轉提示頁面
- 無限分類問題
- 生成微縮圖
- MVC名詞
- MVC架構
- 也許模塊不是唯一的答案
- 哈希算法
- 開發后臺
- 軟件設計架構
- mysql表字段設計
- 上傳表如何設計
- 二開心得
- awesomes-tables
- 安全的代碼部署
- 微信開發筆記
- 賬戶授權相關
- 小程序獲取是否關注其公眾號
- 支付相關
- 提交訂單
- 微信支付筆記
- 支付接口筆記
- 支付中心開發
- 下單與支付
- 支付流程設計
- 訂單與支付設計
- 敏感操作驗證
- 排序設計
- 代碼的運行環境
- 搜索關鍵字的顯示處理
- 接口異步更新ip信息
- 圖片處理
- 項目搭建
- 閱讀文檔的新方式
- mysql_insert_id并發問題思考
- 行鎖注意事項
- 細節注意
- 如何處理用戶的輸入
- 不可見的字符
- 抽獎
- 時間處理
- 應用開發實戰
- python 學習記錄
- Scrapy 教程
- Playwright 教程
- stealth.min.js
- Selenium 教程
- requests 教程
- pyautogui 教程
- Flask 教程
- PyInstaller 教程
- 蜘蛛
- python 文檔相似度驗證
- thinkphp5.0數據庫與模型的研究
- workerman進程管理
- workerman網絡分析
- java學習記錄
- docker
- 筆記
- kubernetes
- Kubernetes
- PaddlePaddle
- composer
- oneinstack
- 人工智能 AI
- 京東
- pc_detailpage_wareBusiness
- doc
- 電商網站設計
- iwebshop
- 商品規格分析
- 商品屬性分析
- tpshop
- 商品規格分析
- 商品屬性分析
- 電商表設計
- 設計記錄
- 優惠券
- 生成唯一訂單號
- 購物車技術
- 分類與類型
- 微信登錄與綁定
- 京東到家庫存系統架構設計
- crmeb
- 命名規范
- Nginx https配置
- 關于人工智能
- 從人的思考方式到二叉樹
- 架構
- 今日有感
- 文章保存
- 安全背后: 瀏覽器是如何校驗證書的
- 避不開的分布式事務
- devops自動化運維、部署、測試的最后一公里 —— ApiFox 云時代的接口管理工具
- 找到自己今生要做的事
- 自動化生活
- 開源與漿果
- Apifox: API 接口自動化測試指南