要想了解支付渠道的业务规则，首先需要知道目前主要的支付渠道、支付产品有哪些，是什么模式，然后商家根据自身产品及业务模式去匹配最优的支付方式。
一般情况下对接的支付渠道有两类：
每个渠道有自己的收款产品，对应在不同的支付终端上使用。这里讲一下，「支付终端」换成「支付场景」也是合适的，不同公司团队个人叫法可能有所不同，总之方便理解来看就是电脑网站、手机网站以及手机应用等等。
这里将各个渠道的收付款产品放到了对应的支付终端下，不同支付终端下支持的渠道支付产品也有所区别，且需要独立申请开通权限。
简单介绍了商家收款，我们也来看看商家付款的产品功能：
下面一张图看看转代付和分账的区别：
B商家发起收款100元，后续可以给C端商家或者B端商家进行打款。这里需要注明的是，给商家或者用户打款的X和Y元，跟100元没有必然联系，只要确保出款账户内资金足够用于B商家打款即可。
2.行业准入和区别
（1）商家收款类别
实物类：医疗类的会有资质文件才可以申请，比如医疗器械、身体康复用品的需要持有《医疗器械经营企业许可证》、经营内容包含美瞳或者隐形眼镜，则需要提供《第三类医疗器械销售资质》等等；虚拟类：比如游戏道具购买，需要具备《网络文化经营许可证》。
2）商家的行业可以直接参照腾讯或者支付宝的的商家类目、费率、资质的文档，简单粗暴，可以到官网上了解一下。
3）这里提及一下，前面的花呗分期和京东白条产品：使用的前提都是至少拥有支付宝或者京东对应的基础支付功能，才能进一步申请分期的产品权限，目前两家的分期产品的权限都是需要单独联系BD，走线下申请的流程，周期较长。
（2）商家付款类别
①费用
看代付的费用从两种情况来看，一个是付款到银行卡，一个是付款到钱包账户。
前者的费用一般是按照单笔手续费计算，比如1-2元/笔。后者代付到钱包一般是免费，这个手续费商家不承担，主要在用户发起提现的时候会需要支付提现手续费。
②限额
各家支付机构不一样，但是主要需要与支付机构沟通的是单笔、单日、单月、以及每天的调用频次等是否有限制，限制是多少。
避免业务部门已经申请完成了渠道，后面产品对接发现根本不能满足业务应用场景，那就后使用起来就GG了。
④支持的银行
早期商家跟渠道的合作比较单一，但是近2年渠道也推出来比较多的合作模式来吸引商家以及合作伙伴。
简单介绍下各种合作模式：
直连直连（入驻）普通服务商银行服务商
各种合作模式的优缺点
4.退款处理规则
接下来我们讲讲退款，原先「退款」这一块的逻辑是放在后面渠道开发对接部分的。
但是因为近期日常渠道运营中遇见了一个关于手续费的问题，退款是否退回手续费的问题一定程度上决定了某些特定场景的商户对于支付渠道的选择，因此把它提到业务规则中来聊一聊。
因此需要提前捋顺几个问题：
退款功能是否需要提前额外申请退款周期是否需要延长退款资金是否需要额外充值：待结算账户、余额充值账户退款或者撤销是否退回原订单的支付手续费
以下是一张关于各渠道的退款周期，是否退回手续费以及退回手续费的逻辑说明：
5.支付渠道对接及管理
（1）资金结算方式
（2）获取对账单方式
业务需要提前确认获取对账单方式，是只能通过商户平台下载还是也能通过接口下载。
如果通过接口下载是否需要提前走申请流程，因为我们有遇见过一些支付渠道下载对账单也需要提前走线下公司盖章的申请流程，周期略长。前期若没有确认好，会都后期项目开发周期造成影响。
（4）区分不同交易对账单
二.支付渠道对接及管理
第一部分主要讲了商家的业务部门在前期申请渠道时候，场景适配以及需要提前跟渠道沟通了解的注意事项。
第二部分就涉及到产品技术对接阶段的一些细节处理。
1.渠道对接步骤和内容
公司内各个部门不同的产品，线上线下产品适用场景不同，费率会有所区分，注意事项在第一部分已经阐述。
①是否需要添加出口IP
部分渠道需要添加IP白名单才可以进行开发、测试调试，有些渠道较快的能添加完成，但是有些银行类的可能要走比较漫长的线下申请。
②对接的接口版本
不同支付渠道的接口版本对应的支付渠道的参数也不一样，所以在商务确定产品合作后需要确认对应的业务申请参数和渠道开发的接口版本是否一致。
③订单号长度和组合
④交易金额单位
一般情况下单位都是以「分」为单位，但也遇到过以「元」为单位的情况。
⑤商品描述特殊字符，是否展示在用户可见的渠道支付页
⑥收款公司名称展示
常规情况下，大部分支付渠道是可以在后台进行设置或者在入网时有很清晰的提示，但是有些渠道是通过某个字段来进行填写并上传的，比如建行龙支付。
⑧分期支付是否支持前置展示
主要是用户体验的问题，假设不做前置展示可能会在最后一步支付时流失掉这个订单。
⑨是否支持禁用信用卡
有些商家不希望用户支付使用信用卡，部分渠道可以通过请求参数字段进行设置，也有渠道通过入网签订协议后台配置。
⑩前端带回的参数信息
大部分商家比较在意前端带回的结果参数信息，例如订单号、支付结果等等
①可退款订单周期、权限开通
之前在对接线下扫码支付，走服务商模式，退款权限并不默认开通，需要走线下申请的流程后才可以开通。可退款订单周期如之前提及，需要提前申请确认。
②单笔订单退款次数、频率限制
③是否支持原单重试
④是否支持部分退款&是否退还手续费以及计算逻辑
对接的渠道大部分都支持部分退款，但是有些个别的渠道是支持退款不退手续费。因此商家遇到用户退款的情况，就会在退款时损失手续费。同时对计算逻辑也要进一步确认，有些渠道的手续费分两部分，一部分是固定手续费，一部分是动态手续费。在退款时也会有全退、只退动态手续费不退固定手续费以及手续费全部不退的情况。
⑤多选一单号请求，需要确认优先级
⑥退款描述特殊支付，是否展现在用户可见的地方
这部分和前面是一样的，就不细说了。
⑦是否支持退款的异步通知
这块主要是需要清楚地明白和业务的关联点在哪里，一般在退款接口上会有区分字段提示。
⑨同步返回的状态，是否可以作为最终结果
该种情况除了接口文档上的描述外，建议与渠道再做二次确认。通常是根据异步通知或者查询的退款结果进行更新，但是存在部分渠道建议直接根据创建退款同步返回结果直接判断的情况，比如支付宝国际的退款，并不提供退款查询接口。
①支付和退款的查询是否区分接口
有的渠道不作区分，但有的渠道例如单号是区分支付成功单号以及退款单号两种不同的字段。
②确认查询接口展示的状态参数
比如退款、用户被扫等模式可能存在多个状态，需要考虑多状态之间的关系和更新逻辑。
③多选一单号查询，需要确认优先级
与前文相同，不做赘述。
④区分通信结果、业务结果、交易结果
查询一个交易结果之前需要判断通信结果以及业务结果，最终展示的交易状态要根据交交易结果来判断。
⑤结算金额、优惠金额、退款渠道等信息是否返回
常规情况下渠道会通过支付成功之后的异步通知或者查询返回对应的信息，但是也存在部分渠道是通过后台配置的优惠信息，仅在支付成功页面、对账单中才有体现，并不会体现在交易返回参数中。
例如支付宝国际支付，查询与异步通知返回的信息不一致，是由于币种的转换造成的。存在部分返回信息需要提前邮件申请进行配置，虽然对外并没有文档指引和说明。
⑦查询频率是否限制，是否有建议的查询间隔机制
不同的渠道略有不同，有的渠道对频率有限制、间隔有限制。因此在前期需要确认。
①各种交易是否有异步通知
产品与技术对接过程当中，需要稍微注意一下，因为渠道的文档都放一起，按照惯例是都有的，但是背不住要踩坑，比如线下支付的用户被扫模式。
②异步通知地址是请求上送还是后台固定配置
不同渠道不一样，大部分是通过接口请求上送；小部分渠道通过后台固定地址配置。
③何种状态会触发异步通知
需要校验异步通知的状态类型，比如支付成功、订单支付中、订单关闭等等，避免未区分异步通知类型导致错误更新订单状态。
⑤是否带回交易请求上送的附加信息
在渠道提供的交易请求信息并不足以区分商家内部的业务订单时，商家往往还会上送额外的字段信息，有些渠道有去无回，即异步通知不带回该额外信息，导致商家业务更新异常。
⑥重试机制以及恢复信息
⑦签名验证或IP白名单
异步通知的验证真伪性一般可以通过签名或者IP白名单，如果是IP白名单的话提现与渠道确认好出口IP。
2.常见对接问题和解决方案
一般情况下上图中的情况会导致交易异常，因此建议商家除了对接渠道异步通知也要对接查询接口，可以设置查询任务；同时不建议商家以业务查询结果为参考，查询服务端的订单状态，一旦不一致就调用接口去查询一下，更保险。还有不要查询频率太高，可能造成渠道结果返回不了。
本文由@支付学院原创发布于人人都是产品经理。未经许可，禁止转载