本文深入剖析了支付行業(yè)的新動向——聚合支付，探討了醫(yī)療機構(gòu)如何整合多樣化的支付方式，以及這一變革背后的業(yè)務(wù)痛點與架構(gòu)設(shè)計。讓我們一起探索支付技術(shù)的前沿，預(yù)見未來支付的無限可能。

隨著科技的快速發(fā)展，人們的支付方式也發(fā)生著翻天覆地的變化。曾經(jīng)攜帶著現(xiàn)金或者銀行卡的我們是否曾想象到如今可以憑著二維碼、人臉、指紋等方式進行快捷線上支付。

線上支付方式的廣泛應(yīng)用，如何進行支付方式整合的業(yè)務(wù)痛點也應(yīng)運而生，市場上“聚合支付”產(chǎn)品也逐步豐富。

對于醫(yī)療機構(gòu)或者是醫(yī)療機構(gòu)信息系統(tǒng)廠商，往往不具備支付牌照，此時需要滿足不同的支付場景需求，需與對應(yīng)的支付公司進行合作，例如具備聚合支付能力的拉卡拉、匯付天下、銀聯(lián)等，微信的微信支付、支付寶的支付功能。

一、支付場景

在說支付產(chǎn)品設(shè)計之前先說說醫(yī)療就診流程中的支付場景：

1. 人工窗口支付

人工窗口（如果是診所一般稱作前臺，后續(xù)統(tǒng)一叫人工窗口）支付是最傳統(tǒng)&原始的支付場景，患者就診完成后，可以去人工窗口排隊支付。

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

隨著“智慧醫(yī)院”的概念產(chǎn)生，智慧服務(wù)評級的開展，醫(yī)療機構(gòu)也漸漸滿足診間支付、自助機支付、移動支付等場景，一方面減少人力成本，另一方面也因排隊時間的縮短而優(yōu)化患者整體的就診體驗和就診環(huán)境。

2. 診間支付

患者在診間就診，醫(yī)生開具診療項目后，完成就診患者有待收費單信息即可在醫(yī)生診間完成支付，繼續(xù)進行后續(xù)的診療流程。

3. 自助機支付

通過機構(gòu)內(nèi)設(shè)置自助機的硬件設(shè)備，患者就診完成后有待收費單信息可通過自助機查詢記錄進行支付。

4. 移動支付

微信公眾號、小程序，支付寶生活號、小程序現(xiàn)已廣泛應(yīng)用，越來越多的醫(yī)療機構(gòu)都支持移動支付，在就診后有待支付單能夠在微信或支付寶上接收待支付訂單信息，查看待支付單詳情，并且直接進行支付。該場景下支付不需要任何的人力成本、設(shè)備成本，而且可以點對點的直接完成。

二、支付機具

了解醫(yī)療的支付場景后，可以繼續(xù)聊一下支付機具。

1. POS機

在支付行業(yè)中以患者的行為來區(qū)分支付的行為：

• 主掃：患者用微信、支付寶、云閃付等移動APP主動掃帶支付信息的二維碼進行支付的行為為主掃。
• 被掃：由收費方使用設(shè)備掃描患者出示微信、支付寶、云閃付等APP內(nèi)的付款碼完成支付的行為為被掃。
• 刷卡：患者出示個人銀行卡刷卡完成支付的行為為刷卡。

在人工窗口支付時，大家應(yīng)該有遇到過收費人員會拿著一個方方正正的機器，用這個機器完成支付后會自動打印出一張小票，這個機器就是POS機。POS機具備刷卡、主掃、被掃的能力，同時因其機器內(nèi)帶有軟件功能，可實現(xiàn)無線支付。

2. 小白盒

區(qū)別于POS機的無線支付，小白盒往往帶有USB線，需要連接電腦，其本質(zhì)是識別出支付的條碼，從而進行支付，因此其只有被掃的能力。

3. 二維碼

區(qū)別于有實體機具的POS機和小白盒，還存在不依賴實體機具的二維碼，患者可以用手機上的微信、支付寶等掃碼打開支付廠商集成的支付頁面完成支付，因此，通過二維碼支付則為主掃。

需注意：聚合支付中的二維碼支付區(qū)別于微信、支付寶的二維碼支付：

