支付型的产品与普通的产品类型不同，需求文档中充斥着大量的业务词汇和场景，导致全局性的需求要更难一些。本文作者分享的这些经验，希望可以成为你的助力。
作为一个文科生转行到IT行业，我想最大的困难是很多时候我不太适应一堆堆技术术语组成的文档。
不过支付系统目前已经是很成熟的体系了，很多都是现成的服务，产品经理更多的职责体现在落地能力。
我所说的落地能力指的是结合商户的业务场景分析出商户需要匹配什么样的解决方案，以及根据现有系统的情况，需要做怎么样的改造或者新建。
本篇文章就简单阐述下，对于一个新业务，产品经理的工作流程是什么样的，以及需求文档如何写。
基于新业务，首先要调研和分析分析业务模式和业务痛点，这是产品经理的基本技能。
即使有行业特性，所谓的各行如隔山，产品经理也可以通过咨询相关业务同事或者商户侧的业务人员得到答案。
当然，如果产品经理在某一或几个行业上具备更多的经验视角，专门服务和拓展某类商户的话，就可以直接为一些商户展示解决方案，再根据商户的反馈去适配或者升级现有的功能。
做好以上的调研分析工作后，产品经理就需要评估如何能快速提供出符合商户或者渠道需要的支付解决方案了。
新业务的接入（前提是业务合理），第一步首先要考虑商户的进件以及计费模式。
商户的进件是一个商户准入的前提，需要与合规、风控、法务和财务等相关部门梳理出商户进件所需的材料。
产品经理需要将业务模式讲清楚，为相关审核同事提供业务支撑，必要时可请业务同事协助。
需要注意的是，很多时候业务的玩法超出想象，所以对于支付行业来说，做好必要的保密工作和交易监控是非常必要的。
在初始评审业务模式时，产品需要对可能存在的业务漏洞具备警觉性，以便在系统设计的各个环节上渗透，甚至必要时预警。
合规，法务，风控等相关审核同事评估好后，产品经理即可获取到商户需要提交的进件材料、计费模式（业务的收费项目），还有一些业务约束，比如限额等等信息。
一般情况下进件材料三证是必须的，特殊行业再加相应证件，比如物流行业需要加《道路运输许可证》等。
还有一些比如说法人代表身份证件，展业平台信息，办公或者营业场所照片等文件。
业务的收费项目做好后，还需要进一步确认记账规则，这一步是提前与财务沟通好的。
财务会分配记账科目，不同的业务类型有不同的记账规则，在支付的过程中会去调用记账规则存储数据，以便后续财务区分业务并做相关统计和分析。
财务还会有BDCA流程，即Bussiness Data Compliance Assurance ，就是业务数据合规安全保障的意思。
最重要的作用是通过各条链路数据上的比对，在有长短款出现的时候能及时发现预警。
BDCA对于有着大量交易的支付公司来说是非常必要的，会避免很多资金风险。
可以说，程序员写的代码就是个劳力，而BDCA是监工，让他们不要出错。
获取到记账规则后，后面就要考虑收费项目的配置问题，如果原有的费率系统不支持，那就要改造或者新建费用配置模版。
一般的收费模式会区分为卡支付和聚合支付。
卡支付一般是以银行为区分的，适配于各通道费用成本不同。再加一个默认兜底值，可以看做统一费率配置，既不区分银行。
聚合支付起初是按照支付方式区分的，比如APP支付，公众号支付、服务窗支付等等。
后来是按照行业属性既MCC计费的，比如大型商超，就属于线下渠道，电商平台就属于线上渠道。
以上的问题有了脉络以后，就该落笔需求文档了。
第一：背景交代。
业务场景说明，术语定义，业务流程等都要交代出来，以便研发和测试同学理解。
如有交互的，还需要出具交互流程和交互界面，以便研发和测试同学直观的理解前后端的需要如何联动。
第二：商户进件。
在商户进件时无论是调用接口还是页面提单，有相应的改造都需要同步，以保障支付产品上线后商户能顺利进件。
第三：产品开通。
商户接产品必然是有权限校验的，那么对应的开通环节也要同步改造。
第四：支付侧改造，也是最核心的一环。
一般情况下，如果通道的接口文档也是新的，那就需要研读通道接口文档，这里是指接入银联或者网联的渠道接口。
首先看接口文档支持的交易类型，比如说消费，撤销，退货，交易查询，退货查询，交易通知等等。
这些都是需要贯穿在前端的交易场景中的，一般来讲，通道的支持情况也决定了产品的体验。
举个例子，交易通知，是无论交易成功失败都通知，还是只支持通知成功的？是通知的最终结果，还是说有了终态后就通知一次？
比如云闪付支付，客户卡余额不足会通知一次支付失败，客户换卡支付成功后又通知一次支付成功。
如果只按照交易通知更新交易结果就会造成长款，既实际交易成功做了失败处理，资金就会滞留在中间户，需要给用户做退款处理。
退货交易要注意不要发起重复退货，重复退货会造成短款，在产品设计过程中遵循宁可长款，不可短款的原则。
因为长款可退，短款很难追，就会造成资金损失。
如果后端接口不是新启用的，那么只要关注现有的流程和接口如何改造即可。
以上摸索完之后就可以画流程图了。
支付流程需要明确各个系统如何调用如何返回，以及如有改造的需要如何改造。
查询流程主要是补充支付过程中对支付结果不明确的情况下的需要系统自动调用查询获取结果，也就是订单超时处理机制。
当然也有商户主动发起的交易结果查询。
交易结果通知一般都是异步通知，在系统设计时，和查询一样附在支付流程中。
支付通知和查询哪个先获取到了终态，就依据哪个变更订单状态，特殊逻辑特殊处理。
比如云闪付的情况，接收到交易通知后不更新订单状态，而是当订单有效期过了以后再次查询渠道获取结果更新。
退款流程要区分是否支持部分退货，如支持部分退款还需特意关注下发起退款时金额与总金额的比对，以免多退造成资金损失。
退款查询也是附带在退回流程中，也是为辅助获取退款结果或者支持商户主动发起查询使用。
卡支付还有鉴权流程，所谓鉴权和支付，其实可以理解为每次支付行为都要填写那么多信息你很烦，所以先出了个鉴权动作。
鉴权本身没有消费行为，但是它为后面的消费行为授权，无需再输入卡号信息。
鉴权时要注意是否支持重复鉴权，如果不支持，会返回什么信息，针对返回信息做不同的处理。
因为鉴权也是有有效期的，如果支持重复鉴权，就要关注鉴权的时间是否会重新计算。
当然还有消费鉴权的场景，就是鉴权和消费用同一个接口交互，支付功能都是适配于不同的业务场景的，所以虽然相对来说消费鉴权体验较好，但也不是每个业务场景都适配消费鉴权。
这就是支付产品的特殊之处，并不是每个动作都追求体验，安全相比体验会更重要些。
第五：商户手续费收取
这里需要先讲下清结算。
支付流程是商户请求，支付机构接收到指令请求到银行，银行返回相应信息，用户进行支付，银行进行扣款，并通知支付公司，支付公司再通知到商户的过程。
清结算是在这个流程中算费和结费的过程。
可以说清分是结算的数据准备阶段，结算才是支付的完结，他们分别代表着数据流和资金流。
清结算系统会定时或实时捞取交易信息，通过查询商户费率计算出手续费费用，刨除时效等不谈，需要强调下是净额结算还是全额结算。
全额结算顾名思义就是全额结算给商户，如基金公司的手续费都是后收。净额结算是去除手续费后结算给商户。
所以，清分就是在获取各种规则后计算出一个计费结果，作为数据存储起来。
结算就是根据清分的数据生产结算指令，结算给商户，至此支付完结。
清结算一般也都是成熟的体系，产品经理需要关注的是，一个商户入驻后，如何记账以及收取的各项手续费在哪里配置，如何配置？
商户的手续费配置都是建立在商户号下，根据不同的交易类型、支持的业务场景进行配置。
至于手续费是业务系统单独算，还是统一丢给清结算系统算，退货退不退手续费，部分退货手续费如何算，是否需要实时结算等等这些都是结合业务场景考虑并需要配置的 。
第六：对账。
通过以上信息其实整个支付流程已经完结了。那么商户对账也是一个重要的板块。
首先，对应的数据落地需要同步到数据对账系统，尤其是新增字段，对账系统也需要对应的改造。
如果支付都做好了，对账服务没提供，商户接入体验就会很差，虽然对账信息，可以通过人工拉取获取给到商户。
其实，要明确商户按照哪些关键字段对账，比如商户号+交易时间+交易类型等字段。
经常出现的问题是比如用户是23:58分发起的支付，但是在00:02分完成了交易，这种情况就要商户沟通好是以哪个时间为准。
这样，双方的账单才是平的。
当然也包含通道侧的对账，通道侧的对账信息一般在通道的接口文档中有规范，一般情况下都是按照银行的对账规则进行对账。
第七：注意下应用的叠加
比如支付方式下是否支持分账产品或其他服务。
这也是在充分沟通商户场景后判断的，新产品争取不要遗漏功能点，免得交付时不满足商户多样的业务场景。
第八：监控
前文提了一些，业务监控和系统监控都要考虑。
一般业务监控都是类似商户余额不足这种业务类的预警以及交易情况异常，需要产品经理介入分析和观测的预警。
系统监控一般是系统异常的报警。
忙活了以上这些后，就要做上线后的准备了。
第一：提交BDCA流程，前文已经介绍了BDCA的作用，不再复述。
转测后测试同学测的差不多了就应该提交财务流程了，正式上线前是需要财务审批通过的。
第二：准备合同模版。
一般商户模版是产品经理起草初稿，然后给到法务同事审核的。需要在产品上线前完成流程审批，以备商户进件使用。
第三：准备培训资料。
含技术培训文档、配置培训文档以及产品介绍文档。对应不同的角色进行不同的培训，确保商户接入时各角色就位，接入顺滑。
如果你认为前面产品经理貌似忙活了好多，其实那也只是开始，真正上线后才是打响了战斗。
因为商户在使用的过程中会提出优化点，或者新场景，产品经理需要在各个商户群中活跃。
听商户的痛点，看产品逻辑的缺陷，想产品的可拓展性以及准备相应的数据观测。
以上，简单的分享了下支付产品需求文档的脉络，浅薄之处，还望包涵，如有错误，也欢迎指正交流。
本文由 @想个昵称想半天 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。