事實上... 還是可以合并付款的。 前面的回答尷尬嗎。
跟支付寶的那位大兄弟的理解有點不一樣。
拆單后二次支付時沒有給統(tǒng)一的聚合支付入口，個人理解哈，與其是技術(shù)原因，更不如說是使用場景的原因。淘寶需要給各個商家創(chuàng)造針對未付款訂單的營銷場景，這個場景的存在價值不用多說，而這個場景下淘寶肯定是要給商戶獨立的訂單數(shù)據(jù)源，不可能把未拆單的數(shù)據(jù)讓各個商戶在此基礎(chǔ)上做二次營銷，那不是把別的商家的訂單也給營銷了嗎。
至于技術(shù)上，提交訂單時已經(jīng)拆單，關(guān)聯(lián)業(yè)務(wù)的請求按照我司的做法是支付回調(diào)拿回后才會請求，例如積分系統(tǒng)，會員系統(tǒng)等系統(tǒng)服務(wù)。而訂單本身層面的優(yōu)惠券，使用積分等，其實在訂單拆分時已經(jīng)入庫了，哪怕是一些特殊服務(wù)的數(shù)據(jù)回滾，其實都可以從技術(shù)層解決，更不用說淘寶本身的訂單層大概率不會直接讀取的數(shù)據(jù)庫（個人猜測，肯定是有訂單聚合層的，能夠?qū)⒉煌瑪?shù)據(jù)庫，Redis里的訂單信息聚合到一個統(tǒng)一的表里，在拆庫拆表的體量下，不可能跟小公司一樣直讀數(shù)據(jù)庫表），所以理論上已經(jīng)生成子單的前提下，在客戶端展示時在聚合成一個未拆單訂單進行支付，本身上應(yīng)該不會有技術(shù)問題的。至于庫存、商品有效性等其他信息的判斷，個人理解：第一次支付能解決，第二次依舊能解決，甚至是沿用第一次的處理邏輯即可。
ps：我沒記錯的話，小米有品就是未拆單的訂單支付的，具體沒深研究，錯了的話別打我。
個人理解，歡迎討論
加載中...