本文作者分享了完整的O2O預付訂單的交易流程。因為用戶、商家、平臺運營人員、派單系統(tǒng)的參與，流程中有很多分支所以較為復雜。筆者將項目上遇到的情況整理、分享出來，希望對讀者有所幫助。

做O2O相關(guān)業(yè)務，本質(zhì)上是平臺作為中介，將能夠提供服務的商家（也就是勞動者）組織起來，然后吸引用戶來購買商家的服務。商家付出了勞動也付出了時間，對于商家而言這段時間是有機會成本的。如果不給某個用戶提供服務，商家可以用這段時間去服務別的用戶，或者做別的事情。

現(xiàn)實當中常常發(fā)生臨近服務時間用戶取消訂單，或者是商家到達制定地點卻聯(lián)系不上用戶的情況。這時商家手上沒有任務，而且一時半會兒也接不到新的訂單，那么就會產(chǎn)生空檔期。

大家使用過打車軟件就會知道，用戶下完單（并且司機接單）后超過一定時間，如果出于自身的原因要取消訂單，用戶是要給予司機一定補償?shù)摹?/p>

其他O2O業(yè)務也存在類似打車業(yè)務的場景。

臨近服務前或者已到了服務時間，用戶取消訂單，就應當對商家進行補償。這種情況的過錯方在用戶，賠償金理應由用戶出。

那么用戶怎么支付賠償金呢？

考慮到少量用戶存在誠信問題，會以各種方式拒絕/逃避賠付，從而打破O2O的訂購-交付-實際完成付款的商業(yè)流程和契約（商家按時到達制定地點也是服務交付的一部分，也應當獲得收益），那么不少情況下就有必要在下單階段就要求用戶預付款。有了預付款，就可以用來支付前面所說的賠償金。

O2O預付訂單的交易流程與普通用戶常見的B2C、C2C實物電商不同。前者因為更多的業(yè)務場景和支付方式，某些方面甚至還要更復雜。

下面就以上門洗碗業(yè)務為例（先不必在意業(yè)務是否合理），來設計一個交易流程。為了覆蓋足夠多的業(yè)務場景，以便這個設計具有更高的通用性，這里我們預設：

1. .對于這項服務，用戶既可以選擇預付也可以選擇服務后付款；
2. 用戶可以線上付款也可以線下付款；
3. 平臺的運營工具包含了會員余額（充X送Y）和代金券（運營/客服發(fā)放，可以抵扣現(xiàn)金）。

一、整體流程

一次完整的服務從開始到結(jié)束包括用戶下單并預付、平臺派單&商家接單、商家提供服務、商家和用戶確認最終賬單并操作出賬、用戶最終完成付款和售后。

另外需要說的是，這里的賬單指的是商品信息和費用信息，交易指的是用戶的支付情況，而訂單則是賬單+交易。

因為交易明細信息（包括服務時長、服務費用、支付方式）在下單時都不是最終態(tài)，在后續(xù)過程中可能會調(diào)整，所以需要將賬單和訂單區(qū)分開來，而交易又有一套獨立于賬單和訂單的流轉(zhuǎn)過程。

在整個流程中，訂單包含這些狀態(tài)：

• 待預付：生成預付賬單還未進行預付時的狀態(tài)
• 處理中：用戶選擇了預付并跳轉(zhuǎn)到收銀臺進行操作時的狀態(tài)，如果用戶在收銀臺未完成付款就返回，則訂單狀態(tài)再次變成“待預付”
• 待確認：系統(tǒng)在派單中時的狀態(tài)
• 已完成：完成服務后，訂單最終完成付款了結(jié)
• 已取消：訂單被取消后的狀態(tài)

賬單有這些狀態(tài)：

• 待處理：生成賬單后的初始狀態(tài)
• 處理中：用戶點擊跳轉(zhuǎn)到收銀臺進行支付時，狀態(tài)=處理中。如果用戶未完成付款，而是從收銀臺點擊返回，那么狀態(tài)變回“待處理”
• 已完成：當賬單被成功支付后，賬單狀態(tài)為“已完成”
• 已關(guān)閉：當賬單沒有被支付或作廢，則賬單狀態(tài)為“已關(guān)閉”

交易有這些狀態(tài)：

