随着科技的快速发展，人们的支付方式也发生着翻天覆地的变化。曾经携带着现金或者银行卡的我们是否曾想象到如今可以凭着二维码、人脸、指纹等方式进行快捷线上支付。

线上支付方式的广泛应用，如何进行支付方式整合的业务痛点也应运而生，市场上“聚合支付”产品也逐步丰富。

对于医疗机构或者是医疗机构信息系统厂商，往往不具备支付牌照，此时需要满足不同的支付场景需求，需与对应的支付公司进行合作，例如具备聚合支付能力的拉卡拉、汇付天下、银联等，微信的微信支付、支付宝的支付功能。

一、支付场景

在说支付产品设计之前先说说医疗就诊流程中的支付场景：

人工窗口（如果是诊所一般称作前台，后续统一叫人工窗口）支付是最传统&原始的支付场景，患者就诊完成后，可以去人工窗口排队支付。

随着“智慧医院”的概念产生，智慧服务评级的开展，医疗机构也渐渐满足诊间支付、自助机支付、移动支付等场景，一方面减少人力成本，另一方面也因排队时间的缩短而优化患者整体的就诊体验和就诊环境。

患者在诊间就诊，医生开具诊疗项目后，完成就诊患者有待收费单信息即可在医生诊间完成支付，继续进行后续的诊疗流程。

通过机构内设置自助机的硬件设备，患者就诊完成后有待收费单信息可通过自助机查询记录进行支付。

微信公众号、小程序，支付宝生活号、小程序现已广泛应用，越来越多的医疗机构都支持移动支付，在就诊后有待支付单能够在微信或支付宝上接收待支付订单信息，查看待支付单详情，并且直接进行支付。该场景下支付不需要任何的人力成本、设备成本，而且可以点对点的直接完成。

二、支付机具

了解医疗的支付场景后，可以继续聊一下支付机具。

在支付行业中以患者的行为来区分支付的行为：

• 主扫：患者用微信、支付宝、云闪付等移动APP主动扫带支付信息的二维码进行支付的行为为主扫。
• 被扫：由收费方使用设备扫描患者出示微信、支付宝、云闪付等APP内的付款码完成支付的行为为被扫。
• 刷卡：患者出示个人银行卡刷卡完成支付的行为为刷卡。

在人工窗口支付时，大家应该有遇到过收费人员会拿着一个方方正正的机器，用这个机器完成支付后会自动打印出一张小票，这个机器就是POS机。POS机具备刷卡、主扫、被扫的能力，同时因其机器内带有软件功能，可实现无线支付。

区别于POS机的无线支付，小白盒往往带有USB线，需要连接电脑，其本质是识别出支付的条码，从而进行支付，因此其只有被扫的能力。

区别于有实体机具的POS机和小白盒，还存在不依赖实体机具的二维码，患者可以用手机上的微信、支付宝等扫码打开支付厂商集成的支付页面完成支付，因此，通过二维码支付则为主扫。

需注意：聚合支付中的二维码支付区别于微信、支付宝的二维码支付：

1. 操作方式差异：聚合支付中的二维码支付打开的页面往往是聚合支付厂商的页面，由该页面唤起支付宝、微信的支付；而非聚合支付的二维码支付，扫码直接唤起支付宝、微信支付；
2. 结算方式差异：聚合支付中的二维码支付最终将与聚合支付厂商结算，而非聚合支付的二维码支付则是直接与支付宝、微信进行结算；
3. 接入方式差异：聚合支付中的二维码支付需要通过向聚合支付厂商进件开通对应的商户号后才能进行支付，而非聚合支付的二维码支付则是直接在微信、支付宝平台进行支付开通申请流程才能接入。

三、支付架构设计

在支付架构设计前，我们需要先了解完成支付涉及到的用户对象和用户行为：

1. 患者：支付账单的归属者，需要核对账单后确认支付，可通过出示付款码、银行卡刷卡或者扫码完成支付。
2. 收银人员/医生：创建账单添加收费项目并触达患者；
3. 财务/机构管理者/运营人员：按支付厂商要求创建支付厂商商户号等，定时进行财务对账与支付厂商进行结算。具体分工可根据机构情况定。

为了提高支付功能接入的灵活性，往往会通过支付网关形式接入不同支付厂商的支付方式，而业务使用方往往通过支付收银台完成。支付收银台可通过网关控制显示对应厂商的支付方式，归类成POS机、小白盒、二维码、信用卡分期、花呗分期。

因不同支付厂商结算费率不同，对应的支付方式前需加上支付厂商/渠道的名称，渠道内支付宝、微信的结算费率也可能不同，因此，记录支付方式需要到三级，例如拉卡拉/POS机/微信，代表该次订单通过拉卡拉的pos机完成微信的支付。

