中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

每天我們都會通過形形色色的收銀臺完成與各種買賣交易，順暢的體驗可能會讓你感覺到支付只是一個收銀臺。想要在不同場景下都能設計出體驗良好的收銀臺。我們可以一起來看一下這篇文章的介紹。

各位小伙伴，大家好！

每天我們都會通過形形色色的收銀臺完成與各種買賣交易，順暢的體驗可能會讓你感覺到支付只是一個收銀臺。然而好的產品千篇一律，爛的產品千奇百怪，很多體驗很差的收銀臺讓你覺得“怎么連一個頁面都做不好”。今天我就來給大家介紹一個標準版的收銀臺產品，通過標準形態的了解，讓你能夠舉一反三在不同場景下都能設計出體驗良好的收銀臺。

【老規矩，覺得簡單或者啰嗦的同學，直接翻到最后看總結】

一、支付收銀臺介紹

1. 收銀臺的終端

圖1：支付終端類型

支付終端的目的是通過場景適配為用戶提供體驗良好的操作體驗，并且也是為了保證用戶的支付安全。

1）場景適配

現在手機、柜面、自助設備、網站等交易場景很多，因此就要給出適配各種場景的收銀臺提供給客戶去使用。

2）操作體驗

原始的支付方式都是一些需要技術開發的接口，因此需要通過各種終端頁面來保證用戶操作的體驗流暢，這樣才能給商家帶來更好的支付轉化率。

3）支付安全

支付安全主要是兩方面，一方面是通過增加“密碼、刷臉、指紋、安全證書”等方式保證用戶支付的安全。另一方面是通過“終端與渠道”綁定，減少中間機構和服務商進行路由套利的機會。

2. 收銀支付方式

圖2：支付方式變遷

一個簡單好用的收銀臺背后是“支付方式”，而支付方式背后則是對支付渠道提供的支付產品的包裝。支付方式的作用一方面是向用戶展示他可使用支付渠道有哪些，另一方面通過錢包、二維碼、刷臉等方式包裝提升用戶支付效率和體驗。

支付方式從現金到二維碼經歷了一個比較長的發展過程，所有的支付方式都是從早期柜面上現金交易的卡、折、電匯、信匯發展而來的。而能夠進行網絡和移動支付的主要分為“卡基、賬基、條碼”三類。

1. 卡基支付

圖3：卡基支付

卡基支付是指以銀行卡為介質進行支付的形式。這也是最基礎的一種支付方式，只要你擁有一張儲蓄卡或者信用卡就能進行支付。

1）POS刷卡

這是最早的一種電子支付方式，也是一種線下的支付方式。通過POS機具讓你在線下門店、商超刷卡支付。后來又演變出手刷、智能POS支付等產品。

2）快捷支付

這是最早的一種移動支付方式，通過線上綁卡就能進行網上的支付和消費。也是移動支付最流行的支付產品，因為他可以擺脫實體卡的束縛通過手機方便的支付。

3）網銀支付

早期的網銀支付是需要通過PC電腦跳轉到銀行的網銀上進行大額的支付，現在網銀支付也逐步開始移動化方向發展了。而傳統的PC端操作的網銀更多的應用在大額支付、企業支付的場景中。

卡基支付雖然在早期移動支付中起到推動作用，但是其使用起來并不是很方便，POS刷卡你就需要攜帶銀行卡在身邊，快捷支付你需要在不同的平臺綁卡，網銀支付你要安裝加密插件或者攜帶U盾。因此賬基支付應運而生。

2. 賬基支付

圖4：賬基支付

基于賬戶的支付方式，他主要是在銀行賬戶、支付賬戶、數幣賬戶上包裝出來的錢包賬戶。這種支付方式依托于互聯網支付平臺大量的實名認證的用戶體系，通過他們的提供的賬戶體系，商家接入后用戶不需要再進行繁瑣的實名認證，直接就能進行消費。

