注：標題有點繞口，先來做一番解釋：我們在電商平台進行交易的過程中，待到支付環節的時候，假如使用者這時強制選擇「返回」，之後頁面如何該跳轉，以及訂單該如何處理？
文/產品範
這個問題**於這段時間負責的電商專案，關於頁面跳轉邏輯日常的和開發進行了一番撕逼，開發堅持認為應該原路返回，堅決站在使用者的角度 ，允許使用者返回修改訂單資訊，bala程式設計客棧bala。
乍一看，這個問題不過是表現層方面的問題，仔細思考後，這個問題並不簡單，隱藏著一些列不為人知的情節，且聽我一一梳理
做產品這段時間以來，總結出乙個有趣現象。每每和其他同事爭論到刀光劍影的時刻，對方很容易就會把「使用者」這尊大佛搬出來，頓時突然想笑。
做產品以使用者為中心，沒錯，但是不管你是開發還是設計你僅僅代表的是你自己，不要輕易去代表使用者，這樣的討論其實是蒼白的，沒有實際價值。
相比於「使用者」這尊大佛，用資料才是最高端的做法，要學會用資料替你說話。不會撕逼的產品不是好產品，既然撕逼一定要撕得漂亮一點。
想必大家都曾遇www.cppcns.com到過這個問題，在電商購物的過程中，已經走到了最後一步：去支付。這個時候突然意識到商品數量不對，或者收貨資訊選錯。
除此之外，使用者還存在之下返回的原因：
（1）目前幾乎所有主流電商平台，在支付頁面點選返回跳轉到訂單的待支付頁面。
（2）有一部分微**，依然原路徑返回，不過依然生成了待支付訂單。
（3）原路返回，也不生成待支付訂單，不過作者目前並沒有找到此型別的案例。
在電商系統中，前端頁面顯示的庫存與倉庫的實體庫存是不同步的，因而在商品出倉前要求前端的庫存進行「鎖定」即前端的減庫存。
關於庫存的鎖定，電商領域存在有兩種方案：
拍下減庫存存在的問題：
使用者可能拍下不買，不乏存在有使用者把拍下當夾用，以致占用庫存，影響平台的交易量。甚至存在更為極端的「噁拍」漏洞，競爭對手會把商品所有庫存全都拍掉，也不付錢，平台的商品就全部被下架了。
支付成功減庫存存在的問題：
支付成功減庫存會碰到最嚴重的問題，是「超賣」。因為系統在付款成功之前，都不減庫存，所以總是會發生「短時間很多人都拍下，甚至都付錢了，但是系統卻發現庫存不夠了」。
買家拍下商品後，從提交付款到付款成功的之間是有時間差的，因為付款的動作是在幾個不同的系統之間傳資訊。因此最後一件商品可能被多人拍下，這幾個人都可能付款成功。
**的做法是把何時減庫存的決定權交給賣家，然後告知賣家兩個方案各自適應的場景。
電商是通過交易驅動的產品型別，因此訂單的每一步都要考慮轉化率，提高轉化率是電商的基礎要求。
使用者在電商下單，大多都是會進行一番思考的，畢竟支付寶裡的錢也不是河水流過來的。使用者在支付前總會有種種原因擱置付款，一般待支付訂單的有效時間為 24 小時以內，在這段有效時間內平台就像一名**員一樣，告知你有未付款的訂單。
結果是幾乎所有的電商都採用了從支付頁面返回跳轉至待支付的方案。
資料是最客觀公證的，當場景遇到矛盾的時候，用資料來做決策。
電商後台 促銷中心 邏輯
中心 形式 形式設計測試用例思路 滿減 1.減價的金額不能大於等於商品原價 使用等價類邊界值的方法 2.階梯滿減，下一階梯要大於上一階梯 3.階梯最多設定多少個？單品 價不能高於等於原價 使用等價類邊界值的方法 套裝 商品a和商品b組成套裝的總價不能大於等於原價 贈品 1.贈品最多贈多少件？2.訂單...
Ofbiz的電商的新建使用者邏輯
註冊使用者的程式邏輯如下 1 在newcustomer.groovy中根據productstore中讀取相關資料。2 setdependentdropdownvaluesjs.ftl中定義了聯動的下拉框.其中getdependentdropdownvalues為乙個通用的下拉框級聯函式，定義在mis...
電商 支付 支付流水表與訂單表的設計
一.支付流水表 作用 主要用於記錄每一次的支付動作，主要用於，記錄使用者是否有重複支付，重複支付或者過期支付，可以用於檢查，然後退款。二訂單表 1.說訂單表，一般都是主表和子表兩個結構。1.1主表記錄買家買了什麼？付款是多少錢？總的優惠是多少？還有要發往 的位址？1.2子表主要記錄賣家的資訊，賣的是...