A. 怎麼樣使用支付寶手機網頁支付介面
摘要 商戶系統按照手機網站支付介面alipay.trade.wap.payAPI的參數規范生成訂單數據，然後在前端頁面通過Form表單的形式請求到支付寶。
B. 接微信支付還需要自己開發對賬系統和訂單管理系統嗎
當然需要自己開發啊
C. 訂單拆單的流程中，系統需要做哪些工作
什麼是拆單？
在網上購買商品下單成功後，過一段時間再次瀏覽時，有時會發現你的訂單會變成兩個或多個，這就是系統做了拆單而導致的。
拆單，就是將一個大的訂單依據某些規則的集合，將其分解成兩個或多個子訂單的過程，原來的訂單稱之為父訂單。
拆單的重要性
通常我們所說的拆單一般情況下是指用戶的銷售訂單，但在實際業務中，拆單情況隨處可見，如采購訂單的拆分、調撥單的拆分等等。本篇後續都是以銷售訂單的拆單講述的，請知悉！
在互聯網電商系統中銷售訂單是與C端用戶關聯最緊密的，單據量是最大的，是影響用戶體驗的，且拆單的規則相對來說是比較復雜的。
折單要求數據 准確、及時 ，因為拆單後的子訂單是需要流入到倉儲進行生產作業的，它會進行 揀貨、出庫、配送 等一系統的流程， 它也是後續財務系統對賬或結算、數據分析的重要數據來源 。
拆單的場景
用戶在APP等平台下單後，由於商品的庫存數量不滿足，可能在前端進行拆單，即用戶自己選擇是否需要拆單，可以按 最快送達 或 最小拆單 的規則進行。
看到這里您可能會有點疑惑， 庫存不足時還能下單嗎？ 現在很多網站上當商品不足時用戶需要自行修改數量，然後才能下單。
確實如此，現在這種場景少了，但是有的商家為了提升客戶體驗，對於商品可以多倉發貨時。因為單倉缺貨而需要拆單時，由用戶來選擇決定是否購買，這應該也是為了 提高轉化率 的一種方式。
還有一種場景，訂單涉及多商家，需要單獨付款的情況下，前端會直接進行拆單，但現在基本上都是合單支付了，這種拆單會使用戶體驗降低。
此外，有的商家既賣國內商品，也賣海淘商品，如果都混在一塊，那麼在支付前是需要進行拆單的，因為海淘商品要求用戶的身份認證等信息的檢驗。
在多數情況下，都是用戶下單完成後，由系統進行在後台進行拆單，拆單是要結合公司業務場景去考慮的。
用戶購買涉及幾種拆單
拆單除了以上幾種場景，對於用戶下單時系統上還會有什麼操作嗎？
有一種情況即用戶下單時系統要根據用戶選擇的收貨地址、商品等信息，判斷是否有庫存，訂單應該歸屬哪個倉庫，是否可以購買等，這個服務嚴格來講應該歸屬於商品庫存服務，但是也可以將其稱為 預拆單 。
預拆單一般是調用倉儲服務進行庫存的判斷，同時還要根據促銷活動進行一些優惠計算，所有的這些都需要前端系統在處理時對訂單商品進行一些標識，以便當用戶支付成功後，訂單流轉到OMS系統進行物理拆單。
前端用戶下單成功後，訂單經過OMS的拉單服務快速流轉到訂單中心，便開始訂單的再生成過程，訂單拆分後的子訂單會展示給用戶，原訂單一般不需要再展示，便於用戶跟蹤和查看。
所以在從用戶角度來看，一種是可以直接看到結果的拆單和一種無感知的預拆單過程。
拆單的時點與地點
預拆單是伴隨著購物流程進行的，這里不多討論，因為這個究竟是否屬於拆單也是要看我們如何定義。正常情況下用戶選購商品完成後，系統不會拆單，因為用戶有可能取消訂單或未支付成功。
拆單的時點是要在 "訂單支付成功" 後進行，且需要前端訂單已經流轉到後端生產庫，在訂單中心進行處理。
在前面有一種場景，如果購物中心不能合並支付時，在購物車中便拆分為幾個訂單，這時的拆單可以定義為 一次拆單 ，也可以歸屬於購物流程，因為用戶不提交就不會生成訂單號，不會保存各個訂單的數據。
在用戶支付成功後，各個訂單同樣是要向後台流轉，經過拆單服務的處理才可以繼續進行下面的生產。
在前面討論拆單場景時提到一種 缺貨拆單 ，這種場景的拆單是在用戶下單支付成功後，訂單有可能已經拆分為不同的子訂單，但因某種原因倉庫無貨而導致的拆單。
這時拆單的時點是靈活的，一般是在客服系統中，根據用戶的反饋確定是否拆單的。
缺貨是影響用戶體驗的，但是缺貨是始終客觀存在的。
拆單分幾級
從上圖看，拆單應該為 三級 ，即用戶創建的訂單為父訂單，然後經過拆單服務正常的分為多個子訂單為第二級，後續因為缺貨等原因子訂單再次拆分為子（孫）訂單。
在數據設計上，一般情況子訂單與父訂單的關聯都通過ParentID來進行關聯，但三級以上時，涉及原始訂單的查詢較麻煩。
具體看數據結構如何設計了，可以再增加一個原始訂單號來記錄最初的訂單號，方便統計查詢等，負責拆單服務的同學可以詳細討論下。
為了避免訂單的復雜度及系統的查詢、統計、分析等數據處理的難度， 訂單最好最多到三級，不宜過多 。
拆單狀態
以前專門梳理過訂單狀態的文章，詳見《 訂單信息與狀態流轉看這個應該足夠了! 》,在拆單過程中也涉及訂單狀態的變換。
當父訂單拆分為子訂單後，子訂單生效，父訂單應該置為無效。
子訂單或父訂單經過缺貨拆單後，原訂單狀態是無效還是其它？
訂單拆單後狀態應該置為「待下發」即需要通過下發服務，將訂單推送給倉庫發貨。
如果訂單已經下發到倉庫後需要缺貨拆單，單據狀態應保留原狀態。
這些都屬於細節，但不得不考慮，因為訂單的狀態涉及到其他業務系統的計算和統計。
如：財務系統在應付報表時是根據支付訂單進行統計和對賬的，如果訂單狀態是無效的，那麼系統如何獲取此部分數據。
BI有些統計分析是按狀態和訂單數量等進行統計的，如客單價、有效訂單數等等。
所以針對拆單而導致的訂單狀態是否應該區分原有的訂單狀態分別標識，是需要綜合考慮的。
拆單原則
拆單的原因我們已經清楚，拆單的目的是為了保證履單，拆單的原則是什麼？
首先是最小拆單原則， 即能拆兩單，不能拆成三單，因為多拆一單不僅是單據數量的增加，它會增加系統的復雜度，降低用戶體驗，加大倉庫作業量，增加運費費用等。
最快送達原則， 拆出的子訂單要快速生產，快速送達，這個是增加用戶體驗的最好辦法。但是快速送達，依賴於倉儲物流的布局，這個在多倉可以發送到一個城市時尤為重要。
一般情況下，拆單要遵循這兩條原則，同時我們也看到拆單服務，是依賴於基礎信息配置的，電商系統最復雜的是很多地方都有關聯。
拆單規則
拆單的規則因每個公司的業務不同而不同，這里羅列一些常見的規則供參考。
（1）不同商家的訂單需要進行拆分
這個主要應用於平台型的電商，一般情況用戶購買商品都進入不同的店鋪，創建的訂單也是歸屬這個商家的。但有的平台採用合單支付，即用戶選購不同商家的商品，但支付是一次的。
這個和淘寶有些不同，淘寶上每個商家的收款賬號是不同的，所以不能一次支付，但平台商家是平台代收款的，所以可以一次支付後再拆單分攤金額。
（2）不同倉或不同供應商的商品需要進行拆單
倉庫不同訂單需要分開，對於不同的供應商訂單主要是指由供應商直接發貨的訂單即商品不存儲在倉庫，由供應商直送到用戶，這個和平台商家類似。但是區別是簽署的合同不同，一個是購銷合同，一個是傭金扣點合同，細節不展開了，有興趣可以留言交流。
（3）商品類型不同需要拆單
一般區分奢侈品或有特殊要求的商品，這個需要業務根據商品要求進行設置。因為商品要求不同，後續在物流環節採用的物流產品類型也不同，物流費用也不同。這部分也可以根據商品信息，在倉儲進行處理，但最後在上位能夠提前區分。
（4）商品溫控屬性不同要進行拆單
此部分一般是指生鮮電商而言，同一個倉庫有常溫倉、冷藏倉、冷凍倉，存儲著不同的商品，商品的揀貨、包裝等都有不同的要求，所以需要進行拆單。
（5）大件商品拆單
大件商品與普通商品不同，它在倉庫的存儲位置、揀貨方式、包裝、運輸都有所區別，所以大件商品需要每一件都拆單，大件商品一般遵循最快送達，不需要最少拆單原因的限制。
（6）根據庫存拆單
這個是針對缺貨商品進行的拆單，即有庫存的一單，無庫存的一單，如果是二級訂單，則父訂單相同，子訂單衍生出子訂單，子訂單1的過程。
（7）線下門店商品不拆單
如果是線下門店購買商品，則不需要拆單。
（8）組合商品不能拆單
在促銷活動中，有時會有一些大禮包等商品的組合銷售，即A,B,C等商品經過倉庫的組合包裝後出庫，所以針對此類商品不能拆單。
在拆單服務中需要調用物料單信息，進行判斷，具體的要看系統如何設計了。
拆單的規則很多，在系統處理時，要依賴於規則設置的優先順序來進行。
拆單演算法
（1）稀缺商品演算法
找所有商品在所有庫房最稀缺的商品，獲取該商品的階數。
（2）降階
找稀缺商品的都需要倉庫組合，這些倉庫是必須發貨的，把這些倉庫計入發貨列表，這樣就降階了，剩餘倉庫再計算組合，減少運算數量。
（3）抽屜原理演算法
找第一階的倉庫列表（發貨量最大的倉庫），這個庫房的庫存是必須要發的，然後再找次發貨量最大的倉庫，以此類推，用於後面的組合計算。
（4）找組合
按照倉庫順序逐漸增加倉庫個數找組合。
演算法也只是拆單過程中的一個路徑參考，且演算法依賴於拆單的規則而制定，無論如何要保證拆單的結果准確，拆單的速度要快。
拆單服務兩步重要工作
以上一直在討論拆單是由 1變2 ，由 2變4 的一些內容，在具體的拆單服務系統中要考慮哪些內容， 又有哪些工作？
前面所說的都應該在設計時考慮，而且最重要的是要依賴規則進行設計，數據的流轉，時序等等。
金額分攤是拆單中最重要的一部分工作，也是最復雜的。
父訂單的拆分，商品的重新組合，生成新的訂單是第一步，第二步就是要將父訂單的金額合理的，正確的分攤到各個子訂單上。
訂單一般分為訂單主表和訂單商品表、訂單支付明細表和訂單活動表。
訂單金額有幾個主要的部分 ：訂單商品金額、折扣金額、禮品卡支付金額、積分支付金額、優惠券支付金額、訂單支付金額等幾個部分。
運費 是訂單表中一個特殊欄位，運費如何分攤是要特殊考慮的，一般情況是按金額佔比進行。所以生成的子訂單中各部分金額，也要保證與父訂單金額一致。
訂單商品表、支付明細表、活動表屬於明細信息，要根據原始訂單明細表的數據和標識進行計算分攤。
子訂單的金額要保證 橫向、縱向 都正確才行， 橫向 是指子單的合與父單金額一致， 縱向 是指子單訂單主表與明細表金額一致。
此外，在金額分攤計算過程有一項重要規則不可避免，即開票金額的考慮。
這部分金額的分攤與公司繳稅息息相關，單據與發票要一致，要考慮商品信息、活動規則等等，非常復雜。
有的拆單服務將金額分攤獨立出來，以降低對拆單的影響，提高訂單流轉速度。
拆單的速度要求
由於拆單後訂單才會下發到倉儲或商家進行生產，所以對於速度要求就是 快 。
在系統設計時可以依據規則等綜合考慮，多線程是最常用的方法，但多線程需要考慮資源競爭和安全性。一般情況，如果下單後已經確定了倉庫，那麼可以按倉庫啟動多個服務，這樣可以避免程序的難度。
對於拆單和下發在系統上也要有數據監控，不能出現積壓的情況。如果拆單有異常時，在定時任務中，很多情況都是依賴一個信息欄位的狀態來進行循環處理，在服務中要有 容錯處理 ，不能一直停滯不前。
拆單的影響
什麼是拆單？為什麼拆單？如何拆單？前面說了很多， 但對於拆單有什麼影響呢？
先說一個場景，公司搞促銷活動，買A贈B，但A與B商品的溫控屬性不同，所以用戶下單後一定會拆單。
拆單後倉儲揀貨、發貨是根據子訂單進行的，很有可能贈品B先發貨了，A後發貨。用戶先收到B簽收了，然後A進行拒收或取消。此時，如果在拒收或取消A時不判斷關聯子訂單，那麼公司就會損失B。
如果判斷關聯子訂單的狀態，那麼系統的復雜度將會非常之大，因為實際場景中一個父單拆為多單時是很常見的。
拆單後，子訂單數量增加，對於客單價、統計分析等報表需要考慮其影響，維度和統計口徑不同，數據結果必然不同，從而會影響到經營分析及決策。
影響，對於不同的業務有不同的理解，作為產品研發應該在拆單設計時還是需要要將利害與業務說清楚，尤其是運營人員(活動方面重點考慮），雖然這屬於一個後台服務。
總結
拆單是復雜的，合理的拆單會加快訂單的流轉，友好的用戶體驗，過度拆單則會產生冗餘的數據，增加訂單的復雜關系，統計、計算、售後等各個環節。
以上是我對拆單的一次梳理與總結，感謝您的閱讀！
D. 單頁網站在線訂單付款系統怎麼製作
1必須在支付寶處進行申請，，難度很大
2通過支付寶給的API以及相關技術文件，針對你目前這個網頁的介面來進行交接
3對接成功，搞定。
最後，你是弄不成的。你這個網頁估計是靜態的，不可能做成支付端，
然後你真要做先得弄個動態的，然後再和支付寶做一個技術上的接入，，
E. 交易單號和商戶單號一樣嗎
不一樣。
交易單號為支付系統的訂單號，由支付系統生成，並在回調時傳回給商戶，用於回調，也可查詢訂單狀態。商戶單號為商戶平台的訂單號，一般在商戶平台生成，自己可以設計自己的規則，如通過時分秒等生成隨機數訂單一般不重復
。
(5)前端支付有商戶訂單系統嗎擴展閱讀
交易單號記錄的是網上交易所產生的資金流向，一般只做為銀行和支付平台之間的對賬，個人一般不會用到這個單號。
但是當有特殊的情況之時，如遇到手機充值話費後流量未到賬，購買的充值卡未收到以及參與優惠活動等與微信支付相關的問題時，此單號可以作為充值後的交易憑證，來輔助解決相關問題。
此單號作為唯一的交易憑證，請妥善保留，交易成功後，請不要基於刪除交易單號，以備不時之需。
交易狀態解釋：
1、待買家支付——買家還未完成支付；
2、訂單已關閉——訂單已作廢（買家還未完成支付）；
3、買家已支付——買家已完成支付；
4、交易結束——交易已完成；
5、全額退款——已將訂單的全額退還給用戶。
F. 支付系統設計小結
支付作為平台最核心的基礎能力，其重要性不言而喻。
對於平台而言，支付功能最簡單粗暴的實現方式是業務系統直接接入支付渠道，支付和業務耦合在一起。流程見下圖。
但隨著業務的多樣性和復雜度的變化以及業務量的提升，需要有獨立的系統來維護支付規則，管理支付渠道，記錄支付信息。因此引入支付系統，業務流程升級為：
在一個消費者付款流程中，支付系統需完成以下任務：
1、接受業務系統的業務訂單；
2、根據業務訂單類型及金額判斷可支持的支付產品並返回給前端頁面，讓用戶選擇；
3、根據用戶選擇的支付產品，選出具體執行扣款的支付渠道；
4、根據選出的支付渠道要求組裝指令，調用渠道執行扣款任務；
5、獲取支付渠道通知的扣款結果或主動查詢通道扣款結果；
6、通知業務系統支付結果；
以上6個任務在具體執行中可以分化出以下幾個單體：
1、支付應用
平台交易每天有無數訂單，支付系統需要將訂單進行分類。不同類型的訂單對支付渠道有著不同的需求，可以將訂單類型對支付渠道的需求規則維護在支付應用層。
支付應用提供給上層業務統一模塊化的調用方式，業務層而不再需要關注支付的實現。一般來說，支付應用可分為： 即時消費（消費類訂單），充值（錢包類業務），轉帳（錢包類業務），提現（錢包類業務），退款（異常情況處理）等。
2、支付核心（支付產品）
支付核心將下游支付渠道自身帶有的原子化功能（鑒權，簽約，扣款等）封裝後提供給上游統一調用。上游通道僅需明確具體支付產品和金額後，由支付核心根據路由選出的渠道的介面要求組裝指令，調用渠道支付介面。
支付核心應封裝渠道包括驗證要素，支付額度，手續費，結算賬戶，查詢方式等屬性。也要能新渠道接入的可擴展性，屏蔽各渠道的差異，將渠道差異統一維護在單個系統中。
3、支付路由
用戶選擇支付產品後，可以有多個支付渠道支持對應支付產品。系統需要根據特定邏輯選出具體的支付通道去執行扣款，而這個特定邏輯就是支付路由。
這里至少要包括以下幾個邏輯：
1) 指定走某條通道、指定不走某條通道；
2) 選出限額滿足訂單金額的支付通道；
3) 選出手續費較低的通道；
4) 現有的支付要素是否滿足通道要求，是否仍需要用戶參與。
另外，支付應用中支持的具體支付產品，也可在路由中實現。
4、渠道管理
支付路由，和支付核心都需要根據通道特性進行判斷，可以獨立維護一個系統來記錄通道的特性。當通道屬性發生變化時，比如需要參數發生變化，費率發生變化等，通道維護時，可以在渠道管理系統中配置相關信息即可，而不需要重新發版。
基於上面的討論，可以抽象出下面兩張模型圖。
支付模型
支付系統
以上僅是收款環節的設計概述，其中仍有很多單體可以展開來講，快捷產品設計，支付路由，賬戶系統等等，有機會再提。
以上僅是個人在實踐中的總結，如有不對的地方，還請指正。
G. 簡談訂單管理系統(OMS)
訂單管理系統即處理訂單的系統，主要管理訂單的輸入，處理，輸出。其在一般電商系統中或在有交易功能的系統中，都是核心系統/功能之一，有一定的復雜度；但是雖然復雜，並不代表理解起來困難。
關於商品的文章裡面，我們已經從商品的輸入、維護、輸出的流程來介紹了商品系統，那訂單也一樣，我們本文把訂單看成一個流程即訂單流來理解。
訂單系統會與購物車、商品系統，營銷系統、會員系統、支付系統、物流系統、倉庫系統、財務系統、內容系統，具體請看示例圖：
1. 購物車 ：個人認為是訂單的起點，商品會被加入購物車，然後會被提交
2. 商品系統： 在提交訂單頁面會看到該訂單所包含的商品信息，例如商品名稱、所購買數量、價格、售後信息等
3. 營銷系統： 會顯示商品是否優惠信息，例如滿減、優惠券
4. 會員系統： 會顯示該會員是否有基於會員等級的折扣信息(如淘寶的88會員)，或是否有可抵扣金額的會員點數(如京豆)；會顯示該會員下面的收貨地址信息、也會顯示該會員下面是否有充值卡、運費券等。
5. 倉庫系統： 基於收貨地址信息顯示發貨倉庫，自提地點等，並且訂單最終會流轉到該系統進行發貨操作。
6. 支付系統 ：顯示支付方式(如貨到付款、在線支付等)、並且在支付的時候計算該會員實際應付的金額，以及顯示銀行卡信息等。
7. 物流系統： 顯示配送時間、配送方式、運費等，並且在訂單發貨後會顯示實際的配送路徑。
8. 財務系統： 顯示開票信息等，在訂單完成後會生成發票。
9. 內容系統： 顯示訂單留言等
個人認為訂單的輸入(亦可稱之為來源)可分為內部和外部兩種方式：
1. 內部： 即自建商城傳輸過來的訂單；
a. 自建商城的訂單系統涉及的其他系統比較多，基本上上圖所示的系統都涉及到了。
b. 自建商城訂單在訂單創建時有著更多的判斷邏輯，如是否需要事先拆單的、優惠信息是否可用、商品庫存是否滿足要求、會員是否正常等
c. 內部訂單由於存在支付的動作，所以會有多出待付款，待評價這2個狀態，
d. 內部訂單由於涉及支付和營銷，所以對訂單系統的並發能力、負載能力以及支付能力有相當高的要求，每一步都不允許出錯，一旦出錯就意味著營業額的損失和用戶的流失。
e. 訂單數據計算和處理的要求更高，商品多少金額，優惠了多少金額，抵扣了多少金額，實付多少金額等都需要准確計算，在財務報表內能夠清晰展示。
2. 外部： 即第三方系統傳輸過來的訂單，一般代表性的就是分銷訂單，如供應商的訂單系統會接收外部系統的訂單，
a. 第三方系統傳輸的訂單，由於訂單比較獨立，所以涉及的相關系統會少很多。
b. 第三方訂單在訂單接收時主要判斷傳輸方是否有資格，商品是否上架狀態，庫存是否滿足，收貨人信息是否完整等。
c. 由於該類訂單相對來說不需要很高的實時性(意思是該類訂單對於消費者來說已經付款了，現在只是後端處理)，所以對介面負載性能等要求相對就沒有那麼高。
d. 訂單數據處理方面，一般都是線下核對賬單，線下結算款項，所以主要在數據記錄和處理的准確性方面有很高要求。
以上就是訂單的輸入，接下來我們聊訂單的處理。
個人認為主要有3種處理方式：
1. 流轉處理
在訂單系統內，系統會對訂單進行各種邏輯規則判斷，判斷後就會根據業務規則分發訂單，可簡單看示例圖：
基本上訂單的流轉處理是秒級，甚至是毫秒級就能處理完畢的，不能處理的或者處理失敗的都會把訂單歸類到異常訂單。
下面是訂單各狀態的流程圖：
2. 發貨處理
訂單一般流轉到倉庫進行發貨操作，發貨後倉庫會把物流信息回傳到訂單系統，訂單系統接收消息後會對訂單進行發貨：
a. 如果是內部訂單則訂單狀態直接改變(消費者端也會同步看到訂單狀態變化)；
b. 如果是外部訂單則會通過介面告訴第三方系統該訂單的物流信息；
3. 特殊情況處理
在特殊情況下，就需要對訂單進行人工處理，例如訂單無法流轉到下一級、訂單有備注等。人工處理的結果可能是跟消費者協商後讓其退款，也可能是手動的傳輸訂單等。
1. 內部訂單：
內部訂單的完成並不在發貨後就完成，一般來說在客戶接收到訂單商品後即算完成。但是對不同類型的商城有所區別：
a. 自營商城：一般客戶收貨後就完成訂單，例如京東。
b. 非自營商城：客戶需要自己點擊確認收貨或經過一段時間後系統自動確認收貨。
2. 外部訂單：
外部訂單系統訂單一般在發貨後就算完成。
1. 在我們設計訂單系統的時候應該先思考下公司業務類型和邏輯，理清業務上訂單流的起止。理清後從訂單源頭開始設計訂單系統：
a. 如果是自建商城類的那麼訂單模塊會涉及到其他系統，需要與其他系統的產品經理(如多人)去討論，如何讓訂單系統與他們負責的系統進行對接；如果是供應鏈類型的訂單系統，則需要考慮如何讓訂單能夠從外部順利傳輸到系統，是我們提供統一標準的API呢還是我們去各自對接第三方系統等等。
b. 考慮輸入方式後，我們就要依據公司業務運營方式來考慮訂單的處理邏輯，訂單進入系統後如何 讓系統自動處理訂單，依據什麼規則；同時也要考慮對異常訂單的處理。
c. 在考慮好訂單處理邏輯後，就要考慮如何輸出訂單，是直接輸出給WMS還是會再輸出給其他ERP等等。由於是自動化的輸出，也就要考慮與其他系統的對接方式。
d. 最後，我們就要用把公司業務代入到系統內，看看是否能行程閉環，是否還有欠缺或者是否遺漏了細節等。
2. 訂單管理系統涉及的其他系統比較多，所以在系統設計上應該具有獨立性、拓展型和准確性，獨立性代表訂單系統的維護或者異常不會影響到其他系統；拓展型代表訂單系統在以後增加功能的時候方便快捷；准確性是指訂單數據涉及到財務方面，所以應該嚴謹和准確。
3. 後台系統訂單頁面的設計：
a. 訂單列表頁面的設計
根據公司業務需要來設計列表頁展示的數據和布局，以及篩選查詢的關鍵欄位，具體可看示例圖：
b. 訂單詳情頁的設計
訂單詳情頁一般來說是模塊化的展示設計，訂單基礎信息、商品信息、物流信息、支付信息等都需要有所區分，這樣設計有利於詳情快速查看以及在系統研發的過程中讓開發小哥哥不容易搞錯哦，具體可看示例圖：
c. 訂單規則設計
訂單規則根據業務的大小有簡單和復雜，所以具體需要看業務規模。如果公司現階段剛起步，則訂單規則可直接寫進訂單系統；如起步有一段時間了或者發展比較快，則可事先就開發好訂單規則模塊，以後有新的訂單規則直接通過運營人員設置即可，更加的方便和更快速的適應業務的發展。
H. 前端訂單拆分和支付功能用到了什麼技術
支付的話您可以使用支付寶的沙箱支付
I. 小程序對接哪家第三方支付
這要根據小程序而定，例如網路小程序可以對接：商家需要有自己的智能小程序，需要接入網路錢包、微信支付、支付寶等第三方支付，完成支付閉環。
第三方支付平台提供一系列的應用介面程序，將多種銀行卡支付方式整合到一個界面上，負責交易結算中與銀行的對接，使網上購物更加快捷、便利。第三方支付整合了後端各大銀行的不同支付介面，對外提供統一的接入平台，方便商戶接入。
商戶已有小程序，在小程序上展示商品或服務，用戶在小程序內下單或享受服務使用支付時，商戶發起本服務通過服務商下單，由服務商呼起微信支付並完成支付。在此支付過程中，作為具有一定開發能力的普通服務商，協助小程序上的商家完成入駐、支付接入、技術開發及其他相關工作（如分賬、分潤、退款等）。小程序商戶接入普通服務商，有兩種接入方式：由服務商新申請特約商戶方式（以下簡稱特約商戶）以及綁定已有微信普通商戶方式（以下簡稱普通商戶）。兩種方式下，服務商都是作為商家與微信支付之間的連接者，服務商本身不經手資金，支付成功後資金直接進入特約商戶商戶號，無論哪種接入方式，當前微信支付的普通服務商僅面向通過微信認證的企業類型服務號開放申請，服務商主體需與小程序主體一致。需要通過小程序的APPID獲取微信支付的能力。
J. 各支付SDK流程
一、微信支付
微信支付官方流程鏈接： https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=8_3
簡要來說流程如下：
1.用戶點擊商品下單：「商戶客戶端」調用「商戶服務端」生成訂單，「商戶服務端」後台調用「微信支付系統」的「統一下單API」介面，生成預付訂單後，返回給「商戶服務端後台」，商戶後台再回調給「商戶客戶端」。
2.用戶確認支付：「商戶客戶端」調用「調起微信支付」介面，界面跳轉到微信進行支付。
3.用戶支付成功：這里有三個回調，其一、「微信支付系統」通知「商戶管理後台」支付信息。其二、「微信支付系統」通知「微信客戶端」支付結果。其三、「微信支付系統」通過「商戶客戶端」實現的回調中處理支付狀態，「商戶客戶端」可通過調用「商戶管理後台」的介面查詢當前訂單狀態。（商戶管理後台也需要調用「微信支付系統」查詢訂單介面）
二、支付寶支付
支付流程圖：
支付寶支付對比微信支付流程還進行了簡化，即在生成訂單時，不需要商戶後台請求支付寶生成訂單，基本流程如下：
1.「商家APP」請求「商家後台」下單，「商家後台」返回訂單信息。
2.「商家APP」根據訂單喚起「支付寶App」進行支付。
3.支付成功後，「支付寶支付後台」返回支付結果給「支付寶App」，「支付寶App」返回支付結果給「商家App」、「支付寶支付後台」非同步通知支付結果給「商家後台」。
三、蘋果支付
流程圖：
支付流程：
1.用戶點擊購買，「App客戶端」請求「App服務端」創建交易訂單。
2.「APP客戶端」拿到交易信息，然後開始調起「IAP 伺服器」創建訂單。
3.「IAP伺服器」通知購買成功，並把收據信息寫入APP沙盒中。
4.「APP客戶端」去沙盒中拿到收據信息，並將收據信息上傳到「APP伺服器」,「APP伺服器」把收據信息請求「IAP 伺服器」驗證，如果有則返回到「APP客戶端」，把訂單結束。
參考鏈接： https://juejin.im/post/5a3b14f36fb9a045104aa6c8