http://www.baidu.com/link?url=Aj_xhOM5Q6rpZXkTMBPq4o0UbCO4eLq0esX8B3K2v06bkRS8F8lC4k06rv-3uZARLLTEKJHMhwzI_cdcJiHfqK&wd=&eqid=904bc71f000181740000000356d7d9bf
https://www.zhihu.com/question/35818812/answer/66086727
知乎頁面訪問存在502 Bad Gateway問題，就將內容保存下來
知乎上的一個解答——DongLin，發呆工程師
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：DongLin
鏈接：https://www.zhihu.com/question/35818812/answer/66086727
來源：知乎
商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：DongLin
鏈接：https://www.zhihu.com/question/35818812/answer/66086727
來源：知乎
模式一和模式二提供了兩種不同的能力，適用于不同的場景，看商戶具體的需求。
兩種模式，在支付的流程中，有一定的共同的流程：
1，生成訂單。
2，用戶支付。
差別在于：
模式一，先掃碼，再生成訂單。
模式二，先生成訂單，再掃碼。
而 生成訂單，代表著 本次支付給商戶的金額是否是已經確定了。
在模式一中，用戶掃描的二維碼，此時可以還沒有確定實際要支付的金額。
在模式二中，用戶掃描的二維碼，金額已經是確定的。
可以這么理解，模式一中的二維碼，是商品的二維碼。
模式二中的二維碼，是 訂單的二維碼，也因為這個是訂單的二維碼，所以必須要有時效性。
那么這兩個場景的玩法，可以有一個明顯的差別，
模式一，更適合無人職守的自動售賣機。所有的商品都有一個固定的二維碼，價格相對穩定，當用戶使用微信支付掃描了二維碼，微信再請求自動售賣機的服務提供商的 后臺接口，注意，這個請求中，是包含了商品ID以及用戶信息的，這樣，商戶系統就可以根據 商品ID，以及用戶的身份，再來確定用戶實際要支付的金額。
模式二，更適合有人職守的，支付金額非常不確定的場合。比如，你去飯館吃飯，雖然每個菜的金額是固定的，但一桌子飯菜的金額不固定，甚至是你還可能使用飯館事先發放的代金券。這個時候，就需要收銀員，預先創建一個訂單，確定好金額，然后你再來掃描這個二維碼來支付。
當然，用模式二來實現無人值守的自動售賣機，也是可以的。只是這個自動售賣機的就要多承擔一些交互以及業務邏輯，在生成二維碼之前，創建訂單。
兩種模式，在支付的流程中，有一定的共同的流程：
1，生成訂單。
2，用戶支付。
差別在于：
模式一，先掃碼，再生成訂單。
模式二，先生成訂單，再掃碼。
而 生成訂單，代表著 本次支付給商戶的金額是否是已經確定了。
在模式一中，用戶掃描的二維碼，此時可以還沒有確定實際要支付的金額。
在模式二中，用戶掃描的二維碼，金額已經是確定的。
可以這么理解，模式一中的二維碼，是商品的二維碼。
模式二中的二維碼，是 訂單的二維碼，也因為這個是訂單的二維碼，所以必須要有時效性。
那么這兩個場景的玩法，可以有一個明顯的差別，
模式一，更適合無人職守的自動售賣機。所有的商品都有一個固定的二維碼，價格相對穩定，當用戶使用微信支付掃描了二維碼，微信再請求自動售賣機的服務提供商的 后臺接口，注意，這個請求中，是包含了商品ID以及用戶信息的，這樣，商戶系統就可以根據 商品ID，以及用戶的身份，再來確定用戶實際要支付的金額。
模式二，更適合有人職守的，支付金額非常不確定的場合。比如，你去飯館吃飯，雖然每個菜的金額是固定的，但一桌子飯菜的金額不固定，甚至是你還可能使用飯館事先發放的代金券。這個時候，就需要收銀員，預先創建一個訂單，確定好金額，然后你再來掃描這個二維碼來支付。
當然，用模式二來實現無人值守的自動售賣機，也是可以的。只是這個自動售賣機的就要多承擔一些交互以及業務邏輯，在生成二維碼之前，創建訂單。
?
?
?
https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=6_4
業務流程時序圖
?
?
?https://pay.weixin.qq.com/wiki/doc/api/native.php?chapter=6_5
業務流程時序圖
性能對比 測試 。 Servlet的性能應該是最好的，可以做為參考基準，其它測試都要向它看齊，參照...)