比如電商類平臺就普遍接入了微信、支付寶、云閃付的支付產品，由于用戶已經完成實名，交易轉化率非常的高。

3. 條碼支付

圖5：條碼支付

這里主要是指面向各種二維碼進行線上訂單碼，線下機具、碼牌等一體化的支付方式，當然他本質上是對銀行卡、賬戶的一種深度聚合包裝。這里二維碼又按照“商戶”和“用戶”維度分為三種形式。

• 商家靜態碼：這是以收款商家的商戶號生成的二維碼，主要做出靜態碼牌，云喇叭等形式用戶掃碼后輸入金額付款，這種二維碼適合做出聚合碼支持多種APP來支付。
• 商家訂單碼：這種是根據商家接收到的商品訂單來生成的二維碼，用戶無需輸入金額直接按照訂單支付即可。這類主要用在自助設備和網站上供用戶支付。
• 用戶付款碼：他是根據用戶的收款賬號生成的付款碼，商家通過掃碼槍或者盒子掃描用戶APP展示的付款碼完成收款。

3. 收銀交互體驗

圖6：支付三步式體驗

“你為什么一個頁面要做這么久”，其實這是對收銀臺的誤解。如果你使用過開戶、綁卡和實名認證，應該知道在未實名的情況下收銀臺的支付方式開通還是比較復雜而繁瑣的，只是在微信、支付寶的大量實名用戶支撐下讓你覺得簡單而已。

收銀臺除了支付方式包裝外，他的用戶流程經過微信、支付寶的市場教育之后也是基本上是一套標準的流程。我們可以把它分為支付前、支付中、支付后三個階段。

1）支付前

這就是用戶看到第一個支付頁面，他分為訂單和支付方式兩部分。

• 訂單信息：是給用戶展示“商品訂單”、“交易金額”、“商家名稱”等簡單的支付信息，讓用戶確認是否要進一步支付。

• 支付方式：是提供用戶選擇通過什么賬戶來進行付款。這里支付方式就需要盡可能的豐富了，因為用戶都下單了，如果因為沒有合適的支付方式而放棄支付，那就太可惜了。因此這里除了銀行卡、賬戶以外，還有貨幣基金、授信額度等多種支付方式供你選擇，總有一款適合你付錢。

2）支付中

用戶選擇了支付方式點擊確認后，就要進入支付頁面了讓用戶完成支付了。如果用戶選擇的是銀行卡、賬戶支付，收銀臺會跳轉到本地的支付頁面；如果是微信、支付寶、銀行APP、數字人民幣等外部提供的支付頁面，需要跳轉到渠道的提供的收銀臺完成支付。

用戶支付成功后需要跳轉回來繼續下一步操作，這時候由于兩邊系統缺少交互，因此分四個步驟來進行，頁面跳轉、支付回調、結果查詢和用戶通知。以確?！绊撁?、賬務系統、接入商家、用戶”四方都能同步到支付結果。

3）支付后

跳轉回來后，給用戶展示的頁面主要分為“支付結果”和“營銷活動”兩部分。

1. 支付結果：就是用戶支付這筆訂單的最終結果，結果頁面的正常展示說明渠道、本地都已經同步結果了，如果沒能正常展示則需要提示用戶去主動查詢訂單結果。
2. 營銷活動：營銷活動是個可選項，并不是每個收銀臺必須的?？梢耘渲脙炔康耐扑]產品和活動，也可以配置外部的營銷活動（例如微信點金計劃）等。

二、收銀臺業務架構

收銀臺由于涉及用戶支付操作的全流程，因此他的“戰線”拉得也比較長。它與“終端，網關、收銀服務、支付服務”緊密協作，為用戶提供良好的支付體驗。

1. 業務架構介紹

圖7：收銀臺業務架構

