起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識淺淺分享下支付產品經理如何寫全局性的需求文檔以及工作流程
支付型的產品與普通的產品類型不同，需求文檔中充斥著大量的業務詞匯和場景，導致全局性的需求要更難一些。本文作者分享的這些經驗，希望可以成為你的助力。
作為一個文科生轉行到IT行業，我想最大的困難是很多時候我不太適應一堆堆技術術語組成的文檔。
不過支付系統目前已經是很成熟的體系了，很多都是現成的服務，產品經理更多的職責體現在落地能力。
我所說的落地能力指的是結合商戶的業務場景分析出商戶需要匹配什么樣的解決方案，以及根據現有系統的情況，需要做怎么樣的改造或者新建。
本篇文章就簡單闡述下，對于一個新業務，產品經理的工作流程是什么樣的，以及需求文檔如何寫。
基于新業務，首先要調研和分析分析業務模式和業務痛點，這是產品經理的基本技能。
即使有行業特性，所謂的各行如隔山，產品經理也可以通過咨詢相關業務同事或者商戶側的業務人員得到答案。
當然，如果產品經理在某一或幾個行業上具備更多的經驗視角，專門服務和拓展某類商戶的話，就可以直接為一些商戶展示解決方案，再根據商戶的反饋去適配或者升級現有的功能。
做好以上的調研分析工作后，產品經理就需要評估如何能快速提供出符合商戶或者渠道需要的支付解決方案了。
01 需求文檔落地前準備
新業務的接入（前提是業務合理），第一步首先要考慮商戶的進件以及計費模式。
商戶的進件是一個商戶準入的前提，需要與合規、風控、法務和財務等相關部門梳理出商戶進件所需的材料。
產品經理需要將業務模式講清楚，為相關審核同事提供業務支撐，必要時可請業務同事協助。
需要注意的是，很多時候業務的玩法超出想象，所以對于支付行業來說，做好必要的保密工作和交易監控是非常必要的。
在初始評審業務模式時，產品需要對可能存在的業務漏洞具備警覺性，以便在系統設計的各個環節上滲透，甚至必要時預警。
合規，法務，風控等相關審核同事評估好后，產品經理即可獲取到商戶需要提交的進件材料、計費模式（業務的收費項目），還有一些業務約束，比如限額等等信息。
一般情況下進件材料三證是必須的，特殊行業再加相應證件，比如物流行業需要加《道路運輸許可證》等。
還有一些比如說法人代表身份證件，展業平臺信息，辦公或者營業場所照片等文件。
業務的收費項目做好后，還需要進一步確認記賬規則，這一步是提前與財務溝通好的。
財務會分配記賬科目，不同的業務類型有不同的記賬規則，在支付的過程中會去調用記賬規則存儲數據，以便后續財務區分業務并做相關統計和分析。
財務還會有BDCA流程，即Bussiness Data Compliance Assurance ，就是業務數據合規安全保障的意思。
最重要的作用是通過各條鏈路數據上的比對，在有長短款出現的時候能及時發現預警。
BDCA對于有著大量交易的支付公司來說是非常必要的，會避免很多資金風險。
可以說，程序員寫的代碼就是個勞力，而BDCA是監工，讓他們不要出錯。
獲取到記賬規則后，后面就要考慮收費項目的配置問題，如果原有的費率系統不支持，那就要改造或者新建費用配置模版。
一般的收費模式會區分為卡支付和聚合支付。
卡支付一般是以銀行為區分的，適配于各通道費用成本不同。再加一個默認兜底值，可以看做統一費率配置，既不區分銀行。
聚合支付起初是按照支付方式區分的，比如APP支付，公眾號支付、服務窗支付等等。
后來是按照行業屬性既MCC計費的，比如大型商超，就屬于線下渠道，電商平臺就屬于線上渠道。
02 準備寫需求文檔
以上的問題有了脈絡以后，就該落筆需求文檔了。
第一：背景交代。
業務場景說明，術語定義，業務流程等都要交代出來，以便研發和測試同學理解。
如有交互的，還需要出具交互流程和交互界面，以便研發和測試同學直觀的理解前后端的需要如何聯動。
第二：商戶進件。
在商戶進件時無論是調用接口還是頁面提單，有相應的改造都需要同步，以保障支付產品上線后商戶能順利進件。
第三：產品開通。
商戶接產品必然是有權限校驗的，那么對應的開通環節也要同步改造。
第四：支付側改造，也是最核心的一環。
一般情況下，如果通道的接口文檔也是新的，那就需要研讀通道接口文檔，這里是指接入銀聯或者網聯的渠道接口。
首先看接口文檔支持的交易類型，比如說消費，撤銷，退貨，交易查詢，退貨查詢，交易通知等等。
這些都是需要貫穿在前端的交易場景中的，一般來講，通道的支持情況也決定了產品的體驗。
舉個例子，交易通知，是無論交易成功失敗都通知，還是只支持通知成功的？是通知的最終結果，還是說有了終態后就通知一次？
比如云閃付支付，客戶卡余額不足會通知一次支付失敗，客戶換卡支付成功后又通知一次支付成功。
如果只按照交易通知更新交易結果就會造成長款，既實際交易成功做了失敗處理，資金就會滯留在中間戶，需要給用戶做退款處理。
退貨交易要注意不要發起重復退貨，重復退貨會造成短款，在產品設計過程中遵循寧可長款，不可短款的原則。
因為長款可退，短款很難追，就會造成資金損失。
如果后端接口不是新啟用的，那么只要關注現有的流程和接口如何改造即可。
以上摸索完之后就可以畫流程圖了。
支付流程需要明確各個系統如何調用如何返回，以及如有改造的需要如何改造。
查詢流程主要是補充支付過程中對支付結果不明確的情況下的需要系統自動調用查詢獲取結果，也就是訂單超時處理機制。
當然也有商戶主動發起的交易結果查詢。
交易結果通知一般都是異步通知，在系統設計時，和查詢一樣附在支付流程中。
支付通知和查詢哪個先獲取到了終態，就依據哪個變更訂單狀態，特殊邏輯特殊處理。
比如云閃付的情況，接收到交易通知后不更新訂單狀態，而是當訂單有效期過了以后再次查詢渠道獲取結果更新。
退款流程要區分是否支持部分退貨，如支持部分退款還需特意關注下發起退款時金額與總金額的比對，以免多退造成資金損失。
退款查詢也是附帶在退回流程中，也是為輔助獲取退款結果或者支持商戶主動發起查詢使用。
卡支付還有鑒權流程，所謂鑒權和支付，其實可以理解為每次支付行為都要填寫那么多信息你很煩，所以先出了個鑒權動作。
鑒權本身沒有消費行為，但是它為后面的消費行為授權，無需再輸入卡號信息。
鑒權時要注意是否支持重復鑒權，如果不支持，會返回什么信息，針對返回信息做不同的處理。
因為鑒權也是有有效期的，如果支持重復鑒權，就要關注鑒權的時間是否會重新計算。
當然還有消費鑒權的場景，就是鑒權和消費用同一個接口交互，支付功能都是適配于不同的業務場景的，所以雖然相對來說消費鑒權體驗較好，但也不是每個業務場景都適配消費鑒權。
這就是支付產品的特殊之處，并不是每個動作都追求體驗，安全相比體驗會更重要些。
第五：商戶手續費收取
這里需要先講下清結算。
支付流程是商戶請求，支付機構接收到指令請求到銀行，銀行返回相應信息，用戶進行支付，銀行進行扣款，并通知支付公司，支付公司再通知到商戶的過程。
清結算是在這個流程中算費和結費的過程。
可以說清分是結算的數據準備階段，結算才是支付的完結，他們分別代表著數據流和資金流。
清結算系統會定時或實時撈取交易信息，通過查詢商戶費率計算出手續費費用，刨除時效等不談，需要強調下是凈額結算還是全額結算。
全額結算顧名思義就是全額結算給商戶，如基金公司的手續費都是后收。凈額結算是去除手續費后結算給商戶。
所以，清分就是在獲取各種規則后計算出一個計費結果，作為數據存儲起來。
結算就是根據清分的數據生產結算指令，結算給商戶，至此支付完結。
清結算一般也都是成熟的體系，產品經理需要關注的是，一個商戶入駐后，如何記賬以及收取的各項手續費在哪里配置，如何配置？
商戶的手續費配置都是建立在商戶號下，根據不同的交易類型、支持的業務場景進行配置。
至于手續費是業務系統單獨算，還是統一丟給清結算系統算，退貨退不退手續費，部分退貨手續費如何算，是否需要實時結算等等這些都是結合業務場景考慮并需要配置的 。
第六：對賬。
通過以上信息其實整個支付流程已經完結了。那么商戶對賬也是一個重要的板塊。
首先，對應的數據落地需要同步到數據對賬系統，尤其是新增字段，對賬系統也需要對應的改造。
如果支付都做好了，對賬服務沒提供，商戶接入體驗就會很差，雖然對賬信息，可以通過人工拉取獲取給到商戶。
其實，要明確商戶按照哪些關鍵字段對賬，比如商戶號+交易時間+交易類型等字段。
經常出現的問題是比如用戶是23:58分發起的支付，但是在00:02分完成了交易，這種情況就要商戶溝通好是以哪個時間為準。
這樣，雙方的賬單才是平的。
當然也包含通道側的對賬，通道側的對賬信息一般在通道的接口文檔中有規范，一般情況下都是按照銀行的對賬規則進行對賬。
第七：注意下應用的疊加
比如支付方式下是否支持分賬產品或其他服務。
這也是在充分溝通商戶場景后判斷的，新產品爭取不要遺漏功能點，免得交付時不滿足商戶多樣的業務場景。
第八：監控
前文提了一些，業務監控和系統監控都要考慮。
一般業務監控都是類似商戶余額不足這種業務類的預警以及交易情況異常，需要產品經理介入分析和觀測的預警。
系統監控一般是系統異常的報警。
03 上線后的準備
忙活了以上這些后，就要做上線后的準備了。
第一：提交BDCA流程，前文已經介紹了BDCA的作用，不再復述。
轉測后測試同學測的差不多了就應該提交財務流程了，正式上線前是需要財務審批通過的。
第二：準備合同模版。
一般商戶模版是產品經理起草初稿，然后給到法務同事審核的。需要在產品上線前完成流程審批，以備商戶進件使用。
第三：準備培訓資料。
含技術培訓文檔、配置培訓文檔以及產品介紹文檔。對應不同的角色進行不同的培訓，確保商戶接入時各角色就位，接入順滑。
04 上線后的關注
如果你認為前面產品經理貌似忙活了好多，其實那也只是開始，真正上線后才是打響了戰斗。
因為商戶在使用的過程中會提出優化點，或者新場景，產品經理需要在各個商戶群中活躍。
聽商戶的痛點，看產品邏輯的缺陷，想產品的可拓展性以及準備相應的數據觀測。
以上，簡單的分享了下支付產品需求文檔的脈絡，淺薄之處，還望包涵，如有錯誤，也歡迎指正交流。
本文由 @想個昵稱想半天 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
