TWI827096B - 動態支付選擇系統及方法 - Google Patents

Abstract

一種動態支付選擇系統，包括交易控制模組、用戶資料模組、商店資料模組及支付路徑選擇器。交易控制模組接收交易請求，交易請求包括用戶識別碼及商店識別碼。用戶資料模組包括用戶資料庫，儲存有用戶綁定的支付方法。商店資料模組包括商店資料庫，儲存有商店接受的支付方法。交易控制模組依據用戶識別碼及商店識別碼獲取用戶資料庫中對應的用戶綁定的支付方法及商店資料庫中對應的商店接受的支付方法，並依此選擇支付方法，進而產生支付請求以發送到支付路徑選擇器。支付路徑選擇器在接收到支付請求之後，選擇對應的支付閘道器以便完成支付。

Description

動態支付選擇系統及方法

本發明涉及電子商務領域，特別是有關於支付系統及方法。

因應數位時代的來臨，消費支付也走向多元及電子化，過往支付工具主要是銀行所提供之帳戶及發行信用卡之信用卡帳戶，2015年，我國修定頒佈電子支付管理條例，增加了電子支付業者亦可以進行儲值及支付。然而，信用卡、金融卡及其他電子帳戶等多元之帳戶支付方法均有各自的清算網路及流程(銀行帳戶之支付交換可由財金公司協助之金資中心完成，亦可以由台灣票據交換所之網路完成，以及國際之SWIFT等方式，而信用卡則由VISA，MASTER，JCB，AMEX等，國內部份由NCCC聯合信用卡中心或各別銀行來完成，而電子支付業者如悠遊卡，一卡通簡單支付等各有各自之清算網路)，並多由各自不同的結帳支付業者或金融機構提供在買賣點POS上使用之支付或收單交易服務及付款閘道，同時，也多只支持簡易且標準之支付方法。