• 終端：它是用來適配各類支付場景，例如“h5支付”頁面要提供定制化的引導頁面，支付后的活動頁面?！癆PP支付”要提供可以給商戶APP集成的SDK，收銀設備要提供不同設備環境內的“應用APP”等。同時收銀終端也要為客戶提供“安全證書、密鑰”等安全加密機制，以確保終端和網關之間的交互安全。
• 網關：網關是對外提供各類的服務接口給商家平臺和終端設備進行調用，并且負責根據請求處理對后端調用。對接收銀臺的網關主要分為“收單網關”和“會員網關”兩類。收單網關負責“收款、分賬”等支付請求的處理；“會員網關”負責“充值、付款、開戶、綁卡等”賬戶請求的處理。
• 收銀服務：收銀臺服務主要用來負責“收銀臺訪問”，“收銀臺展示”，“交易過程處理”。它向前端提供收銀臺服務的接口，收銀臺展示和交易處理的流程，以及對后臺支付服務調用。
• 支付服務：他為收銀臺提供后臺支撐服務，內容包括“商戶系統”、“支付渠道”、“賬戶系統”、“交易系統”、“實時風控”等多個系統。

2. 收銀臺用例介紹

圖8：收銀臺用例

1）收銀臺業務邊界

• 網關訪問：收銀臺對外提供“收銀臺服務接口”，接收來自收單網關、會員網關的支付請求。
• 客戶系統：收銀臺對“客戶系統”主要是訪問“會員認證”和“商戶產品”配置。其中“會員認證”用于對用戶支付方式對應的“銀行卡”和“賬戶”進行信息驗證，同時也可以擴展“綁卡/開戶”的操作。收銀臺本身是商戶簽約產品的一部分，因此收銀臺的配置是從商戶簽約產品中獲得信息。
• 支付系統
• 交易服務：為收銀臺提供收款、充值、付款，以及收款成功后交易分賬處理。
• 支付渠道：如果渠道也有類似“小程序、APP、H5”的收銀臺，需要通過本地收銀臺與渠道進行“獲取、拉起和回跳”等訪問和處理。
• 實時風控：對交易限額、限次等實時風控規則對收銀臺交易檢查，即時攔截用戶支付時監測到的風險。

2）收銀臺用例說明

• 收銀臺接口：收銀臺提供給外部的服務接口，包括“地址獲取、頁面獲取、回調處理、結果查詢”等；
• 收銀臺服務：收銀臺服務的主控服務，通過讀取商家的收銀臺參數來控制頁面展示和交易處理流程。
• 支付方式：以接口或者頁面的形式，提供收銀臺支付方式的信息的查詢，以及在收銀臺上對于綁卡、開戶操作的擴展。
• 支付頁面：按支付前、支付中、支付后三個步驟來操作對應的支付頁面。

三、收銀臺工作原理

隨著移動支付的推廣，以及微信/支付寶的長期的市場教育，他們四段式收銀臺交互標準，已經成為事實上的行業標準。掌握這個標準流程，做個收銀臺其實很簡單。

圖9：收銀臺“四段式”交互流程

1. 標準四段式交互

1）支付下單

這是支付的第一步，我們選擇商品下單后就會進入“收銀臺頁面”向你展示支付金額，商品摘要信息，讓你選擇支付方式，你確認后就會向后臺下單。

2）調用收銀臺

下單后服務端會返回一個收銀臺參數，獲得這個參數后支付平臺就能拉起收銀臺讓用戶跳轉完成支付了。如果用戶選擇的“快捷、余額支付”等本地支付方式，就會調用本地收銀臺，如果用戶選擇的是微信、支付寶這類外部的賬戶就會調用渠道的收銀臺。

3）回調通知

回調包括兩部分，一部分是收銀臺返回，另一部分是支付結果通知。

• 收銀臺返回：用戶在收銀臺上完成支付后，需要返回發起交易的平臺繼續完成后續的操作，
• 支付結果通知：跳轉收銀臺這種方式雖然很安全，但是用戶的支付結果對于發起交易的“商家或支付平臺”是無法掌握的。因此，需要通過回調的方式把結果推送給發起者所在的平臺。

