電商支付流程的「返回」邏輯

37 評論 26964 瀏覽 261 收藏 7 分鐘

標題有點繞口,先來做一番解釋:我們在電商平臺進行交易的過程中,待到支付環節的時候,假如用戶這時強制選擇「返回」,之后頁面如何該跳轉,以及訂單該如何處理?

這個問題來源于這段時間負責的電商項目,關于頁面跳轉邏輯日常的和開發進行了一番撕逼,開發堅持認為應該原路返回,堅決站在用戶的角度 ,允許用戶返回修改訂單信息,balabala。

乍一看,這個問題不過是表現層方面的問題,仔細思考后,這個問題并不簡單,隱藏著一些列不為人知的情節,且聽我一一梳理

做產品這段時間以來,總結出一個有趣現象。每每和其他同事爭論到刀光劍影的時刻,對方很容易就會把「用戶」這尊大佛搬出來,頓時突然想笑。

做產品以用戶為中心,沒錯,但是不管你是開發還是設計你僅僅代表的是你自己,不要輕易去代表用戶,這樣的討論其實是蒼白的,沒有實際價值。

相比于「用戶」這尊大佛,用數據才是最高級的做法,要學會用數據替你說話。不會撕逼的產品不是好產品,既然撕逼一定要撕得漂亮一點。

一、場景描述

想必大家都曾遇到過這個問題,在電商購物的過程中,已經走到了最后一步:去支付。這個時候突然意識到商品數量不對,或者收貨信息選錯。

除此之外,用戶還存在之下返回的原因:

  1. 誤點擊,也就是說用戶還是想買的;
  2. 猶豫中點了返回,想買的欲望不是十分堅決;
  3. 堅決不買了。

二、可選方案

(1)目前幾乎所有主流電商平臺,在支付頁面點擊返回跳轉到訂單的待支付頁面。

(2)有一部分微商城,依然原路徑返回,不過依然生成了待支付訂單。

(3)原路返回,也不生成待支付訂單,不過作者目前并沒有找到此類型的案例。

三、為什么要有「待付款」狀態

1. 庫存計算

在電商系統中,前端頁面顯示的庫存與倉庫的實體庫存是不同步的,因而在商品出倉前要求前端的庫存進行「鎖定」即前端的減庫存。

關于庫存的鎖定,電商領域存在有兩種方案:

  • 一種是拍下減庫存即生成訂單(待付款)減庫存,故此方案繞不過「待支付」;
  • 一種是支付成功減庫存。

拍下減庫存存在的問題:

用戶可能拍下不買,不乏存在有用戶把拍下當收藏夾用,以致占用庫存,影響平臺的交易量。甚至存在更為極端的「惡拍」漏洞,競爭對手會把商品所有庫存全都拍掉,也不付錢,平臺的商品就全部被下架了。

支付成功減庫存存在的問題:

支付成功減庫存會碰到最嚴重的問題,是「超賣」。因為系統在付款成功之前,都不減庫存,所以總是會發生“短時間很多人都拍下,甚至都付錢了,但是系統卻發現庫存不夠了”。

買家拍下商品后,從提交付款到付款成功的之間是有時間差的,因為付款的動作是在幾個不同的系統之間傳信息。因此最后一件商品可能被多人拍下,這幾個人都可能付款成功。

淘寶的做法是把何時減庫存的決定權交給賣家,然后告知賣家兩個方案各自適應的場景。

2. 提高轉化

電商是通過交易驅動的產品類型,因此訂單的每一步都要考慮轉化率,提高轉化率是電商的基礎要求。

用戶在電商下單,大多都是會進行一番思考的,畢竟支付寶里的錢也不是河水流過來的。用戶在支付前總會有種種原因擱置付款,一般待支付訂單的有效時間為24小時以內,在這段有效時間內平臺就像一名促銷員一樣,告知你有未付款的訂單。

四、確定解決方案

結果是幾乎所有的電商都采用了從支付頁面返回跳轉至待支付的方案。

  • 從用戶角度來考量:退回去修改信息(收貨信息、商品信息)一定是用戶真實存在的訴求。
  • 在商家的角度:提高訂單的成交率,是第一要務。這個時候最好的辦法就是利用數據工具,做埋點和統計,根據各種情況出現的概率做出相應的決策。

數據是最客觀公證的,當場景遇到矛盾的時候,用數據來做決策。

在做產品時,很多業務場景中的實際問題是兩難的,甚至更多。我們作為產品的設計者,需要在不同的角色利益之間做出權衡,因此我們需要設計出一個算法,賦予每個相關變量最恰當的權重,以此來求得一個最優解。

 

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

