支付系統對接pos機,接入和管理

網上有很多關于支付系統對接pos機,接入和管理的知識，也有很多人為大家解答關于支付系統對接pos機的問題，今天pos機之家(www.tonybus.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、支付系統對接pos機

支付系統對接pos機

如今，支付通道已經是日常生活和商業交易中不可或缺的部分，也是各種支付業務的基礎。本文作者對如何接入支付通道及規劃通道管理系統相關功能進行了分析，一起來看一下吧。

從最初的現金支付到當下的電子支付，支付通道已然是日常生活和商業交易中不可或缺的部分，也是各種支付業務的基礎。本文將詳細解析如何接入支付通道及規劃通道管理系統相關功能。

01 什么是支付通道

以運輸貨物為例，要將一批貨從A地運到B地，可實現的運輸方式有路運、海運、鐵運、空運。相同的目的地，不同的運輸方式，往往還有許多不同的航道、鐵道和公路可供選擇，只不過過程中耗費的時間、承擔的風險、金錢成本不同而已。

1. 支付通道概念

類似于運輸，支付通道的本質是通過構建一個個信息交換的環境，用于支持交易過程中多方之間的信息的傳遞和驗證，以實現交易資金的流動，最終促進交易的完成。

狹義上支付通道是指交易時連接消費者、商家和銀行各方錢包賬戶的網絡通路，而從廣義上來看，只要能需滿足支付的需求，并將信息、資金成功安全地轉移給對應的收款方的路徑，即使是企業的用積分去支付、利用虛擬卡、利用虛擬賬戶等內部的資產形式來支付，與這些管理資產的系統對接接入，我們可以說接入了“內部的虛擬支付通道”。

2. 支付通道的分類

隨著支付行業的發展，不同支付場景催生出多種多樣的支付通道，不同的通道細分出了不同的特點，我們可以從多個不同的維度進行分類，來更好地感知支付通道的差異。例如：

支持不同卡類型的通道：僅支持借記卡的通道、僅支持貸記卡的通道、借貸卡都支持的通道；扣款交互模式不同的通道：扣款前需要簽約、鑒權的快捷通道、可建立預付授權關系，用于信用卡還款和水電煤繳費的代扣通道、需跳轉銀行頁面進行付款的網銀通道、通常被用于手機話費支付和流量充值等業務的手機運營商鑒權通道、支付時使用微信、支付寶等第三方支付平臺輸入支付密碼或者進行指紋識別等進行認證的身份認證通道；交易支持不同發起方的通道：持卡人（用戶）發起、商戶（平臺）發起；有不同行業限制的通道：微信代扣就僅限符合周期扣費和先享后付場景的行業使用，會員續費、水電煤民生類行業、打車、酒店類行業、停車場或高速公路無人繳費；扣款要素不同的通道：如網銀需要卡號和密碼二要素、快捷則需要驗證卡號/賬號、戶名、證件號、手機號四要素；支付標的物不同的通道：比如用積分來支付、銀行卡支付、代幣支付、虛擬幣支付、銀行卡支付等。

1）根據通道的用途

通道的用途，顧名思義就是通道的功能，直白一點就是用來干嘛的，分為收款、付款、認證、跨境等。

收款通道：常說做支付要先做收單，收款通道就是實現讓別人的“資產”付給自己的通道，打比方有早餐店“掃碼支付”收錢立牌、線下商超的POS機支付、各類公交地鐵卡和乘車碼。出款通道：“出來混總是要還的”，出款通道能夠實現把自己的錢付給別人，好比公司給我們發工資的代付通道、靈活用工通道、銀企直連通道。鑒權通道：鑒權通道可以被想象成一條連接交易雙方之間的安全通道，要先經過驗證，才能通往支付之門。常見有銀行卡簽約驗證；身份信息認證（四要素等），像賬戶的一些實名認證以及銀行卡的綁定都需要用到；3D-Secure（3DS），一種用于網上支付的安全協議；指紋識別、面部識別等生物識別技術，通過授權人的生物特征來進行鑒權。

2）根據通道支持的對象

通道支持的對象，指的是支付交易的雙方是誰，可以是個人、企業、組織等，通常我們區分為對公和對私。

對公通道：用于企業賬戶支付，包括企業網銀，企業賬戶代扣，企業轉賬等等。對私通道：用于個人賬戶支付，包括銀行卡支付，微信、支付寶等三方個人賬戶支付。

3）按渠道提供方分類

其實支付通道是分層次的，下層為上層服務。不同的角色（按有無支付牌照、金融資質區分）對應所需的通道提供方是不同的。

對于普通企業：通道的提供方是具有支付牌照的三方公司如支付寶、微信支付；各個銀行；或者是企業自己內部搭建的虛擬賬戶支付通道、卡券支付通道、積分支付通道等。對于三方支付機構：那些有支付牌照，能對外提供支付能力的三方機構，他們需要的通道則是金融機構（銀行、網聯、銀聯）的核心系統。對于銀行：銀行所需的通道就是央行（也就是人行）的大小額系統、超級網銀系統，這幾個通道也是金融活動的根基。

4）其他分類

根據支付方式：就是用戶在平臺下單后調起收銀臺看到各種各樣支付方式，包括云閃付、支付寶、微信支付、Apple Pay等。如京東PC收銀臺就有2個支付品牌，京東支付和微信支付；3個支付方式，白條、小金庫、微信掃碼支付。

根據支付場景：包括線上支付、線下支付、跨境支付等。假設你深夜餓了，通過餓了么點外賣之后支付寶線上支付，或者出去樓下實體店面吃一碗隆江豬腳飯用二維碼線下支付，然后早上醒來后像梁朝偉一樣去倫敦喂鴿子，想喝一杯咖啡就需要用到跨境支付了。根據支付保障機制：包括擔保交易（拍賣網站的拍賣交易就是一種擔保交易方式）、中介支付（像電商支付平臺，買家付款后會將資金凍結，待確認收貨后才會把錢付給賣家）、風控評估（例如，貸款公司對借款人進行風險評估，判斷其還款能力和信用水平）等。

對支付通道有了初步的認識之后，我們來假定以下這樣一個場景。假如你的公司要上線一個新業務，涉及到線上交易，需要你來負責接入支付，你會怎么處理。

3. 支付通道的結構關系

要深如了解支付通道，我們還需要知道一個通道在支付體系中所存在的結構關系，這也是很多人容易混淆的，特別是支付方式、支付通道、支付品牌、支付產品、支付合作方之間的關系。

支付方式、通道和品牌上文已經釋義過，而什么是支付產品呢，我們借用微信支付的定義，支付產品其實就是支付機構針對某個支付場景，提供給外放使用的一套“解決方案”，其最基礎也是最核心需要包含“支付通道”和“賬戶”兩個服務，然后才能結合不同的場景包裝出不同的產品。

1）支付通道-支付方式的關系

同一個支付方式，除了自身的官方通道，往往也會授權其他機構合作封裝出對應通道，所以一個支付方式是由多個支付通道可以選擇。

2）支付通道-支付合作方的關系

支付通道跟不同的合作方，又是處于什么關系呢。假設“光企業”要通過易票聯接入微信支付的通道，那這條通道跟各個機構的關系如下。

3）支付通道-收付賬戶的關系

文章開頭咱們也講過，通道最終目的就算將不同收付賬戶之間的資金進行轉移。以微信支付通道舉例，可以看到通道和賬戶之間的關系和資金的轉移。

4）普通商戶的支付通道結構關系

作為一個普通的企業，是有可能同時接入多個支付方式，因此也會有多條支付通道，那么這之間整體的關系又是怎么樣的呢。

5）普通商戶與金融機構的支付通道結構關系

再往下走就涉及到支付機構和清結算機構了。

通過上面的結構關系分析，我們可以初步看出一個從用戶支付方式到各層支付支付組織之間的關系。

02 選擇支付通道

尋找合適的通道之前，我們來看下應該怎么選。

假設你是光企業的物流運輸部，你需要采購一輛貨車，那你肯定需要關注對應貨車的屬性有哪些對吧？車型是普通貨車還是牽引車、載重總量是多少、要燃油車還是新能源等。

選通道也是，要知道通道都有哪些屬性，這些屬性就是我們在選擇時要思考的維度，這些屬性也是后續路由去判斷的維度依據。

了解了通道的屬性，就對通道有了更直觀的認識，那么就可以基于需求區選擇所需要的通道了。

1. 基于業務和交易場景做選擇

要選擇什么通道，要先了解業務的場景，不同的業務模式需要不同的支付方式。例如，傳統的線下零售業務可以選擇POS機、微信支付寶的主掃、掃臉等，而線上平臺則需要根據不同的平臺進行選擇。

打比方公司準備依托微信小程序開發一款“針對園區等高密度打工人區域的午餐外賣”產品，則肯定是需要選擇接入“微信小程序支付”方式的通道，而不可能選擇支付寶。當產品成熟了有余力了再考慮拓展其他平臺或者接入其他支付方式的通道。

2. 多維度指標評估預選通道

選定好合作機構之后，可以根據下表，評估該通道是否符合公司業務需求，評估滿足需求的話，就可以著手接入了。

3. 通道的接入流程

1）參與的團隊成員及分工

2）對接準備

步驟一：明確自身需求

對接之前，先確定自己的功能需求，比如我們是做演唱會票務，用戶搶票之后是不允許退款的，那此時沒有退款功能也不影響第一期上線。另外如果咱們是租賃場景比如租房，需要向用戶收押金，但是退款往往有時限，這個時候就需要思考其他退款辦法了，比如接入打款通道。

步驟二：明確接口文檔

一般的支付公司為了方便廣大用戶使用,提供各種不同的接口,相同的功能也進行多變的實現。所以我們跟對方講清需求后，對方開發人員通常比你更熟悉接口的使用和效果，他們很可以幫助我們快速找到最優的接口方案。

另外，很多合作方的文檔都可能存在更新不及時問題，可以跟對方確定清楚用哪個板本的文檔。

步驟三：研讀接口文檔

必須弄清你需要哪些接口后，我們要看清楚接口字段值怎么傳、是否必傳，以及有什么響應碼。另外注意要和對方確定好返回結果是以碼為準，還是以描述為準。

步驟四：輸出需求文檔

包含接入的背景，羅列功能點，第一期做哪些。

這里先強調一個支付中和退款中的問題，一定要牢記設計支付狀態要考慮中間狀態，以免產生線上問題。

此外安全類對接準備也需要提前溝通清楚，如IP地址白名單是否配置，怎么配置；公私鑰加簽驗簽；接口加密解密；是否需要專網、前置機堡壘機等，作為普通企業，如果不是對接銀行核心系統的話，一般是不需要前置機堡壘機。這個環節你也可以拉上開發大哥協助評估。

03 通道管理系統設計

選擇好要接入的之后，我們就需要規劃我們的通道管理模塊，以避免后續支付業務壯大了，最基礎的模塊卻一團糟，因為很多人都是圖快，先干上線，等到發現好亂了的時候，已經為時已晚。

規劃通道管理模塊之前，我們先看下通道管理在整個業務系統中是在哪里發揮作用的。

上游系統選擇完通道，就可以拉起對應的支付、退款、打款請求了。

接著我們就來分析，我需要為通道管理規劃什么樣的功能。管理管理，首先咱們肯定得知道有什么通道，才能管理吧，因此肯定需要有一個通道管理列表。

1. 通道管理列表

這里以入金通道舉例子，接入通道之后，每一條通道都有唯一的通道名稱和編碼，這個好理解，就像每個人都有身份證和名稱一樣。然后再把通道關聯上支付方式和狀態，沒有其他追求的話，這個通道管理也就能用起來了。

不過咱們還是要為以后打好基礎，站在企業的角度，咱們是不是需要核算每一次支付產生，企業所要付出的成本，也就是通道手續費，此時我們就需要為該通道關聯對應的“成本規則”；比如站在運營/維護通道人員的角度，通道的一些商戶號、回調地址有時候也需要變更，我們是不是做成配置化會顯得更人性化；假設我們財務要知道每一筆支付是去到哪個賬戶，好去核對每天的賬目，那我們是不是需要在通道關聯“入賬賬戶”會讓后續的對賬更方便（注意這里不是指定真實的資金流渠道哪個賬戶，而是純粹的記錄，方便后續核賬）。

至于“映射通道代碼編碼”和“權重”，沒有也行。“權重”主要是為了方便路由去兜底一個支付通道。而“映射通道代碼編碼”作用是讓運營和后續接手的開發知道，這一條我們“定義的通道”對應是走那一套真實的通道代碼。闡述一個具體情況，當我們公司接入某家公司同一條通道，但是出于商務等原因開通了幾個商戶號，這幾個商戶號要參與路由切換，而背后對應的代碼，則是同一套。

所以一開始設計的時候，個人建議把我“不同真實通道+不同商戶號”為最小顆粒度，定義我們通道管理里的唯一通道。

2. 通道成本規則

通道成本規則我們設計成單獨配置規則，然后再從通道關聯對應的成本規則，這樣就不用新增通道的時候反復配置同樣的成本規則。

遇到銀行卡通道的時候，不同的銀行收的費用可能會不一樣，所以可以根據自身需求定義一個特殊銀行特殊配置，如果特殊銀行多的話，建議用導入配置文件的交互形式。

至于通道成本怎么用呢，其實就是在我們發起交易和退款的時候，讀取對應通道的成本規則，計算出這一筆交易所產生的成本，并記錄在每一筆支付記錄里面，以后統計就可以很方便拉。

3. 通道參數配置

通道參數配置，一般是配置比較敏感的內容，商戶號、請求地址等，記得做好菜單或者功能權限，專人專用。

04 銀行卡代扣通道接入實戰1. 接入背景

為給客戶提供更快捷、更優秀的支付體驗，我們團隊決定開發上線一個銀行卡代扣支付功能，讓用戶實現賬單的自動代扣支付，免去繁瑣的操作。

經過公司領導層商議，決定接入PAF協議支付這條通道。

2. 研讀接口文檔

1）接口調用流程

通過接口調用流程，我們可以看出要銀行卡代扣通道，要完成支付之前，還需要進行簽約兩步。

第一步調用協議簽約接口進行簽約請求，下發短信給用戶，用戶輸入短信后調用協議簽約短信驗證接口驗證驗證碼，完成簽約；

第二步通過協議簽約返回的信息（簽約號）進行協議扣款，并同步返回交易狀態。

弄清楚流程之后，我們繼續細看接口文檔。

2）簽約環節

①協議簽約接口

就是發起協議簽約申請，發起成功后會給持卡人下發一條短信。

可以看到這條通道申請協議簽約的時候，需要上送一個銀行編碼，并且這個編碼是要根據這條通道的定義來，看到這里我們就要聯想起兩個問題。

第一點，卡簽約的時候需要知道這張卡是什么銀行卡，這個后續跟大家介紹卡bin模塊。第二點是，不同無卡通道有可能存在的特殊標準，使用的銀行編碼標準與其他不相同，這時可以回想我們的通道屬性和特征，就存在通道銀行編碼的對應維護了。

這里再說一個點，有一些通道簽約信用卡的時候，需要上送CCV和有效期，而剛好這條通道不需要，因此前端簽約頁面也需要根據不同的通道進行路由，從這里又印證了咱們通道管理和維護還是蠻重要的。

調用簽約申請之后，合作方會給持卡人手機發送短信，并接口返回一個令牌號。

②短信驗證接口

用戶輸入短信驗證碼后，接口上送驗證碼和令牌號，就可以完成短信驗證，驗證通過就可以簽約成功，獲取對應的協議號。

3）扣款和退款環節

①扣款接口

拿到簽約協議號，則可以根據該協議號進行發起扣款，咱們看接口說明，需要特別注意交易金額這個字段，單位是分，千萬要搞清楚交易金額的單位，別擺大烏龍。

另外咱們看到有一個后臺通知地址，他是我們發起扣款交易時，指定一個交易結果的通知地址，當交易有結果后，通道方會將結果告訴我們，按照上述地址。像更嚴密的通道方還會要求接入方進行結果響應，并且有一套完整的通知策略。

發起扣款之后，我們就需要關注扣款是否成功，可以看到響應信息已經說明這個操作成功僅代表請求成功，不代表交易成功。

因此這里重點說一聲，支付狀態一定要有支付中這個中間狀態，以及要對支付中這個狀態有對應的補償機制，不然很容易發生線上交易事故。當你發起一筆交易的時候，還沒收到通道方的結果之前這一筆交易就是支付中，等到有回調結果或者主動查詢，再根據結果更改狀態。

另外我們也要關注，單筆交易有無最低金額限制，以及并發量最多是多少，能不能多線程。

順便再提一嘴，最好建議開發大哥在封裝支付和退款接口的時候，即使接入了很多不同的通道，建議也盡量封裝成一個統一的下單接口和回調接口給業務層用，可以避免很多麻煩。

以及一定要讓前后端大哥們記得做防抖！

②退款接口

退款也可以看到，金額單位是分，以及退款也需要加退款中狀態，同扣款一樣就不贅述。

這種退款是原路退回，通道方會做好校驗，一般不太可能一筆支付多退了錢，倒是要考慮退款時效是多長（有的合作方限制交易半年或一年后就不能退款）、能不能部分退款、退款次數有沒有限制、同一筆支付能不能同時發起2次退款。

4）響應碼

一般響應碼有公共響應碼和不同接口對應的業務響應碼，這里建議前期梳理出一些常見通用的響應碼，并“翻譯”出用戶可讀懂的文字，以供展示。以及可以在報錯類的提示前面加上通道合作方英文，以方便定位是我們系統報錯，還是哪個通道方報錯。

如我們公司定義為DM，某通道方定義為PAF，則報錯內容展示為PAF:XXXXX，就可以很快速定位到是通道方的報錯。

3. 功能規劃

1）用戶端簽約

考慮到用戶體驗問題，用戶綁卡簽約的時候最好就是不用自己輸入卡號和選擇所屬銀行。因此我們就要接入銀行卡OCR功能，以及需要根據OCR識別出來的卡號匹配到銀行卡所屬的銀行以及銀行卡的類型，才能根據通道方的要求來上送銀行編碼和卡類型，這個時候卡bin模塊就可以派上用場。

具體用戶端交互大家可以去參考支付寶、微信等大產品。

此外建議保留讓用戶手動選擇更改銀行卡所屬銀行的功能，避免卡號識別錯誤導致無法進行簽約。

2）卡BIN管理

卡BIN是一種標識銀行卡的編碼方式，又稱為銀行識別碼。它通常由6到9個數字組成，前幾位數字可以表明銀行卡所屬的銀行、卡的種類以及卡的國際標準組織（ISO）代碼等信息?？˙IN在銀行卡的處理流程中非常重要，可以用來驗證卡的有效性、確定卡的類型及所屬銀行等信息。

國內的卡表信息如下圖，一般跟通道方拿一下都會有。

經過數據清洗之后，提取我們所需的信息，銀行卡中心的卡BIN管理就出來了。更加專業一點的公司甚至會將卡BIN圖標配置進來，以及將通道和卡BIN進行匹配關聯維護，做到更加精細化管理通道所支持的能力。

有了卡BIN之后，我們就能根據用戶輸入的銀行卡號匹配該卡所屬銀行。

匹配邏輯可以如下：

首先用銀行卡驗證luhn算法校驗卡號的正確性，如不正確可以提示用戶檢查修改卡號。其原理是將銀行卡號逐位相加，然后將結果與校驗碼比較。具體步驟如下：

從銀行卡號的最后一位數字開始，逆向將每個數字和它的位數做乘積。將這些乘積相加，得到一個和值。將和值除以模數（10）取余，得到校驗碼。如果校驗碼與銀行卡號的最后一位數字相同，則銀行卡號有效，否則銀行卡號無效。

以中國銀行卡為例，luha算法的模數為10，校驗碼為銀行卡號末位數字。

實際操作中，可以先將銀行卡號轉換為int類型，再進行計算和比較。例如，以下代碼可以驗證一個銀行卡號是否有效：

“`python

def check_luhn(card_num):

num_list= list(map(int, str(card_num)))

fori in range(len(num_list)-2, -1, -2):

num_list[i]<<= 1

ifnum_list[i] > 9:

num_list[i]-= 9

ifsum(num_list) % 10 == 0:

returnTrue

else:

returnFalse

“`

其中，str(card_num)將card_num轉換為字符串，map(int, str(card_num))將字符串轉換為由每位數字組成的列表，然后進行逆向乘積求和，并進行校驗。

代碼來源：chatGPT，僅供參考。

目前銀聯卡幾乎都支持校驗碼算法，但是也不排除極個別不支持此算法的，如杭州銀行早期發行的西湖卡和浙江民泰商業銀行。

銀行卡號檢測正確之后，就從10位開始遍歷卡bin表，依次遞減至6位，直到找到唯一卡bin為止，并返回該卡bin對應的銀行卡信息和所屬銀行。（目前國內銀聯卡,因銀行眾多,特別是村鎮銀行的存在,BIN長度以6位占絕大部分,另外還存在7、8、9、10等位數卡BIN）。

如果要更嚴謹，還可以匹配銀行卡長度對應得上不。

3）銀行管理

銀行管理用于維護企業自己系統的標準銀行及編碼，為什么要加自己內部的標準？

還記得上文說過的不同通道可能有不同的銀行編碼標準嗎？如果我們接了多個通道都有不同標準的銀行編碼，那么我們要根據我們自己的卡BIN，匹配我們標準的銀行編碼，再去映射不同的通道編碼。

再者當我們沒有接入多個通道的時候，不用復雜的路由的時候，哪些銀行的儲蓄卡、信用卡是否支持簽約代扣，也可以放在此處去維護管理，當前端識別到不支持的銀行的時候，則直接提示用戶換卡即可。

4）簽約記錄

簽約記錄，方便運營/客服人員核實某個用戶某張卡的簽約狀態，以應對用戶的進件咨詢和對外合作。

簽約數據結構大家可以根據實際場景來設計，一種是卡號+商戶、一種是用戶+卡號+商戶。兩者靈活度不一樣，舉個場景，一個車隊老板名下掛靠了很多太車，分別不同司機在管理，但是都用老板或者公司的賬戶簽約代扣ETC通行費，如果某臺車離職了，如果簽約結構是卡號+商戶，那把離職的司機的簽約關系解綁了，那老板名下所有簽約關系都解綁了。

然后關于簽約數據，建議一開始就讓開發大哥們維護一份獨立的、統一的通道簽約數據層，用于記錄卡/賬戶信息在不同通道上的簽約或者驗證結果，以便路由層及其他業務場景可以據此來進行重新簽約或者支付路由。

如果部維護統一的簽約數據，而是業務各自去維護，就會出現一個比較尷尬的現象，以我司舉例子，我們有客車和貨車業務線，但是同一個用戶同一張卡可能同時辦理了客車和貨車，簽約數據如果各自維護，存在先后的簽約關系，在通道方舊的簽約號就會失效，失效的那一條業務線對應的用戶就會扣款失敗。

同一張卡的簽約策略也是值得考究的，比如通道方是否允許重復簽約，重復簽約會返回什么樣的結果，這些都是要搞清楚的。

然后基于企業自身，重復簽約的時候是自己內部走個驗證即可，還是重新上送通道方進行簽約，這些也都要考慮好。如果通道方沒有限制，個人傾向重新上送通道方去做簽約，這樣可以及時更新已過期的簽約號。

有了統一的簽約數據的話，同一張卡我甚至可以根據業務需求，在用戶不同綁卡場景下判斷是否走另外的通道進行簽約，為同一張卡增加多一個扣款通道。

5）通道異常應急處理機制

最后再建議大家，可以在前期就考慮規劃下異常預警機制，比如某個通道連續簽約、扣款失敗，就要及時發出通知。

我們可以秉承下列3個原則設定處理機制，在通道出了異常之后快速響應，確保交易正常、規避損失、維護用戶體驗。

專業：應急規范及角色分工清晰；有序：應急流程清楚簡單、為可執行的標準化流程；快速：優先恢復通道交易穩定性，其次定位問題和提出解決方案。

萬丈高樓平地起，對于支付而言，支付通道管理是不可或缺的一環，其他第三方底層服務也可沿用該思路進行管理，希望本文能對大家帶來幫助。

專欄作家

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

以上就是關于支付系統對接pos機,接入和管理的知識，后面我們會繼續為大家整理關于支付系統對接pos機的知識，希望能夠幫助到大家！