4）同步結果

• 商家結果查詢：返回發起方的頁面后會有一個短暫的白屏頁面，這是本地的結果頁面要查詢訂單結果給用戶看。如果回調結果已經到了支付系統，那本地查詢下就可以了。如果沒有則需要到渠道把這個支付結果查回來然后記賬并完成結果頁面的推送。
• 用戶結果通知：如果一直查不回來，那豈不是用戶和商家都不知道呢？這個設計者也想到了，渠道不僅會通知商家支付系統，也會發送短信或者APP消息告知用戶已經扣款。

以上就是一個行業內通用的收銀臺支付過程，在網絡一切正常的情況下他幾乎是在一瞬間完成，讓你對此渾然不知。即使出現網絡異常，他也能保證交易對手之間至少有一個人對于支付結果是明確的。

2. 收銀臺服務流程

了解了四段式的處理方式我們再來深入技術實現的細節，看下系統內部各個模塊之間是如何去串聯的和處理的。

圖10：收銀臺時序圖

1）收銀臺參數

我們看到下單過程創建訂單前，首先跟進用戶選擇的支付方式在商戶系統中讀取收銀臺的配置信息，這樣做的目的就是校驗商家有權限使用哪些支付產品，收銀臺應該給他如何展現。

2）支付下單

支付下單過程中包含兩個過程：

1. 創建支付訂單：首先是本地創建支付訂單，如果涉及渠道收銀臺也要同步去創建。
2. 獲取收銀臺參數：其次就是要生成收銀臺參數，提供調用收銀臺做準備。收銀臺參數一般是鏈接或者訪問的令牌（這個在后面詳細介紹）。

3）收銀臺跳轉

• 收銀臺跳轉：獲得收銀臺參數后，下一步就是讓用戶跳轉到指定的收銀臺上進行支付。這一步主要是通過“收銀臺系統”與“渠道收銀臺”之間參數進行轉換和收銀臺的跳轉。
• 二次開發：這里也是渠道收銀臺是否要二次包裝的關鍵位置，比如我們做聚合二維碼的時候，在此處就可以根據用戶掃碼的APP來決定是跳轉“微信公眾號”還是“支付寶服務窗”，這樣用戶可以無感的完成跳轉選擇。

4）支付回調

• 支付結果登記：為了能夠及時掌握用戶在渠道收銀臺上是否完成了支付，作為收銀臺提供者一方要給交易發起者一個支付結果通知，這樣發起者就能進行賬務登記。
• 及時響應結果：作為發起者也要完成賬務登記后給支付渠道一個“成功”響應結果，告訴渠道我記完賬了。如果不返回會怎么辦呢？渠道為了保證你能成功就收，他會按照一定的時間間隔不斷的向你發送結果通知，直到你給回復，或者超出規定的次數或時間。

5）收銀臺返回

• 頁面返回：完成支付后需要返回商戶結果頁面，這個結果頁面一般是通過在渠道的商戶后臺進行設置或者通過集成的SDK來獲得返回地址。
• 結果查詢：頁面返回后本地的結果頁面還不知道這筆訂單記賬成功沒有，是否有折扣、是否扣收用戶手續費等信息，因此要進行一次結果查詢。如果沒有查回來則會讓用戶去主動確認訂單結果，系統也會定時地去掃描結果，直至最終支付系統和渠道的結果一致。
• 用戶通知：這個處理支付渠道和用戶之間的交互，有APP內通知、短信通知等多種形式。中間商戶系統、支付系統本身不需要處理。其目的就是確保用戶了解支付結果，防止訂單被篡改。

四、收銀臺設計實戰

了解了收銀臺四段式的工作原理之后，我們再通過一個實際案例來介紹下具體的設計實現。我們來設計一款“統一收銀臺”的收銀臺支付產品，他能以統一的方式完成市面上主流支付方式以收銀臺的形式完成支付。

1. 統一收銀方案

