模式一和模式二提供了兩種不同的能力，適用於不同的場景，看商戶具體的需求。
兩種模式，在支付的流程中，有一定的共同的流程：
1，生成訂單。
2，用戶支付。
差別在於：
模式一，先掃碼，再生成訂單。
模式二，先生成訂單，再掃碼。
而 生成訂單，代表着 本次支付給商戶的金額是否是已經確定了。
在模式一中，用戶掃描的二維碼，此時可以還沒有確定實際要支付的金額。
在模式二中，用戶掃描的二維碼，金額已經是確定的。
可以這麼理解，模式一中的二維碼，是商品的二維碼。
模式二中的二維碼，是 訂單的二維碼，也因爲這個是訂單的二維碼，所以必須要有時效性。
模式一開發前，商戶必須在公衆平臺後臺設置支付回調URL。URL實現的功能：接收用戶掃碼後微信支付系統回調的productid和openid；URL設置詳見回調地址設置。
業務流程時序圖
模式二與模式一相比，流程更爲簡單，不依賴設置的回調支付URL。商戶後臺系統先調用微信支付的統一下單接口，微信後臺系統返回鏈接參數code_url，商戶後臺系統將code_url值生成二維碼圖片，用戶使用微信客戶端掃碼後發起支付。注意：code_url有效期爲2小時，過期後掃碼不能再發起支付。
業務流程時序圖
那麼這兩個模式的差別：
模式一，更適合無人職守的自動售賣機。所有的商品都有一個固定的二維碼，價格相對穩定，當用戶使用微信支付掃描了二維碼，微信再請求自動售賣機的服務提供商的 後臺接口，注意，這個請求中，是包含了商品ID以及用戶信息的，這樣，商戶系統就可以根據 商品ID，以及用戶的身份，再來確定用戶實際要支付的金額。
模式二，更適合有人職守的，支付金額非常不確定的場合。比如，你去飯館吃飯，雖然每個菜的金額是固定的，但一桌子飯菜的金額不固定，甚至是你還可能使用飯館事先發放的代金券。這個時候，就需要收銀員，預先創建一個訂單，確定好金額，然後你再來掃描這個二維碼來支付。