201106286 六、發明說明： 【發明所屬之技術領域】 本申請案屬於網路技術領域，尤其是一種自適應選擇 銀行卡進行支付的系統及方法。 【先前技術】 近年來，電子商務逐漸成爲網際網路經濟發展的主要 潮流’網上購物和支付也成爲一種方便的生活方式。 請參閱圖1，其爲現有技術一種網上支付的原理結構 示意圖.用戶所在的用戶終端11透過支付平台12向收款 方支付款項。收款方可以是商戶。收款方所在收款方終端 13可以透過網路連接至支付平台12。用戶在支付平台12 上有對應的支付帳戶，用戶在銀行子系統1 4上開設有銀 行帳戶。爲了減少風險，用戶通常不採用直接在網頁上輸 入卡號和密碼來進行支付，當卡號和密碼被洩露時，容易 給用戶造成損失。 爲此’支付平台12採用支付帳戶和銀行帳戶進行綁 定’用戶只需要選擇自己綁定的銀行卡，支付平台12負 責完成與銀行子系統14之間的結算、對帳等資料操作。 爲了提高安全性，支付平台12還可以讓用戶設定銀行卡 對應的別名。當用戶所在的用戶終端1 1向支付平台1 2發 出支付請求時，除了需支付的資訊（包括支付方資訊和支 付金額等）’运需要指定付款的銀行卡別名等資訊。支付 平台12處理支付請求，將費用支付至對應的收款方對應 -5- 201106286 的帳戶，該帳戶可以是收款方在支付平台12上有對應的 收款方帳戶’也可以是設置在銀行上該收款方對應的銀行 帳戶。 支付平台12至少包括支付伺服器21、對帳處理伺服 器22和資料庫23，資料庫23上儲存有使用支付平台12 的用戶資訊、帳戶資訊、支付處理資訊以及與各家銀行子 系統14完成的結算對帳資訊。支付伺服器21主要是完成 支付請求的處理操作，對帳處理伺服器22主要是完成與 銀行子系統1 4等的結算、對帳、資料交互等操作。 目前，用戶在支付平台12中會設置多個用於支付操 作的銀行卡資訊。當用戶終端11透過網際網路連接至支 付平台12時，若向支付平台12發送的支付請求中未攜帶 用於此次支付的銀行卡資訊，則支付平台12需要與用戶 終端Π進行交互後獲得本次支付操作的銀行卡資訊。由 於銀行卡資訊是敏感資訊，這種方式獲得不僅佔用支付伺 服器21的處理資源，而且在網際網路上進行這種敏感資 訊的交互安全性低。還有，每一次支付時都需要向用戶詢 問選擇哪家銀行卡，延長支付處理時間，而且佔用支付伺 服器21和網路的資源。 +現有技術中透過電話支付或是透過WAP (無線應用 協議，Wireless Application Protocol)進行支付時，若向 支付平台12發送的支付請求中未攜帶用於此次支付的銀 行卡資訊時，由於資源的限制’支付平台1 2不能提供一 個交互頁面來供用戶具體選擇使用哪張銀行卡’支付平台 -6- 201106286 12通常是選擇用戶使用最頻繁的銀行卡來完成支付。如 果支付平台12提供一個交互頁面供用戶選擇銀行卡，該 支付平台12可以透過WAP網路將該交互頁面提供到至手 機用戶，建立與手機用戶的交互。也就是說，一次選卡的 交互需要透過web伺服器、WAP代理伺服器和無線通訊 網路的通訊，不僅使得選卡時間變長，從而使得支付處理 的時間長，而且當其中某一設備發生故障時，整個選卡即 中止，降低支付的成功率^ 也就是說，目前利用支付平台進行支付的支付過程中 ，通常需要支付平台提供交互頁面來供用戶具體選擇使用 哪張銀行卡完成支付，這種方式不僅佔用網路資源來進行 交互，而且最爲重要的是降低了支付處理的速度，使得支 付伺服器2 1需要花費資源和時間來完成處理操作。並且 ，在一些應用場景，支付平台12不能提供交互頁面來供 用戶具體選擇使用哪張銀行卡，而是支付平台12自作主 張選擇某種銀行卡，這種處理存在著安全問題。 【發明內容】 本申請案的目的在於提供一種自適應選銀行卡進行支 付的系統，以解決現有技術選卡過程中安全性低、延長支 付處理時間及佔用資源的技術問題。 本申請案的另一目的在於提供一種自適應選銀行卡進 行支付的方法，以解決現有技術選卡過程中安全性低、延 長支付處理時間及佔用資源的技術問題。 201106286 一種自適應選擇銀行卡進行支付的系統’透過支付平 台爲用戶向收款方進行支付操作，所述支付平台包括： 資料庫··用於儲存包括用戶帳戶資訊、用於支付的多 張銀行卡資訊、選卡規則資訊、支付記錄資訊在內的資訊 » 規則引擎單元：連接所述資料庫，用於按照所述選卡 規則資訊從多張銀行卡中找出本次支付的銀行卡； 支付處理單元：分別連接所述資料庫和所述規則引擎 單元，用於接收用戶所在用戶終端的支付請求，透過所述 規則引擎單元得到本次支付的銀行卡，利用該銀行卡將支 付金額支付至收款方。 規則引擎單元和支付處理單元分別設置在規則引擎伺 服器和支付伺服器上。 一種自適應選擇銀行卡進行支付的方法，透過支付平 台爲用戶向收款方進行支付操作，包括： (1)設定從多張銀行卡中選擇出支付卡的選卡規則 資訊； (2 )當接收到用戶所在用戶終端的支付請求時’按 照所述選卡規則和支付記錄資訊，從多張銀行卡中選擇當 前本次支付的銀行卡； (3 )利用該銀行卡將支付金額支付至收款方的操作 〇 與現有技術相比，本申請案具有以下優點： 首先，本申請案可以預先設定選卡規則，在每次選卡 201106286 時，不需要重新和用戶所在用戶終端建 用戶選卡後再進行後續的支付操作。不 ，而且也不需要佔用網路和支付平台的 用戶是以手機終端的方式透過WAP協 支付請求時，也無需進一步選卡操作， 效率，也進一步提升了支付的成功率。 其次，透過設置支付伺服器和規則 成支付和選卡操作。不需要對現有的支 改動，透過額外增加規則引擎伺服器和 種設計能提高現有支付伺服器的安全性 統的耦合性。 最後，預先在每次規則引擎軟體啓 則資訊調入該伺服器的記憶體中，並且 保存的選卡規則，在保證選卡的精準度 度。 【實施方式】 結合附圖，具體說明本申請案。 實施例1 請參閱圖2、圖3，其爲本申請案 進行支付的系.統的第一實施例示意圖< 4 1、支付平台4 2、收款方所在收款方終 子系統44。用戶終端4 1可以是作爲網 立選卡交互，等待 僅提高了支付速度 資源。特別是，當 定向支付平台發起 提高了整個支付的 引擎伺服器分別完 付伺服器做過大的 完成選卡操作，這 ，而且還能提高系 動時將所述選卡規 定期更新記憶體中 時還提高了選卡速 自適應選擇銀行卡 >它包括用戶終端 端43和各種銀行 路終端透過網際網 -9- 201106286 路連接至支付平台42上，也可以作爲一個電話機，透過 現有的固話系統與支付平台42進行通訊，也可以是作爲 手機，利用WAP協定透過無線通訊網路和網際網路建立 與支付平台42的通訊。收款方在支付平台42上設置有對 應的收款方帳戶，也可以是與支付平台42連接的銀行子 系統中設置對應的收款方帳戶。爲了說明方便，本實施例 中’收款方在支付平台42上設置有對應的收款方帳戶， 用戶在支付平台42上設置有對應的支付帳戶。事實上， 收款方所設置的收款方帳戶和用戶設置的支付帳戶，支付 平台42是作爲用戶做統一的管理的，也就是說，收款方 和用戶同樣是支付平台42的用戶，收款方帳戶和支付帳 戶僅僅是叫法上不同，性質上都是做爲用戶帳戶進行管理 〇 支付平台42進一步包括資料庫51、支付伺服器52、 規則引擎伺服器5 3和對帳處理伺服器5 4。 資料庫51用於儲存用戶帳戶資訊、用戶設定用於支 付的多張銀行卡資訊、選卡規則資訊、支付記錄資訊等在 內的資訊。請參閱圖3，其爲資料庫51的結構原理示意 圖。它包括： 用戶資訊儲存單元511:用於儲存包括用戶資訊、對 應的支付帳戶資訊、與該支付帳戶匹配的用於支付的多張 銀行卡資訊在內的資訊； 支付記錄儲存單元5 1 2 :用於儲存處理每次支付請求 的處理結果資訊 .10- 201106286 規則儲存單元513:用於儲存用戶自設定的多張銀行 卡的選卡規則和儲存包括各家銀行卡支付額度在內的系統 選卡規則。 用戶資訊儲存單元511和支付記錄儲存單元512通常 是指邏輯上的劃分，其在物理上可以透過一張寬表來保存 所有資訊。比如，該張寬表可以以支付帳戶爲單元進行儲 存，其欄位包括該帳戶對應的訪問密碼、支付密碼、用戶 資訊、多張銀行卡資訊、支付資訊等。多張銀行卡資訊包 括銀行卡號、別名、銀行卡所屬的銀行資訊、該張銀行卡 當曰交易額資訊、當月累計交易額資訊等。支付資訊包括 該用戶帳戶當日交易額資訊、當月累計交易額資訊等。支 付伺服器52定期更新該張寬表的內容。 規則儲存單元513可以包括系統選卡規則儲存子單元 、用戶選卡規則儲存子單元、規則儲存子單元。系統選卡 規則儲存子單元用於儲存包括各家銀行卡支付額度在內的 系統選卡規則。系統選卡規則是指對各家銀行卡使用限定 條件，主要是指各家銀行卡的支付額度限定。系統選卡規 則儲存子單元可以以表格的形式儲存選卡規則，比如以各 家銀行卡爲單位，保存該銀行卡的使用限定條件。用戶選 卡規則儲存子單元是保存用戶自定義的選卡規則。選卡規 則可以是一張銀行設定一個自定義的選卡規則，也可以是 所有的卡設置一個或多個選卡規則。規則儲存子單元是用 於融合用戶自定義的選卡規則和系統選卡規則後確定的該 用戶最後的選卡規則。用戶選卡規則儲存子單元也可以省 -11 - 201106286 略，當接收到用戶自定義的選卡規則後，訪問系統選卡規 則儲存子單元直接確定該用戶最後的選卡規則，並將該選 卡規則儲存規則儲存子單元中。 比如，支付平台42接收到用戶自定義規則爲：該銀 行借記卡的支付規則包括（1 )單筆金額小於800元；（2 )每日累計額度2000元：（3 )每月累計小於2000元； (4)使用日期爲每月15日至31號。而該銀行借記卡在 系統選卡規則儲存子單元儲存的系統選卡規則爲：（1) 單筆金額小於500元；（2)每日累計額度1 500元，則最 後確定的該用戶的該銀行卡的選卡規則爲：（1)單筆金 額小於500元；（2 )每曰累計額度1 500元；（3 )每月 累計小於2000元；（4)使用曰期爲每月15曰至31號。 也就是說，這四個限定條件儲存在選卡規則中，可以以表 1的形式儲存。 表1 用戶 ID 銀行名 卡類型 卡別名 單筆 額度 每曰累 計額度 每月累 計額度 使用 曰期 001 GDB 借記卡 工資卡 500 1500 2000 15-31 001 ... • · · ... • · ♦ ..· » 上述資料庫51公開各種儲存單元，主要是從邏輯上 進行劃分，並非指物理上的劃分。從物理上，資料庫5 1 可以由多個資料庫組成，也可以是一個資料庫組成° 規則引擎伺服器53，用於連接資料庫5 1，用於按照 -12- 201106286 所述選卡規則資訊從多張銀行卡中找出本次支付的銀行卡 。在本實例中，預先設定規則引擎軟體（後簡稱規則引擎 單元53 1 )來完成選卡操作。該規則引擎單元531可以採 用開源的Drools來實現，或者自己構造一個DFA來實現 。規則引擎單元531用什麼樣的編程語言進行編程，本實 例並非侷限。規則引擎單元5 3 1主要是訪問寬表中的記錄 判斷該些銀行卡是否滿足表1中儲存的各種銀行卡的限定 條件。規則引擎單元53 1以銀行卡爲單位，透過訪問寬表 中的記錄判斷該銀行卡是否滿足表1中的條件，如果是， 則該張銀行卡即爲本次支付的銀行卡，如果不是，則選擇 下一張銀行卡，判斷其是否滿足表1中的條件，直到找到 一張滿足條件的銀行卡作爲本次支付的銀行卡，或者是判 斷到所有銀行卡都不能滿足表1的條件。規則引擎單元 53 1也可以將所有滿足表1條件的銀行卡都找到，後按照 預先設定的選擇次序確定本次支付的銀行卡。規則引擎單 元531通常是用軟體來實現，當然本申請案也不排除用硬 體來實現。本申請案所說的規則引擎單元531主要是指安 裝有規則引擎軟體的處理器。 規則引擎伺服器53除了包括規則引擎單元531之外 ，更包含： 規則調入記憶體處理單元· 5 3 2，用於每次規則引擎軟 體啓動時將所述選卡規則資訊調入該伺服器53的記憶體 中〇 規則更新處理單元5 3 3，用於從資料庫5 1中獲得新 201106286 增或更新的選卡規則，並根據該些選卡規則來更新 中當前儲存的選卡規則。規則更新處理單元533可 查找資料庫5 1，獲得新增或更新的選卡規則。一 常見的實現方案爲表1中設置一個更新時間欄位， 存該銀行卡的選卡規則更新的時間，規則更新處 533透過該更新時間欄位即可獲得新增或更新的選 〇 規則引擎單元5 3 1、規則調入記憶體處理單元 規則更新處理單元533主要是邏輯上的劃分，這種 是用於侷限本申請案的。在具體的實現上，可以透 軟體來實現上述規則引擎單元5 3 1、規則調入記憶 單元5 3 2和規則更新處理單元5 3 3具有的所有功能 支付伺服器52，其包括選卡規則交互處理單元 支付處理單元522 »支付伺服器52更包含以下的 接收用戶新建帳戶以及修改用戶及帳戶資訊、顯示 付資訊等，由於這些功能是現有的支付伺服器.52 的功能，在此本申請案就不再說明。與現有支付 52不同的是，本支付伺服器52的選卡規則交互處 521和支付處理單元5 22。 選卡規則交互處理單元52 1，用於接收用戶新 改選卡規則，並將所述選卡規則保存至所述資料庫 支付處理單元522，用於接收用戶終端41的 求，透過所述規則引擎單元5 3 1得到本次支付的銀 利用該銀行卡將支付金額支付至收款方的操作。支 記憶體 以定期 種比較 用於保 理單元 卡規則 5 3 2和 劃分不 過一個 體處理 〇 521、 功能： 用戶支 上已有 伺服器 理單元 增或修 中。 支付請 行卡， 付處理 -14- 201106286 單元5 22接收到用戶終端41的支付請求，從中解析出用 戶資訊 '收款方資訊及需支付金額等。當按照用戶資訊到 寬表中找到對應的銀行卡資訊，若找到多張銀行卡資訊後 ’則向規則引擎伺服器5 3發出選卡請求，接收到規則引 擎伺服器53返回的選卡處理結果。選卡處理結果包括兩 種：選出某張卡爲本次支付的銀行卡和未找到符合條件的 銀行卡。 若選出某張卡爲本次支付的銀行卡，則透過該張卡完 成支付，並將支付處理結果保存至資料庫51中。若未找 到符合條件的銀行卡，則結束處理流程，並將處理結果返 回至用戶終端4 1。 對帳處理伺服器54，用於根據支付記錄儲存單元512 中儲存的處理每次支付請求的處理結果資訊，來與不同的 銀行完成對帳結算操作。 對帳處理伺服器54和支付伺服器52可以透過同一伺 服器來實現。 本實例中，透過支付伺服器5 2和規則引擎伺服器5 3 分別完成支付和選卡操作。不需要對現有的支付伺服器 5 2做過大的改動，透過額外增加規則引擎伺服器5 3和完 成選卡操作，這種設計能提高現有支付伺服器52的安全 性，而且還能提高系統的耦合性。 在本實例中，預先在每次規則引擎軟體啓動時將所述 選卡規則資訊調入該伺服器5 3的記億體中，並且定期更 新記憶體中保存的選卡規則，在保證選卡的精準度時還提 -15- 201106286 高了選卡速度。 請參閱圖4，其爲本自適應選銀行卡進行支付的方法 的實例流程圖。它透過支付平台爲用戶向收款方進行支付 操作，包括： S110 :設定從多張銀行卡中選擇出支付卡的選卡規則 資訊。 首先，支付伺服器5 2提供用戶設定或修改銀行卡選 卡規則的維護介面； 接著，支付伺服器52接收用戶透過維護介面設定或 修改的自定義選卡規則； 最後，支付伺服器52將用戶自定義選卡規則和包括 各家銀行卡支付額度在內的系統選卡規則融合成本用戶的 選卡規則，後將其選卡規則保存在資料庫的規則儲存單元 5 1 3 (如表1 )中。 S 1 20 :當接收到用戶終端的支付請求時，支付伺服器 52利用規則引擎伺服器53按照所述選卡規則和支付記錄 資訊，從多張銀行卡中選擇當前本次支付使用的銀行卡。 當支付伺服器52接收到用戶終端的支付請求時，獲 得需支付金額和收款方終端資訊； 若支付伺服器52確定該用戶對應有多張銀行卡，則 向規則引擎伺服器5 3發送選卡請求： 規則引擎伺服器53對多張銀行卡，依次對該些銀行 卡判斷是否符合選卡規則要求，選擇其中一張符合選卡規 則要求的銀行卡作爲當前本次支付的銀行卡。 -16- 201106286 S 1 3 0 :支付伺服器5 2利用該銀行卡將支付金 至收款方。 支付伺服器52保存該支付處理情況至支付記 中；透過對帳處理伺服器54完成與銀行子系統之 帳結算操作。 在本實例中，預先在每次規則引擎軟體啓動時 選卡規則資訊調入該伺服器53的記億體中，定期 庫中獲得新增或更新的選卡規則，並根據該些選卡 更新記憶體中當前儲存的選卡規則》在保證選卡的 時還提高了選卡速度。 實施例2 參閱圖5、圖6，其爲本申請案自適應選銀行 支付的系統的第二實施例示意圖。它包括支付平老 收款方所在收款方終端62、各種銀行子系統63以： 網路64。WAP網路64包括web伺服器641、WAP 服器642和手機終端643。Web伺服器（Web Serve 以HTML網頁來傳送資料，由其上的HTML篩檢 該網頁轉換成 WML( Wireless Markup Language， 記語言）格式，然後再由WAP代理（WAP Proxy 器642處理後形成二進位的WML資料流程送往用 即手機終端643。WAP網路64可以是其他的形式 其組成都是現有技術，在此就不再詳細說明。本實 web伺服器641、WAP代理伺服器642和手機終端 額支付 錄資訊 間的對 將所述 從資料 規則來 精準度 卡進行 ί 61、 泛WAP 代理伺 ：r ) 64 1 程式將 無線標 )伺服 戶端' ，由於 例中， 64 3僅 -17- 201106286 僅是舉例說明，並非用於侷限本申請案。 支付平台61進一步包括資料庫71和伺服器72。資 料庫7 1中儲存的資料可以和第一實施例相同，伺服器72 可以包括規則引擎單元721、支付處理單元722和對帳處 理單元723。 規則引擎單元72 1 :連接所述資料庫7 1，用於按照所 述選卡規則資訊從多張銀行卡中找出本次支付使用的銀行 卡； 支付處理單元722:分別連接所述資料庫71和所述 規則引擎單元721，用於接收用戶終端的支付請求，透過 所述規則引擎單元72 1得到本次支付的銀行卡，利用該銀 行卡將支付金額支付至收款方的操作； 對帳處理單元723，用於與不同的銀行子系統完成對 帳結算操作。 也就是說，第一實施例中支付伺服器、規則引擎伺服 器和對帳處理伺服器所實現的功能透過伺服器72來實現 。這種實現方式能夠提高選卡和支付的處理速度。 請參閱圖7，其爲一種自適應選擇銀行卡進行支付的 方法的第二流程示意圖。它透過支付平台爲用戶終端向收 款方終端進行支付操作，包括： S210:伺服器設定從多張銀行卡選擇出支付卡的選卡 規則資訊。 用戶可以透過網路終端來進行支付卡的選卡規則資訊 ，也可以作爲手機終端643來進行支付卡的選卡規則資訊 -18- 201106286 選卡的過程大致爲：伺服器提供用戶設定或修改銀行 卡選卡規則的維護介面；伺服器接收用戶透過維護介面設 定或修改的自定義選卡規則；伺服器將用戶自定義選卡規 則和包括各張銀行卡支付額度在內的系統選卡規則融合成 選卡規則，後將其選卡規則保存在資料庫中。 S220 :當接收到用戶終端的支付請求時，伺服器按照 所述選卡規則和支付記錄資訊，從多張銀行卡中選擇當前 本次支付的銀行卡。 當伺服器上接收到用戶終端的支付請求時，獲得需支 付金額和收款方資訊；若伺服器確定該用戶對應有多張銀 行卡，則向規則引擎單元發送選卡請求；規則引擎單元對 多張銀行卡，依次對該些銀行卡判斷是否符合選卡規則要 求，選擇其中一張符合選卡規則要求的銀行卡作爲當前本 次支付的銀行卡。 S 2 3 0 :利用該銀行卡將支付金額支付至收款方終端的 操作。 伺服器利用該張銀行卡完成支付操作，並且後續定期 完成與銀行子系統的對帳結算操作。 在本實例中，也可以將選卡規則儲存在記憶體中。並 且，伺服器定期從資料庫中獲得新增或更新的選卡規則’ 並根據該些選卡規則來更新記憶體中當前儲存的選卡規則 -19- 201106286 【圖式簡單說明】 圖1爲現有技術一種網上支付的原理結構示意圖； 圖2爲本申請案自適應選銀行卡進行支付的系統的第 一實施例結構原理示意圖； 圖3爲本申請案中支付平台的部分原理結構示意圖； 圖4爲本申請案自適應選銀行卡進行支付方法的第一 實施例流程示意圖： 圖5爲本申請案自適應選銀行卡進行支付的系統的第 二實施例結構原理示意圖； 圖6爲本申請案中支付平台的部分原理結構示意圖； 圖7爲本申請案自適應選銀行卡進行支付方法的第二 實施例流程示意圖》 【主要元件符號說明】 1 1 :用戶終端 1 2 :支付平台 1 3 :收款方終端 1 4 :銀行子系統 2 1 :支付伺服器 22 :對帳處理伺服器 23 :資料庫 -20- 201106286 41 :用戶終端 4 2 :支付平台 4 3 :收款方終端 44 :銀行子系統 5 1 :資料庫 5 2 :支付伺服器 53 :規則引擎伺服器 5 4 :對帳處理伺服器 6 1 :支付平台 6 2 :收款方終端 6 3 :銀行子系統 6 4 : W A P網路 7 1 :資料庫 72 :伺服器 5 1 1 :用戶資訊儲存單元 5 1 2 :支付記錄儲存單元 5 1 3 :規則儲存單元 521:選卡規則交互處理單元 522 :支付處理單元 531 :規則引擎單元 5 3 2 :規則調入記憶體處理單元 5 3 3 :規則更新處理單元 641 : web伺服器 642 : WAP代理伺服器 -21 - 201106286 6 4 3 .手機終端 721 :規則引擎單元 722 :支付處理單元 723 :對帳處理單元 -22-201106286 VI. Description of the Invention: [Technical Field of the Invention] This application belongs to the field of network technology, and in particular, to a system and method for adaptively selecting a bank card for payment. [Prior Art] In recent years, e-commerce has gradually become a major trend in the development of the Internet economy. Online shopping and payment have also become a convenient lifestyle. Please refer to FIG. 1 , which is a schematic diagram of the principle structure of the online payment in the prior art. The user terminal 11 where the user is located pays the payment to the payee through the payment platform 12 . The payee can be a merchant. The payee terminal 13 where the payee is located can connect to the payment platform 12 via the network. The user has a corresponding payment account on the payment platform 12, and the user has a bank account on the bank subsystem 14. In order to reduce the risk, users usually do not use the card number and password directly on the web page to make payment. When the card number and password are leaked, it is easy to cause losses to the user. To this end, the payment platform 12 uses the payment account and the bank account for binding. The user only needs to select the bank card to which he is bound, and the payment platform 12 is responsible for completing the settlement and reconciliation operations with the bank subsystem 14. In order to improve security, the payment platform 12 can also allow the user to set an alias corresponding to the bank card. When the user terminal 11 where the user is located issues a payment request to the payment platform 12, in addition to the information to be paid (including the payer information and the payment amount, etc.), the information such as the bank card alias for the specified payment is required. The payment platform 12 processes the payment request and pays the fee to the account corresponding to the corresponding payee--5-201106286, which may be the payee's corresponding payee account on the payment platform 12' or may be set at the bank The bank account corresponding to the payee. The payment platform 12 includes at least a payment server 21, a reconciliation processing server 22, and a database 23. The database 23 stores user information, account information, payment processing information, and payment with the banking subsystem 14 using the payment platform 12. Settlement reconciliation information. The payment server 21 is mainly a processing operation for completing the payment request, and the reconciliation processing server 22 mainly performs operations such as settlement, reconciliation, and data interaction with the bank subsystem 14. Currently, the user sets a plurality of bank card information for payment operations in the payment platform 12. When the user terminal 11 is connected to the payment platform 12 via the Internet, if the payment request sent to the payment platform 12 does not carry the bank card information for the payment, the payment platform 12 needs to interact with the user terminal to obtain Bank card information for this payment operation. Since the bank card information is sensitive information, this method not only occupies the processing resources of the payment server 21, but also the interactive security of such sensitive information on the Internet is low. Also, each time a payment is made, the user is asked which bank card to select, the payment processing time is extended, and the resources of the payment server 21 and the network are occupied. In the prior art, when paying by telephone or by WAP (Wireless Application Protocol), if the payment request sent to the payment platform 12 does not carry the bank card information for the payment, due to the resource Restricted 'Payment Platform 1 2 cannot provide an interactive page for the user to specifically choose which bank card to use' Payment Platform-6- 201106286 12 Usually the user is selected to use the most frequently used bank card to complete the payment. If the payment platform 12 provides an interactive page for the user to select a bank card, the payment platform 12 can provide the interactive page to the mobile phone user via the WAP network to establish interaction with the mobile phone user. That is to say, the interaction of a card selection requires communication through a web server, a WAP proxy server, and a wireless communication network, which not only makes the card selection time longer, but also makes the payment processing time long, and when one of the devices fails. At the same time, the entire selection card is suspended, reducing the success rate of payment. That is to say, in the payment process using the payment platform for payment, it is usually required that the payment platform provides an interactive page for the user to specifically select which bank card to use to complete the payment. Not only does the network occupy the network resources for interaction, but the most important thing is to reduce the speed of the payment processing, so that the payment server 21 needs to spend resources and time to complete the processing operation. Moreover, in some application scenarios, the payment platform 12 cannot provide an interactive page for the user to specifically select which bank card to use, but the payment platform 12 selects a certain bank card as a master. This processing has security problems. SUMMARY OF THE INVENTION The purpose of the present application is to provide a system for adaptively selecting a bank card for payment, which solves the technical problems of low security, extended payment processing time, and resource occupation in the prior art card selection process. Another object of the present application is to provide a method for adaptively selecting a bank card for payment, which solves the technical problems of low security, extended payment processing time, and resource occupation in the prior art card selection process. 201106286 A system for adaptively selecting a bank card for payment to perform payment operations for a user to a payee through a payment platform, the payment platform comprising: a database for storing a plurality of banks including user account information for payment Card information, card selection rule information, payment record information, etc. » Rule engine unit: Connect the database to find the bank card for payment from multiple bank cards according to the card selection rule information; a payment processing unit: connecting the database and the rule engine unit respectively, for receiving a payment request of the user terminal where the user is located, obtaining the bank card for the payment through the rule engine unit, and using the bank card to pay the payment amount To the payee. The rules engine unit and the payment processing unit are respectively disposed on the rule engine server and the payment server. A method for adaptively selecting a bank card for payment, and performing payment operations for a user to a payee through a payment platform, including: (1) setting a card selection rule information for selecting a payment card from a plurality of bank cards; (2) When receiving the payment request of the user terminal where the user is located, 'according to the card selection rule and the payment record information, the current bank card is selected from the plurality of bank cards; (3) using the bank card to pay the payment amount to the receipt Compared with the prior art, the present application has the following advantages: First, the application can pre-set the card selection rule, and each time the card 201106286 is selected, it is not necessary to re-establish the user selection card with the user terminal of the user. Subsequent payment operations are performed. No, and the user who does not need to occupy the network and the payment platform pays the request through the WAP in the manner of the mobile terminal, and does not need to further select the card operation, and the efficiency further increases the success rate of the payment. Second, payment and card selection operations are set up by setting up payment servers and rules. There is no need to make changes to existing ones, and the additional security of the existing payment server can be improved by adding additional rules engine servers and designs. Finally, each time the rules engine software starts to transfer information into the server's memory, and the saved card selection rules ensure the accuracy of the card selection. [Embodiment] The present application will be specifically described with reference to the drawings. Embodiment 1 Please refer to FIG. 2 and FIG. 3, which are schematic diagrams of a first embodiment of a system for making payment in accordance with the present application. 4. A payment platform 4 2. A payee terminal subsystem 44 in which a payee is located. The user terminal 4 1 can interact as a network selection card, waiting for only the payment speed resource to be increased. In particular, when the directional payment platform initiates an increase in the entire payment engine server to complete the server to perform a large completion card selection operation, and can also improve the selection of the card during the update period in the memory The card selection speed adaptive selection bank card is also improved. It includes the user terminal 43 and various bank road terminals connected to the payment platform 42 via the Internet-9-201106286, or can be used as a telephone through the existing fixed line. The system communicates with the payment platform 42, or as a mobile phone, using the WAP protocol to establish communication with the payment platform 42 via the wireless communication network and the Internet. The payee has a corresponding payee account set on the payment platform 42, or a corresponding payee account set in the bank subsystem connected to the payment platform 42. For convenience of description, in the present embodiment, the payee has a corresponding payee account set on the payment platform 42, and the user has a corresponding payment account set on the payment platform 42. In fact, the payee account set by the payee and the payment account set by the user, the payment platform 42 is managed as a unified user, that is, the payee and the user are also users of the payment platform 42, receiving The payment account and the payment account are only different in meaning, and are managed as a user account in nature. The payment platform 42 further includes a database 51, a payment server 52, a rule engine server 53, and a reconciliation processing server. 5 4. The database 51 is used for storing user account information, information for setting a plurality of bank card information for payment, card selection rule information, payment record information, and the like. Please refer to FIG. 3, which is a schematic diagram of the structure of the database 51. It includes: a user information storage unit 511: for storing information including user information, corresponding payment account information, and multiple bank card information for payment matching the payment account; payment record storage unit 5 1 2 : The processing result information for storing and processing each payment request. 10- 201106286 Rule storage unit 513: a card selection rule for storing a plurality of bank cards set by the user and a system selection including storing the payment amount of each bank card Card rules. User information storage unit 511 and payment record storage unit 512 generally refer to a logical division that physically stores all information through a wide table. For example, the wide table can be stored in a payment account unit, and the field includes an access password, a payment password, user information, multiple bank card information, and payment information corresponding to the account. The multiple bank card information includes the bank card number, the alias, the bank information to which the bank card belongs, the bank card, the transaction amount information, and the accumulated transaction amount information for the current month. The payment information includes the transaction amount information of the user account on the day, and the accumulated transaction amount information of the current month. The payment server 52 periodically updates the contents of the wide table. The rule storage unit 513 may include a system card selection rule storage subunit, a user card selection rule storage subunit, and a rule storage subunit. System Card The Rule Storage subunit is used to store system card selection rules including the payment amount of each bank card. The system card selection rules refer to the restrictions on the use of each bank card, mainly referring to the payment limit of each bank card. The system card selection rule storage sub-unit can store the card selection rules in the form of a table, for example, by using each bank card as a unit, and saving the use conditions of the bank card. The user card selection rule storage sub-unit is to save the user-defined card selection rules. The card selection rule can be a bank setting a custom card selection rule, or all cards can set one or more card selection rules. The rule storage sub-unit is the last card selection rule of the user determined after the user-defined card selection rules and system card selection rules are merged. The user card selection rule storage sub-unit can also save -11 - 201106286. After receiving the user-defined card selection rule, the system card selection rule storage sub-unit directly determines the last card selection rule of the user, and selects the user. The card rule storage rule is stored in the subunit. For example, the payment platform 42 receives the user-defined rule as follows: the payment rule of the bank debit card includes: (1) the single amount is less than 800 yuan; (2) the daily cumulative amount is 2,000 yuan: (3) the monthly cumulative amount is less than 2000. (4) The date of use is from 15th to 31st of each month. The system card selection rules stored in the system card selection rule storage sub-unit of the bank debit card are: (1) the single amount is less than 500 yuan; (2) the daily cumulative amount is 1,500 yuan, and the user is finally determined. The card selection rules for the bank card are: (1) the single amount is less than 500 yuan; (2) the cumulative amount of each bank is 1,500 yuan; (3) the monthly total is less than 2,000 yuan; (4) the use period is 15 per month.曰 to the 31st. That is to say, these four qualifications are stored in the card selection rules and can be stored in the form of Table 1. Table 1 User ID Bank Name Card Type Card Alias Single Credit Per Cum Total Credit Monthly Total Credit Use Period 001 GDB Debit Card Pay Card 500 1500 2000 15-31 001 ... • · · ... • · ♦ ..· The above database 51 discloses various storage units, which are mainly logically divided, and do not refer to physical division. Physically, the database 5 1 may be composed of a plurality of databases, or may be a database. The rule engine server 53 is configured to connect to the database 5 1 for selecting cards according to -12-201106286. Information Find out the bank card for this payment from multiple bank cards. In the present example, the rule engine software (hereinafter referred to as the rule engine unit 53 1 ) is preset to complete the card selection operation. The rules engine unit 531 can be implemented using open source Drools or by constructing a DFA itself. The programming engine unit 531 is programmed in what programming language, and this example is not limited. The rule engine unit 53 1 mainly accesses the records in the wide table to determine whether the bank cards satisfy the qualification conditions of the various bank cards stored in Table 1. The rule engine unit 53 1 determines whether the bank card satisfies the conditions in Table 1 by accessing the records in the wide table in the form of a bank card, and if so, the bank card is the bank card for the payment, if not, Then select the next bank card to determine whether it meets the conditions in Table 1, until a bank card that meets the conditions is found as the bank card for this payment, or it is determined that all bank cards cannot meet the conditions of Table 1. The rule engine unit 53 1 can also find all the bank cards satisfying the conditions of Table 1, and then determine the bank card for the payment in accordance with the preset selection order. The rule engine unit 531 is usually implemented in software, although the application does not exclude the use of hardware. The rule engine unit 531 referred to in the present application mainly refers to a processor in which the rule engine software is installed. The rule engine server 53 includes, in addition to the rule engine unit 531, a rule loading memory processing unit · 5 3 2 for loading the card selection rule information into the server every time the rule engine software starts. The memory rule update processing unit 53 3 of 53 is configured to obtain a new 201106286 added or updated card selection rule from the database 51, and update the currently selected card selection rule according to the card selection rules. The rule update processing unit 533 can look up the database 51 to obtain a new or updated card selection rule. A common implementation scheme is to set an update time field in Table 1, and save the time when the card selection rule of the bank card is updated, and the rule update location 533 can obtain a new or updated selection rule engine through the update time field. The unit 5 3 1. The rule-input memory processing unit rule update processing unit 533 is mainly a logical division, which is used to limit the present application. In a specific implementation, all the function payment servers 52 of the above rule engine unit 513, the rule call memory unit 523, and the rule update processing unit 533 may be implemented through software, including card selection rule interaction. The processing unit payment processing unit 522 » the payment server 52 further includes the following receiving user new account and modifying user and account information, displaying payment information, etc., since these functions are functions of the existing payment server .52, the present application No longer explain. Unlike the existing payment 52, the card selection rule interaction unit 521 and the payment processing unit 52 of the payment server 52. The card selection rule interaction processing unit 52 1 is configured to receive a user new reselection card rule, and save the card selection rule to the database payment processing unit 522, for receiving the request of the user terminal 41, and transmitting the rule engine The unit 5 3 1 obtains the operation of paying the payment amount to the payee by using the bank card. The memory is used for regular factor comparison. It is used for factoring unit card rules 5 3 2 and is divided into one body processing 521 521. Function: The server unit has been added or repaired. Payment request card, payment processing -14- 201106286 Unit 5 22 receives the payment request from the user terminal 41, and analyzes the user information 'receiver information and the amount to be paid. When the corresponding bank card information is found in the wide table according to the user information, if a plurality of bank card information is found, then a card selection request is sent to the rule engine server 5, and the card processing result returned by the rule engine server 53 is received. . There are two types of card processing results: selecting a card for this payment and not finding a matching bank card. If a card is selected for the current payment, the payment is completed through the card, and the payment processing result is saved in the database 51. If the eligible bank card is not found, the processing flow is terminated, and the processing result is returned to the user terminal 41. The reconciliation processing server 54 is configured to perform a reconciliation settlement operation with a different bank based on the processing result information of the processing per payment request stored in the payment record storage unit 512. The reconciliation processing server 54 and the payment server 52 can be implemented by the same server. In this example, the payment and card selection operations are completed by the payment server 52 and the rules engine server 5, respectively. There is no need to make major changes to the existing payment server 52. By additionally adding the rules engine server 53 and completing the card selection operation, this design can improve the security of the existing payment server 52, and can also improve the system. Coupling. In this example, the card selection rule information is previously loaded into the server of the server 53 every time the rule engine software is started, and the card selection rules stored in the memory are periodically updated, and the card selection is guaranteed. The accuracy of the -15- 201106286 is also higher than the selection speed. Please refer to FIG. 4, which is an example flow chart of a method for making payment by adaptively selecting a bank card. It performs payment operations for the user to the payee through the payment platform, including: S110: setting the card selection rule information for selecting the payment card from the plurality of bank cards. First, the payment server 52 provides a maintenance interface for the user to set or modify the bank card selection rule; then, the payment server 52 receives the custom card selection rule set or modified by the user through the maintenance interface; finally, the payment server 52 will be the user. The custom card selection rules and the system card selection rules including the payment amount of each bank card are combined with the user's card selection rules, and then the card selection rules are stored in the rule storage unit of the database 5 1 3 (as shown in Table 1). in. S 1 20: When receiving the payment request of the user terminal, the payment server 52 uses the rule engine server 53 to select the current bank card used for the current payment from the plurality of bank cards according to the card selection rule and the payment record information. . When the payment server 52 receives the payment request from the user terminal, the payment amount and the payee terminal information are obtained; if the payment server 52 determines that the user has multiple bank cards, the selection is sent to the rule engine server 53. Card Request: The rule engine server 53 determines whether or not the bank card meets the requirements of the card selection rule for a plurality of bank cards, and selects one bank card that meets the requirements of the card selection rule as the current bank card for payment. -16- 201106286 S 1 3 0 : The payment server 52 uses the card to pay the payment to the payee. The payment server 52 saves the payment processing status to the payment record; the account settlement operation with the banking subsystem is completed by the reconciliation processing server 54. In this example, each time the rule engine software is started, the card selection rule information is transferred into the cell of the server 53, and the newly selected or updated card selection rules are obtained in the regular library, and updated according to the card selection. The currently selected card selection rules in the memory also improves the card selection speed when the card is selected. Embodiment 2 Referring to FIG. 5 and FIG. 6, FIG. 6 is a schematic diagram of a second embodiment of a system for adaptive bank selection payment according to the present application. It includes a payee terminal 62 in which the payee is paying, and various bank subsystems 63 to: network 64. The WAP network 64 includes a web server 641, a WAP server 642, and a mobile terminal 643. Web server (Web Serve uses HTML web pages to transfer data, which is filtered by HTML to convert the web page into WML (Wireless Markup Language) format, and then processed by WAP proxy (WAP Proxy 642 to form binary) The WML data flow is sent to the mobile phone terminal 643. The WAP network 64 can be in other forms, the composition of which is prior art, and will not be described in detail herein. The real web server 641, the WAP proxy server 642 and the mobile phone The pair of terminal payment records information will be carried out from the data rules to the accuracy card ί 61, the general WAP proxy server: r) 64 1 program will be wireless standard) Servo client', as in the case, 64 3 only -17 - 201106286 is for illustrative purposes only and is not intended to limit the application. The payment platform 61 further includes a database 71 and a server 72. The data stored in the repository 71 can be the same as the first embodiment, and the server 72 can include a rules engine unit 721, a payment processing unit 722, and a reconciliation processing unit 723. The rule engine unit 72 1 is configured to connect the database 7 1 for finding the bank card used for the payment from the plurality of bank cards according to the card selection rule information; and the payment processing unit 722: respectively connecting the database The rule engine unit 721 is configured to receive a payment request of the user terminal, obtain the bank card of the current payment through the rule engine unit 72 1 , and use the bank card to pay the payment amount to the operation of the payee; The account processing unit 723 is configured to complete the reconciliation settlement operation with different bank subsystems. That is, the functions implemented by the payment server, the rules engine server, and the reconciliation processing server in the first embodiment are implemented by the server 72. This implementation can increase the processing speed of card selection and payment. Please refer to FIG. 7, which is a second flow diagram of a method for adaptively selecting a bank card for payment. It performs payment operations for the user terminal to the payee terminal through the payment platform, including: S210: The server sets the card selection rule information for selecting the payment card from the plurality of bank cards. The user can use the network terminal to perform the card selection rule information of the payment card, or can be used as the mobile phone terminal 643 to perform the card selection rule information of the payment card. -18- 201106286 The process of selecting the card is roughly as follows: the server provides the user to set or modify the bank. The maintenance interface of the card selection rule; the server receives the custom card selection rules set or modified by the user through the maintenance interface; the server fuses the user-defined card selection rules and the system card selection rules including the bank card payment quotas. After the card selection rules, the card selection rules are saved in the database. S220: When receiving the payment request of the user terminal, the server selects the current current payment bank card from the plurality of bank cards according to the card selection rule and the payment record information. When the server receives the payment request of the user terminal, the payment amount and the payee information are obtained; if the server determines that the user has multiple bank cards, the card selection request is sent to the rule engine unit; the rule engine unit pair Multiple bank cards, in turn, determine whether the bank cards meet the requirements of the card selection rules, and select one of the bank cards that meet the requirements of the card selection rules as the current bank card for payment. S 2 3 0 : The payment of the payment amount to the payee terminal operation using the bank card. The server uses the bank card to complete the payment operation, and subsequently performs the reconciliation settlement operation with the bank subsystem periodically. In this example, the card selection rules can also be stored in the memory. Moreover, the server periodically obtains new or updated card selection rules from the database and updates the currently stored card selection rules in the memory according to the card selection rules. -19- 201106286 [Simplified Schematic] FIG. 1 A schematic diagram of the principle structure of the online payment system in the prior art; FIG. 2 is a schematic structural diagram of the first embodiment of the system for adaptively selecting a bank card for payment according to the present application; FIG. 3 is a partial schematic structural diagram of the payment platform in the present application; 4 is a schematic flow chart of a first embodiment of a method for performing payment by adaptively selecting a bank card according to the present application: FIG. 5 is a schematic structural diagram of a second embodiment of a system for automatically selecting a bank card for payment according to the present application; A schematic diagram of a part of the principle of the payment platform in the application; FIG. 7 is a schematic flow chart of the second embodiment of the method for the payment of the adaptive bank card of the present application. [Description of the main components] 1 1 : User terminal 1 2: payment platform 1 3 : Payee terminal 1 4 : Bank subsystem 2 1 : Payment server 22 : Reconciliation processing server 23 : Database -20 - 201106286 41 : User terminal 4 2: payment platform 4 3 : payee terminal 44 : bank subsystem 5 1 : database 5 2 : payment server 53 : rule engine server 5 4 : reconciliation processing server 6 1 : payment platform 6 2 : Payee terminal 6 3 : Bank subsystem 6 4 : WAP network 7 1 : database 72 : server 5 1 1 : user information storage unit 5 1 2 : payment record storage unit 5 1 3 : rule storage unit 521: Card selection rule interaction processing unit 522: payment processing unit 531: rule engine unit 5 3 2: rule loading memory processing unit 5 3 3: rule update processing unit 641: web server 642: WAP proxy server-21 - 201106286 6 4 3. Mobile terminal 721: rule engine unit 722: payment processing unit 723: reconciliation processing unit-22-