1. 統一收銀背景

我們希望介紹一套統一的收銀系統，支付平臺只要發布一套標準服務，就能快速擴展主流的支付方式，包括“快捷支付、余額支付、小程序、公眾號、APP、H5、掃碼支付（C掃B）、條碼支付（B掃C）”等都能支持。

2. 產品實現方案

圖11：統一收銀臺的核心能力

1）產品方案分析

從上圖中我們可以看到，微信、支付寶兩套接口整體交互基本是一致的，唯一的區別就在調用的收銀臺由于適配的終端不同需要采用不同的調用方式。所以我們就采用“微信、支付寶”接口標準作為我們收銀臺服務的標準（沒錯，就是抄）。

這里比較麻煩的是，快捷、賬戶兩個支付方式，他們服務交互形式各有各的特色，并不是很好整合。所以我們統一把這些個性化的支付方式按照“四段式交互標準”包裝成“APP和H5”形式的“聚合收銀臺”，這樣支付的整體交互就統一了。

2）統一下單方案

通過方案分析，我們知道做一個收銀臺它的個性化部分主要是在下單和調用收銀臺，我們就從這里下手來做統一收銀臺。至于服務的交互標準我們就采用微信的交互方式稍加改造我們自己的統一收銀就實現了（我們不是抄產品，我們只是行業標準的搬運工）。

圖12：統一下單數據要素（紅色字體為通用報文頭）

• 增加支付類型：要做統一收銀臺，并不是簡單的照抄微信，因為微信雖然標準但它不是統一收銀。所以我們在統一下單的報文中增加一個“支付類型”，讓商家要使用什么支付方式進行選擇，這樣就能無限擴展新增的收銀臺了。
• 定義公共要素：我們希望每個報文公共部分都是一樣的，業務要素是可以根據具體場景再來補充。所以我們需要仔細研讀各種收銀臺的接口文檔抽取出公共部分，當然這個過程還是挺費時間和吃功夫的。為了節約大家時間我這里給大家一套標準的方案直接拿去改吧。把圖中標紅的字段作為公共的報文要素，保持每個報文都按此方式統一處理。其他信息按照具體業務場景進行增減和保證即可。

• 擴展業務信息：統一下單訂單目的是創建一筆訂單來記錄交易過程，然后根據不同支付方式返回不同類型的收銀臺提供下一步操作。因此我們給返回報文定義完公共信息后，增加一個擴展參數支持各種收銀臺參數和交互業務信息的返回給交易發起方進行下一步操作。

3）收銀調用方案

完成了訂單創建后，我們就可以跳轉收銀臺進行支付了。這一步是否順利完成，就不是接口層面的事情了。它依靠的是你當初商戶入網時候申請的支付產品了，畢竟支付是件合規性要求很高的事情，什么樣的場景適用于什么收銀臺都要根據實質業務場景來審核的。下面我們來看下申請收銀臺需要哪些前期準備。下面我們以微信支付為例來介紹整個準備過程，支付寶和其他錢包APP基本類似，稍作轉換和后臺配置即可。

圖13：收銀臺使用的參數說明

1）申請參數（讓你擁有身份）

首先你要在渠道上申請“應用編號”和“商戶編號”，應用編號是支付渠道給你分配使用支付應用的一個統一編號。簡單來說有了他你就可以去申請各種收銀臺了。“商戶編號”就是你可以收錢的賬戶編號。

2）安全加密（讓你安全支付）

支付說到底是個接口生意，由于需要交易數據交互和多段式接口調用，因此需要安全證書和密鑰，確保信息安全的加密傳輸，交易接口也不會被交易發起方隨意的篡改和套用。

3）應用配置（讓收銀臺返回）

當你申請完成開通商戶后，還不能立即進行開發你要設置收銀臺結果頁面返回地址，以便于用戶操作完后返回你的平臺。這里的設置根據不同的收銀臺各有不同設置方式，其目的就是讓用戶返回更為順暢。