而另一方面，商家與消費者對於買賣，無不期望能有更多元的支付方式，例如，能先享受後付款，或者分期付款等。但礙於目前支付系統複雜，提供相關服務之業者必須與特定支付系統整合才可以完成付款交易。例如，特定信用卡分期付款之支付，對消費者而言，只能單方面到了店家或其網站，依其有支援之金流服務(目前台灣市場也只有信用卡分期付款及資融業者以虛擬帳戶事後列印繳款單，來進行有限的分期付款方式。很多時候，消費者剛好没有持有特定的信用卡，到了店家消費當下，想要分期付款，卻發現無法進行，相當令人懊惱。

事實上，消費者往往手上有不少信用卡與帳戶，不同的信用卡有不同的信用額度，消費者當然希望能整合運用，更希望能夠先享受後付款，還最好能準時繳款，不要陷入遲繳或者要繳循環信用的利息等情況。因此，消費者可能希望大部份的商店都能接受分期付款買賣。又，開始進行分期付款時，若是能夠第一期用A信用卡完成付款，第二期款以B信用卡完成，第三期則以銀行帳戶自動扣款等方式，則能達到靈活的帳款消費與管理。另一方面，商店則傾向使用原本已經與POS機整合的支付系統，不要再多測試一個新系統，以免增加商店人員學習操作不同支付系統的負擔。然而，礙於目前每個支付工具都有自己的特性與自訂的規則，並只支持簡易且標準之支付方法，且支付工具彼此不相連通，無法整合運用，因而無法達成上述靈活運用不同支付方式及多元分期付款等的功能。

有鑑於此，本發明提供一種動態支付選擇系統，包括：交易控制模組，架構用於接收來自使用者終端的交易請求，該交易請求包括用戶識別碼及商店識別碼；用戶資料模組，連接該交易控制模組且包括用戶資料庫，儲存有用戶資料及用戶綁定的支付方法；商店資料模組，連接該交易控制模組且包括商店資料庫，儲存有商店資料及商店接受的支付方法；以及支付路徑選擇器，連接該交易控制模組，其中，該交易控制模組依據該用戶識別碼及該商店識別碼獲取該用戶資料庫中對應的用戶綁定的支付方法及該商店資料庫中對應的商店接受的支付方法，並依據獲取的該用戶綁定的支付方法及該商店接受的支付方法選擇支付方法，進而依據選擇的該支付方法產生支付請求以發送到該支付路徑選擇器，該支付路徑選擇器在接收到該支付請求之後，選擇對應的支付閘道器以便完成支付。

本發明還提供一種動態支付選擇方法，藉由計算裝置執行，包括以下步驟：接收來自使用者終端的交易請求，該交易請求包括用戶識別碼及商店識別碼；依據該用戶識別碼從用戶資料庫獲取用戶綁定的支付方法；依據該商店識別碼從商店資料庫獲取商店接受的支付方法；依據獲取的該用戶綁定的支付方法及該商店接受的支付方法選擇支付方法，進而依據選擇的該支付方法產生支付請求；依據該支付請求，選擇對應的支付閘道器以便完成支付。

藉由本發明提供的動態支付選擇系統及方法，能夠同時解決上述消費者與商家面臨的問題，克服新興多元支付及分期付款服務的障礙，進而使消費者在選擇付款方式時更加靈活及便利，甚而補助刺激消費，讓商家與消費者都受益，成為正向的多元支付金融科技，幫助民眾管理好自己的帳戶與自己的信用，達成普惠金融的價值。

圖1是依據本發明一實施例的動態支付選擇系統100示意圖。動態支付選擇系統100包括交易控制模組201、用戶資料模組202、商店資料模組203及支付路徑選擇器206。交易控制模組201架構用於經由網際網路104及Web伺服器105接收來自使用者終端101及102的交易請求。用戶資料模組202連接交易控制模組201且包括用戶資料庫，用戶資料庫儲存有用戶資料及用戶綁定的支付方法。商店資料模組203連接交易控制模組201且包括商店資料庫，商店資料庫儲存有商店資料及商店接受的支付方法。支付路徑選擇器206連接交易控制模組201。在一些實施例中，動態支付選擇系統100還包括分期控制模組204，連接交易控制模組201。在一些實施例中，動態支付選擇系統100還包括催收控制模組205，連接交易控制模組201。

同時參考圖1及圖2，於步驟S201，交易控制模組201經由網際網路104及Web伺服器105接收來自使用者終端101及102的交易請求。使用者終端101及102分別為用戶終端及商店終端。用戶終端透過網際網路104在Web伺服器105網頁上註冊帳號，上傳個人資料並經驗證後成為會員。商店終端透過網際網路104在Web伺服器105網頁上註冊帳號，並且上傳商店所經營販售的商品或服務。用戶終端透過網際網路104在Web伺服器105網頁上選購商品，或在實體店面選購商品，當商品或服務交易從用戶終端啟動時，交易請求會從Web伺服器105傳送至交易控制模組201，其中，交易請求包括用戶識別碼及商店識別碼。在一些實施例中，交易請求還可以包括商品識別碼、付款條件、支付方法、分期付款指示、商品運送資訊等。使用者終端101及102可以是電腦、智慧型手機、智慧型電視或任何具有連網功能的裝置。在圖1中示出兩個使用者終端101及102，然而，在其他實施例中，動態支付選擇系統100可以包括三個或更多個使用者終端，而交易控制模組201可以接收來自多個用戶終端及/或多個商店終端的交易請求。

在一些實施例中還包括步驟S202及步驟S203。交易控制模組201在接收到交易請求之後，確定交易請求中的用戶識別碼是否為新用戶，若該用戶識別碼為新用戶，則至步驟S203，啟動用戶資料模組202之新建用戶資料功能，引導新用戶註冊。同時參考圖3，圖3是依據本發明一實施例的新建用戶資料的流程圖。用戶終端透過網路在Web伺服器網頁上註冊帳號，上傳個人資料並經驗證後成為會員，並且留存綁定支付方法。詳細而言，用戶資料模組202接收用戶輸入的個人資料(步驟S301)，用戶的個人資料例如可包括姓名、身份證明號碼、電信號碼等。接著，核實用戶的個人身份(步驟S302)及核實電信資料(步驟S303)。於步驟S304，確認用戶是否同意要求其他機構移轉資料。若用戶同意授權，則用戶資料模組202轉向至其他合作業者或機構單位要求移轉資料或要求執行資料驗證。移轉資料包括但不限於用戶綁定的支付方法，例如信用卡、銀行帳號、電子支付帳戶資料，以及用戶交易的交易歷史，經過去識別化後，可以作為信用評等參考資料。若用戶不同意要求其他機構移轉資料，則要求用戶綁定欲使用交易服務的支付方法，包括信用卡支付、銀行帳戶支付及電子支付之至少一者(步驟S305)。可選的，於步驟S306，用戶可以設定交易選項，例如，若用戶綁定多個支付方法，則可以設定偏好的支付方法順序。可選的，於步驟S307，用戶可以設定送貨地址。可選的，於步驟S308，用戶還可以設定分期選項，例如預設一次付清、延後付款或分期支付及分期的期數。上述新建的用戶資料皆儲存於用戶資料庫中。

繼續參考圖2，在一些實施例中，還包括步驟S204及步驟S205。交易控制模組201在接收到交易請求之後，確定交易請求中的商店識別碼是否為新商店，若該商店識別碼為新商店，則至步驟S205，啟動商店資料模組203之新建商店資料功能，引導新商店註冊。同時參考圖4，圖4是依據本發明一實施例的新建商店資料的流程圖。商店終端透過網路在Web伺服器網頁上註冊帳號，並且上傳個人或法人資料、商品或服務資訊、各種支付的選項及折扣，包含活動代碼及活動時限，以及商店之支付API憑證。詳細而言，商店資料模組203接受提供商品或服務的商店輸入的個人或法人資料等商店資料，或經由支付業者集體註冊移轉資料(步驟S401)。接著，核實商店的負責人身份(步驟S402)及核實電信資料(步驟S403)。於步驟S404，確認商家是否同意要求其他機構移轉資料。若商家同意授權，則商店資料模組203轉向至其他合作業者或機構單位要求移轉資料或要求執行資料驗證。移轉資料包括商店接受的支付方法，例如信用卡、銀行帳號或電子支付資料，以及綁定的支付API憑證。若商家不同意要求其他機構移轉資料，則要求商家設定接受的支付方法，包括信用卡、銀行帳號或電子支付帳號之至少一種(步驟S405)，並綁定商店之支付API憑證(步驟S406)。可選的，於步驟S407，商家可以設定支付選項，例如，若商家接受多個支付方法，則可以設定不同支付方法給予的折扣，包含活動代碼及活動時限。可選的，於步驟S408，商家可以上傳商品資訊。可選的，於步驟S409，商家還可以設定分期選項，例如接受客戶一次付清、延後付款或分期支付及分期的期數。上述新建的商店資料皆儲存於商店資料庫中。

繼續參考圖2，於步驟S206，交易控制模組201依據交易請求中的用戶識別碼，從用戶資料庫獲取對應的用戶綁定的支付方法，包含卡號、卡別、銀行帳號、支付業者ID等資訊。於步驟S207，交易控制模組201依據交易請求中的商店識別碼從商店資料庫獲取對應的商店接受的支付方法，包含各種支付的選項及折扣，以及活動代碼及活動時限。接著，於步驟S208，交易控制模組201依據獲取的用戶綁定的支付方法及商店接受的支付方法，計算出對用戶最有利的方式，並依此選擇出最佳的支付方法。在一實施例中，用戶也可以手動選擇支付方法。於步驟S209，確認交易請求中是否具有分期付款或延後付款指示，若交易請求中不具有分期付款或延後付款指示，則依據選擇的支付方法產生支付請求(步驟S210)，並向支付路徑選擇器206發送支付請求以便完成支付(步驟S212)。在一實施例中，支付不成功，則依據用戶手動選擇或用戶資料庫中設定的自動選擇邏輯選擇下一個最適合的支付方法，並依據下一個支付方法再次向支付路徑選擇器206發送支付請求以便完成支付。在一實施例中，若用戶要求中斷交易請求或用戶資料庫中對應的用戶綁定的支付方法之每一者皆無法完成支付，則取消交易請求並通知對應的用戶及商店。

可選的，在一些實施例中，動態支付選擇方法還包括步驟S211。於步驟S209，確認交易請求中是否具有分期付款或延後付款指示。若交易請求中具有分期付款或延後付款指示，交易控制模組201啟動分期控制模組204的功能，執行延後付款及/或分期付款。同時參考圖5，圖5是依據本發明一實施例的分期付款的流程圖。詳細而 言，在接收交易請求之後，分期控制模組204依據分期付款指示中的分期期數設定分期利率、分期費用及分期時間點(步驟S501)。接著於步驟S502，設定下一個收款的分期時間點並啟動計時器。於步驟S503，當計時器到達收款的分期時間點，分期控制模組204向支付路徑選擇器206發送支付請求(步驟S504)以便完成當期支付。又，分期時間點中的第一時間點為接收到交易請求時，若第一時間點之支付不成功，則依據用戶手動選擇或用戶資料庫中設定的自動選擇邏輯選擇下一個最適合的支付方法，並依據下一個支付方法再次向支付路徑選擇器206發送支付請求(步驟S507)以便完成當期支付。在一實施例中，若用戶要求中斷交易請求或用戶資料庫中對應的用戶綁定的支付方法之每一者皆無法完成支付，則取消交易請求並通知對應的用戶及商店。在一實施例中，在第一時間點以外的其他分期時間點(非接收到交易請求時的時間點)向支付路徑選擇器206發送支付請求時，於步驟S505若支付不成功，則分期控制模組204依據用戶資料模組中設定的自動選擇邏輯選擇下一個最適合的支付方法，並依據下一個支付方法再次向支付路徑選擇器206發送支付請求(步驟S507)以便完成當期支付。於步驟S505及步驟S508，若支付成功，則完成當期支付(步驟S506)並且設定下一個收款的分期時間點，直到所有款項皆付清。在一實施例中，若用戶要求更改分期期數或提前部份或全部清償，分期控制模組204相應修改其後的分期時間點，使發送支付請求的時間點相應改變。若用戶要求手動變更部份或全部的支付方法，分期控制模組204修改其後的分期時間點的支付請求，使發送的支付請求之支付方法改變。在一實施例中，若交易請求中具有延後付款指示，分期控制模組204依據延後付款指示設定延後付款時間點並啟動計時器。當計時器到達收款的時間點，分期控制模組204向支付路徑選擇器206發送支付請求以便完成支付。在一些實施例中，交易請求中可能同時具有分期付款及延後付款指示，即，分期時間點中的第一時間點不是接收到交易請求時。

可選的，在一些實施例中，動態支付選擇方法還包括步驟S509。於步驟S508，若在第一時間點以外的其他分期時間點(非接收到交易請求時的時間點)用戶資料庫中對應的用戶綁定的支付方法之每一者皆無法支付成功，則啟動催收控制模組205的功能，以進行催收(步驟S509)。同時參考圖6，圖6是依據本發明一實施例的催收流程圖。詳細而言，催收控制模組205依照用戶資料庫中用戶設定的通知方式發送通知給用戶，以及依照商店資料庫中商店設定的通知方式發送通知給商店(步驟S601)。接著，催收控制模組205依據失敗的支付請求的時間點重新設定下一個再次發動該期款項的催收支付請求的時間點(步驟S602)，並且計算延遲利息及滯納金(步驟S603)。於步驟S604，依據該期應繳款項、延遲利息及滯納金設定催收支付請求。於步驟S605，當到達催收的時間點，催收控制模組205向支付路徑選擇器206發送催收支付請求(步驟S606)以便完成當期支付。

在一些實施例中，動態支付選擇系統100更包括支付閘道器208、210及防火牆207、209。支付路徑選擇器206與支付閘道器208之間具有防火牆207，而支付路徑選擇器206與支付閘道器210之間具有防火牆209。支付路徑選擇器206經由防火牆207、209及支付閘道器208、210耦接銀行或支付業者300，以便完成支付。在圖1中示出兩個支付閘道器208及210，然而，在其他實施例中，動態支付選擇系統100可以包括一個或大於兩個的支付閘道器，各個支付閘道器與支付路徑選擇器206之間具有防火牆。支付閘道器為介接銀行或發卡機構之服務，由於不同支付媒介(例如，不同卡片、不同卡種、不同第三方支付業者、不同電支業者、不同金流業者等)提供服務之串接協定不同，支付閘道器可以為多個。支付閘道器之基本服務均為交易控制、商店管理及帳務清算等。支付閘道器使用API憑證做為服務之入口保護，只要API憑證不符合加密規則，或不屬於註冊商家留存的API憑證，此支付請求不會執行。同時，API憑證可用於識別該商店是否為支付業者服務之對象。

同時參考圖7，圖7是依據本發明一實施例的執行支付的流程圖。於步驟S701，支付路徑選擇器206接收到交易控制模組201發送的支付請求。於步驟S702，依據用戶設定選擇優先支付方法。接著，於步驟S703，選擇可用的支付閘道器。於步驟S704，設定商店API憑證。於步驟S705，確定所選的支付閘道器是否接受API憑證。若所選的支付閘道器接受API憑證，則經由防火牆向支付閘道器發送支付請求封包。

經由支付路徑選擇器發出的支付請求封包，到達支付業者提供的支付閘道器前，因為經過實體網路路徑，通常是網際網路環境，因而需要予以保護。於本案的實施例中，藉由使用防火牆及加密之API憑證，達到保護的目的，只要支付請求封包來源不符合安全規則，或API憑證不符合安全規則，或不屬於註冊商家留存的API憑證，此支付請求封包不會執行。同時參考圖8，圖8是依據本發明一實施例的防火牆運作的流程圖。圖8進一步說明防火牆運作的流程，藉由防火牆執行步驟S801至S806。於步驟S801，防火牆接收到支付請求封包後，檢查支付請求封包來源，並於步驟S802檢查是否符合來源安全規則。若符合來源安全規則，則於步驟S803檢查目的地的支付閘道器安全規則。於步驟S804，若符合安全規則，則返回檢查通過。若不符合來源安全規則或不符合目的地的支付閘道器安全規則，則返回檢查不通過。

繼續參考圖7，若防火牆檢查通過，則防火牆傳送該支付請求封包至目的地的支付閘道器(步驟S708)。接著，同時參考圖9，圖9說明依據本發明一實施例的支付閘道器運作的流程圖。在接收交易請求封包之後，藉由支付閘道器執行步驟S901至908。於步驟S901，檢查商店API憑證密碼。於步驟S902，若商店API憑證密碼符合加密規則，則至步驟S903檢查商店API憑證。於步驟S904，若商店API憑證為所屬商店，則至步驟S905檢查支付請求參數。於步驟S906，若確認可以完成支付交易，則至步驟S907執行支付並返回完成支付。若商店API憑證密碼不符合加密規則，或商店API憑證不是所屬商店，或執行支付失敗，則返回支付不成功。

回到圖7，若支付閘道器不接受API憑證，或防火牆檢查不通過，或支付閘道器支付不成功，則至步驟S710，選擇下一個可用的支付閘道器。於步驟S711，若有可用的支付閘道器，則回到步驟S704，藉由選擇的下一個支付閘道器執行支付。於步驟S712，若已經沒有可用的支付閘道器，則返回支付不成功，並回到圖5的步驟S507選擇下一個支付方法並再次發送支付請求。於步驟S709，若支付閘道器完成支付，則返回完成支付(步驟S713)，並回到圖5的步驟S506完成當期支付。

需注意，圖7至圖9所示的經由支付路徑選擇器、防火牆及支付閘道器執行支付的流程，可應用於一次付清的支付請求、延後付款的支付請求、分期付款的支付請求及催收支付請求。換言之，當支付路徑選擇器206接收到交易控制模組201、分期控制模組204或催收控制模組的支付請求時，皆可執行圖7至圖9所述的流程，以完成支付。

依據上述，藉由本案提供的動態支付選擇系統，當交易控制模組處理交易請求時，依據交易特性，參考用戶資料模組、商店資料模組的支付方法資料，組合計算後，配合分期控制模組，催收控制模組的流程，產生出一系列的支付請求，然後交由支付路徑選擇器，依據實際介接的支付業者，也就是支付閘道器的運行情況，選擇出最佳的支付路徑。支付路徑必須驗證商店之支付API憑證，因為一個商店不同時間點可以在多個支付業者註冊，也可以設定不同的支付條件，因此支付路徑選擇器可以依照動態的設定，選擇對商店請求支付的最佳的支付路徑。

經由支付路徑選擇器發出的支付請求封包，到達支付業者提供的支付閘道器前，因為經過實體網路路徑，通常是網際網路環境，因此必須予以保護，使用防火牆及加密之API憑證，可以達到保護的目的，只要支付請求來源不符合安全規則，或目的地不符合安全規則，則加以阻擋封包行進。

支付請求到達支付閘道器時，由於不同支付媒介，提供服務之串接協定不同，支付閘道器首先驗證API憑證，只要API憑證不符合加密規則，或不屬於註冊商家留存的API憑證，此支付請求不會執行。同時API憑證可用於識別該商店是否為支付業者服務之對象。當支付路徑選擇器經由防火牆發送支付請求時，雖然已經確定該商店屬於該支付業者的支付閘道器，但是因為多個商店可以在多個支付閘道器上註冊，而支付路徑選擇器又可以隨時依照用戶意願或其他演算法自由選擇支付閘道器，因此該支付閘道器只能依照該筆支付請求進行清算。如果支付閘道器在支付請求到達時無法運行，支付路徑選擇器可以另外尋找合適可用的支付閘道器。因此使用API憑證作為商店識別的依據，可以將不同的支付請求自由選擇最適合的支付閘道器，使各支付閘道器各自清算自己的支付請求，而使本案的動態支付選擇系統提供之服務更彈性多元。

藉由本發明提供的動態支付選擇系統及方法，能夠同時解決上述消費者與商家面臨的問題，在消費者與支付業者間架起一座橋樑，可以幫助消費者在支付時將帳款靈活拆分，自由選擇支付方法，或由系統選擇最有利方式，制定分期支付時程，還可以隨時改變支付方法及時間，帶給消費者非常大的便利性與安全性。另一方面，對於商店，可以提供商店更多元的收款方式，更靈活運用應收帳款的財務調配。

為了使本領域技術人員更容易理解本發明，以下提供一些範例。應當理解，以下提供的範例僅是舉例說明，不應依此限定本發明。 範例一

用戶終端U001使用本系統，想在商店S001買貨品G001，使用三期分期付款，第一期7天後付款，其餘期數每隔十天付款，從Web伺服器傳送一個交易T001至交易控制模組，T001封包如下：

TxID	T001
UserID	U001
ShopID	S001
GoodsID	G001
Installment	3
Initial	7
Period	10

交易控制模組向用戶資料模組要求讀取該用戶U001的資料如下：

UserID	U001
Name	user-1
Card-1	C001
Bank-1	B001
Payment-1	P001
Payment-2	P002
LateFee	200

交易控制模組向商店資料模組讀取該商店S001的資料如下：

ShopID	S001
Payment-1-Key	K001
Payment-2-Key	K002
GoodsID	G001
Price	1000
Payment-1	P001
Discount-1	90%
Interest-1	8%
Payment-2	P002
Discount-2	88%
Interest-2	12%

交易控制模組比對後發現用戶U001綁定P001及P002兩種支付方式，商店S001也提供P001及P002兩種支付方式，因此各單試算P001及P002的支付方式，包含折扣、分期以單利利息計算： P001=1000*90%*(1+8%*(7+10+10)/365)=906 P002=1000*88%*(1+12%*(7+10+10)/365)=888

試算結果P002支付方式較划算，因此交易控制模組向分期控制模組要求產生三個P002支付請求，因為都是延後付款，分期控制模組分別會在D+7，D+17，D+27三天向支付路徑選擇器發動支付請求：

RequestID	P002-1
PaymentID	P002
Payment-Key	K002
Date	D+7
Amount	296
PayBy	Card1

RequestID	P002-2
PaymentID	P002
Payment-Key	K002
Date	D+17
Amount	296
PayBy	Card1

RequestID	P002-2
PaymentID	P002
Payment-Key	K002
Date	D+27
Amount	296
PayBy	Card1

範例二

如範例一之情境，但該交易沒有要求分期：

TxID	T001
UserID	U001
ShopID	S001
GoodsID	G001

交易控制模組直接產生一個P002支付請求，並且立即向支付路徑選擇器發動支付請求：

RequestID	P002-1
PaymentID	P002
Payment-Key	K002
Date	NOW
Amount	880

範例三

如範例一之情境，當分期控制模組向支付路徑選擇器發動P002-2支付請求時，P002支付閘道器無法連線，但商店S001可以支援P001收款，因此支付路徑選擇器將修改P002-2支付請求，另外向P001支付閘道器發動支付請求。

RequestID	P002-2
PaymentID	P001
Payment-Key	K001
Date	D+17
Amount	296
PayBy	Card1

範例四

如範例一之情境，當分期控制模組向支付路徑選擇器發動P002-3支付請求時，P002支付閘道器回應支付不成功，原因可能是額度不足，但用戶U001允許使用其他綁定支付方法銀行帳戶扣款Bank1，因此支付路徑選擇器將修改P002-3支付請求成為P002-3-1，繼續向支付閘道器發動支付請求。

RequestID	P002-3-1
PaymentID	P002
Payment-Key	K002
Date	D+27
Amount	296
PayBy	Bank1

範例五

如範例四之情境，當分期控制模組向支付路徑選擇器發動P002-3-1支付請求時，P002支付閘道器回應支付不成功，原因可能是餘額不足，但用戶U001己經沒有其他支付方式，因此支付路徑選擇器要求催收控制模組將P002-2支付請求延後兩天，加上滯納金後，繼續向支付閘道器發動支付請求P002-3-2。

RequestID	P002-3-2
PaymentID	P002
Payment-Key	K002
Date	D+17+2
Amount	296
PayBy	Card1
LateFee	200

範例六

如範例一之情境，在D+10日時用戶U001決定要將餘下款項全部付清，交易控制模組將產生P004支付請求，金額修改為餘下全部未付總額，向P002支付閘道器發動支付請求，支付成功後要求分期控制模組清除P002-2及P002-3支付請求。

RequestID	P004
PaymentID	P002
Payment-Key	K002
Date	D+10
Amount	592
PayBy	Card1

範例七

如範例一之情境，在D+10日時用戶U001決定要將第二期款項改由銀行帳戶Bank1支付，付款日期不變，將第三期款項改由銀行帳戶Bank1支付，付款日期改為D+30，調整付款金額加上延長利息，交易控制模組要求分期控制模組將P003-2及P003-3支付請求，修改為新的支付方法，分期控制模組重新排程向P002支付閘道器發動支付請求。

RequestID	P003-2
PaymentID	P002
Payment-Key	K002
Date	D+17
Amount	296
PayBy	Bank1

RequestID	P003-3
PaymentID	P002
Payment-Key	K002
Date	D+30
Amount	308
PayBy	Bank1

以上說明是執行本發明之最佳模式。本發明所屬技術領域中具有通常知識者應能知悉在不脫離本發明的精神和架構的前提下，當可作些許更動、替換和置換。本發明之權利範圍當視所附之申請專利範圍而定。

100:動態支付選擇系統 101:使用者終端 102:使用者終端 104:網際網路 105:Web伺服器 201:交易控制模組 202:用戶資料模組 203:商店資料模組 204:分期控制模組 205:催收控制模組 206:支付路徑選擇器 207:防火牆 208:支付閘道器 209:防火牆 210:支付閘道器 300:銀行或支付業者 S201~S212:步驟 S301~S308:步驟 S401~S409:步驟 S501~S509:步驟 S601~S606:步驟 S701~S713:步驟 S801~S806:步驟 S901~S908:步驟

[圖1]是依據本發明一實施例的動態支付選擇系統示意圖； [圖2]是依據本發明一實施例的動態支付選擇方法流程圖； [圖3]是依據本發明一實施例的新建用戶資料的流程圖； [圖4]是依據本發明一實施例的新建商店資料的流程圖； [圖5]是依據本發明一實施例的分期付款的流程圖； [圖6]是依據本發明一實施例的催收流程圖； [圖7]是依據本發明一實施例的執行支付的流程圖； [圖8]是依據本發明一實施例的防火牆運作的流程圖；以及 [圖9]是依據本發明一實施例的支付閘道器運作的流程圖。

100:動態支付選擇系統 101:使用者終端 102:使用者終端 104:網際網路 105:Web伺服器 201:交易控制模組 202:用戶資料模組 203:商店資料模組 204:分期控制模組 205:催收控制模組 206:支付路徑選擇器 207:防火牆 208:支付閘道器 209:防火牆 210:支付閘道器 300:銀行或支付業者

Claims (20)

1. 一種動態支付選擇系統，包括：交易控制模組，架構用於接收來自使用者終端的交易請求，該交易請求包括用戶識別碼及商店識別碼；用戶資料模組，連接該交易控制模組且包括用戶資料庫，儲存有用戶資料及用戶綁定的支付方法；商店資料模組，連接該交易控制模組且包括商店資料庫，儲存有商店資料及商店接受的支付方法；以及支付路徑選擇器，連接該交易控制模組，其中，該交易控制模組依據該用戶識別碼及該商店識別碼獲取該用戶資料庫中對應的用戶綁定的支付方法及該商店資料庫中對應的商店接受的支付方法，並依據獲取的該用戶綁定的支付方法及該商店接受的支付方法選擇支付方法，進而依據選擇的該支付方法產生支付請求以發送到該支付路徑選擇器，該支付路徑選擇器在接收到該支付請求之後，選擇對應的支付閘道器以便完成支付，其中，該支付路徑選擇器在接收到該支付請求之後，設定商店API憑證，並確定所選的支付閘道器是否接受該商店API憑證，若所選的該支付閘道器接受該商店API憑證，則經由防火牆向該支付閘道器發送支付請求封包以便完成支付。
2. 如請求項1之動態支付選擇系統，更包括分期控制模組，連接該交易控制模組， 其中，當該交易請求具有分期付款指示時，該分期控制模組依據分期期數設定分期費用及複數個分期時間點，並且在設定的該複數個分期時間點向該支付路徑選擇器發送支付請求以便完成當期支付。
3. 如請求項2之動態支付選擇系統，其中，該複數個分期時間點中的第一時間點為接收到該交易請求時，其中，若該第一時間點之支付不成功，則該分期控制模組依據用戶手動選擇或該用戶資料模組中設定的自動選擇邏輯選擇下一個支付方法，並依據該下一個支付方法再次發送支付請求到該支付路徑選擇器，並且其中，若該用戶要求中斷該交易請求或該用戶資料庫中對應的該用戶綁定的支付方法之每一者皆無法完成支付，則取消該交易請求。
4. 如請求項3之動態支付選擇系統，其中，在該第一時間點以外的該複數個分期時間點向該支付路徑選擇器發送支付請求時，若支付不成功，則該分期控制模組依據該用戶資料模組中設定的該自動選擇邏輯選擇下一個支付方法，並依據該下一個支付方法再次發送支付請求到該支付路徑選擇器。
5. 如請求項4之動態支付選擇系統，更包括催收控制模組，連接該交易控制模組，其中，在該第一時間點以外的該複數個分期時間點向該支付路徑選擇器發送支付請求時，若該用戶資料庫中對 應的該用戶綁定的支付方法之每一者皆無法完成支付，則發送通知至該交易請求對應的用戶及商店，並且設定再次發送支付請求的時間點，以及計算延遲利息。
6. 如請求項1之動態支付選擇系統，其中，該使用者終端是電腦、智慧型手機、智慧型電視或具有連網功能的裝置。
7. 如請求項1之動態支付選擇系統，該用戶綁定的支付方法包括信用卡支付、銀行帳戶支付及電子支付之至少一者。
8. 如請求項1之動態支付選擇系統，其中，該交易控制模組接收該交易請求之後，確定該用戶識別碼是否為新用戶，若該用戶識別碼為新用戶，則啟動該用戶資料模組新建用戶資料。
9. 如請求項1至8中任一項之動態支付選擇系統，更包括該支付閘道器，連接該支付路徑選擇器，其中，該支付閘道器為複數個，該支付路徑選擇器在接收到該支付請求之後，選擇該複數個支付閘道器之一者執行支付，若該複數個支付閘道器之該一者執行支付失敗，則該支付路徑選擇器選擇該複數個支付閘道器之另一者執行支付。
10. 如請求項9之動態支付選擇系統，其中，該複數個支付路徑選擇器之每一者與該支付閘道器之間具有防火牆。
11. 一種動態支付選擇方法，藉由計算裝置執行，包括以下步驟：接收來自使用者終端的交易請求，該交易請求包括用戶識別碼及商店識別碼；依據該用戶識別碼從用戶資料庫獲取用戶綁定的支付方法；依據該商店識別碼從商店資料庫獲取商店接受的支付方法；依據獲取的該用戶綁定的支付方法及該商店接受的支付方法選擇支付方法，進而依據選擇的該支付方法產生支付請求；依據該支付請求，選擇對應的支付閘道器，設定商店API憑證，並確定所選的支付閘道器是否接受該商店API憑證，若所選的該支付閘道器接受該商店API憑證，則經由防火牆向該支付閘道器發送支付請求封包以便完成支付。
12. 如請求項11之動態支付選擇方法，其中，該交易請求更包括分期付款指示，該方法更包括：在接收該交易請求之後，依據該分期付款指示中的分期期數設定分期費用及複數個分期時間點，並且在設定的該複數個分期時間點產生支付請求以便完成當期支付。
13. 如請求項12之動態支付選擇方法，其中，該複數個分期時間點中的第一時間點為接收到該交易請求時， 其中，若該第一時間點之支付不成功，則依據用戶手動選擇或該用戶資料庫中設定的自動選擇邏輯選擇下一個支付方法，並依據該下一個支付方法再次產生支付請求，並且其中，若該用戶要求中斷該交易請求或該用戶資料庫中對應的該用戶綁定的支付方法之每一者皆無法完成支付，則取消該交易請求。
14. 如請求項13之動態支付選擇方法，其中，在該第一時間點以外的該複數個分期時間點產生支付請求時，若支付不成功，則依據該用戶資料庫中設定的自動選擇邏輯選擇下一個支付方法，並依據該下一個支付方法再次產生支付請求以便完成支付。
15. 如請求項14之動態支付選擇方法，更包括：在該第一時間點以外的該複數個分期時間點產生支付請求以便完成支付，若該用戶資料庫中對應的該用戶綁定的支付方法之每一者皆無法完成支付，則發送通知至該交易請求對應的用戶及商店，並且設定再次發送支付請求的時間點，以及計算延遲利息。
16. 如請求項11之動態支付選擇方法，其中，該用戶綁定的支付方法包括信用卡支付、銀行帳戶支付及電子支付之至少一種。
17. 如請求項11之動態支付選擇方法，更包括： 在接收該交易請求之後，確定該用戶識別碼是否為新用戶，若該用戶識別碼為新用戶，則新建用戶資料，包括：接收用戶輸入個人資料；核實該用戶的個人身份；設定該用戶對應的用戶綁定的支付方法；以及設定該用戶的交易選項。
18. 如請求項11之動態支付選擇方法，更包括：在接收該交易請求之後，確定該商店識別碼是否為新商店，若該商店識別碼為新商店，則新建商店資料，包括：接收商店資料；核實該商店的負責人身份；設定該商店對應的商店接受的支付方法；綁訂支付API憑證；以及設定該商店的支付選項。
19. 如請求項11至18中任一項之動態支付選擇方法，其中，該依據該支付請求，選擇對應的支付閘道器以便完成支付更包括：向所選的支付閘道器發送支付請求封包，藉由該支付閘道器執行以下步驟：檢查商店API憑證密碼；檢查該商店API憑證； 檢查支付請求參數；以及執行支付，若執行支付失敗，則返回支付不成功。
20. 如請求項19之動態支付選擇方法，其中，該依據該支付請求，選擇對應的支付閘道器以便完成支付更包括：經由防火牆向該支付閘道器發送該支付請求封包，藉由該防火牆執行以下步驟：檢查該支付請求封包來源；檢查目的地的該支付閘道器安全規則，若符合安全規則，則傳送該支付請求封包至該支付閘道器，若不符合安全規則，則返回支付不成功。

Images