零售行業發展至今，無論是大型還是小型商戶，線下商超還是 WooCommerce 連鎖店鋪，高頻低額還是低頻高額的交易場景，一個好的 ERPWooCommerce 收銀系統是整個交易環節的不可或缺的元素之一，易操作、快速收銀、支付體驗佳等均是衡量一個 WooCommerce 收銀系統是否為一個好產品的標準。
而在支付過程中，難免遇到一些系統或操作導致的異常從而導致交易阻塞甚至是客訴，那麼儘量避免系統發生異常或發生異常時的解決策略，也是我們在設計產品時需要考慮的。
如何設計一個收銀產品這裡就不多說了，感興趣的同學可以搜尋一下相關資料，下面和大家簡單討論下如何透過一些小技巧減少支付異常率。
目前線下 WooCommerce 收銀系統多采用 CS 設計模式——即客戶端/服務端分離，使用時需安裝獨立客戶端，交易過程中和第三方支付系統互動的多為商戶系統的服務端，我們可分別在客戶端/服務端做改動從而實現我們的需求。
一、支付前校驗/支付後判重
支付前校驗：在建立完待付款訂單後，服務端呼叫支付 API 前，對該訂單進行校驗，是否為待支付訂單。若是待支付訂單，則繼續進行支付，若否，則直接對該訂單進行處理。
支付後判重：商戶系統在收到支付結果後，同樣根據業務引數對此訂單進行判斷是否為重複訂單或異常訂單而做出對應處理。
做好支付前校驗和支付後判重，能有效解決同比訂單重複支付、重複生效等相關異常問題。同樣在建立訂單或訂單支付成功生效後也可以做校驗訂單狀態的動作從而達到更好的過濾效果。
二、部分系統引數配置化
商戶系統在接入第三方支付時，呼叫第三方系統提供的 API，除了需要傳入業務引數，還需要傳入大量系統引數，如下圖展示的支付寶支付 API 介面中的 app_id 、 sign 等，若在程式碼中固定，日後如需修改或維護均要進行測試上線等流程，耗費大量資源。若採用在管理後臺配置、交易過程中直接從後臺查詢 獲取的方式，便於商戶系統對支付方式的管理，同時也更利於日後接入其他支付方式的拓展
三、提供主動撤銷的入口
目前業內第三方支付服務商在在交易時返回支付結果多采用主動通知或提供查詢服務讓商戶系統自行查詢，但即使商戶系統同時接入這兩種服務或做了輪詢和 異常場景主動撤銷的機制，仍存在多種原因導致無法獲取支付結果，如網路異常，介面異常，引數異常等，從而造成使用者扣錢而訂單未成功引起不必要的糾紛。
遇到此種場景不要慌張，多數支付系統會提供撤銷的服務，我們只需在商戶系統中加入可以主動撤銷的入口，手動撤銷此訂單，便可很輕鬆解決此問題，但入口和操作許可權控制也需深思。
四、提供手工再次發起查詢的入口
上文提到要留主動撤銷的入口以主動解決異常訂單，但對於商戶來說損失一筆訂單畢竟不是一個上等決策，幸好大多數支付系統會提供查詢服務供商戶系統查詢訂單狀態。
因此我們在 WooCommerce 收銀系統中可預留一個再次發起查詢訂單狀態的入口及時挽回損失，但此場景僅適用於支付成功、商戶未獲取到支付結果而導致的支付異常場景。
五、要留再次發起退款的入口
商戶系統在退款時也同樣會存在退款失敗的問題，如商戶系統退款完成而並未呼叫支付系統的退款服務或呼叫退款服務時失敗，且有些第三方服務商也不會同步返回退款結果，從而造成在商戶系統中退款成功而實際並未給使用者退錢。
若此時加入可以再次發起退款的入口直接呼叫退款服務完成退款，可有效解決部分退款異常問題。
以上觀點僅供參考，小夥伴們在運用時一定要結合實際業務場景進行使用，切勿照貓畫虎，有些異常可透過定時任務解決的就不用開放手動處理的入口了，而有些功能一定要注意許可權的控制。
用好了能提升產品的使用體驗，降低異常發生的頻率，用不好會引起大問題。
本文來源：人人都是產品經理