201023067 六、發明說明： 【發明所屬之技術領域】 本申請案係關於一種支付方法及系統，尤其關於一種 利用虛擬卡提高支付安全的支付方法及系統。 【先前技術】 隨著網際網路的快速發展和普及，B2C電子商@也隨 ^ 之快速的發展起來，但是，其發展也受到了支付手段這一 瓶頸的制約，相對於現實中的支付方法，目前流行的網上 支付方法通常有以下三種：（1 )透過銀行網銀系統直接 支付；（2)透過第三方支付公司支付；（3)在電子商務 平台的網頁上直接輸入卡號和密碼進行支付。以現在技術 來說，前兩種方法的安全性相對較高，而且目前越來越多 的電子商務平台也開始支援第三方支付公司的支付方式， 但仍然有很多的電子商務平台採用上述第三種支付方式。 • 第三種支付方式由於用戶在購物時需要直接輸入銀行的卡 號和密碼，而如今網路上的惡意行爲眾多，客戶無法識別 該購物站點是否是惡意的，或者是否存在漏洞有可能洩露 其卡號和密碼的，所以會給用戶的用卡安全帶來一定的威 脅。 中國專利號爲CN01 1 29250的發明專利公開一種電子 商務網上支付系統及其實現方法，該方法包括如下步驟： S 1 0 1 :企業整合多種商品或服務，建立銷售這些商品 或服務的電子商務平台； 201023067 S 1 02 :企業發行預置固定價値的能夠支付這些商品或 服務的序列5ίΙ和街碼’序列號、密碼載於一定介質上，介 質做封裝處理； S103:企業將封裝著序列號、密碼的介質透過銷售管 道發行到客戶中； S1 04:客戶在企業指定的電子商務平台上訂購商品； S1 05:客戶塡寫在這種商品上的使用資訊； S106:塡寫企業提供的預置固定價値的能夠支付多種 _ 商品服務的序列號和密碼； S 1 07 :電子商務平台計費系統程式進行序列號、密碼 驗證，成功後扣除序列號、密碼上客戶選擇的商品的價値 ，成功後用程式告知此商品、服務商驗證成功的資訊； S 1 08 :商品、服務廠商給予客戶的服務許可權，客戶 得到相應的商品或服務。 但是，上述電子商務網上支付方法交易方法特別複雜 ，並且不具有通用性和普遍性。現在的交易是朝著方便、 〇 快捷、安全的方向出發’特別是網際網路的出現’實現了 足不出戶即可購買到性能價格比很優的商品。即透過第三 種支付方式現逐步成爲主流。由於用戶在購物時需要直接 輸入銀行的卡號和密碼’而如今網路上的惡意行爲眾多’ 客戶無法識別該購物站點是否是惡意的’或者是否存在漏 洞有可能洩露其卡號和密碼，所以會給用戶的用卡安全帶 來一定的威脅，特別是容易造成用戶的財產損失° 201023067 【發明內容】 針對上述缺陷，本申請案的思想在於提供利用虛擬卡 提高支付安全的支付方法，以解決現有技術中在網頁上直 接輸入銀行卡號及密碼用以網上支付或辦理其他業務時不 能有效地保護帳號的缺陷。 本申請案的另一思想是提供一種利用虛擬卡提高支付 安全的支付系統，以解決現有技術中在網頁上直接輸入銀 Φ 行卡號及密碼用以網上支付或辦理其他業務時不能有效地 保護帳號的缺陷。 本申請案的第三思想在提供一種支付平台。 本申請案提出一種利用虛擬卡提高支付安全的支付方 法，用以提高用戶透過銀行卡進行支付的安全性，包括： (1) 提供第三方支付平台，所述第三方支付平台透 過專線或網路連接至少一家銀行卡的發卡行； (2) 第三方支付平台接收到用戶的虛擬卡申請請求 φ 後’獲得用戶的銀行卡資訊，並向對應的發卡行發送虛擬 卡申請請求’所述請求中包含銀行卡資訊及虛擬卡使用規 則·， (3) 當第三方支付平台接收到發卡行發送的已申請 的虛擬卡號資訊時，返回至用戶； (4) 當發卡行接收到包含虛擬卡號資訊和支付金額 的支付請求時，若虛擬卡滿足虛擬卡使用規則且對應銀行 卡的支付規則，則支付成功。 依照本申請案較佳實施例所述的支付方法，步驟（2 201023067 )中獲得用戶的銀行卡資訊進一步包括：第三方支付平台 預先儲存有與該用戶綁定的銀行卡資訊，當接收到虛擬卡 申請請求時，確定發送該虛擬卡申請請求的用戶，找到該 用戶綁定的銀行卡資訊。 依照本申請案較佳實施例所述的支付方法，步驟（2 )獲得用戶的銀行卡資訊進一步包括：第三方支付平台接 收的由用戶發送的虛擬卡申請請求從中包含銀行卡及其密 碼資訊’當桌二方支付平台接收到所述虛擬卡申請請求時 ，從中解析出銀行卡及密碼資訊。 依照本申請案較佳實施例所述的支付方法，還包括： 第三方支付平台接收的由用戶發送的虛擬卡申請請求中包 含有虛擬卡使用規則，或者，第三方支付平台上預先設置 好若干虛擬卡使用規則範本，接收用戶選定的虛擬卡使用 規則範本作爲虛擬卡使用規則。 依照本申請案較佳實施例所述的支付方法，還包括： 第三方支付平台接收用戶選擇的修改虛擬卡使用規則的請 求’並將所述修改虛擬卡使用規則的請求發送至對應的發 卡行；第三方支付平台將發卡行返回的修改是否成功結果 發送至對應的用戶。 依照本申請案較佳實施例所述的支付方法，所述虛擬 卡使用規則進一步包括：包含其使用次數限定和/或使用 時間限定的所述虛擬卡使用的有效條件，虛擬卡對應密碼 設定情況。 本申請案提出一種提高利用虛擬卡提高支付安全的支 -8 - 201023067 付系統，包括桌二方支付平台和至少一家銀行卡的發卡行 所述第三方支付平台進一步包括支付平台伺服器和支 付平台資料庫，其中，所述支付平台伺服器至少包括：用 戶介面處理單元：接收用戶發送的包含虛擬卡申請請求在 內的各種請求，並把本平台的處理結果返回至用戶；發卡 行介面處理單元：用以與各家與該第三方支付平台簽約的 Φ 發卡行建立交互，發送至對應發卡行包含虛擬卡申請請求 在內的各種請求、接收虛擬卡申請成功在內的處理結果； 虛擬卡業務處理單元：連接至用戶介面處理單元和發卡行 介面處理單元’用於接收虛擬卡申請請求時，獲得用戶的 銀行卡資訊和虛擬卡使用規則，並且透過銀行卡資訊找到 對應的發卡行資訊，形成虛擬卡申請請求報文透過所述發 卡行介面處理單元發送至對應的發卡行； 支付平台資料庫進一步包括：用於保存用戶及對應的 φ 虛擬卡申請/修改的所有情況的虛擬卡記錄儲存單元、用 於保存銀行卡與發卡資訊對應的發卡行儲存單元，用於保 存用戶資訊的用戶屬性儲存單元； 所述發卡行進一步包括發卡行資料庫及發卡行伺服器 ’其中’發卡行資料庫進一步包括銀行卡與虛擬卡綁定的 卡對應關係表'銀行卡屬性儲存單元及銀行卡交易記錄儲 存單元，所述發卡行伺服器進一步包括：銀行卡認證單元 :接收第三方支付平台發送的包含虛擬卡申請請求在內的 各種申請’並對該申請內的銀行卡資訊進行匹配認證；虛 -9 - 201023067 擬卡產生單元：用以處理透過銀行卡認證單元認證的虛擬 卡申請請求，產生虛擬卡，並將該虛擬卡資訊發送至第三 方處理平台；交易處理單元：用以處理包含虛擬卡號資訊 和支付金額的支付請求，在對請求進行處理前，先對虛擬 卡使用規則進行驗證，驗證成功後並在滿足銀行卡上的金 額不小於支付金額的前提下對支付請求進行處理，並回饋 處理情況。 本申請案又提出一種利用虛擬卡提高支付安全的支付 方法，用以提高用戶透過銀行卡進行支付的安全性，包括 (η銀行卡的發卡行接收用戶發送的虛擬卡申請請 求，所述請求中包含銀行卡資訊及虛擬卡使用規則； (2 )該發卡行收到用戶的虛擬卡申請請求後，對該 銀行卡資訊進行認證，並根據通過認證後的請求產生虛擬 卡號及註冊虛擬卡使用規則，然後返回虛擬卡號至用戶； (3 )當發卡行接收到包含虛擬卡號資訊和支付金額 的支付請求時，若虛擬卡滿足虛擬卡使用規則且對應銀行 卡的支付規則，則支付成功。 本申請案再提出一種利用虛擬卡提高支付安全的支付 系統，包括至少一家銀行卡的發卡行， 該發卡行進一步包括發卡行資料庫及發卡行伺服器， 其中，發卡行資料庫進一步包括銀行卡與虛擬卡綁定的卡 對應關係表、銀行卡屬性儲存單元及銀行卡交易記錄儲存 單元，所述發卡行伺服器進一步包括： -10- 201023067 銀行卡認證單元：接收用戶發送的包含虛擬卡申請請 求在內的各種申請，並對該申請內的銀行卡資訊進行匹配 認證；虛擬卡產生單元：用以處理透過銀行卡認證單元認 證的虛擬卡申請請求，產生虛擬卡，並將該虛擬卡資訊發 送給用戶；交易處理單元：用以處理包含虛擬卡號資訊和 支付金額的支付請求，在對請求進行處理前，先對虛擬卡 使用規則進行驗證，驗證成功後並在滿足銀行卡上的金額 • 不小於支付金額的前提下對支付請求進行處理，並回饋處 理情況。 本申請案再提出一種支付平台，其包括支付平台伺服 器和支付平台資料庫，其中，支付平台伺服器至少包括： 用戶介面處理單元：接收用戶發送的包含虛擬卡申請 請求在內的各種請求，並把本平台的處理結果返回至用戶 發卡行介面處理單元：用以各家與該第三方支付平台 φ 簽約的發卡行建立交互，發送至對應發卡行包含虛擬卡申 請請求在內的各種請求、接收虛擬卡申請成功在內的處理 結果； 虛擬卡業務處理單元：連接至用戶介面處理單元和發 卡行介面處理單元，用於接收虛擬卡申請請求時，獲得用 戶的銀行卡資訊和虛擬卡使用規則，並且透過銀行卡資訊 找到對應的發卡行資訊，形成虛擬卡申請請求報文透過所 述發卡行介面處理單元發送至對應的發卡行； 支付平台資料庫進一步包括：用於保存用戶及對應的 -11 - 201023067 虛擬卡申請/修改的所有情況的虛擬卡記錄儲存單元、用 於保存銀行卡與發卡資訊對應的發卡行儲存單元，用於保 存用戶資訊的用戶屬性儲存單元。與現有技術相比，本串 請案具有以下優點： (1) 用戶透過第三方平台向銀行申請訂制了使用規 則的虛擬卡號，並利用該虛擬卡號到各個電子商務平台進 行消費，可以有效的保障用戶的利益，減少客戶的損失。 (2) 當虛擬卡號和密碼被盜，其透過預先設定的虛 擬卡的使用規則，如預先設定使用次數和使用限額（如 5 00元），即可將損失限定在用戶能夠控制的範圍。 (3) 現有技術中當銀行卡資訊被盜後，需要到網點 或透過電話等方式進行掛失處理，絕大多數發卡行的網點 不是24小時營業的，所以透過網點掛失存在時間和地理 上的受限，如果透過電話方式進行掛失，現有的每家發卡 行的電話存在不容易打進去以及採用電話系統存在處理延 後的問題。而本發明即可透過第三方支付平台透過網路實 現即時掛失處理，處理速度非常快，減少了用戶損失財務 的時間。 (4) 本發明提供的虛擬卡不僅可以在網路上使用， 還可以在傳統的環境下使用，虛擬卡的產生可採用傳統的 銀行卡號的產生方式，即虛.擬卡號中至少也包括有發卡行 資訊，特別是當用戶在一些陌生的不信任的環境下，使用 該虛擬卡來進行消費，能降低用戶的損失，從而提高用戶 銀行卡的安全性。當然，本發明最常適用的環境是網路交 -12- 201023067 易。 (5)該方案不需要各個商戶做任何改動，只需要第 三方平台和銀行間有所改動即可，具有普遍的適用性。 需要說明的是，上述實施本發明的任一產品不一定需 要同時達到以上所述的所有優點。 【實施方式】 Φ 本申請案的核心在於：用戶透過第三方支付平台向銀 行申請虛擬卡號和密碼，並對該虛擬卡號和密碼訂制使用 規則，然後將得到的虛擬卡號和密碼進行消費，由於用戶 使用的是虛擬的卡號和密碼，而且該卡號和密碼上還訂制 了各種使用規則，所以可以最大限度的減少用戶由於網路 上各種惡意行爲而遭到的損失。本申請案所述的第三方支 付平台，是一些和國內外各大銀行簽約、具備一定實力和 信譽保障的第三方獨立機構提供的交易支付平台，比如支 • 付寶’它可以綁定其所屬用戶的銀行卡資訊。 以下結合附圖，具體說明本申請案。 第一實施例 本申請案提出一種利用虛擬卡提高支付安全的支付系 統’請參見圖1，其爲本申請案一種利用虛擬卡提高支付 安全的支付系統的結構圖。該支付系統包括用戶110、第 三方支付平台120、至少一家銀行卡的發卡行130和商戶 140，其中，第三方支付平台12〇透過專線或者網路和至 -13- 201023067 少一家銀行卡的發卡行130相連，商戶140同樣也透過專 線或者網路和該發卡行1 30相連，而用戶1 1 〇則可以分別 連接至第三方支付平台120和商戶M〇。 該第三方支付平台120進一步包括支付平台伺服器 121和支付平台資料庫122(請參見圖2)，其中，支付平 台伺服器121至少包括： 用戶介面處理單元1211:其用以接收用戶110發送的 包含虛擬卡申請/修改請求在內的各種請求，並把本平台 的處理結果返回至用戶110; 發卡行介面處理單元1213:用以與各家與該第三方支 付平台120簽約的發卡行13〇建立交互，發送至發卡行 130包含虛擬卡申請/修改請求在內的各種請求、接收虛擬 卡申請/修改成功在內的處理結果，· 虛擬卡業務處理單元1212:連接至用戶介面處理單元 1211和發卡行介面處理單元ι213，其用於接收虛擬卡申 請/修改請求時，獲得用戶110的銀行卡資訊和虛擬卡使 用規則’並且透過分析該銀行卡資訊中的B IN碼來找到對 應的發卡行資訊，形成虛擬卡申請/修改請求報文透過所 述發卡行介面處理單元發送至對應的發卡行，該虛擬卡申 請/修改請求報文中包含了銀行卡資訊和虛擬卡使用規則 資訊。 用戶介面處理單元1211、發卡行介面處理單元1213 和虛擬卡業務處理單元1212可以是硬體，也可以是軟體 。本實例中最好是設置在伺服器中處理器上的邏輯單元， -14 - 201023067 即俗稱的軟體。 支付平台資料庫122進一步包括：用於保存用戶及對 應的虛擬卡申請/修改的所有情況的虛擬卡記錄儲存單元 1221、用於保存銀行卡與發卡資訊的發卡行儲存單元1222 ，用於保存用戶資訊的用戶屬性儲存單元1 223。 虛擬卡記錄儲存單元1221、和發卡行儲存單元！222 和用戶屬性儲存單元1 2 2 3是邏輯單元，是固化在記憶體 φ 中的邏輯單元。發卡行儲存單元1222主要用於儲存與之 簽約的發卡行標識與發卡行的對應關係，所述發卡行的標 識是指PIN碼固定位置用於標識發卡行的數位。 該發卡行130進一步包括發卡行資料庫131及發卡行 伺服器132(請參見圖3)。其中，發卡行資料庫丨31進 一步包括：用以將產生的虛擬卡號和真實銀行卡號相綁定 的卡對應關係表1311，用以儲存銀行卡包括用戶名、卡號 及密碼在內的各種屬性的銀行卡屬性儲存單元1312及用 φ 以儲存銀行卡交易記錄及餘額的銀行卡交易記錄儲存單元 1313。發卡行伺服器132進一步包括： 銀行卡認證單元1 32 1 ·_其用以接收第三方支付平台 120發送的包含虛擬卡申請/修改請求在內的各種申請，並 對該申請內的銀行卡資訊根據銀行卡屬性儲存單元1312 內的資訊進行匹配認證； 虛擬卡產生單元1 322 :用以處理透過銀行卡認證單元 1 3 2 1認證的虛擬卡申請/修改請求，根據通過認證的虛擬 卡申請請求’產生一虛擬卡號，該虛擬卡號中包含有用以 -15- 201023067 識別該發卡行的BIN碼，同時將該虛擬卡號和真實銀行卡 號綁定，並寫入卡對應關係表1311，然後對虛擬卡申請請 求內的虛擬卡使用規則進行註冊，最後將該虛擬卡號資訊 發送至第三方處理平台120;而對於通過認證的虛擬卡修 改請求，則對先前註冊的虛擬卡使用規則進行修改，並將 結果回饋至第三方處理平台120。 交易處理單元1323:用以處理商戶轉發的包含虛擬卡 號資訊和支付金額的支付請求，在對請求進行處理前，先 對虛擬卡使用規則進行驗證，驗證成功後並在滿足銀行卡 上的金額不小於支付金額的前提下對支付請求進行處理， 並回饋處理情況。 銀行卡認證單元1321、虛擬卡產生單元1322和交易 處理單元1 3 23可以是硬體，也可以是軟體，通常情況下 是設置在伺服器內的軟體。 基於上述支付系統，本申請案提出一種利用虛擬卡提 高支付安全的支付方法，用以提高用戶透過銀行卡進行支 付的安全性，請參見圖4，其爲本申請案一種支付方法的 流程圖。 該支付方法包括如下步驟： S4〇l，提供第三方支付平台，該第三方支付平台透過 專線或網路連接至少一家銀行卡的發卡行，其和該發卡行 爲簽約關係，該發卡行可以爲該第三方支付平台提供一系 列業務處理，包括本申請案所涉及到的虛擬卡申請業務。 該第三支付平台爲用戶提供虛擬卡申請業務，其可以 -16 - 201023067 透過網際網路和用戶相連，當然，用戶也可以直接到該第 三方支付平台所設辦事處申請虛擬卡申請業務。用戶一般 爲該第三方支付平台的註冊用戶，用戶可以綁定一與第三 方支付平台有簽約關係銀行的銀行卡，當然，用戶也可以 只註冊而不綁定銀行卡。以第三方支付平台支付寶爲例， 現有的支付寶用戶通常有與其綁定的銀行卡資訊。 S402，第三方支付平台接收用戶發送的虛擬卡申請請 φ 求和虛擬卡使用規則。該虛擬卡使用規則可以是由第三方 支付平台預先設定好的範本，然後供用戶在申請的時候根 據需要對範本進行選擇，同樣，該虛擬卡使用規則也可以 是由用戶在申請時自由進行設定，當然，這種自由設定也 是會限制在一定的範圍之內的。根據實際應用，該虛擬卡 使用規則一般可以包含虛擬卡使用次數限定和/或使用時 間限定的虛擬卡有效條件的設定、虛擬卡對應密碼設定情 況等，比如虛擬卡有效條件可以在下述方案中進行選擇： φ ( a )按照使用次數： (b)按虛擬卡有效使用時間： (b 1 )當前到N時間段有效； (b 2 )以後的A時間到B時間段有效； (b3 )指定的迴圈時間段有效； (c )手動關閉虛擬卡。 而虛擬卡對應密碼設定又可以在下述方案中進行選擇 原銀行卡密碼； -17- 201023067 ϋ· 指定虛擬卡密碼； ΐϋ· 無密碼； ΠΠ·任意密碼； 第三方支付平台接收到用戶的虛擬卡申請請求後，判 斷該用戶是否具有綁定的銀行卡資訊，若該用戶預先在第 三方支付平台設定了與該用戶綁定的銀行卡資訊，則第三 方支付平台在接收到虛擬卡申請請求後讀取出該銀行卡資 訊；如果該用戶並未預先設定綁定銀行卡資訊，而是在提 出申請請求時一倂塡寫了銀行卡號和密碼資訊，則第三方 支付平台從中解析出銀行卡資訊。銀行卡的卡號是標識發 卡機構和持卡人資訊的號碼，其由以下三部分組成：發卡 行標識代碼（BIN碼）、發卡行自定義位和校驗碼，第三 方支付平台可以透過BIN碼來判斷該銀行卡是否爲簽約銀 行’當第三方支付平台確定該銀行爲簽約銀行後，根據 BIN碼識別出銀行卡所屬發卡行，並向該發卡行發送虛擬 卡申請請求，該虛擬卡申請請求中包含銀行卡資訊及虛擬 卡使用規則。若該第三方支付平台判斷該銀行卡爲非簽約 銀行則返回錯誤資訊至用戶端。 S403，發卡行接收到虛擬卡申請請求後，對該請求中 包含的銀行卡資訊進行驗證，具體驗證方式可以透過驗證 BIN碼是否是本行的號碼、檢查校驗碼判斷是否僞卡，匹 配卡號密碼等。發卡行根據通過驗證的虛擬卡申請請求隨 機生成一虛擬卡號，該虛擬卡號中也可以包含有用以識別 該虛擬卡所屬銀行的號碼（類似於BIN碼），並將該虛擬 201023067 卡號和銀行卡號予以綁定並寫入一卡對應關係表，然後發 卡行將該虛擬卡資訊發送至第三方支付平台。 第三方支付平台將接收到的虛擬卡資訊返回至用戶。 S 4 04，商戶的交易系統接收用戶發出的利用該虛擬卡 資訊進行交易支付的請求，該用戶的支付方式最常見的就 是在各種商戶提供的頁面上直接輸入虛擬卡號和密碼，當 然，用戶也可以當面在交易處輸入虛擬卡號和密碼。商戶 ^ 交易系統接收到支付請求後，根據虛擬卡號的BIN碼來判 斷出該卡號所屬發卡行，並將相關業務請求連同虛擬卡號 和密碼一起發送至該對應發卡行。當發卡行接收到包含虛 擬卡號資訊和支付金額的支付請求時，先對該虛擬卡的使 用規則進行驗證，查證該虛擬卡號的使用是否繼續有效以 及密碼是否正確，若有一項不正確則返回錯誤資訊至商戶 系統。通過虛擬卡使用規則驗證後’該發卡行根據步驟 S403建立的卡對應關係表將該虛擬卡號翻譯成真實卡號 φ ，並對該相關業務請求進行處理’此時若該銀行卡帳戶滿 足銀行卡支付規則，則支付成功’否則返回支付失敗的資 訊至商戶系統。 該銀行卡支付規則一般是銀彳了業內同一規定的’部分 也可以是該銀行特別規定的。比如’若該銀行卡是普通的 借記卡，即不具有透支功能的銀行卡’則銀行卡的支付規 則至少包括虛擬卡對應的銀行卡的金額不小於支付金額’ 若該銀行卡是信用卡’則銀行卡的支付規則至少包括滿足· 該虛擬卡對應的信用卡的使用規則。 -19- 201023067 當第三方支付平台接收到用戶需要對其申請到的虛擬 卡使用規則進行修改時，可以按如下步驟進行修改： S501，第三方支付平台接收到用戶發送虛擬卡修改請 求，同樣的，用戶可以在第三方支付平台提供的範本中進 行選擇，也可以重新自由設定使用規則； S 502，第三方支付平台根據該虛擬卡修改請求，讀取 出該用戶的銀行卡和密碼資訊，並將該修改虛擬卡使用規 則的請求連同銀行卡及密碼資訊發送至對應的發卡行； S 5 03，發卡行對銀行卡資訊進行認證，若認證通過， 則修改先前註冊的虛擬卡使用規則，並返回修改成功的資 訊至第三方支付平台； S504，第三方支付平台返回修改成功資訊至用戶。 上述第一實施例，其透過網上支付是本發明的最佳實 施例。 第二實施例 本申請案又提出另一種利用虛擬卡提高支付安全的支 付系統，請參見圖5，其爲本申請案的另一種網上支付系 統的結構圖，該網上支付系統包括用戶510、至少一家銀 行卡的發卡行520和商戶530，其中發卡行520和商戶 530之間透過專線或網路連接，而用戶510則分別可以連 至發卡行520和商戶530。 發卡行520進一步包括發卡行資料庫521及發卡行伺 服器522，其中，發卡行資料庫52 1進一步包括用以將產 201023067 生的虛擬卡號和真實銀行卡號相綁定的卡對應關係表5211 ，用以儲存銀行卡包括用戶名、卡號及密碼在內的各種屬 性的銀行卡屬性儲存單元5212及用以儲存銀行卡交易記 錄及餘額的銀行卡交易記錄儲存單元5213(請參見圖6) 。發卡行伺服器522進一步包括： 銀行卡認證單元5221:其用以接收用戶510發送的包 含虛擬卡申請/修改請求在內的各種申請，並對該申請內 φ 的銀行卡資訊根據銀行卡屬性儲存單元5212內的資訊進 行匹配認證； 虛擬卡產生單元5222 :用以處理透過銀行卡認證單元 522 1認證的虛擬卡申請/修改請求，根據通過認證的虛擬 卡申請請求，產生一虛擬卡號，該虛擬卡號中包含有用以 識別該發卡行的BIN碼，同時將該虛擬卡號和真實銀行卡 號綁定，並寫入卡對應關係表5211，然後將該申請中的虛 擬卡使用規則予以註冊，最後將該虛擬卡號資訊發送至用 φ 戶510;而對於通過認證的虛擬卡修改請求，則對先前註 冊虛擬卡使用規則進行修改，並將結果回饋至用戶510。 交易處理單元5223:用以處理商戶530轉發的包含虛 擬卡號資訊和支付金額的支付請求，並在對請求進行處理 前，先對虛擬卡使用規則進行驗證，驗證成功後並在滿足 銀行卡上的金額不小於支付金額的前提下對支付請求進行 處理，然後回饋處理情況。 基於上述系統本申請案又一種提高網上支付安全的網 上支付方法，用以提高用戶透過銀行卡進行網上支付的安 -21 - 201023067 全性，請參見圖7’其爲本申請案另一種支付方法的流程 圖，該支付方法包括如下步驟：201023067 VI. Description of the Invention: [Technical Field] The present application relates to a payment method and system, and more particularly to a payment method and system for improving payment security by using a virtual card. [Prior Art] With the rapid development and popularization of the Internet, B2C e-commerce@ has also developed rapidly with it, but its development has also been restricted by the bottleneck of payment means, compared to the payment method in reality. Currently, there are usually three popular online payment methods: (1) direct payment through the bank online banking system; (2) payment through a third-party payment company; (3) direct input of the card number and password on the e-commerce platform's web page. . In terms of current technology, the security of the first two methods is relatively high, and more and more e-commerce platforms are beginning to support the payment methods of third-party payment companies, but there are still many e-commerce platforms using the third. Kind of payment method. • The third payment method requires the user to directly enter the bank card number and password when shopping, but now there are many malicious acts on the network, the customer cannot identify whether the shopping site is malicious, or whether there is a loophole that may reveal the card number. And the password, so it will bring certain threats to the user's card security. The invention patent of CN01 1 29250 discloses an e-commerce online payment system and an implementation method thereof, the method comprising the following steps: S 1 0 1 : an enterprise integrates multiple commodities or services, and establishes an electronic commerce for selling these goods or services. Platform; 201023067 S 1 02: The company issues pre-set fixed price 能够 can pay for the sequence of these goods or services 5 Ι Ι and street code 'serial number, password is carried on a certain medium, the medium is packaged; S103: the enterprise will encapsulate the serial number The password medium is distributed to the customer through the sales pipeline; S1 04: the customer orders the goods on the enterprise-designated e-commerce platform; S1 05: the customer writes the usage information on the goods; S106: writes the pre-provided information provided by the enterprise The fixed price can be used to pay a variety of _ product service serial number and password; S 1 07: e-commerce platform billing system program for serial number, password verification, after successful deduction of the serial number, password on the customer's choice of the price of the product, successful The post-use program informs the goods and service providers to verify the successful information; S 1 08: the goods and service manufacturers give the customers Service license, the customer gets the corresponding goods or services. However, the above e-commerce online payment method transaction method is particularly complicated and does not have versatility and universality. The current transaction is in the direction of convenience, speed, and security, especially the emergence of the Internet. It is possible to purchase products with excellent performance and price ratio without leaving the house. That is to say, through the third payment method, it is gradually becoming the mainstream. Since the user needs to directly enter the bank card number and password when shopping, and now there are many malicious acts on the Internet, 'the customer cannot identify whether the shopping site is malicious' or if there is a loophole that may reveal its card number and password, it will give The user's card security brings certain threats, especially the user's property loss. 201023067 [Invention] In view of the above drawbacks, the idea of the present application is to provide a payment method for improving payment security by using a virtual card to solve the prior art. In the case of directly entering the bank card number and password on the webpage for online payment or other business, the defect of the account cannot be effectively protected. Another idea of the present application is to provide a payment system that uses a virtual card to improve payment security, so as to solve the problem that the direct input of the silver Φ line card number and password on the webpage for online payment or other services cannot be effectively protected in the prior art. Defects in the account. The third idea of the present application is to provide a payment platform. The present application proposes a payment method for improving payment security by using a virtual card, which is used to improve the security of payment by a user through a bank card, including: (1) providing a third-party payment platform through a dedicated line or network The issuing bank that connects at least one bank card; (2) The third-party payment platform receives the user's virtual card application request φ and then 'obtains the user's bank card information, and sends a virtual card application request to the corresponding issuing bank'. Include bank card information and virtual card usage rules·, (3) When the third-party payment platform receives the requested virtual card number information sent by the card-issuing bank, return to the user; (4) When the card-issuing bank receives the information including the virtual card number and When the payment request for the payment amount is satisfied, if the virtual card satisfies the virtual card usage rule and corresponds to the payment rule of the bank card, the payment is successful. According to the payment method described in the preferred embodiment of the present application, obtaining the bank card information of the user in the step (2 201023067) further includes: the third party payment platform pre-stores the bank card information bound to the user, when receiving the virtual When the card applies for a request, it is determined that the user who sent the virtual card application request finds the bank card information bound by the user. According to the payment method of the preferred embodiment of the present application, the step (2) of obtaining the bank card information of the user further includes: the virtual card application request sent by the user received by the third-party payment platform includes the bank card and the password information thereof. When the two-party payment platform receives the virtual card application request, the bank card and password information are parsed therefrom. The payment method according to the preferred embodiment of the present application further includes: the virtual card application request sent by the third-party payment platform is included in the virtual card application request, or the third-party payment platform is preset in advance. The virtual card uses the rule template to receive the virtual card usage rule template selected by the user as the virtual card usage rule. The payment method according to the preferred embodiment of the present application further includes: the third-party payment platform receiving the request of the user to modify the virtual card usage rule and sending the request for modifying the virtual card usage rule to the corresponding issuing bank. The third-party payment platform sends the modified result returned by the issuing bank to the corresponding user. According to the payment method of the preferred embodiment of the present application, the virtual card usage rule further includes: an effective condition for using the virtual card that is limited by the number of uses and/or a time limit for use, and a virtual card corresponding password setting. . The present application proposes a support system for improving payment security by using a virtual card, including a table two-party payment platform and at least one bank card issuing bank. The third-party payment platform further includes a payment platform server and a payment platform. The database, wherein the payment platform server comprises at least: a user interface processing unit: receiving various requests sent by the user, including a virtual card application request, and returning the processing result of the platform to the user; the card issuing interface processing unit : used to establish interaction with each Φ issuing bank that has signed a contract with the third-party payment platform, and send it to various processing requests corresponding to the issuing card including the virtual card application request, and receive the virtual card application success; virtual card service Processing unit: connected to the user interface processing unit and the card issuing interface processing unit for receiving the virtual card application request, obtaining the user's bank card information and the virtual card usage rule, and finding the corresponding issuing bank information through the bank card information, forming The virtual card application request message is transmitted through the card issuing bank The interface processing unit is sent to the corresponding issuer bank; the payment platform database further includes: a virtual card record storage unit for storing all the conditions of the user and the corresponding φ virtual card application/modification, and the bank card and the card issue information are saved. a card issuing bank storage unit, a user attribute storage unit for storing user information; the card issuing bank further comprising a card issuing bank database and a card issuing bank server, wherein the 'issuing bank database further comprises a card card and a virtual card binding card corresponding to the card issuing bank Relationship table 'bank card attribute storage unit and bank card transaction record storage unit, the card issuer server further comprises: a bank card authentication unit: receiving various applications including a virtual card application request sent by a third party payment platform' The bank card information in the application is matched and authenticated; virtual-9 - 201023067 the card generation unit: for processing the virtual card application request authenticated by the bank card authentication unit, generating a virtual card, and transmitting the virtual card information to a third party Processing platform; transaction processing unit: used to process the virtual card number The payment request for information and payment amount is verified by the virtual card usage rule before the request is processed. After the verification is successful, the payment request is processed and the feedback is processed on the premise that the amount on the bank card is not less than the payment amount. Handle the situation. The application further proposes a payment method for improving payment security by using a virtual card, which is used for improving the security of payment by a user through a bank card, including (n. the card issuing bank of the bank card receives a virtual card application request sent by the user, in the request Include bank card information and virtual card usage rules; (2) After receiving the virtual card application request from the user, the card issuing bank authenticates the bank card information, and generates a virtual card number and a registered virtual card usage rule according to the request after the authentication. And then returning the virtual card number to the user; (3) When the card issuing bank receives the payment request including the virtual card number information and the payment amount, if the virtual card satisfies the virtual card usage rule and corresponds to the payment rule of the bank card, the payment is successful. The invention further proposes a payment system for improving payment security by using a virtual card, comprising at least one bank card issuing bank, the card issuing bank further comprising a card issuing bank database and a card issuing server, wherein the issuing bank database further comprises a bank card and a virtual card. Card-bound card correspondence table, bank card attribute storage unit, and bank The card transaction record storage unit further includes: -10- 201023067 The bank card authentication unit: receives various applications including a virtual card application request sent by the user, and matches the bank card information in the application. Authentication; virtual card generating unit: for processing a virtual card application request authenticated by the bank card authentication unit, generating a virtual card, and transmitting the virtual card information to the user; the transaction processing unit: for processing the virtual card number information and the payment amount The payment request is verified by the virtual card usage rule before the request is processed. After the verification is successful, and the amount on the bank card is satisfied, the payment request is processed under the premise of not less than the payment amount, and the processing is processed. The application further provides a payment platform, which includes a payment platform server and a payment platform database, wherein the payment platform server at least includes: a user interface processing unit: receiving various requests sent by the user, including a virtual card application request, And return the processing results of this platform to the user. The issuing card interface processing unit: establishing an interaction with each card issuing bank contracted by the third party payment platform φ, and transmitting the processing result to the corresponding issuing bank including the virtual card application request and receiving the virtual card application success. The virtual card service processing unit is connected to the user interface processing unit and the issuer interface processing unit, and is configured to obtain the user's bank card information and virtual card usage rules when receiving the virtual card application request, and find the corresponding card issuance through the bank card information; And the virtual card application request message is sent to the corresponding issuer through the card issuer interface processing unit; the payment platform database further includes: for saving the user and the corresponding -11 - 201023067 virtual card application/modification The virtual card record storage unit of the situation, the card issuer storage unit corresponding to the bank card and the card issue information, and the user attribute storage unit for storing the user information. Compared with the prior art, this series of appeals has the following advantages: (1) The user applies to the bank through the third-party platform to customize the virtual card number of the usage rule, and uses the virtual card number to consume to each e-commerce platform, which can be effective. Protect the interests of users and reduce the loss of customers. (2) When the virtual card number and password are stolen, the pre-set virtual card usage rules, such as pre-set usage times and usage limits (such as $500), can limit the loss to the range that the user can control. (3) In the prior art, when the bank card information is stolen, it is necessary to go to the outlet or through the telephone to report the loss. Most of the issuing bank's outlets are not open 24 hours, so the loss of time and geographical acceptance through the outlets However, if the loss is reported by telephone, the existing telephone number of each issuing bank is not easy to get in and there is a problem that the telephone system has a delay in processing. The present invention can realize instant loss reporting through a network through a third-party payment platform, and the processing speed is very fast, which reduces the time lost by the user. (4) The virtual card provided by the present invention can be used not only on the network but also in a traditional environment. The generation of the virtual card can be performed by using a traditional bank card number, that is, at least the card is included in the virtual card number. The information, especially when the user uses the virtual card to consume in some unfamiliar and untrusted environment, can reduce the user's loss, thereby improving the security of the user's bank card. Of course, the most common environment for the present invention is the Internet -12-201023067. (5) The program does not require any changes from the merchants. It only requires changes to the third-party platform and the bank, and has universal applicability. It should be noted that any of the above-described products embodying the present invention does not necessarily need to achieve all of the advantages described above at the same time. [Embodiment] Φ The core of the application is that the user applies for a virtual card number and password to the bank through a third-party payment platform, and subscribes to the virtual card number and password, and then consumes the obtained virtual card number and password. The user uses a virtual card number and password, and the card number and password also have various usage rules, so that the user's loss due to various malicious acts on the network can be minimized. The third-party payment platform described in this application is a transaction payment platform provided by a third-party independent institution that has signed contracts with major banks at home and abroad and has certain strength and credit guarantee. For example, Zhifubao can bind its own. User's bank card information. The present application will be specifically described below with reference to the accompanying drawings. [First Embodiment] This application proposes a payment system for improving payment security by using a virtual card. Referring to Fig. 1, there is shown a structural diagram of a payment system for improving payment security using a virtual card. The payment system includes a user 110, a third-party payment platform 120, at least one bank card issuing bank 130, and a merchant 140, wherein the third-party payment platform 12 transmits a card with a bank card through a dedicated line or network and to -13-201023067 Line 130 is connected, and merchant 140 is also connected to the issuing bank 1 30 via a dedicated line or network, and the user 1 1 可以 can be connected to the third party payment platform 120 and the merchant M〇, respectively. The third-party payment platform 120 further includes a payment platform server 121 and a payment platform database 122 (see FIG. 2), wherein the payment platform server 121 includes at least: a user interface processing unit 1211 for receiving the user 110 Various requests including virtual card application/modification request, and returning the processing result of the platform to the user 110; the card issuing interface processing unit 1213: the issuing bank 13 for signing with the third party payment platform 120 Establishing an interaction, sending to the issuer 130 for various requests including the virtual card application/modification request, receiving the virtual card application/modification success, the virtual card service processing unit 1212: connecting to the user interface processing unit 1211 and The issuing bank interface processing unit ι213 is configured to obtain the bank card information and the virtual card usage rule of the user 110 when receiving the virtual card application/modification request and find the corresponding issuing bank by analyzing the B IN code in the bank card information. Information, the virtual card application/modification request message is sent to the corresponding sender through the card issuing interface processing unit OK, the virtual card applicant / modification includes bank card information and virtual card usage rules Information request packet. The user interface processing unit 1211, the issuer interface processing unit 1213, and the virtual card service processing unit 1212 may be either hardware or software. In this example, it is better to set the logic unit on the processor in the server, -14 - 201023067 is commonly known as software. The payment platform database 122 further includes: a virtual card record storage unit 1221 for saving all the situations of the user and the corresponding virtual card application/modification, and a card issuer storage unit 1222 for saving the bank card and the card issue information, for saving the user. User attribute storage unit 1 223 of information. Virtual card record storage unit 1221 and issuer storage unit! 222 and the user attribute storage unit 1 2 2 3 are logical units and are logical units solidified in the memory φ. The issuing bank storage unit 1222 is mainly used for storing the correspondence between the issuing bank identification and the issuing bank, and the identification of the issuing line refers to the fixed position of the PIN code for identifying the digit of the issuing line. The issuer bank 130 further includes a card issuer database 131 and a card issuer server 132 (see Figure 3). The card issuing bank database 31 further includes: a card correspondence table 1311 for binding the generated virtual card number and the real bank card number, for storing various attributes of the bank card including the user name, the card number and the password. The bank card attribute storage unit 1312 and the bank card transaction record storage unit 1313 that stores the bank card transaction record and balance with φ. The issuer server 132 further includes: a bank card authentication unit 1 32 1 · for receiving various applications including a virtual card application/modification request sent by the third party payment platform 120, and the bank card information in the application The matching authentication is performed according to the information in the bank card attribute storage unit 1312. The virtual card generating unit 1 322 is configured to process the virtual card application/modification request authenticated by the bank card authentication unit 133, and apply for the request according to the authenticated virtual card. 'Generate a virtual card number, the virtual card number contains a BIN code identifying the card issuing line with -15-201023067, and binding the virtual card number to the real bank card number, and writing the card correspondence table 1311, and then to the virtual card The virtual card usage rule in the application request is registered, and finally the virtual card number information is sent to the third-party processing platform 120; and for the authenticated virtual card modification request, the previously registered virtual card usage rule is modified, and the result is Feedback is provided to the third party processing platform 120. The transaction processing unit 1323 is configured to process the payment request including the virtual card number information and the payment amount forwarded by the merchant, and verify the virtual card usage rule before the request is processed, and the amount on the bank card is not verified after the verification is successful. The payment request is processed under the premise of less than the payment amount, and the processing is reported. The bank card authentication unit 1321, the virtual card generating unit 1322, and the transaction processing unit 1323 may be hardware or software, and are usually software installed in the server. Based on the above payment system, the present application proposes a payment method for improving payment security by using a virtual card, which is used to improve the security of payment by a user through a bank card. Referring to FIG. 4, it is a flowchart of a payment method of the present application. The payment method includes the following steps: S4〇l, providing a third-party payment platform, the third-party payment platform connecting a card issuing bank of at least one bank card through a dedicated line or a network, and signing a relationship with the card issuing behavior, the issuing bank may be the The third-party payment platform provides a series of business processes, including the virtual card application business involved in this application. The third payment platform provides the user with a virtual card application service, which can be connected to the user through the Internet at -16 - 201023067. Of course, the user can also apply for the virtual card application business directly to the office set up by the third party payment platform. The user is generally a registered user of the third-party payment platform. The user can bind a bank card that has a contractual relationship with the third-party payment platform. Of course, the user can also register only without binding the bank card. Taking Alipay, a third-party payment platform, as an example, existing Alipay users usually have bank card information bound to them. S402. The third-party payment platform receives the virtual card application sent by the user, and asks for the virtual card usage rule. The virtual card usage rule may be a template preset by a third-party payment platform, and then the user may select the template according to the needs at the time of application, and the virtual card usage rule may also be freely set by the user at the time of application. Of course, this freedom setting will also be limited to a certain range. According to the actual application, the virtual card usage rule may generally include a virtual card usage limit and/or a use time limited virtual card effective condition setting, a virtual card corresponding password setting, etc., for example, the virtual card valid condition may be performed in the following scheme. Select: φ ( a ) according to the number of uses: (b) According to the effective use time of the virtual card: (b 1 ) is valid for the current time period of N; (b 2 ) is valid for the next time from time A to time B; (b3) specified The loop time period is valid; (c) manually close the virtual card. The virtual card corresponding password setting can also select the original bank card password in the following scheme; -17- 201023067 ϋ·specify the virtual card password; ΐϋ· no password; ΠΠ·any password; the third party payment platform receives the user's virtual card After the request is made, it is determined whether the user has the bound bank card information. If the user pre-sets the bank card information bound to the user on the third-party payment platform, the third-party payment platform receives the virtual card application request. The bank card information is read out; if the user does not pre-set the binding bank card information, but writes the bank card number and password information when the application request is made, the third party payment platform analyzes the bank card information. . The card number of the bank card is the number that identifies the card issuer and the cardholder information. It consists of the following three parts: the issuer identification code (BIN code), the issuer's custom bit and the check code, and the third-party payment platform can pass the BIN code. To determine whether the bank card is a contracted bank. 'When the third party payment platform determines that the bank is a contracted bank, the card issuing bank is identified according to the BIN code, and a virtual card application request is sent to the card issuing bank, and the virtual card application request It contains bank card information and virtual card usage rules. If the third party payment platform determines that the bank card is a non-contracted bank, an error message is returned to the client. S403. After receiving the virtual card application request, the card issuing bank verifies the bank card information included in the request, and the specific verification mode can determine whether the BIN code is the number of the bank, check the check code, determine whether the fake card, and match the card number. Password, etc. The issuing bank randomly generates a virtual card number according to the verified virtual card application request, and the virtual card number may also include a number (similar to the BIN code) useful for identifying the bank to which the virtual card belongs, and the virtual 201023067 card number and the bank card number are given. Bind and write a card correspondence table, and then the card issuing bank sends the virtual card information to the third party payment platform. The third party payment platform returns the received virtual card information to the user. S 4 04, the merchant's transaction system receives the request sent by the user to use the virtual card information for transaction payment, and the most common payment method of the user is to directly input the virtual card number and password on the pages provided by various merchants, of course, the user also You can enter the virtual card number and password in person at the exchange. After the merchant system receives the payment request, it judges the card issuing bank to which the card number belongs according to the BIN code of the virtual card number, and sends the relevant service request together with the virtual card number and password to the corresponding issuing bank. When the card issuing bank receives the payment request including the virtual card number information and the payment amount, first verify the usage rule of the virtual card, verify whether the use of the virtual card number continues to be valid, and whether the password is correct, and return an error if one item is incorrect. Information to the merchant system. After the virtual card usage rule is verified, the card issuing bank translates the virtual card number into a real card number φ according to the card correspondence table established in step S403, and processes the related service request. At this time, if the bank card account satisfies the bank card payment The rule, the payment is successful 'otherwise, the information of the payment failure is returned to the merchant system. The bank card payment rules are generally part of the same regulation in the industry. It can also be specified by the bank. For example, if the bank card is a normal debit card, that is, a bank card that does not have an overdraft function, the payment rule of the bank card includes at least the amount of the bank card corresponding to the virtual card is not less than the payment amount 'if the bank card is a credit card' Then, the payment rule of the bank card at least includes the usage rule of the credit card corresponding to the virtual card. -19- 201023067 When the third-party payment platform receives the modification of the virtual card usage rules that the user needs to apply, the following steps can be modified: S501, the third-party payment platform receives the user to send the virtual card modification request, the same The user may select in the template provided by the third-party payment platform, or may re-set the usage rule freely; S 502, the third-party payment platform reads the bank card and password information of the user according to the virtual card modification request, and Sending the request for modifying the virtual card usage rule together with the bank card and password information to the corresponding issuing bank; S 5 03, the issuing bank authenticates the bank card information, and if the authentication passes, modifying the previously registered virtual card usage rule, and Returning the modified information to the third-party payment platform; S504, the third-party payment platform returns the modified success information to the user. The above first embodiment, which is paid online, is a preferred embodiment of the present invention. Second Embodiment This application further proposes another payment system that utilizes a virtual card to improve payment security. Referring to FIG. 5, which is a structural diagram of another online payment system according to the application, the online payment system includes a user 510. At least one bank card issuing bank 520 and a merchant 530, wherein the issuing bank 520 and the merchant 530 are connected by a dedicated line or a network, and the user 510 can be connected to the issuing bank 520 and the merchant 530 respectively. The card issuing bank 520 further includes a card issuing bank database 521 and a card issuing bank server 522. The card issuing bank database 52 1 further includes a card correspondence table 5211 for binding the virtual card number generated by the 201023067 and the real bank card number. A bank card attribute storage unit 5212 for storing various attributes of the bank card including the user name, the card number and the password, and a bank card transaction record storage unit 5213 for storing the bank card transaction record and balance (see FIG. 6). The issuer server 522 further includes: a bank card authentication unit 5221: it is configured to receive various applications including the virtual card application/modification request sent by the user 510, and store the bank card information of the φ in the application according to the bank card attribute. The information in the unit 5212 is matched and authenticated; the virtual card generating unit 5222 is configured to process the virtual card application/modification request authenticated by the bank card authentication unit 522 1 , and generate a virtual card number according to the authenticated virtual card application request, the virtual The card number includes a BIN code for identifying the card issuer, and the virtual card number is bound to the real bank card number, and written into the card correspondence table 5211, and then the virtual card usage rule in the application is registered, and finally The virtual card number information is sent to the user 510; and for the authenticated virtual card modification request, the previously registered virtual card usage rule is modified, and the result is fed back to the user 510. The transaction processing unit 5223 is configured to process the payment request including the virtual card number information and the payment amount forwarded by the merchant 530, and verify the virtual card usage rule before the request is processed, and after verifying successfully, and satisfying the bank card The payment request is processed under the premise that the amount is not less than the payment amount, and then the feedback is processed. Based on the above system, the present application further provides an online payment method for improving online payment security, which is used to improve the user's online payment through a bank card. Please refer to FIG. 7' A flow chart of a payment method, the payment method comprising the following steps:
S 701，銀行卡的發卡行接收到用戶發送的虛擬卡申請 請求，該虛擬卡申請可以是用戶透過網際網路在發卡行提 供的申請頁面進行申請的’同時，也可以是用戶至發卡行 的營業所進行申請的，該虛擬卡申請請求中包含銀行卡資 訊及虛擬卡使用規則。根據實際應用，該虛擬卡使用規則 一般可以包含虛擬卡使用次數限定和/或使用時間限定的 虛擬卡有效條件的設定、虛擬卡對應密碼設定情況等，比 如虛擬卡有效條件可以在下述方案中進行選擇： (a )按照使用次數； (b )按虛擬卡有效使用時間： (b 1 )當前到N時間段有效； (b2 )以後的A時間到B時間段有效； (b3 )指定的迴圈時間段有效；S 701, the card issuing bank of the bank card receives the virtual card application request sent by the user, and the virtual card application may be the user applying through the application page provided by the issuing bank through the Internet, or may be the user to the issuing bank. If the business office makes an application, the virtual card application request includes bank card information and virtual card usage rules. According to the actual application, the virtual card usage rule may generally include a virtual card usage limit and/or a use time limited virtual card effective condition setting, a virtual card corresponding password setting, etc., for example, the virtual card valid condition may be performed in the following scheme. Select: (a) according to the number of uses; (b) according to the effective use time of the virtual card: (b 1) valid for the current time period of N; (b2) valid for the later time from time A to time B; (b3) the specified circle The time period is valid;
(c )手動關閉虛擬卡。 而虛擬卡對應密碼設定又可以在下述方案中進行選擇 i. 原銀行卡密碼； ϋ· 指定虛擬卡密碼； iii. 無密碼； iiii.任意密碼； S 7 02，發卡行接收到用戶的虛擬卡申請請求後，對該 請求中包含的銀行卡資訊進行驗證，具體驗證方式可以透 -22- 201023067 過驗證BIN碼是否是本行的號碼、檢査校驗碼判斷是否僞 卡，匹配卡號密碼等。發卡行根據通過驗證的虛擬卡申請 請求生成一虛擬卡號’該虛擬卡號中也可以包含有用以識 別該虛擬卡所屬銀行的號碼（類似於BIN碼），並將該虛 擬卡號和銀行卡號予以綁定並寫入一卡對應關係表，然後 發卡行將該虛擬卡資訊發送給用戶。 S 703，商戶的交易系統接收用戶發出的利用該虛擬卡 φ 資訊進行交易支付的請求，該用戶的支付方式最常見的就 是在各種商戶提供的頁面上直接輸入虛擬卡號和密碼，當 然，用戶也可以當面在交易處輸入虛擬卡號和密碼。商戶 交易系統接收到該支付請求後，根據虛擬卡號的BIN碼來 判斷出該卡號所屬發卡行，並將相關業務請求連同虛擬卡 號和密碼一起發送至該對應發卡行。當發卡行接收到包含 虛擬卡號資訊和支付金額的支付請求時，先對該虛擬卡的 使用規則進行驗證，查證該虛擬卡號的使用是否繼續有效 φ 以及密碼是否正確，若有一項不正確則返回錯誤資訊至商 戶系統。通過虛擬卡使用規則驗證後，該發卡行根據步驟 S7 02建立的卡對應關係表將該虛擬卡號翻譯成真實卡號 ，並對該相關業務請求進行處理，此時若該銀行卡帳戶滿 足銀行卡支付規則，則支付成功，否則返回支付失敗的資 訊至商戶系統，該銀行卡支付規則一般是銀行業內同一規 定的，部分也可以是該銀行特別規定的。 當發卡行接收到用戶需要對其申請到的虛擬卡使用規 則進行修改時，可以按如下步驟進行修改： -23- 201023067 S801，發卡行接收用戶發送的虛擬卡修改請求； S8 02，發卡行收到該請求後，將該虛擬卡號轉換爲真 實卡號，若轉換成功，則修改先前註冊的虛擬卡使用規則 ，並返回修改成功的資訊至用戶。 第三實施例 本申請案再提出了 一種支付平台，其可以接收用戶申 請虛擬卡的請求，並向對應銀行爲用戶申請虛擬卡，其結 構如第一實施例中第三方支付平台相同（即圖2所示）。 該第三方支付平台120進一步包括支付平台伺服器121和 支付平台資料庫122(請參見圖2)，其中，支付平台伺 服器1 2 1至少包括： 用戶介面處理單元1211:其用以接收用戶110發送的 包含虛擬卡申請/修改請求在內的各種請求，並把本平台 的處理結果返回至用戶110; 發卡行介面處理單元1213:用以與各家與該第三方支 付平台120簽約的發卡行130建立交互，發送至發卡行 130包含虛擬卡申請/修改請求在內的各種請求、接收虛擬 卡申請/修改成功在內的處理結果； 虛擬卡業務處理單元1212:連接至用戶介面處理單元 1211和發卡行介面處理單元1213，其用於接收虛擬卡申 請/修改請求時’獲得用戶110的銀行卡資訊和虛擬卡使 用規則’並且透過分析該銀行卡資訊中的BIN碼來找到對 應的發卡行資訊，形成虛擬卡申請/修改請求報文透過所 201023067 述發卡行介面處理單元發送至對應的發卡行，該虛擬卡申 請/修改請求報文中包含了銀行卡資訊和虛擬卡使用規則 資訊。 用戶介面處理單元1211、發卡行介面處理單元1213 和虛擬卡業務處理單元1212可以是硬體，也可以是軟體 。本實例中最好是設置在伺服器中處理器上的邏輯單元， 即俗稱的軟體。 φ 支付平台資料庫1 22進一步包括：用於保存用戶及對 應的虛擬卡申請/修改的所有情況的虛擬卡記錄儲存單元 1221、用於保存銀行卡與發卡資訊的發卡行儲存單元1222 ’用於保存用戶資訊的用戶屬性儲存單元1 223。 虛擬卡記錄儲存單元1221、和發卡行儲存單元1222 和用戶屬性儲存單元1 223是邏輯單元，是固化在記憶體 中的邏輯單元。發卡行儲存單元1222主要用於儲存與之 簽約的發卡行標識與發卡行的對應關係，所述發卡行的標 φ 識是指BIN碼固定位置用於標識發卡行的數位。 本申請案所稱的網上支付方法不但包括付款，還包括 轉帳、抵押、凍結等業務。所以與現有技術相比，本申請 案具有以下優點： 1、 用戶透過第三方平台向銀行申請訂制了使用規則 的虛擬卡號，並利用該虛擬卡號到各個電子商務平台進行 消費，可以有效的保障用戶的利益，減少客戶的損失。 2、 該方案不需要各個商戶做任何改動，只需要第三 方平台和銀行間有所改動即可，具有普遍的適用性。 -25- 201023067 以上公開的僅爲本發明的幾個具體實施例，但本發明 並非局限於此’任何本領域的技術人員能思之的變化’都 應落在本發明的保護範圍內。 【圖式簡單說明】 圖1爲本申請案一種利用虛擬卡提高支付安全的系統 的結構圖； 圖2爲本申請案一第三方支付平台的結構圖； 圖3爲本申請案一發卡行的結構圖； 圖4爲本申請案一種利用虛擬卡提高支付安全的支付 方法的流程圖； 圖5爲本申請案另一種利用虛擬卡提尚支付安全的支 付系統的結構圖； 圖6爲本申請案另一發卡行的結構圖； 圖7爲本申請案另一種利用虛擬卡提高支付安全的支 付方法的流程圖。 【主要元件符號說明】 1 10 :用戶 120 :第三方支付平台 1 2 1 :支付平台伺服器 122 :支付平台資料庫 1 3 0 :發卡行 1 3 1 :發卡行資料庫 -26- 201023067 13 2 :發卡行伺服器 140 :商戶 5 10 :用戶 520 :發卡行 52 1 =發卡行資料庫 522 =發卡行伺服器 530 :商戶 龜 1211 :用戶介面處理單元 12 12 :虛擬卡業務處理單元 12 13 :發卡行介面處理單元 122 1 :虛擬卡記錄儲存單元 1222 :發卡行儲存單元 1223 :用戶屬性儲存單元 13 11 :卡對應關係表 13 12 :銀行卡屬性儲存單元 ❹ 1313 :銀行卡交易記錄儲存單元 132 1 :銀行卡認證單元 1322 :虛擬卡產生單元 13 23 :交易處理單元 52 11 :卡對應關係表 52 12 :銀行卡屬性儲存單元 52 13 :銀行卡交易記錄儲存單元 522 1 :銀行卡認證單元 5222 :虛擬卡產生單元 -27- 201023067 5223··交易處理單冗(c) Manually shut down the virtual card. The virtual card corresponding password setting can be selected in the following schemes. i. The original bank card password; ϋ· specifies the virtual card password; iii. no password; iiii. any password; S 7 02, the card issuing bank receives the user's virtual card After requesting the application, verify the bank card information contained in the request. The specific verification method can be verified by -22-201023067 whether the BIN code is the number of the bank, check the check code to determine whether it is a fake card, and match the card number password. The issuing bank generates a virtual card number according to the verified virtual card request request. The virtual card number may also include a number (similar to the BIN code) useful for identifying the bank to which the virtual card belongs, and bind the virtual card number and the bank card number. And write a card correspondence table, and then the card issuing bank sends the virtual card information to the user. S 703, the merchant's transaction system receives the request sent by the user to use the virtual card φ information for transaction payment, and the most common payment method of the user is directly inputting the virtual card number and password on the pages provided by various merchants, of course, the user also You can enter the virtual card number and password in person at the exchange. After receiving the payment request, the merchant transaction system determines the card issuer to which the card number belongs according to the BIN code of the virtual card number, and sends the relevant service request together with the virtual card number and password to the corresponding issuer. When the card issuing bank receives the payment request including the virtual card number information and the payment amount, first verify the usage rule of the virtual card, verify whether the use of the virtual card number continues to be valid φ and whether the password is correct, and if one item is incorrect, return Error message to the merchant system. After the virtual card usage rule is verified, the card issuing bank translates the virtual card number into a real card number according to the card correspondence table established in step S102, and processes the related service request. At this time, if the bank card account satisfies the bank card payment If the rule is successful, the payment will be returned to the merchant system. The bank card payment rules are generally the same as those in the banking industry, and some may be specified by the bank. When the card issuing bank receives the modification of the virtual card usage rule that the user needs to apply, it can be modified as follows: -23- 201023067 S801, the card issuing bank receives the virtual card modification request sent by the user; S8 02, the card issuing bank receives After the request, the virtual card number is converted into a real card number. If the conversion is successful, the previously registered virtual card usage rule is modified, and the successfully modified information is returned to the user. The third embodiment further proposes a payment platform, which can receive a request for a user to apply for a virtual card, and apply for a virtual card for the user to the corresponding bank, and the structure is the same as that of the third-party payment platform in the first embodiment (ie, 2)). The third-party payment platform 120 further includes a payment platform server 121 and a payment platform database 122 (see FIG. 2), wherein the payment platform server 1 2 1 at least includes: a user interface processing unit 1211 for receiving the user 110 Sending various requests including virtual card application/modification request, and returning the processing result of the platform to the user 110; the card issuing interface processing unit 1213: for issuing the card issuing bank with each third party payment platform 120 130 establishes an interaction, sends to the card issuing bank 130 various requests including the virtual card application/modification request, and receives the processing result of the virtual card application/modification success; the virtual card service processing unit 1212: connects to the user interface processing unit 1211 and The card issuing card interface processing unit 1213 is configured to: obtain the bank card information of the user 110 and the virtual card usage rule when receiving the virtual card application/modification request and find the corresponding issuer information by analyzing the BIN code in the bank card information. Forming a virtual card application/modification request message to be sent to the corresponding server through the 201023067 description card issuing interface processing unit The issuing bank, the virtual card applicant / modification request message includes the bank card information and virtual information card usage rules. The user interface processing unit 1211, the issuer interface processing unit 1213, and the virtual card service processing unit 1212 may be either hardware or software. In this example, it is preferable to set a logic unit on the processor in the server, which is a so-called software. The φ payment platform database 1 22 further includes: a virtual card record storage unit 1221 for storing all cases of the user and the corresponding virtual card application/modification, and a card issuer storage unit 1222 for saving the bank card and the card issue information. User attribute storage unit 1 223 that stores user information. The virtual card record storage unit 1221, the issuer storage unit 1222, and the user attribute storage unit 1223 are logical units that are solidified in a memory. The issuing bank storage unit 1222 is mainly used for storing the correspondence between the issuing bank identification and the issuing bank, and the identification of the issuing unit refers to the fixed position of the BIN code for identifying the digit of the issuing line. The online payment method referred to in this application includes not only payment, but also transfers, mortgages, and freezes. Therefore, compared with the prior art, the present application has the following advantages: 1. The user applies for a virtual card number that uses the rule to the bank through the third-party platform, and uses the virtual card number to consume to each e-commerce platform, which can effectively protect The interests of users reduce the loss of customers. 2. The program does not require any changes from merchants. It only requires changes from third-party platforms and banks, and has universal applicability. The above disclosure is only a few specific embodiments of the present invention, but the present invention is not limited thereto, and any variations that can be considered by those skilled in the art are intended to fall within the scope of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a structural diagram of a system for improving payment security by using a virtual card; FIG. 2 is a structural diagram of a third-party payment platform of the present application; FIG. 3 is a card issuing line of the present application; FIG. 4 is a flow chart of a payment method for improving payment security by using a virtual card according to the present application; FIG. 5 is a structural diagram of another payment system using a virtual card to provide payment security; FIG. Another structural diagram of the issuing bank; FIG. 7 is a flow chart of another payment method for improving payment security by using a virtual card. [Main component symbol description] 1 10 : User 120: Third-party payment platform 1 2 1 : Payment platform server 122: Payment platform database 1 3 0: Issuer bank 1 3 1 : Issuer database -26- 201023067 13 2 : Issuer Server 140: Merchant 5 10: User 520: Issuer 52 1 = Issuer Database 522 = Issuer Server 530: Merchant Turtle 1211: User Interface Processing Unit 12 12: Virtual Card Service Processing Unit 12 13 : Issuer interface processing unit 122 1 : Virtual card record storage unit 1222 : Issuer storage unit 1223 : User attribute storage unit 13 11 : Card correspondence table 13 12 : Bank card attribute storage unit ❹ 1313 : Bank card transaction record storage unit 132 1 : bank card authentication unit 1322 : virtual card generation unit 13 23 : transaction processing unit 52 11 : card correspondence table 52 12 : bank card attribute storage unit 52 13 : bank card transaction record storage unit 522 1 : bank card authentication unit 5222 : Virtual card generation unit -27- 201023067 5223··Transaction processing single redundancy
-28--28-