当然，除了聚合支付外，机构也可以通过网关直接接入微信或支付宝，但因直接接入的费率往往比聚合支付厂商费率高很多，目前越来越多机构会选择聚合支付，除此之外，也兼容了更多的支付方式。

四、支付功能设计

支付产品设计从使用方差异性可分成机构端和运营端。

1. 机构端：面向医疗机构；主要分支付管理、支付收银台、报表中心三大块。

1）支付管理：往往是医疗机构管理层或者财务操作，需要满足医疗机构可以在平台申请开通聚合支付功能，能够填写机构的相应信息用于向三方支付公司开通支付商户号，开通后可查询机构对应的支付费率，并且用聚合支付方式产生的交易流水及流水汇总数据。

• 医疗机构可能存在对公结算账户和对私结算账户，因此，设计时需注意兼容一个医疗机构对应多个支付商户号。
• 按以往对接经验，信用卡分期对应的商户号与其他支付方式商户号不同。
• 若服务公司要接入多家三方支付公司，在医疗机构入网时填写的信息则需兼容多家公司接入要求，取最大集合。

2）支付收银台：往往是医疗机构收银窗口、医生或咨询师操作，进行支付方式选择完成收费和退费流程。

• 功能表象看起来比较简单，可以选具体的支付方式，触发支付流程；背后需要关联支付网关与三方支付公司联动完成支付全流程。
• 小白盒流程比较简单，插入即可用；POS机的差异相对比较大，需要根据支付公司要求完成POS机设备的绑定，才能实现将业务订单待支付金额推送到POS机设备上完成支付。目前遇到的两种场景有通过进件返回的激活码与POS设备的设备号绑定或者根据系统生成的随机编码同步将编码在POS机设备上输入进行绑定。
• 针对通过二维码主扫支付，本质上背后是三方支付功能的支付页面，针对此类可以同步在微信、支付宝小程序推送待支付订单消息，完成移动端支付。
• 医疗机构也可以自行管理使用的支付方式，包含常用支付方式设置、支付方式停启用、支付方式选择排序等；

3）报表中心

• 主要有两类报表需要管理，一类是支付业务流水报表、另一类为自动对账报表；
• 针对支付流水业务报表：可按需设计，大体需要体现患者、收费项目、支付方式、支付时间等信息；
• 针对自动对账报表：主要是为了减轻医疗机构人员对账工作量，拿三方的支付对账数据和自身支付流水对比金额、时间、支付方式，完全一致则对账成功，否则对账失败，工作人员只需确认对账失败的记录进行查询，避免人工在两个系统将交易进行核对。

2. 运营端：面向为医疗机构提供支付服务的运营公司；主要用于运营人员进件、分期的审核，交易流水的管理，支付机具的管理，支付方式的管控，支付渠道的管理；

1）进件审核：主要用于运营人员对机构进件申请填写资料进行审核、确认开通的支付渠道、明确费率及支付协议，作为医疗机构与三方支付渠道的沟通桥梁。

• 一家医疗机构往往仅选择一个三方支付渠道，但也总是有意外，所以设计上需要兼容多渠道，而功能上可以先以单渠道为主。
• 目前开通流程上还存在很多线下处理的流程，尤其是协议签订这块，可引入电子签实现线上签署，便利双方。

此外，

• 交易流水：主要用于运营人员对Saas平台上机构产生的交易流水的管理，功能上相对比较简单。
• 支付机具：主要用于运营人员管理三方支付渠道发放的支付机具，例如POS机和小白盒。
• 支付方式：主要用于运营人员从后台方管控机构的支付方式，有效的停启用相应的支付方式。
• 支付渠道：主要用于开发内部管理，简化对接流程。

除了上文中的提到的聚合支付渠道像拉卡拉、汇付等由Saas服务商选择的渠道外，还有医疗机构指定的支付渠道，例如当地合作的银行等，这类特殊渠道不需要客户进行线上进件，线下进件后提供支付参数接入，通过渠道管理区分渠道类型决定进件方式；

• 因渠道类型差异性，对线下进件的支付渠道可通过后台配置定义支付参数范围，大抵包含appID、秘钥、私钥、公钥等，支付参数具体数值由医疗机构自行准备；而支持线上进件的支付渠道商则是运营进件审核可选的渠道范围；
• 支付渠道的功能范围可控，例如部分渠道商不支持POS机由业务方进行关单只能由设备关单，通过渠道管理参数控制来管理支付收银台是否显示该功能；
• 对接入的支付渠道的统一管理，有利于后续新渠道接入功能的整体性和统一性。

笔者做支付产品也是纯属于偶然，接触的时间也不是很长，后续应该也不会再继续深入，小小对之前做的内容总结下，希望对各位同僚有所帮助，如若有描述的不对的，欢迎大家留言批评指正。

本文由 @五五五檬檬 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。