題圖來自PEXELS,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫得很好,如果能更詳細說明拍下扣庫存、支付成功扣庫存的好處和壞處就好了,貌似有一種新的做法,提交訂單鎖庫存,但是10分鐘內未支付則釋放庫存,不會一直占著,等用戶支付成功,再次鎖庫存,超賣的話就提示,,可能適用商品的場景不同吧,對于一些量少而又要搶的商品,還是拍下扣庫存好點,因為很多人會支付成功,超賣時,都沒買到給他退款體驗就不太好了

    來自廣東 回復
  2. 淘寶好多都是原路返回的貌似,像購物車結算付款后,返回到購物車的頁面,只是購物車被清空了而已

    來自廣東 回復
  3. 學習了,支持!

    回復
  4. 美團外賣支持原路返回 了解一下

    來自廣東 回復
    1. 是的,但是外賣類產品和電商還是有區別的,一般沒有庫存的概念故沒必要想用戶展示預訂單;外賣屬于一次性消費而且具有即時性,通過待支付提升轉化沒有意義。

      來自廣東 回復
    2. 外賣平臺不存在庫存鎖定的問題,多賣最好。

      來自四川 回復
    3. 剛試了一下,美團外賣現在不能原路返回了

      來自北京 回復
  5. 結尾急了點

    來自浙江 回復
    1. 我也覺得,比較倉促

      來自廣東 回復
  6. 東方紅合伙人

    回復
  7. 看似干貨很多,但是讀了幾遍也沒給出答案,為什么不原路返回同時不生成生成待支付訂單?

    來自上海 回復
    1. 確實沒說太多干貨,我已經不咋看這類App了……
      回復你的建議:其實它就是沒有考慮用戶的需求,因為按照正常邏輯就應該是一步步返回,用戶哪里要修改了就可以停下修改嘛,目前電商產品的統一做法都反映的是商家自己的需求,把用戶的操作流程給切斷了甚至需要重新下單??

      回復
    2. 因為原路返回而不生成未支付訂單,用戶可能就不買了,生成了未支付訂單就可以提醒用戶支付,訂單成功的幾率就變大了

      回復
  8. 都不是啥問題,1)下單減庫存一般都會設置訂單的有效時間,如20分鐘(后臺配置)。用戶20分鐘內不支付,時間一到訂單直接失效,恢復商品庫存!2)支付減庫存,一般都會是支付成功才會去減少商品庫存,即使下的訂單超過了商品庫存,如最后一件商品有多個訂單,那都是誰先支付就是誰的,其他人去支付肯定不能給支付成功,會給提示商品已售馨!(第一種訂單失效時間最好用數據字典配置;第二種就是每次支付時還要去判斷當前商品的庫存)

    回復
    1. 老鐵, 方案1

      來自上海 回復
    2. 兩種都有把,類似于搶單支付的業務中更多就是方案二的流程,就像小米搶購流程一樣,先搶到訂單,支付完成才算購買成功,支付過程也存在庫存售罄

      來自湖北 回復
    3. 我字沒打完, 就鬧鬼回復了。。

      來自上海 回復
    4. 很多購買都是發生在碎片時間的,未支付有些很可能是發生了突發狀況。20分鐘的等待時間未必夠,我覺得8小時或者1天差不多。

      來自北京 回復
  9. 生成訂單時扣減庫存可以有一定的辦法預防惡意的重復下訂單。比如,第二個相同訂單增加驗證碼、限制多少時間內一個用戶對某個商品不可重復下單等等。 當然支付成功也可能被惡意占用庫存,只是成本較高。 限制的越嚴格用戶體檢就越差,想要做得好需要產品與市場來衡量這個點定在何處,并且要對重要促銷時產生的數據進行實時監控以及應急處理有較完善的處理方案。

    來自陜西 回復
    1. 我第一次下訂單,就購買庫存里所有的貨品,這怎么預防

      回復
    2. 一般后臺會有單個用戶id的限購數量設置

      回復
    3. 你這個方法不行喲,就像樓上說的,我不需要下多個訂單,一次性就把你的商品全部拍下!這個肯定是后臺要限制每個商品每個用戶id最多的購買數量,以及對待付款訂單的時效性進行處理

      回復
  10. 不太明白“超賣”概念。

    回復
    1. 就是買的人太多了,超過庫存量了,但是系統在下訂單的時候沒有減掉庫存,所以導致已經沒有庫存了但是還可以下單。

      來自遼寧 回復
    2. 現在庫存都是鎖定了的,只會提示支付不成功或者是庫存不足,可以下單但是并不能支付成功。

      來自四川 回復
  11. 加油,有待提高。

    回復
    1. ??

      回復
  12. 一個思維導圖 讓他弄懵!

    回復
  13. 這是表達什么結果啊?

    回復
    1. 支付取消之后為什么返回到待支付頁面

      回復
  14. 不知所謂…講了半天沒講出一點有價值的內容

    回復
    1. 我繼續努力,您多多指教

      回復
  15. 拍下減庫存中,某些用戶惡意占用庫存這個問題,現在都設置了商品最大購買數量,或促銷產品增加單日限購一件的限制。所以,這個漏洞基本不存在了。

    來自山西 回復
    1. 解決剛才那個問題,咋會去限制用戶每天僅能買一件嘛!我想多買幾件,實實在在付錢,咋辦?

      回復
    2. 比如衣服,多買幾件是可以的,不過沒人一次買5件或者10件以上吧?所以,不同的產品設置不同的購買上限唄。

      來自北京 回復
    3. 雖然限制一個賬戶購買量,但可以很多個賬號一起買嘛

      回復
  16. 補充:從技術的角度來說,幾乎沒有不可修改的信息(區塊鏈可能是個例外),待支付訂單即是商家與用戶達成的共識,達成共識之后那整個交易細節說明已經敲定好,也已映射為合同這個概念。

    來自廣東 回復