这是虚拟to B支付专题研究的第二篇：虚拟to B支付设计思考。本篇是在第一篇《基础知识科普篇》基础上，对虚拟to B支付相关设计知识进行更深入研究，更侧重于设计思考。

　　本篇研究方法：对比法

　　社会科学中运用较广的方法。对比法旨在将有一定关联的现象和概念，进行比较对照，判断异同、分析缘由。

　　对于认知陌生领域，好处在于通过与已知熟悉事物的对比，从熟悉事物迁移到陌生事物，更形象地认识陌生新事物。

　　因此，本篇会通过与To C对比，更好地理解To B支付设计特别之处。

　　一、什么是虚拟To B支付

　　虚拟To B支付是“B端用户购买组织所需的虚拟商品时进行的支付”。上一篇文章对此有过详细定义《虚拟To B支付设计研究-基本知识科普篇》

　　对此再回顾几个要点，唤起大家的回忆：

　　虚拟To C支付，可以联想平时游戏充值、开通包月的场景，比如QQ音乐充值会员;虚拟To B支付，可以联想其他公司买腾讯服务的场景，比如企业邮箱购买。

　　区分To B还是To C支付在于“谁”支付，只要是B端账号支付，都是To B支付。

　　“B”因为是组织，使用B账户的，可能是多个人。

　　目前To B支付(B资金转出去)的方式有：网银、柜台公章、新兴在线支付。它们各有利弊。

　　二、虚拟to B支付设计差异点

　　1、提供用户更稳健的操作

　　虚拟To B支付牵扯的通常是大宗商品，这类商品最大的特点是：交易金额高，交易频率低。可能一年才买一次，但是一次就花个成百上千万。比如某某企业购买腾讯云业务。

　　因此，对于虚拟To B支付来说，操作过程会更加求稳。因此在设计时需要注意几个要点：

　　1.1 操作流程更“稳”

　　一般虚拟To C支付的场景多为冲动型消费，冲动型消费的特点是，用户的购买意愿很容易消减，为了抓住这一点的稍纵即逝的消费意愿，越快让它支付完越好。

　　因此“快”会是非常重要的考虑因素。参考米大师web，举一个例子，我们在包月付费时，我们会想办法来缩短用户的支付路径，想办法让用户越快给完钱越好。比如我们一般是把后台下单逻辑隐藏，因此前端是不出现的，前端可以直接一步完成：选商品→支付流程。

　　BUT，在虚拟to B支付场景中，操作步骤不一定最快，但是一定是最稳健：该有的操作一步也不能少，有时候为了稳健，还需要用户多次安全确认。

　　我们通常会用指示器把操作步骤显示出来。让用户每一步都能确认，避免犯错。

　　1.2 资金流向时刻反馈

　　在虚拟To C场景中，由于是小额资金交易，银行对资金的处理速度很快，能及时反馈结果。从用户侧下单支付(下单支付页)，到后台反馈银行结果(结果页)，用时都很快。

　　BUT，虚拟To B支付则不同，由于是大额资金交易，银行需要进行核实，这个过程有时候需要进行很传统的操作，比如：人工打电话核实、登录网银U盾操作核实。因此从用户侧下单支付，到后台反馈银行结果，有时候需要一定时间。

　　动辄成百上千万的资金，用户需要对自己给出去的钱有极致的操控感，需要实时获知自己的资金流向。因此需要在用户每个操作时都给出实时的资金反馈。我们在设计时会着重注意实时反馈。

　　举一个例子，如果资金延迟到账，我们会展示一个时间轴，时刻反馈资金的处理情况。(类似于电商中的物流时间流同步)

　　1.3 退款作为一个重要的功能设计

　　在虚拟To C支付中，因为到账及时率高，加上用户冲动消费(买了也不贵的心理)，退款是一个非常低频的操作，在产品设计上通常“有即可”，或者有问题找到求助方法即可。

　　举一个例子，腾讯服务的付费，在业务中我们不提供一个专门的退款功能，但是会在客服中提供发生问题求助的法子。