1. 操作方式差異：聚合支付中的二維碼支付打開的頁面往往是聚合支付廠商的頁面，由該頁面喚起支付寶、微信的支付；而非聚合支付的二維碼支付，掃碼直接喚起支付寶、微信支付；
2. 結(jié)算方式差異：聚合支付中的二維碼支付最終將與聚合支付廠商結(jié)算，而非聚合支付的二維碼支付則是直接與支付寶、微信進行結(jié)算；
3. 接入方式差異：聚合支付中的二維碼支付需要通過向聚合支付廠商進件開通對應(yīng)的商戶號后才能進行支付，而非聚合支付的二維碼支付則是直接在微信、支付寶平臺進行支付開通申請流程才能接入。

三、支付架構(gòu)設(shè)計

在支付架構(gòu)設(shè)計前，我們需要先了解完成支付涉及到的用戶對象和用戶行為：

1. 患者：支付賬單的歸屬者，需要核對賬單后確認(rèn)支付，可通過出示付款碼、銀行卡刷卡或者掃碼完成支付。
2. 收銀人員/醫(yī)生：創(chuàng)建賬單添加收費項目并觸達患者；
3. 財務(wù)/機構(gòu)管理者/運營人員：按支付廠商要求創(chuàng)建支付廠商商戶號等，定時進行財務(wù)對賬與支付廠商進行結(jié)算。具體分工可根據(jù)機構(gòu)情況定。

為了提高支付功能接入的靈活性，往往會通過支付網(wǎng)關(guān)形式接入不同支付廠商的支付方式，而業(yè)務(wù)使用方往往通過支付收銀臺完成。支付收銀臺可通過網(wǎng)關(guān)控制顯示對應(yīng)廠商的支付方式，歸類成POS機、小白盒、二維碼、信用卡分期、花唄分期。

因不同支付廠商結(jié)算費率不同，對應(yīng)的支付方式前需加上支付廠商/渠道的名稱，渠道內(nèi)支付寶、微信的結(jié)算費率也可能不同，因此，記錄支付方式需要到三級，例如拉卡拉/POS機/微信，代表該次訂單通過拉卡拉的pos機完成微信的支付。

當(dāng)然，除了聚合支付外，機構(gòu)也可以通過網(wǎng)關(guān)直接接入微信或支付寶，但因直接接入的費率往往比聚合支付廠商費率高很多，目前越來越多機構(gòu)會選擇聚合支付，除此之外，也兼容了更多的支付方式。

四、支付功能設(shè)計

支付產(chǎn)品設(shè)計從使用方差異性可分成機構(gòu)端和運營端。

1. 機構(gòu)端：面向醫(yī)療機構(gòu)；主要分支付管理、支付收銀臺、報表中心三大塊。

1）支付管理：往往是醫(yī)療機構(gòu)管理層或者財務(wù)操作，需要滿足醫(yī)療機構(gòu)可以在平臺申請開通聚合支付功能，能夠填寫機構(gòu)的相應(yīng)信息用于向三方支付公司開通支付商戶號，開通后可查詢機構(gòu)對應(yīng)的支付費率，并且用聚合支付方式產(chǎn)生的交易流水及流水匯總數(shù)據(jù)。

• 醫(yī)療機構(gòu)可能存在對公結(jié)算賬戶和對私結(jié)算賬戶，因此，設(shè)計時需注意兼容一個醫(yī)療機構(gòu)對應(yīng)多個支付商戶號。
• 按以往對接經(jīng)驗，信用卡分期對應(yīng)的商戶號與其他支付方式商戶號不同。
• 若服務(wù)公司要接入多家三方支付公司，在醫(yī)療機構(gòu)入網(wǎng)時填寫的信息則需兼容多家公司接入要求，取最大集合。

2）支付收銀臺：往往是醫(yī)療機構(gòu)收銀窗口、醫(yī)生或咨詢師操作，進行支付方式選擇完成收費和退費流程。