• 未支付：訂單生成后初始狀態(tài)為“未支付”
• 已預付：當訂單完成預付則該狀態(tài)變?yōu)椤耙杨A付”（非強制預付的訂單無此狀態(tài)）
• 已出賬：未支付&已預付的賬單由商家更新并出帳，交易狀態(tài)變成“已出賬”狀態(tài)
• 已支付：服務結(jié)束后訂單被成功支付，狀態(tài)為“已支付”（當商家確認現(xiàn)金支付時，不使用“已支付”，而是變?yōu)椤耙汛_認”）
• 已確認：商家在商家端點擊確認收到現(xiàn)金，交易狀態(tài)=“已確認”
• 已退款：訂單發(fā)生過支付（預付），但是后續(xù)訂單被取消，則交易狀態(tài)為已退款
• 已作廢：訂單未發(fā)生過支付，訂單被取消后，交易狀態(tài)為已作廢

二、用戶端下單流程

用戶下單時首先需要選擇服務項目、服務時間、服務人員和服務地點，以及這筆訂單是否要使用代金券或者是會員余額。用戶確認并操作下一步時會生成預付賬單信息。系統(tǒng)根據(jù)策略判斷該筆訂單是否需要強制預付款，策略可以根據(jù)業(yè)務情況自行制定，這里舉例：

• 產(chǎn)品線維度：部分產(chǎn)品線必須預付，其余的無需
• 時間維度：一天當中的某些時段需要預付
• 用戶維度：多次取消訂單用戶、芝麻信用分較低用戶必須預付
• 天氣：遭遇惡劣天氣時需預付
• 經(jīng)營情況：平臺單量大/庫存占用率高時需預付

如果用戶無需預付，則提交后直接進入系統(tǒng)派單流程；如果需要預付則調(diào)起收銀臺進行付款。付款過程中會占用庫存（因為指定了服務人員和服務時間），所以需要限制付款時間，一旦超時未完成付款，則系統(tǒng)自動取消訂單。用戶完成預付后同樣進入派單流程。

另外需要注意，如果用戶在一筆訂單中同時使用多種支付方式，處理邏輯需要進行設計以避免優(yōu)惠和運營規(guī)則出現(xiàn)沖突或者崩潰。

比如：

1. 如果允許用戶同時使用會員卡和優(yōu)惠券，那么是所有優(yōu)惠券都可以和會員卡同時使用，還是僅限部分類型的券；
2. 出于更好的用戶體驗，系統(tǒng)自動幫助用戶綁定一張券，那么優(yōu)先綁定什么券（大額優(yōu)先還是近期失效的優(yōu)先？折扣券優(yōu)先還是代金券優(yōu)先？等等）。

三、商家端推送賬單、保單、結(jié)算流程

商家到達制定地點、做好服務準備后，需要在商家端確認“開始服務”，此后商家和用戶都無法在APP上取消訂單。

等到商家完成服務，根據(jù)實際情況對服務時長（以及是否使用其自帶的工具材料）進行調(diào)整，然后發(fā)給用戶確認，用戶確認無誤后最終完成付款?；谶@樣的業(yè)務流程，需要將訂單結(jié)算拆分為推送賬單和報單兩個部分。

• 推送賬單：是指商家按照實際服務情況填寫好消耗的時長和物料，并將服務明細推送給用戶。好比是去飯店吃法，在付款前飯店先給一個已上菜名稱、價格的列表和匯總金額。如果賬單有誤，用戶看完后可以要求商家調(diào)整。因此，推送賬單的頁面存在兩種情況（首次推送前的形態(tài)，及推送過后返回來修改的形態(tài)）。
• 報單：是指商家將賬單提交給系統(tǒng)，并依據(jù)此賬單完成結(jié)算。

在商家收款過程中，流程設計人員要明確的是：

