該篇文章通過剖析涉及金額高、募集周期長的訂單業務需求，提出了這類訂單的設計流程及原型方案。

在訂單系統中，常見的類型有：付款-到貨的電商類、票務類訂單，付款-消費的團購類、外賣類O2O訂單等等。

這些訂單系統都具備完整的售前-售中-售后流程，其中售中的關鍵動作是支付，但大部分的訂單系統都只有一次支付動作。

其實還有一些業務類型，在整個訂單生命周期中是有兩次支付動作的。本文主要就是列舉一種在訂單生命周期中涉及兩次支付的訂單系統的設計方案。

一、業務背景

有些業務涉及的金額高、募集周期長，如果讓用戶一開始就支付足額資金，那么這些大額資金就會出現站崗的現象：也就是說，資金支付并鎖定了，但獲得份額或收益還需要等待數周或更長。

由于這些資金動輒幾十萬、數百萬、甚至上千萬，在幾周或一兩個月的時間里站崗的話，利息的損失是可觀的，對用戶來說是一種實實在在的經濟損失。

例如，金額較高的眾籌類，包括酒店、民宿等空間眾籌，募集周期常常達到1個月以上，甚至2-3個月，而不少投資金額是一萬起、或數萬、或一二十萬，這些資金在幾個月的時間里站崗，損失的利息最高可以達到數千元。更厲害的諸如信托、私募類的大額理財產品，起投金額一般是100萬，募集周期短的1-2周，長的可能有一兩個月，由于金額非常高，利息損失更高。

因此，類似這樣的業務就出現一種需求場景：客戶先支付少量預約金鎖定額度，然后在預約期結束時，集中打款支付剩余的金額，從而既保證了募集結果的可控性，也保護了用戶利益。

保證募集結果可控指的是：在長周期的募集過程中，由于用戶支付了定金性質的預約金，后續反悔的可能性小，對順利完成募集影響不大。

保護用戶利益是指：用戶只需支付小額預約金（一般為認購額度的1%～5%），就可以鎖定額度，且大額資金也不用站崗損失利息。

描述到這里，核心流程就呼之欲出了：用戶先支付預約金，到特定的時間點后再支付剩余金額。

二、兩次支付為什么不是兩個訂單？

熟悉支付系統的人聽到兩次支付，一定會下意識認為應該是兩筆訂單，一筆是預約金支付訂單，一筆是認購金支付訂單。從支付系統的角度來說是正確的，因為對于支付系統來說，一個“支付訂單”的生命周期包含了待支付、支付成功、支付失敗或支付超時等狀態，管理的一般是一筆支付的情況。

但上述所列舉的場景，在業務角度上以及開發角度上，我們把它定義為一筆訂單。原因如下：

• 從用戶的角度：支付預約金目的是為了鎖定額度，且后續支付的也是“剩余金額”，實際上在用戶看來是一個事務的前后關系
• 從開發的角度：在業務系統層面（非支付系統層面）分開兩個訂單，然后再創建關聯，復雜度反而會提高

因此，我們把它設計成在支付層是兩筆訂單，但在業務層則是一筆訂單的兩個階段。

三、預約-認購流程解析

下圖是預約-認購的核心流程，描述如下：

預約階段：一般周期較長，用戶可以支付少量預約金，鎖定尚未被預約的份額。例如，欲認購某信托基金500萬元，這個階段只需要支付5萬元預約金。需要注意的是，預約金是定金性質，支付后如果在認購階段放棄認購資格的話，從法律角度來說平臺是可以不退還的，但為了用戶的體驗，一般可以設計成可原路退還或可轉為代金券在下次認購時使用的方式。

點擊進入預約金支付頁面后，訂單即生成，這時候訂單處于“預約金待支付”狀態，支付成功則狀態更新為“預約成功”。

認購階段：一般周期較短，需要通過多種方式通知到客戶及時打款支付剩余金額（例如余下99%的金額），如上信托的例子，用戶需要再支付495萬元，支付成功則認購成功。如果在認購階段沒有完成支付，則在基金結束募集進入了封閉期后，用戶支付的5萬元按定金方式處理。

由于從預約到認購是同一個訂單，用戶在認購階段觸發認購支付流程時，會將訂單更新為“認購待支付”狀態，并顯示待支付的剩余金額，支付成功后則狀態更新為“認購成功”。

這個流程是抽取最核心的部分，在實際產品的設計中，還有諸多的細節需要處理好：

1. 訂單上要明顯標明當前是處于預約階段或認購階段；
2. 預約支付時，明確說明預約金用途及后續未認購的處理；
3. 預約成功且到認購階段時，應通過多種方式（APP消息、短信、人工電話通知）通知到客戶，且在訂單列表中可以便捷進行預約訂單的認購操作，確保預約客戶最大化轉化為認購客戶；
4. 認購階段，非預約用戶點擊認購時，需要做好提醒，例如提醒用戶還有剩余額度，可聯系客服直接認購等；也可以設置一個開放認購期，供未預約用戶認購剩余份額。

四、訂單管理原型設計

訂單管理是該流程面向用戶的重要界面，設計良好的功能流程可以保障用戶使用順暢、提高認購轉化率。

訂單流轉和狀態原型描述如下：

1. 預約待支付：點擊預約進入支付頁面后，如果未支付，則是待支付狀態，需要顯示訂單類型為“預約”、顯示需要支付的金額、支付剩余時間，并可進行取消訂單和付款的操作；
2. 預約已支付：類型為“預約”，狀態為“預約成功”；
3. 認購引導：預約成功后，訂單處于等待狀態，在項目進入認購期后，訂單出現“去認購”的提醒，注意此時訂單的狀態并未變化，只是多了一個開始認購的提醒和去認購的便捷按鈕；
4. 認購待支付：點擊去認購并生成認購待支付訂單后，訂單狀態更新為認購階段的待支付狀態，同樣可以選擇取消訂單和付款兩個操作。需要注意的是，如果業務模式限定必須先預約才有資格認購，則類型顯示為“認購”即可，之所以顯示為“預約轉認購”是為了區別那種有開放認購并行存在的情況；
5. 認購支付成功：認購訂單支付完剩余款項后，訂單狀態更新為“認購成功”；
6. 未認購：過了認購期仍然沒有支付剩余款項的，訂單類型保持為“預約”，訂單狀態保持為“預約成功”，但給予用戶“預約金已轉為代金券”的友好提示。

五、總結

對于涉及兩次支付的訂單系統的設計，需要整合好支付層的訂單轉化為方便用戶使用的業務層的訂單。

本文提出的方案是將一個事務中的兩筆支付訂單合成為有前后關系的一筆訂單，從而方便用戶在不同階段對訂單進行管理。

本文由 @?Alex 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議