• 功能表象看起來比較簡單，可以選具體的支付方式，觸發(fā)支付流程；背后需要關(guān)聯(lián)支付網(wǎng)關(guān)與三方支付公司聯(lián)動完成支付全流程。
• 小白盒流程比較簡單，插入即可用；POS機的差異相對比較大，需要根據(jù)支付公司要求完成POS機設(shè)備的綁定，才能實現(xiàn)將業(yè)務(wù)訂單待支付金額推送到POS機設(shè)備上完成支付。目前遇到的兩種場景有通過進件返回的激活碼與POS設(shè)備的設(shè)備號綁定或者根據(jù)系統(tǒng)生成的隨機編碼同步將編碼在POS機設(shè)備上輸入進行綁定。
• 針對通過二維碼主掃支付，本質(zhì)上背后是三方支付功能的支付頁面，針對此類可以同步在微信、支付寶小程序推送待支付訂單消息，完成移動端支付。
• 醫(yī)療機構(gòu)也可以自行管理使用的支付方式，包含常用支付方式設(shè)置、支付方式停啟用、支付方式選擇排序等；

3）報表中心

• 主要有兩類報表需要管理，一類是支付業(yè)務(wù)流水報表、另一類為自動對賬報表；
• 針對支付流水業(yè)務(wù)報表：可按需設(shè)計，大體需要體現(xiàn)患者、收費項目、支付方式、支付時間等信息；
• 針對自動對賬報表：主要是為了減輕醫(yī)療機構(gòu)人員對賬工作量，拿三方的支付對賬數(shù)據(jù)和自身支付流水對比金額、時間、支付方式，完全一致則對賬成功，否則對賬失敗，工作人員只需確認(rèn)對賬失敗的記錄進行查詢，避免人工在兩個系統(tǒng)將交易進行核對。

2. 運營端：面向為醫(yī)療機構(gòu)提供支付服務(wù)的運營公司；主要用于運營人員進件、分期的審核，交易流水的管理，支付機具的管理，支付方式的管控，支付渠道的管理；

1）進件審核：主要用于運營人員對機構(gòu)進件申請?zhí)顚戀Y料進行審核、確認(rèn)開通的支付渠道、明確費率及支付協(xié)議，作為醫(yī)療機構(gòu)與三方支付渠道的溝通橋梁。

• 一家醫(yī)療機構(gòu)往往僅選擇一個三方支付渠道，但也總是有意外，所以設(shè)計上需要兼容多渠道，而功能上可以先以單渠道為主。
• 目前開通流程上還存在很多線下處理的流程，尤其是協(xié)議簽訂這塊，可引入電子簽實現(xiàn)線上簽署，便利雙方。

此外，

• 交易流水：主要用于運營人員對Saas平臺上機構(gòu)產(chǎn)生的交易流水的管理，功能上相對比較簡單。
• 支付機具：主要用于運營人員管理三方支付渠道發(fā)放的支付機具，例如POS機和小白盒。
• 支付方式：主要用于運營人員從后臺方管控機構(gòu)的支付方式，有效的停啟用相應(yīng)的支付方式。
• 支付渠道：主要用于開發(fā)內(nèi)部管理，簡化對接流程。

除了上文中的提到的聚合支付渠道像拉卡拉、匯付等由Saas服務(wù)商選擇的渠道外，還有醫(yī)療機構(gòu)指定的支付渠道，例如當(dāng)?shù)睾献鞯你y行等，這類特殊渠道不需要客戶進行線上進件，線下進件后提供支付參數(shù)接入，通過渠道管理區(qū)分渠道類型決定進件方式；

• 因渠道類型差異性，對線下進件的支付渠道可通過后臺配置定義支付參數(shù)范圍，大抵包含appID、秘鑰、私鑰、公鑰等，支付參數(shù)具體數(shù)值由醫(yī)療機構(gòu)自行準(zhǔn)備；而支持線上進件的支付渠道商則是運營進件審核可選的渠道范圍；
• 支付渠道的功能范圍可控，例如部分渠道商不支持POS機由業(yè)務(wù)方進行關(guān)單只能由設(shè)備關(guān)單，通過渠道管理參數(shù)控制來管理支付收銀臺是否顯示該功能；
• 對接入的支付渠道的統(tǒng)一管理，有利于后續(xù)新渠道接入功能的整體性和統(tǒng)一性。

筆者做支付產(chǎn)品也是純屬于偶然，接觸的時間也不是很長，后續(xù)應(yīng)該也不會再繼續(xù)深入，小小對之前做的內(nèi)容總結(jié)下，希望對各位同僚有所幫助，如若有描述的不對的，歡迎大家留言批評指正。