本文主要是与大家分享一种支付宝渠道服务商的的业务模式，这种业务模式对没能拿到支付牌照且有资源的公司或企业来说具有普适性；但前提是能够获得支付宝或者微信的的渠道服务商资格（简称isv，本文以支付宝的isv为例子进行阐述），且能在各大银行中混得开，以求得结算通道。

下图为行文的顺序：首先介绍有关支付宝渠道服务商的相关知识，譬如相关概念、接口等；其次会以一种集成了支付宝三个接口的综合支付运营系统为例，具体阐述相关业务的始末。希望能给大家带来些许不一样的视角。

支付宝ISV

支付宝ISV（也称系统开发商）可代支付宝完成商家签约、当面付集成、优惠活动配置的主体，为商户提供线下支付宝收款、入驻口碑、发布折扣和支付宝商家服务窗等服务。

就个人理解而言，支付宝isv渠道商一般都是具有独立软件研团队的公司和企业。说穿了，这种公司存在的理由无非是在支付宝有一定的资源，靠着关系拿到了支付宝的几个接口，面向某一邻域的商户，为其提供商业变现的解决方案，并从中拿到分润。具体业务模式如下：

1、首先，公司或者企业必须获得支付宝的承认，与支付宝签订N年的渠道服务商，其中必须明确其后系统集成的支付接口的详情；并同时设置支付的对应接口的费率，每个接口都对应设置。一般：支付宝app为1.0、支付宝wap1.0、支付宝即时到账0.6。

2、然后，公司必须能够与一家银行合作，为商户解决每日的结算款的处理问题，同时也避免了二清。这其中，系统与银行端的交互基本上是相关的接口请求与响应。

3、其次，如果公司的资源很多，能够拓展数以千计甚至万计的商户，此时可以想“代理链条”模式。

此模式能够在很大程度上将系统的交易额提升到一个客观的高度，且能“借他人之手”来管理商户，一举两得。

4、最后，也是最最关键的，任何商业活动最终都会与“钱”挂钩，支付更不例外。因此，在设定支付宝成本费率的同时，公司也会与代理商签订合同，合同中就包含对应的代理商对应三个接口的费率；而商户则会与被其拓展的代理商进行合同签约，此时也会设定商户费率。而这三个费率必须满足一下关系：支付宝成本费率 ≤ 代理商陈本费率 ≤ 商户成本费率支。（此外，商业银行对每笔订单也会收取对应的手续费）否则，系统结算就会行不通。具体费率计算会在下一章节的结算中给出具体的计算公式。

5、支付上下游各方收取的手续费总和为商户被扣的手续费。

（ps：商业的本质其实是钱与服务发生了关系的存在）

线上支付系统

该系统集成了支付宝线上三种接口：支付宝即时到账、支付宝wap、支付宝app，其本身就是一个功能齐全、业务逻辑复杂的后台运营系统。可以理解为一个CRM为过，因为该系统确实管理和运营者支付下游代理商、商户的关系。如下图，为线上支付系统的元素介绍。其中商户平台通过代理商平台与运营平台发生简介数据流关系。

系统操作权限解析

不管是怎样的系统，都会设计到账号登录。针对这种复杂的业务系统，登录权限设计更是必不可少。本系统主要采用“分而治之”的设计思想，大致思路如下：

1. 从一个超级管理员账号出发，在运营平台为代理商创建账号；
2. 然后，代理商用全局唯一的账号登录代理商平台，然后再为次代理商创建不同系统角色的用户来管理用户；
3. 最终，商户的登录账号由代理商平台商户报件时自动生成。

整个支付运营系统的功能分为四个部分：（代理商开户）商户报件、支付（开发面向下游商户的三个支付接口）、渠道对账、商户结算。如下具体的泳道图。

代理商开户

运营人员为代理商进行开户操作流程如下：

1. 代理商需要与企业签订相关协议，其中协议的主要内容包含所用支付接口的个数、接口费率等；
2. 代理商签订合同后，会在相应时间里将代理商公司的企业信息、绑卡信息、费率信息以文档的形式提交给运营人员；然后由运营人员在系统进行录入、审核；审核通过后会为该代理商创建登录账号，方便代理商登录代理商系统。

商户报件

商户报件也即商户入驻：

1. 商户入驻平台类似大学生入学，你得提供相关个人信息（身份证、手机号等），由学校相关人员（运营人员）将你的信息录入教务系统，然后审核通过后，为你生成全局唯一的学号（商户编号）。
2. 商户入驻平台时填报的信息包含：法人基本信息、费率信息、绑卡信息。
3. 此操作需要代理商在代理商平台进行页面表单填报操作。
4. 因为对接的是支付宝的交易接口，因此商户报件的基本信息要提交到支付宝后天进行审核。在整个过程中会调用支付宝黑名单查询接口和支付宝间连商户入驻接口。

支付

提供给下游商户的额接口包括支付宝即时到账支付、支付宝WAP支付、支付宝APP支付。

描述： 

1. 用户通过商户平台下单，商户系统确认订单后对订单信息进行MD5加密，然后通过网络上传至代理商系统；
2.  代理商系统也采用类似的加密方法，对商户订单进行验证，然后将加密的订单信息向上游传递；
3.  运营管理系统接收到下游订单，也会采用加密机制进行验证，确认后，系统向代理商系统返回支付页面的URL;紧接代理商系统向商户系统传递URL，最终由商户系统向用户展示URL对应的支付界面；
4. 商户直接与支付宝收银台交互：输入支付密码，提交支付申请后，支付宝系统确认支付成功。
5. 支付宝确认支付成功后，首先会回调支付结果给企业运营平台，然后再由企业运营平台回调给代理商系统。完成整个支付流程。

对账

设计到该支付系统的对账为渠道对账。

1. 本系统的渠道对账是指在当天某个时间通过网络协议从支付宝获取前一天平台的交易订单信息（支付宝商户号、支付订单号、商户订单号、交易金额、支付渠道、支付时间等），一般以excel的形式从服务器上获取。
2. 获取渠道对账文件后，将其与平台数据库订单表里的前天交易流水进行一一比对，判断订单是否出现问题（包含：无误、长款、短款、金额不一致）
3. 长款指运营平台有此笔订单而渠道对或者那个文件里却没有。造成的原因主要是发生日切的情况下（23：59：00），平台记录了商户提交了订单，但由于用户未能及时支付；等到支付后，时间可能来到了第二天00：10：01。此时，同一笔交易就跨越了两个时间维度（今天和明天）。
4. 对于长款的处理一般会将平台的长款订单进行逻辑处理，使其在明天的对账过程中再次举行对账。
5. 一般短款、和金额不一致的情况几乎不可能发生，平台可不做处理。
6. 另外，当日对账完成后，系统可以生成对应的报表，其中典型的是对账差异报表。

结算

说到结算，可能很多小伙伴们会比较兴奋；因为，经过前面的一些“播种”、“施肥”操作，终于到了丰收的时候。其实，结算就是通过银行通道将商户每天的扣除手续费后的交易额打到商户的结算卡上的一个过程。如果细心的话，这里的提到的“结算卡”就是商户报件时提到的结算卡。

下面的费率计算公式完全可以为ni所用：

诚然，支付系统是一个以业务为主导的互联网产品。如上叙述的支付渠道“贩子”（运营）系统，对接的外部系统多、业务模块复杂；那么相应的，具体涉及到某个业务的细节，也是能够喝上一壶的。因此，这里由于篇幅的原因，就不具体详述业务深处细节。希望感兴趣的pm们一起探讨。

本文由 @阮籍猖狂 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来源于网络