4）下單接口（實現統一下單）

下單接口都是采用統一下單的方式。其中付款碼稍微特殊些，他是一種用掃碼槍或者掃碼盒子主掃（B掃C）的形式，需要交易發起方上傳讀取的二維碼給渠道方，渠道方校驗通過后返回訂單結果給交易發起方。

5）返回參數（三類收銀參數）

下單后的返回收銀臺參數各有不同，主要分為以下三類

1. 交易編號：它返回的是創訂單的“預支付編號”，適用于在渠道APP內部調用的收銀臺（例如小程序、公眾號、APP等），渠道會根據預支付編號查詢你原始的訂單，并加載收銀臺給你使用。
2. 收銀臺鏈接：適用于掃碼、H5等通過支付鏈接來返回二維碼和收銀臺的支付方式。
3. 無收銀臺參數：當然也有像“付款碼”這種收銀臺在用戶一側，無須任何收銀臺信息的交互形式。

6）收銀調用（四種技術手段）

收銀臺調用是比較偏技術實現層面的，它分為“API調用、瀏覽器調用，集成sdk調用和鏈接訪問”四種方式。詳細的我們在后面“產品需要知道的技術”文章中單獨介紹。

7）回調地址（通知支付結果）

回調地址就是支付結果的通知地址，這個地址是在下單時候交易發起方主動上傳的，用來接收用戶在收銀臺上的支付結果。至此我們整個收銀臺的實現方案已經明確好了，下面我們就可以開始實際的設計了。

2. 收銀臺交互

通過收銀臺完成支付主流移動支付形式有四類“銀行卡支付、余額支付、APP支付、掃碼支付”，這些支付方式都遵循了“四段式”的支付方式。（需要說明的是以下收銀臺交互都是以一家為商戶提供支付服務的三方支付機構視角提供頁面）

1. 銀行卡支付

圖14：銀行卡快捷支付

銀行卡支付底層是基于快捷支付產品，快捷產品特點就是需要簽約綁卡，支付的時候也一般需要短信驗證碼。因此這里的選擇支付方式之后是調用了本地快捷收銀臺，其后的回調結果由于是本地支付方式因此速度非?？炀涂梢酝瓿桑S后將結果同步給商家。

2. 本地余額支付

圖15：支付賬戶余額支付

本地余額支付主要指通過本地支付賬戶進行支付（支付賬戶又叫會員賬戶、余額賬戶）。用戶選擇支付方式后會跳轉到余額賬戶的收銀臺確認訂單與賬戶后輸入密碼完成支付。由于賬戶是本地的因此回調結果非?？斓姆祷亟o商家，同步也返回商家頁面。

3. 渠道賬戶支付

圖16：渠道賬戶支付

渠道賬戶支付主要是指接入“微信、支付寶”或者“銀行數字賬戶”等產品，這類也是采用了四段式交互，因此過程就相對復雜了。用戶在收銀臺選擇支付方式后，先要調用渠道收銀臺，讓用戶跳轉后完成支付。支付成功后需要接收渠道的回調結果，然后將回調結果同步給商家。最后渠道返回頁面到支付平臺，支付平臺再返回到商家。

由此可見，這個過程每個節點都有商家、支付平臺、渠道要進行轉發和同步，因此比較容易出現結果不明的情況，因此這類產品需要配合定時任務來同步結果，保持“商家、支付平臺、渠道”結果最終一致性。

4. 掃碼支付

圖17：掃碼支付

掃碼支付主要是指“靜態碼牌”或者“網站/自助設備商品碼”，他們的特點就是可以自制一個二維碼，在用戶掃碼下單后，判斷掃碼APP來跳轉到不同的收銀臺（一般是公眾號或者服務窗）完成支付。支付成功后通過用戶在APP內點擊確認返回結果頁面，這里的結果頁面如果是靜態碼牌由于商家未做定制因此直接返回支付的頁面即可。

3. 收銀臺配置

