本文内容来自支付学院·三期课程导师——「一亩田支付业务负责人于高禾」老师，于老师自2014年加入一亩田，担任支付业务负责人，从0开始搭建在线支付平台。

农业电商的现状

与典型电商某宝某东进行对比：

①没有库存：付款了也不一定有货，农业由于是大宗货物，无法像其他产品一样保证库存。

②没有物流追踪：无法实时跟踪物流，农村无法做到目前城市内的四通一达，隔日达、物流追踪目前依然没有成体系的系统。

③价格变动频繁：上午打电话1块3，下午去摘果就1块4。典型电商在日常活动及运营过程中，会互相对标价格，但农产品价格变动极其频繁。

④非标严重：货不对板，易损易腐。其他产品基本可以达到标准品，但农产品个个都是独一无二的，描述理解差异较大，且易损易腐，退换货困难。

⑤大额支付困难：快捷单笔5000，微信支付宝额度也不高，手续费还贵。大宗货物交易额很高，水果客单价也很高。

一亩田的支付系统

一亩田的支付系统始于2014年，涵盖主流收付流程，日交易笔数500000+，支付转化率约90%。

业务架构

支撑业务层大概可以看出平台是为谁服务的；

支付服务层涵盖4个方面：收银台、交易系统、风控以及企业服务。

核心系统层其实是类比银行的核心系统，涵盖4个方面：支付、清算、账务以及会计。其中账务是整个支付系统的核心，做支付一定要避免糊涂账；但其中的会计又区别于财务会计。

支撑系统主要是一些技术内容和对账核算的逻辑。

业务域划分

①交易核心：主要制定交易的流程。主流电商和微商的交易流程就有一定的区别，比如某宝通过支付宝走担保交易这种流程；而有些微商是交易确定后需要先付款才行，因此交易流程与业务流程息息相关。这一部分的本质是面向商户，为商户服务。

②支付核心：主要完成收付退等支付协议管理及支付引导。例如担保交易具体流程，收钱之后钱放在哪、什么时候付给谁、收付退的限制条件等等，要实现主要的控制流。

③渠道清算核心：对接上下游，例如银行、三方前置，微信支付宝的接口都是不一样的，因此要做一个统一的适配系统，这一部分主要面向的是渠道。每个系统的边界即前置。

④账务会计核心：账务和会计处理。单式记账和复式对账并举。

⑤对账核算：支付的本质是对账。账证、账实等对账。

支付平台的定位

在一亩田，支付平台是为商户服务、为业务进行支撑同时也是通用中台（阿里巴巴提出的概念，即无论业务线千变万化，核心不变）。

统一收银台

1、收银台的核心指标：支付成功率（也称为支付转化率）。

①单次支付成功率=支付成功的支付单数/发起支付的支付单数（支付单数即：每发起一次支付，生成1个支付单。）

②支付成功率=支付成功的业务订单数/发起支付的业务订单数

例子：

用户A在一亩田下订单购买5000斤橘子，每斤0.6元，运杂费500元，订单总额3500元，订单号O1234。在线支付时，先选择微信支付，发现余额不足，取消支付后，又使用支付宝付款成功。

①单次支付成功率=1/2=50%

②支付成功率=1/1=100%

如何定义统一的收银台？

由于不同业务线对支付方式需求不同，但是支付平台作为业务通用中台，不可能耦合太多业务，所以要抽象出统一的收银台。

例子：

A业务线有大额的需求，需要支持转账汇款。

B业务线都是小额支付，希望支持免密，并且屏蔽转账。

C业务线在金额超过10000时，默认走支付宝通道。

……

根据商户号、交易分类、客户ID、业务订单号、金额、币种等维度筛选符合条件的支付方式。

收银台样式：标准收银台/快捷收银台/简版收银台等

默认支付方式：某个渠道ID。如：ALIMOBILEPAY。

支付列表：具体支付方式配置有序列表（举例）

收银台策略

决定支付成功率的因素：

a.用户意愿【最重要的还是业务端，即用户付款的意愿】

b.通道的服务质量【用户体验流畅，会对支付成功率有正向影响】

c.支付流程设计

具体展开：

综合业务场景：对不同业务场景的样式处理。

客户身份：对新用户/优质客户等用户身份处理。

风控：对风控黑名单（设备/人/IP等）的处理。

端：对新旧版本/不同的端（安卓/iOS/小程序/H5）的兼容。

版本：对连续支付失败的召回处理。

渠道（费率/质量）等因素处理：对一个支付渠道可以禁用/屏蔽/展示。

统一收单流程

收单涉及到的概念：

商户号：各业务线；

交易分类：业务分类，例如农产品、农资、小额付费、营销活动；

交易类型：S/FP/FPX；

支付渠道：微信/支付宝/快捷/虚拟币等；

支付产品：代收/代付/担保交易；

币种：人民币/虚拟币。

支付流程

无论用什么端、什么收银台，支付的流程均可概括为三步曲：

1、支付预下单：创建支付交易（哪个业务线的哪个客户要发起一个什么交易付多少钱）；

2、发起支付：通过收银台通过支付核心通过路由，生成三方支付链接或秘钥串，报送前端唤起SDK进行支付；

3、获取支付结果：引导支付结果页。

看图就懂：

虚拟币体系

虚拟币概念简介

虚拟币账户与R(Revenue)值？

什么是R值？即每收入1虚拟币，折算多少元人民币。（例如：1美元=6.9182人民币）

账户的设立

每个客户拥有一个通用虚拟币账户和若干或定向业务虚拟币账户。对于通用虚拟币账户和普通的会计账户类似。对于定向业务虚拟币账户会额外包含：发卡渠道、面值、余额、R值、交易场景限制、有效期等关键属性。

任意虚拟币账户消费都需要详细记录对应的R值。

R值的更新

无论账户分多少批充值，每个账户只维护一个R值。例如100块钱买100个币，第二天50元买了100个币，那么这个账户的R值是0.75。一般情况下，在账户余额增加时更新R值，消费时R值不变。退款时，余额减少的一方也要更新R值，退款时的R值要与付款时一致，否则会影响利润。

R值的维护主要为了摊销。

虚拟币生命周期

定向业务虚拟币

有消费限制的虚拟币。限制包括：时间限制/业务场景限制。

账户1：支持业务A/业务B/业务C

账户2：支持业务B

账户3：支持业务B/业务D

虚拟币组合支付规则按顺序如下：

a.定向业务虚拟币优先于通用虚拟币

b.有效期临近的账户优先

c.支持业务分类少的优先

d.余额少的账户优先

如何快速支持任意交易分类组合？

在账户上设置属性记录允许的交易分类。

使用varchar存储并使用位运算可以快速支持任意交易分类组合。

交易分类ID化:

业务A：1

业务B：2

业务C：3

业务D：4

例子：

客户甲拥有两个虚拟币账户:账户1，面值100，余额80，R值1，有效期剩余3天，允许的交易分类为3；账户2，面值100，余额80，R值0.5，有效期剩余3天，允许的交易分类为-1

实例：

客户现在需要在交易分类B消费消费150币，能否消费成功？如果能消费成功，本次消费的平均R值时多少？

解析：

交易分类B的筛选掩码为：1<<(2-1)=2=(10)b

账户1允许的交易分类3=(11)b

账户2允许的交易分类-1=(1111)b

select*from tbl_xxx_accounts where account_no=‘xxx’and allow_trans_cat&2>0 for update;

虚拟币的核心是R值的控。