1. 會員卡、現(xiàn)金、其他線上支付方式在什么情況下可以選用？下面舉例的流程中，只有當用戶是會員并且會員卡余額充足時才可以使用。當然，從運營的角度，在培訓時得向商家強調(diào)必須事先與用戶確認，才能操作收款；從產(chǎn)品角度，商家完成收款之前在界面上也應該進行提示。
2. 用戶是否在商家收款前就完成了線上支付，也就是預付？如果沒有預付，則需要用戶現(xiàn)金支付或者在用戶端進行線上支付。
3. 用戶已在線上預付的金額比實際金額多或少該如何處理？一般是多退少補。預付過少時需要再次支付；預付過多時需要考慮扣款的優(yōu)先級，一般是代金券>會員余額>第三方支付，多余的部分原路退回。
4. 商家正常完成收款時，在商家端如何給予引導？可以參考下面流程圖中的情形。
5. 在異常情況下，這筆訂單已經(jīng)完成最終結(jié)算了，此時商家繼續(xù)操作報單、收款應該如何處理？一般而言，需要在前端進行報錯提示，可參考流程圖中的情形。

四、用戶完成支付流程

商家推送賬單后，如果仍然有部分金額或者全額需要支付，則用戶可以支付現(xiàn)金、使用會員卡余額支付（如果有卡且余額足夠），或者是通過第三方支付進行結(jié)算。前兩個選項都無需用戶在APP端操作，第三類則需要。

而在后端請求支付接口前必須先校驗賬單/訂單的狀態(tài)，如果訂單已經(jīng)完成支付或者是已取消，則支付流程中斷。這些都是基本常見的考量，不贅述。

五、關(guān)于訂單被取消的處理

一個訂單可能因為各種原因被取消，具體包括但不限于下面表格中列出的情況。其中，1類的情形過失方為用戶；2類情形的過失方為商家；3類情形過失方為平臺。

如果是商家或者平臺的過失，則用戶不應當承受不利后果。所以對于已預付的訂單被取消，則應該對用戶進行原路退款、全額退款。

在一些情況下，甚至還應當給用戶發(fā)券進行補償。舉例：

1. 長期忠實高價值用戶因訂單取消而發(fā)起投訴；
2. 無可派商家，或者是系統(tǒng)多次派單都無法滿足用戶的需求；
3. 臨近服務時間，臨時取消訂單，給用戶帶來不便；
4. 優(yōu)惠券/代金券因過期而無法原樣退回。

因商家自身原因取消訂單，應記錄到商家的考核評價體系中。多次取消訂單的商家，可以減少派單甚至不派單，也可以根據(jù)業(yè)務情況進行罰款、扣押金、增加培訓、解約等。

如果是因用戶的過失而導致取消訂單，則會存在全額罰款、部分罰款和全額退款三種處理方式。

• 未預付的訂單：平臺無法對用戶進行罰款，這種情況下商家時間和收入上的損失由平臺進行補償。但是平臺會記錄用戶的失信行為，用戶后期再次使用平臺服務就需要預付了。
• 預付訂單：根據(jù)用戶取消訂單的時機來決定應當采取哪種處理方式。舉例，距離服務時間T<24小時，全罰；24小時≤T<48小時，罰用戶在線支付總額的一半；T≥48小時，全額退款。

對于出現(xiàn)的退款，需要對退款的路徑、各種退款方式的優(yōu)先級、退款中卡券的處理做出相應的規(guī)則。

• 退款路徑：原路退回，用戶使用什么方式付款，退款時就回到相應的賬戶中。
• 退款方式優(yōu)先級舉例：第三方支付>會員卡>代金券/優(yōu)惠券。這樣設定，是因為第三方支付無特權(quán)，其余兩種有特權(quán)，既然用戶失信則應對特權(quán)進行限制；會員卡是用戶通過充值獲得的，而代金券/優(yōu)惠券是平臺運營給予的，用戶獲取后者的成本遠低于前者，所以會員卡的優(yōu)先級比券高。當然，為了避免用戶做出錯誤決定并導致其投訴，需要在用戶使用前就提示這種業(yè)務場景。
• 卡券異常情況處理：卡券如果按照原樣返回會過期的情況，根據(jù)業(yè)務確定是否延期；2.因為卡券的存在，按照比例規(guī)則計算時可能會出現(xiàn)退款金額>在線支付金額的情況，此時應該加一條兜底規(guī)則，避免過多的退款。

六、關(guān)于售后

如果商家服務完離開后用戶發(fā)現(xiàn)質(zhì)量問題并向平臺投訴，則在一些情況下平臺運營會介入并了解情況，確認問題存在后會先行用代金券賠付給用戶，而后再對商家進行懲罰。該流程是整個服務的一部分，但是不涉及預付，此處一筆帶過。