有了收銀臺支付產品，就需要能夠靈活的配置出來提供給商戶使用，并且收銀臺上的所展示的內容可以進行靈活的配置，滿足不同產品、不同客戶的需求。因此收銀臺采用了下的配置過程。

圖18：收銀臺配置關系

商戶入網申請通過后，會給商戶配置所申請的“簽約產品”，簽約產品一般是提前設置好的，只要在“商戶簽約設置”中將簽約產品關聯上就可以了。

1. 簽約產品配置

在提供商戶配置之前，要先創建一個默認的支付方式配置。像聚合收銀臺這樣的產品，它可能是多組支付方式組成的，因此在這里我們把這一組的支付方式稱為一個“簽約產品”。

圖19：簽約產品設置

創建一個簽約產品需要給他設置很多東西，包括使用什么網關接口，交易類型，收付款賬戶，默認分賬方，以及為每個支付方式設置他們的交易屬性。

從上圖我們可以看到，支付方式可以進行多級分組，這樣就能適應收銀臺多種支付方式分類展示，讓用戶使用更加一目了然。同時每個支付方式還能設置它的排序、是否展開，logo，營銷文案，綁定卡很多時默認展示幾張卡等一系列細致入微的特性。

一般情況下簽約產品是提前設置好的，商戶簽約的時候直接選擇就可以了；如果商戶有特殊需求我們按照模板重新給他創建一個就能滿足不同商戶的需求。

需要再次說明的是，這里的簽約產品配置是以“收單機構”場景下的產品設置，與普通非持牌機構設置不同之處在于賬戶部分的設置。因為收單機構有清結算資質可以做渠道路由，所以不必每個支付方式綁定對應的渠道，只要設置商戶結算賬戶就可以了。

如果是非持牌機構只要把“賬戶設置部分”改為“支付渠道”的設置就可以了。

2. 商戶信息管理

圖18：商戶信息列表

一個商戶簽約入網完成實名認證和事前審核后，商戶運營人員就會在此處給商戶創建支付產品，點擊創建會跳轉到的“商戶產品配置”頁面進行產品設置，設置完成后簽約產品會與商戶進行關聯這樣商戶就能接入使用了。當然每次配置創建、修改都需要重新審核通過后才能生效，避免配置不當造成不當配置影響商戶使用。

3. 商戶產品配置

商戶產品配置的目的就是把商戶和簽約產品關聯起來，并對支付方式提供的默認參數進行修改以符合客戶的使用需求。

圖19：商戶產品配置

從圖中我們可以看到，一個商戶可以添加多個簽約產品，并且每種簽約產品可以根據“原始簽約產品”提供的參數進行設置，以滿足不同商戶交易、賬戶和優惠活動參與的需求。

五、總結：統一收銀臺設計

1. 四段式收銀臺設計

統一收銀臺的精華就在于它“四段式”設計標準，他是所有做支付人的共同語言，因此請大家牢記這四個交互過程，學會了他，再復雜的收銀臺設計都能收到手到擒來

2. 收銀臺能力視圖

收銀臺在方便了用戶操作和提升支付安全的同時，也把各種不同的支付方式進行了統一，使得對接也變得非常規范和簡單。Ping++曾經提出來“7行代碼完成支付開發”就是看透了收銀臺設計的本質，支付的差異化就在下單和調用收銀臺兩個過程，其他過程都是標準可復用。

3. 用例模型舉一反三

掌握收銀臺的標準用例模型，理解網關、接口、客戶系統在，四段式設計，統一交互和產品配置方面如何實現整體閉環。理解了這張圖你任何收銀臺設計都能應付自如。

4. 多看微信、支付寶接口

我可以負責任的說，國內所有的移動端收銀臺產品都是參考這兩家的標準來做的。所以要多研究這兩家的接口設計，特別是“下單、調用收銀臺、結果通知和結果查詢”這四個接口。產品做的好不好全看對于這四個接口理解的深淺。????