專利名稱：用于處理電子支付交易的方法和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及用于處理電子交易的系統(tǒng)和方法，更具體地涉及用于接收、 處理和傳送電子支付交易信息的系統(tǒng)和方法。
背景技術(shù)：
商家在從事商品和/或服務(wù)的銷售過程中通常接受來自消費(fèi)者的各種 形式的支付。這些交易中的一些交易包括現(xiàn)金、支票、借記卡、信用卡等 支付。這些支付形式中的許多支付形式本質(zhì)上是電子支付(例如信用卡、借記卡、電子支票支付、儲值卡、忠誠點(diǎn)償還(loyalty points redemptions)、電子權(quán)益轉(zhuǎn)移)并且為消費(fèi)者提供某些便利。例如，當(dāng)電子支付被接受時，消費(fèi) 者不必確定他們是否隨身帶有足量現(xiàn)金，他們經(jīng)常不必立即將資金轉(zhuǎn)賬給 商家，而且有時可以利用賒購線購買商品或服務(wù)。這種電子支付的提供也使商家受益。例如，通過給消費(fèi)者提供支付選 項(xiàng)組，商家通常會發(fā)現(xiàn)銷售增加。然而，這樣的電子支付系統(tǒng)具有各種不足。例如，位于商家駐地的電 子支付系統(tǒng)對于可以與這種系統(tǒng)交互的終端類型具有限制。典型地，商家 駐地具有一個或多個中央計(jì)算機(jī)或服務(wù)器，它們支持在商家處使用的電子 支付終端。僅可以使用那些配置成與商家計(jì)算機(jī)或服務(wù)器交互的終端。一 個解決方案是擁有多個計(jì)算服務(wù)器或計(jì)算機(jī)，但是這樣的系統(tǒng)可能昂貴和 臃腫。另一解決方案是在商家駐地希望使用新終端時，連續(xù)地修改服務(wù)器或 計(jì)算機(jī)。然而，這樣的解決方案可能要求對商家計(jì)算機(jī)軟件和硬件的大量 維護(hù)。此外，電子支付系統(tǒng)典型地經(jīng)由撥號調(diào)制解調(diào)器進(jìn)行通信。這樣的系
統(tǒng)對于消費(fèi)者和商家是不便的，因?yàn)榻灰卓赡苷加瞄L時間才能完成，對消 費(fèi)者和商家造成延遲。此外，這種系統(tǒng)不支持向通過電子支付系統(tǒng)傳遞的 數(shù)據(jù)提供增強(qiáng)安全性的某些加密技術(shù)。此外，如果商家希望利用眾多電子 支付終端來支持交易，則使用撥號調(diào)制解調(diào)器需要使用多個電話線。同樣，將許多電子終端配置成使得與結(jié)算過程有關(guān)的交易數(shù)據(jù)由這樣 的終端存儲而且僅成批地發(fā)送到商家服務(wù)器。當(dāng)實(shí)行結(jié)算過程時，這樣的 設(shè)置造成延遲。發(fā)明內(nèi)容本發(fā)明涉及用于處理交易的系統(tǒng)和方法，以及更具體地涉及一種克服 上述缺點(diǎn)的用于接收、處理和傳輸電子支付交易信息的系統(tǒng)和方法。該系 統(tǒng)和方法訪問交易軟件引擎，該引擎實(shí)行對電子支付請求的授權(quán)和對授權(quán) 的電子支付的結(jié)算。根據(jù)本發(fā)明實(shí)施例，交易軟件引擎駐留于商家駐地， 并且更具體地駐留在與一個或多個網(wǎng)絡(luò)終端通信的商家服務(wù)器或計(jì)算機(jī) 內(nèi)。利用這樣的系統(tǒng)，關(guān)于某些交易(例如授權(quán)、結(jié)算等)的數(shù)據(jù)由終端發(fā)送 到軟件引擎。典型地，當(dāng)進(jìn)行電子支付請求時，授權(quán)請求得到處理。根據(jù) 本發(fā)明實(shí)施例，由商家的終端存儲結(jié)算請求直至預(yù)定時間為止，然后在逐 筆交易的基礎(chǔ)上將每個請求從引擎?zhèn)鬏數(shù)綌?shù)據(jù)交易主機(jī)用于處理。此外，軟件引擎使得能夠通過互聯(lián)網(wǎng)傳輸數(shù)據(jù)。結(jié)果，與僅僅使用傳 統(tǒng)電話線相比較，縮短了處理支付授權(quán)和結(jié)算的時間。此外，交易軟件引擎能夠接受格式有變化的數(shù)據(jù)且能夠?qū)@樣的數(shù)據(jù) 重新編碼，從而可由交易軟件引擎處理該數(shù)據(jù)。結(jié)果，交易軟件引擎可以 處理從各種終端接收的和發(fā)送到各種終端的數(shù)據(jù)以及發(fā)送到各種數(shù)據(jù)交易 提供商主機(jī)的和從各種數(shù)據(jù)交易提供商主機(jī)接收的數(shù)據(jù)。


根據(jù)與示出本發(fā)明說明性實(shí)施例的附圖相結(jié)合進(jìn)行的以下具體描述，
本發(fā)明的更多目的、特征和優(yōu)點(diǎn)將變得明顯，在附圖中圖1是根據(jù)本發(fā)明實(shí)施例的電子支付交易系統(tǒng)的方框圖；圖2是根據(jù)本發(fā)明另一實(shí)施例的電子支付交易系統(tǒng)的方框圖；圖3是根據(jù)本發(fā)明實(shí)施例在處理電子支付交易的交易軟件引擎之內(nèi)結(jié)合的模塊的方框圖；圖4圖示了根據(jù)本發(fā)明實(shí)施例在處理電子支付交易時駐存的數(shù)據(jù)字段；圖5是圖示了根據(jù)本發(fā)明實(shí)施例授權(quán)電子支付請求的方法的流程圖；以及圖6是圖示了根據(jù)本發(fā)明實(shí)施例結(jié)算電子交易的方法的流程圖。
具體實(shí)施方式
本發(fā)明涉及用于處理交易的系統(tǒng)和方法，且更具體地涉及用于接收、 處理和傳輸電子支付交易信息的系統(tǒng)和方法。該系統(tǒng)和方法訪問交易軟件 引擎，該引擎實(shí)行對電子支付請求的授權(quán)及對授權(quán)的電子支付的結(jié)算。根 據(jù)本發(fā)明實(shí)施例，交易軟件引擎駐留于商家駐地，并且更具體地駐留在與 一個或多個網(wǎng)絡(luò)或串行終端通信的商家服務(wù)器或計(jì)算機(jī)內(nèi)。利用這樣的系 統(tǒng)，當(dāng)發(fā)生每個交易(與成批發(fā)送的一組交易相對照)時，關(guān)于某些交易(例 如授權(quán)、結(jié)算等)的數(shù)據(jù)可由終端發(fā)送到軟件引擎。此外，軟件引擎使得能夠通過互聯(lián)網(wǎng)傳輸數(shù)據(jù)。結(jié)果，與僅使用傳統(tǒng) 電話線相比較，縮短了處理支付授權(quán)和結(jié)算的時間。此外，交易軟件引擎能接受格式有變化的數(shù)據(jù)且對這樣的數(shù)據(jù)重新編 碼，從而可由交易軟件引擎處理該數(shù)據(jù)。結(jié)果，交易軟件引擎可以處理從 各種終端接收的和發(fā)送到各種終端的數(shù)據(jù)以及發(fā)送到各種數(shù)據(jù)交易提供商 主機(jī)的和從各種數(shù)據(jù)交易提供商主機(jī)接收的數(shù)據(jù)。系統(tǒng)
圖1是圖示了結(jié)合本發(fā)明特征的電子支付交易系統(tǒng)10的方框圖。系統(tǒng) IO特別地通過支持商家(如商家100)與支付處理器(如數(shù)據(jù)交易提供商140) 之間的通信來處理對電子支付交易的授權(quán)和對這種交易的結(jié)算。如圖1中 所示，在這樣的處理中可以涉及到各種實(shí)體。例如，系統(tǒng)10通過公共網(wǎng)絡(luò) (如互聯(lián)網(wǎng)120)和例如第三方互聯(lián)網(wǎng)協(xié)議網(wǎng)絡(luò)(IPN)13來實(shí)現(xiàn)商家100與數(shù) 據(jù)交易提供商140之間的通信。在一個實(shí)施例中，IPN130可由數(shù)據(jù)線通信 網(wǎng)絡(luò)的交易傳送網(wǎng)絡(luò)(Datawire Communication Network's Transaction Delivery Network)提供。商家100是對電子支付交易的授權(quán)和/或結(jié)算進(jìn)行請求的任何個人或?qū)?體。應(yīng)該注意，在此使用的術(shù)語"支付"可包括涉及資金支付或資金賒購的交易。典型地，商家ioo具有用于處理電子支付請求的一個或多個信用/借記卡處理終端。例如在圖1中，商家100具有與商家服務(wù)器110通信的 數(shù)個終端102-1至102-N。在圖1中，終端102-1至102-N通過串行連接來 連接到商家服務(wù)器110，因此這些終端稱為"串行終端"。串行終端102的 例子是Verifone的TRANZ型號380。例如，當(dāng)由例如串行終端102-1產(chǎn)生電子支付交易請求時，數(shù)據(jù)包經(jīng) 由串行連接從終端102發(fā)送到商家服務(wù)器110。商家服務(wù)器110包括至少下 述組件中央處理單元112、交易軟件引擎111和互聯(lián)網(wǎng)路由器113。CPU 112可具體化為單個商用處理器?？蛇x地，在另一實(shí)施例中，CPU 112可具體化為并行操作的許多這樣的處理器。交易軟件引擎111可操作用來存儲下面結(jié)合圖3-6進(jìn)一步討論的一個 或多個指令，CPU112可操作用以取回、解譯和執(zhí)行該指令。例如，如下 所述，引擎111優(yōu)選地存儲用于授權(quán)和結(jié)算電子支付的過程。CPU 112優(yōu)選地以公知的方式包括控制單元、算術(shù)邏輯單元(ALU)以及 CPU本地存儲器存儲設(shè)備，如例如可堆疊的高速緩存或多個寄存器。控制 單元可操作用來從交易軟件引擎111取回指令。ALU可操作用來執(zhí)行為了 實(shí)現(xiàn)指令而需要的多個操作。CPU本地存儲器存儲設(shè)備可操作用來提供用 于存儲臨時結(jié)果和控制信息的高速存儲?；ヂ?lián)網(wǎng)路由器113將商家服務(wù)器110連接到互聯(lián)網(wǎng)120，并且可以例 如是D-Link路由器機(jī)型DI704。此外，商家服務(wù)器110還可經(jīng)由撥號調(diào)制 解調(diào)器(未示出)連接到主機(jī)142-1至142-N。根據(jù)本發(fā)明實(shí)施例，缺省地經(jīng) 由互聯(lián)網(wǎng)110和IPN 130，嘗試商家服務(wù)器110與主機(jī)142之間的通信。因 此在這種情況下，僅當(dāng)無法通過專用網(wǎng)絡(luò)130建立通信時才使用交易商家 服務(wù)器110與主機(jī)142之間的撥號調(diào)制解調(diào)器通信。如下面更全面討論的，將數(shù)據(jù)交易提供商主機(jī)142-1至142-N特別地 配置用于接收對處理電子支付交易的請求、確定所請求的電子支付交易的 類型、授權(quán)或拒絕電子支付交易、以及結(jié)算交易。數(shù)據(jù)交易提供商主機(jī)142-1 至142-N配置成處理常規(guī)信用卡和借記卡交易、電子支票、贈卡等。圖2是圖示了根據(jù)本發(fā)明實(shí)施例的電子支付交易系統(tǒng)20的方框圖。支 付交易系統(tǒng)20與系統(tǒng)10類似之處在于商家(例如商家IOI)與數(shù)據(jù)交易提 供商140的主機(jī)142通信——經(jīng)由互聯(lián)網(wǎng)120和EPN 130，但是系統(tǒng)20提 供了終端與商家服務(wù)器之間的傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議(TCP/IP)連接。因 此，如圖2中所示，系統(tǒng)20支持TCP終端103-1至103-N與商家服務(wù)器 110經(jīng)由以太網(wǎng)交換機(jī)104的通信。TCP終端103的例子是Omni 3750。與 系統(tǒng)10的商家服務(wù)器100相似，系統(tǒng)20的商家服務(wù)器110包括交易軟件 引擎lll、 CPU112和互聯(lián)網(wǎng)路由器113。交易軟件引擎除了其它內(nèi)容外，交易軟件引擎111還可操作用來存儲用于授權(quán)和結(jié) 算電子支付的指令，如下所述。根據(jù)本發(fā)明實(shí)施例，交易軟件引擎lll能 通過訪問由引擎111所例示的一個或多個交易模塊來提供這樣的指令。這 樣的模塊在圖3中示出而且包括工作項(xiàng)目模塊302、包分解器模塊304、 接收器模塊306、發(fā)送器模塊308、格式產(chǎn)生器模塊310、 NBDot格式化模 塊312、 DBDot格式化模塊314、授權(quán)處理模塊316、結(jié)算處理模塊318、
命令處理模塊320、 IPN傳送器模塊322及撥號傳送器模塊324?，F(xiàn)在下文 參照圖3來描述這些模塊。下面參考圖5和6來描述通過使用引擎111的 模塊302至324的授權(quán)和結(jié)算電子支付交易的過程。應(yīng)該注意，DBDot、 NBDot和SVDot是數(shù)據(jù)格式類型，這些數(shù)據(jù)格式 類型包括下面參考圖4描述的而且由一個或多個主機(jī)142-1至142-N處理的 一個或多個數(shù)據(jù)字段。這些數(shù)據(jù)格式典型地在由相應(yīng)的格式類型所包括的 數(shù)據(jù)字段的長度和/或次序方面有所不同，而且在一些實(shí)例中可包括在授權(quán) 和結(jié)算處理時有用的附加信息。參考圖3，工作項(xiàng)目模塊302負(fù)責(zé)臨時地存儲由商家服務(wù)器110從例 如串行終端102、 TCP終端103或主機(jī)142接收的數(shù)據(jù)。臨時地存儲數(shù)據(jù)從 而引擎111可以通過圖3中所示的一個或多個其他模塊處理數(shù)據(jù)。每當(dāng)終 端設(shè)備102或103建立與交易軟件引擎111的通信話路時，訪問工作項(xiàng)目 模塊302。因此，每當(dāng)數(shù)據(jù)發(fā)送到引擎lll，工作項(xiàng)目由工作項(xiàng)目模塊302 建立，而且通過訪問其它模塊來實(shí)現(xiàn)這種數(shù)據(jù)的處理。包分解器302確定與接收的數(shù)據(jù)相聯(lián)系的請求類型。因此，包分解器 302確定是否所接收的數(shù)據(jù)涉及對支付授權(quán)的請求、結(jié)算請求或命令。應(yīng)該注意，術(shù)語"授權(quán)"是指由數(shù)據(jù)交易提供商140批準(zhǔn)為商家100 或101驗(yàn)證交易。這樣的授權(quán)例如指明當(dāng)請求授權(quán)時購買者信用限度的可 用性或者指明消費(fèi)者賬號的有效性。"結(jié)算"是指從銷售交易、現(xiàn)金支出、 商品賒購獲得的財(cái)務(wù)數(shù)據(jù)的交換過程，這些銷售交易、現(xiàn)金支出、商品賒 購最終被記賬到進(jìn)行電子支付的購買者的賬戶。"命令"是控制交易軟件 引擎lll的指令，而且可包括終止一個或多個通信的"停止"命令、恢復(fù) 系統(tǒng)10或20的數(shù)據(jù)流的"開始"命令、關(guān)斷引擎lll的"斷電"、開啟 引擎lll的"通電"等。接收器模塊306使得能夠處理從交易軟件引擎111接收的數(shù)據(jù)。這些 設(shè)備包括串行終端102-至102-N、 TCP終端103-1至103-N或主機(jī)142-1至 142-N。然而，發(fā)送器模塊308使得能夠處理由交易軟件引擎111如串行終 端102-至102-N、 TCP終端103-1至103-N或主機(jī)142-1至142-N接收的數(shù) 據(jù)。由接收器模塊306和發(fā)送器模塊308分別地處理流入和流出的信息流， 有助于實(shí)施對引擎111的維護(hù)和增強(qiáng)。將內(nèi)置計(jì)時器結(jié)合到模塊306和308中，從而由系統(tǒng)10或20進(jìn)行的 通信可在通信故障情況下終止。根據(jù)本發(fā)明的一個實(shí)施例，將時間設(shè)置到 60秒。格式產(chǎn)生器310標(biāo)識對所接收的數(shù)據(jù)加以格式化的方式。根據(jù)本發(fā)明 實(shí)施例，指定用于由交易軟件引擎111接收和處理的數(shù)據(jù)的格式是由針對 該交易而作為目標(biāo)的主機(jī)142來規(guī)定。因此，格式產(chǎn)生器310確定哪個主 機(jī)142被指定用來處理交易并且識別由這樣的主機(jī)142支持的數(shù)據(jù)格式。 確定哪個主機(jī)142被指定用來處理交易，是通過讀取在用于數(shù)據(jù)格式(例如 NBDot、 SVDot等)和目標(biāo)主機(jī)的包標(biāo)題中存儲的數(shù)據(jù)來實(shí)現(xiàn)的，該目標(biāo)主 機(jī)被指定用于處理這種數(shù)據(jù)格式。因此，通過這種方式，當(dāng)接收來自終端 102或103的數(shù)據(jù)時，引擎111確定所接收的數(shù)據(jù)是否為例如NBDot、 DBDOT、 SVDot或一些其它的數(shù)據(jù)格式類型。 一旦識別所接收的數(shù)據(jù)的數(shù) 據(jù)格式，則格式產(chǎn)生器識別要訪問的適當(dāng)格式化程序以處理所接收的數(shù)據(jù)。 圖3中所示的格式化程序模塊的兩個實(shí)例是NBDot格式化模塊312和 DBDot格式化模塊314，不過當(dāng)然可以針對交易軟件引擎111提供附加的 格式化模塊，從而當(dāng)主機(jī)142-1至142-N要求時，可由引擎111支持附加的 數(shù)據(jù)格式。格式化模塊312和314接收典型地以流中的包的形式來接收的數(shù)據(jù)， 并且基于包的字段來解析這樣的包。下面參考圖4，說明根據(jù)本發(fā)明實(shí)施例 可包含于通信數(shù)據(jù)包中而且由格式化模塊312和314使用的字段的列表。授權(quán)處理模塊316負(fù)責(zé)處理授權(quán)請求。授權(quán)模塊處理程序316產(chǎn)生用 于與授權(quán)有關(guān)的數(shù)據(jù)包的包標(biāo)題。這樣的標(biāo)題特別地包括標(biāo)識信息，該信 息用于將包標(biāo)識為攜帶有用于授權(quán)請求的數(shù)據(jù)。此外，授權(quán)處理模塊316 將授權(quán)請求數(shù)據(jù)委托給適當(dāng)?shù)膫魉推?見下面對IPN傳送器模塊322和撥號
傳送器模塊324的描述)。結(jié)算處理模塊318負(fù)責(zé)處理結(jié)算請求。結(jié)算處理模塊318產(chǎn)生用于與 結(jié)算請求有關(guān)的數(shù)據(jù)包的包標(biāo)題。這樣的標(biāo)題特別地包括標(biāo)識信息，該信 息用于將包標(biāo)識為攜帶有結(jié)算請求的數(shù)據(jù)。此外，結(jié)算處理模塊318將授 權(quán)請求數(shù)據(jù)委托給適當(dāng)?shù)膫魉推?見下面對IPN傳送器模塊322和撥號傳送 器模塊324的描述)。命令處理模塊320處理從用于控制交易軟件引擎111的遠(yuǎn)程計(jì)算機(jī)接 收的數(shù)據(jù)。此模塊解析并執(zhí)行命令，這些命令允許對交易軟件引擎lll的 遠(yuǎn)程控制。因此，如果商家希望從例如遠(yuǎn)程計(jì)算機(jī)發(fā)出停止或開始交易軟 件引擎111的命令，則從這樣的計(jì)算機(jī)發(fā)出的命令由引擎111的處理程序 320檢測和處理。IPN傳送器模塊322提供經(jīng)過互聯(lián)網(wǎng)發(fā)送和接收數(shù)據(jù)包的格式化，并 且撥號傳送器模塊324提供使用撥號調(diào)制解調(diào)器發(fā)送和接收數(shù)據(jù)包的格式 化。根據(jù)本發(fā)明實(shí)施例，所用的數(shù)據(jù)格式是基于XML的包格式。NBDot數(shù)據(jù)字段圖4圖示了如下字段，這些字段被結(jié)合到由系統(tǒng)10和20處理以便處 理授權(quán)和結(jié)算請求的數(shù)據(jù)包中。當(dāng)數(shù)據(jù)包在如圖1和2中所示的各種設(shè)備 之間傳送時，這些字段存儲與請求有關(guān)的信息，或者該字段保持為空。在 本發(fā)明的另一實(shí)施例， 一個或多個字段可存儲空(null)數(shù)據(jù)(如數(shù)字O)而不是 空的，從而每個字段存儲相關(guān)數(shù)據(jù)或空數(shù)據(jù)。由系統(tǒng)10和20使用的數(shù)據(jù)包中結(jié)合的字段如下商家號字段402、 終端序號字段404、消息類型標(biāo)識符字段406、賬號字段408、有效日期字 段410、軌道-2數(shù)據(jù)字段412、軌道-1數(shù)據(jù)字段414、交易量字段416、交 易號41S、交易日期字段420、交易時間字段422或錯誤消息段424。商家號字段402是指由數(shù)據(jù)交易供應(yīng)商140分別為接入到系統(tǒng)10、 20 的每個商家IOO、 101所分配的唯一商家號。終端序號404是指如下唯一終 端號，該終端號由每個終端102-1至102-N及103-1至103N存儲并且每當(dāng) 數(shù)據(jù)包傳輸?shù)揭?11時提供給引擎111以指明所傳輸?shù)臄?shù)據(jù)包的源。消息類型標(biāo)識符字段406標(biāo)識通過系統(tǒng)10或20傳輸?shù)南㈩愋?。?息類型可包括授權(quán)(即從終端102或103到引擎111或從引擎111到主機(jī) 142的授權(quán)請求)、授權(quán)響應(yīng)(即從主機(jī)142到引擎111或從引擎111到終端 102或103的授權(quán)響應(yīng))、結(jié)算(即從終端102或103到引擎111或從引擎111 到主機(jī)142的結(jié)算請求)、結(jié)算響應(yīng)(即從主機(jī)142到引擎111的結(jié)算響應(yīng))、 關(guān)閉話路(即終止話路的請求)、關(guān)閉話路響應(yīng)(即對終止話路請求的確認(rèn))。賬號字段408是指要從其中轉(zhuǎn)賬資金以實(shí)行電子支付賬戶的標(biāo)識號 的。有效日期字段410是指電子支付卡(例如信用卡、借記卡、贈卡)要到期 的曰期。軌道1字段412和軌道2字段414包括在用戶信用卡、借記卡、贈卡 等的磁條上存儲的信息。根據(jù)本發(fā)明的實(shí)施例，軌道1字段是79字節(jié)且包 括帳號、有效日期、姓名和任意數(shù)據(jù)。根據(jù)本發(fā)明實(shí)施例，軌道2字段414 長度為40字節(jié)且包括帳號、有效日期和與用戶卡有關(guān)聯(lián)的任意號。交易量字段416是指在已經(jīng)為之進(jìn)行授權(quán)或結(jié)算請求的電子支付中涉 及的資金量。交易號字段418是指用來識別由系統(tǒng)10和20處理的每個交 易的唯一標(biāo)識符。交易日期字段420和交易時間字段422分別指代由系統(tǒng)10和20處理 每個電子支付交易的日期和時間。錯誤消息字段424存儲如下信息，該信息包含當(dāng)一個或多個錯誤發(fā)生 時傳送到商家100、 101的一個或多個錯誤通知。根據(jù)本發(fā)明的實(shí)施例，交 易軟件引擎將錯誤消息存儲于終端102或103所期待的同一數(shù)據(jù)包內(nèi)部的 錯誤消息字段424中，因此終端可以自動地顯示所接收的錯誤消息。也可使用其它格式類型，如DBDot或SVDot。 DBDot或SVDot使用 了與上面參照NBDot所述相同的許多數(shù)據(jù)字段。這些數(shù)據(jù)格式可以在相應(yīng) 類型所包括的數(shù)據(jù)字段的長度和/或次序方面有所不同，而且在一些實(shí)例中
可包括在授權(quán)和結(jié)算處理中有用的附加信息。
授權(quán)請求
當(dāng)實(shí)行電子支付時，商家100或101典型地將涉及采購的相關(guān)交易信息(例如商家標(biāo)識信息、消費(fèi)者標(biāo)識信息、消費(fèi)者賬戶信息、支付類型、交易量、日期、時間)輸入到電子支付處理終端如串行終端102或TCP/IP終端 103中。這可以通過例如對包含消費(fèi)者標(biāo)識信息、消費(fèi)者賬戶信息的卡進(jìn)行 刷卡以及通過位于終端102或103的鍵盤輸入交易量來實(shí)現(xiàn)。剩余的信息 可自動地由終端102或103產(chǎn)生。
然后載入所輸入的信息，由此允許商家100或101進(jìn)行授權(quán)支付交易 的請求。如上所述，該授權(quán)過程實(shí)現(xiàn)了數(shù)據(jù)交易提供商140的批準(zhǔn)以驗(yàn)證 對于商家100或101的交易。此驗(yàn)證例如確保在請求授權(quán)時購買者賒購限 度的可用性、所提供的賬戶數(shù)據(jù)有效等。
圖5是圖示了根據(jù)本發(fā)明實(shí)施例執(zhí)行授權(quán)請求的過程的流程圖。分別 地繼續(xù)參考圖1和2的系統(tǒng)10和20以及圖3的軟件模塊來描述這樣的過 程。
在步驟505，交易軟件引擎lll的工作項(xiàng)目模塊302接收授權(quán)數(shù)據(jù)包, 該數(shù)據(jù)包包括與在商家100或101發(fā)生的交易有關(guān)的數(shù)據(jù)。授權(quán)數(shù)據(jù)駐存 有數(shù)據(jù)包的至少如下字段商家號402、終端序號404、消息類型標(biāo)識符 406(在這一實(shí)例中表示了消息類型涉及授權(quán)請求)、帳號408、有效日期410、 交易量416、交易號418、交易日期420和交易時間422。
接著，在步驟510，格式產(chǎn)生器模塊310分析經(jīng)格式化的授權(quán)包以確 定委托主機(jī)142-1至142-N中的哪個主機(jī)接收該授權(quán)請求。一旦確定目標(biāo)主 機(jī)，格式產(chǎn)生器模塊310將授權(quán)數(shù)據(jù)包傳輸?shù)脚c目標(biāo)主機(jī)142相聯(lián)系的格 式化程序，從而授權(quán)數(shù)據(jù)包可由目標(biāo)主機(jī)142讀取并處理。因此，數(shù)據(jù)包 從格式產(chǎn)生器模塊310轉(zhuǎn)發(fā)到NBDot格式化程序312或DBDot格式化程序 314(或由交易軟件引擎111所例示的且與主機(jī)142-1至142-N中的一個或多
個主機(jī)相聯(lián)系的一些其它格式化程序)。在步驟515，格式化程序312或314(依賴于目標(biāo)主機(jī)數(shù)據(jù)格式化要求) 對接收的授權(quán)數(shù)據(jù)包的標(biāo)題編碼以便傳輸?shù)侥繕?biāo)主機(jī)142。在這樣做時，授 權(quán)處理模塊316選擇IPN傳送器模塊322(如果數(shù)據(jù)包經(jīng)由IPN 130傳輸)或 者撥號傳送器模塊324(如果數(shù)據(jù)包經(jīng)由撥號調(diào)制解調(diào)器傳輸)。根據(jù)本發(fā)明 實(shí)施例，缺省地經(jīng)由IPN 130嘗試引擎111與主機(jī)142之間的數(shù)據(jù)包通信。 因此，在這種情況下，當(dāng)無法由專用網(wǎng)絡(luò)130建立通信時才使用交易軟件 引擎111與主機(jī)142之間的撥號調(diào)制解調(diào)器通信。根據(jù)本發(fā)明實(shí)施例，將 標(biāo)題編碼成可擴(kuò)展標(biāo)記語言(XML)，這是一種有助于交換結(jié)構(gòu)化數(shù)據(jù)的公 知標(biāo)記語言。此外，根據(jù)本發(fā)明實(shí)施例，利用安全套接層(SSL)協(xié)議，通過 互聯(lián)網(wǎng)120在交易軟件引擎111與主機(jī)142之間傳送XML格式化的數(shù)據(jù)包。 SSL是以加密形式通過互聯(lián)網(wǎng)傳輸通信的公知協(xié)議。SSL確保信息不變地 僅發(fā)送到商家100或101所預(yù)定的主機(jī)。在交易軟件引擎111將授權(quán)請求發(fā)送到主機(jī)142(在步驟515)之后，引 擎111然后等待來自主機(jī)142的響應(yīng)。根據(jù)本發(fā)明實(shí)施例，該響應(yīng)也是XML 語言。 一旦接收響應(yīng)，在步驟520，引擎111對經(jīng)由IPN130從主機(jī)142接 收的響應(yīng)進(jìn)行解碼，然后將響應(yīng)轉(zhuǎn)發(fā)到終端102或103(步驟525)。該授權(quán) 響應(yīng)典型地是以交易接受或拒絕的形式。 一旦分別在商家100或101的終 端102或103接收該授權(quán)響應(yīng)，則向這樣的商家通知了如由終端102或103 提供的授權(quán)響應(yīng)，并且授權(quán)請求過程完成。應(yīng)當(dāng)注意，用于處理串行終端102的授權(quán)響應(yīng)的方法與用于處理TCP 終端103的授權(quán)響應(yīng)的方法相比是很相似的。然而，對于TCP終端103而 言，連接和斷開步驟典型地由系統(tǒng)20提供。當(dāng)終端103初始地接收用于傳 輸?shù)杰浖鎙ll的交易數(shù)據(jù)時，終端103打開TCP/IP插座，而且利用所 配置的IP地址連接到引擎lll。類似地，在授權(quán)請求被處理之后，引擎lll 發(fā)送信號以關(guān)閉引擎111與終端103之間的連接。結(jié)算請求然后由系統(tǒng)10和20對授權(quán)的交易進(jìn)行結(jié)算。根據(jù)本發(fā)明實(shí)施例，一 旦交易被授權(quán)，則將這種交易的結(jié)算所需要的數(shù)據(jù)傳送到交易軟件引擎 111。引擎111被配置用來為在預(yù)定時段一例如對于直至午夜為止的給定 一天期間發(fā)生的交易存儲授權(quán)數(shù)據(jù)，并且當(dāng)滿足這樣的預(yù)定時段時，引擎 111從終端102和103接收結(jié)算數(shù)據(jù)，然后引擎111針對在那一時段中發(fā)生 的交易在逐筆交易的基礎(chǔ)上將數(shù)據(jù)傳輸?shù)街鳈C(jī)142。因此，每個授權(quán)請求可 經(jīng)由互聯(lián)網(wǎng)120和IPN 130由引擎111作為其自己的請求發(fā)送到主機(jī)142。 即使逐筆交易的請求中的多個請求例如可能在給定時間由主機(jī)142傳輸和/ 或處理也仍然如此。如上所述，結(jié)算過程是指交換從銷售交易、現(xiàn)金支出或商品賒購獲得 的財(cái)務(wù)數(shù)據(jù)的過程，這些銷售交易、現(xiàn)金支出或商品賒購最終被記賬到進(jìn) 行電子支付的購買者的賬戶。圖6是圖示了根據(jù)本發(fā)明實(shí)施例執(zhí)行結(jié)算請求的過程的流程圖。分別 地繼續(xù)參考圖1 、2的系統(tǒng)10和20以及圖3的軟件模塊來描述這樣的過程。在步驟605，交易軟件引擎lll的工作項(xiàng)目模塊302接收結(jié)算數(shù)據(jù)包， 該數(shù)據(jù)包包括與在商家100或101發(fā)生的交易有關(guān)的數(shù)據(jù)。結(jié)算數(shù)據(jù)駐存 有要結(jié)算的用于每次傳輸?shù)臄?shù)據(jù)包的至少以下字段商家號402、終端序號 404、消息類型標(biāo)識符406(在這個實(shí)例中指明了消息類型涉及結(jié)算請求)、 賬號408、有效日期401、交易量416、交易號418、交易日期420和交易 時間422。接著，在步驟610，格式產(chǎn)生器模塊310分析經(jīng)格式化的結(jié)算包以確 定委托主機(jī)142-1至412-N中的哪個主機(jī)接收結(jié)算請求。一旦確定目標(biāo)主機(jī)， 格式產(chǎn)生器模塊310將結(jié)算數(shù)據(jù)包傳送到與目標(biāo)主機(jī)142相聯(lián)系的格式化 程序，從而結(jié)算數(shù)據(jù)包可以由目標(biāo)主機(jī)142讀取和處理。因此，數(shù)據(jù)包從 格式產(chǎn)生器模塊310轉(zhuǎn)發(fā)到DBDot格式化程序312或DBDot格式化程序 314(或由交易軟件引擎111存儲的而且與主機(jī)142-1至142-N中的一個或多 個主機(jī)相聯(lián)系的一些其它格式化程序)。接著，在步驟615，交易軟件引擎111將結(jié)算啟動請求傳輸?shù)街鳈C(jī)142， 并且在步驟620，引擎111等待接收從主機(jī)142返回的啟動響應(yīng)。一旦發(fā)生這樣的啟動握手，則在步驟625，傳送器322或324對接收 的結(jié)算數(shù)據(jù)包的標(biāo)題進(jìn)行編碼以便傳輸?shù)侥繕?biāo)主機(jī)142。在這樣做時，結(jié)算 處理模塊318選擇IPN傳送器模塊322(如果數(shù)據(jù)包經(jīng)由IPN 130傳輸)或者 撥號傳送器模塊324(如果數(shù)據(jù)包經(jīng)由撥號調(diào)制解調(diào)器傳輸)。根據(jù)本發(fā)明實(shí) 施例，缺省地經(jīng)由IPN 130，嘗試引擎110至主機(jī)142之間的數(shù)據(jù)包通信。 因此，在這種情況下，僅當(dāng)無法通過專用網(wǎng)絡(luò)130建立通信時才使用交易 軟件引擎111與主機(jī)142之間的撥號調(diào)制解調(diào)器通信。根據(jù)本發(fā)明實(shí)施例，將標(biāo)題編碼成XML。此外，根據(jù)本發(fā)明，利用 SSL協(xié)議，通過互聯(lián)網(wǎng)120在交易軟件引擎111與主機(jī)142之間傳送XML 格式化的數(shù)據(jù)包，以確保信息不變化地僅發(fā)送到商家100或101預(yù)定的主 機(jī)。在交易軟件引擎111向主機(jī)142發(fā)送結(jié)算請求(在步驟625)之后，弓l擎 111然后等待經(jīng)由IPN 139的來自主機(jī)142的響應(yīng)。根據(jù)本發(fā)明實(shí)施例，響 應(yīng)也是XML語言。 一旦接收該響應(yīng)，則在步驟630，引擎lll然后向終端 102或103發(fā)送包標(biāo)題響應(yīng)(步驟635)，請求已發(fā)送到主機(jī)142的結(jié)算信息(前 面所述)。交易軟件引擎111然后從終端是02和103接收結(jié)算細(xì)節(jié)(步驟640)。 結(jié)算細(xì)節(jié)然后在格式產(chǎn)生器模塊310的指令下被編碼而且發(fā)送到目標(biāo)主機(jī) 142(步驟645)。 一旦整批結(jié)算數(shù)據(jù)由主機(jī)142接收和處理，則引擎111接 收一指明了結(jié)算數(shù)據(jù)包結(jié)束的結(jié)算包報尾(步驟650)。此報尾然后由引擎 111轉(zhuǎn)發(fā)到終端102或l(B(步驟655)，然后結(jié)算話路終止請求被發(fā)送到主 機(jī)142(步驟660)，指明了結(jié)算過程的結(jié)束。應(yīng)該注意，用于處理串行終端102的結(jié)算請求的方法與用于處理TCP 終端103的結(jié)算請求的方法相比是很相似的。然而，對于TCP終端103， 連接和斷開步驟典型地由系統(tǒng)20提供。因此，當(dāng)終端103初始地接收用于 傳輸?shù)浇灰总浖?11的交易數(shù)據(jù)時，終端103打開TCP/IP插座并且利用所配置的IP地址連接到引擎lll。類似地，在結(jié)算請求被處理之后，引擎111發(fā)送信號以關(guān)閉引擎111與終端103之間的連接。上文僅說明了本發(fā)明的原理。因此將理解到本領(lǐng)域技術(shù)人員將能夠構(gòu) 思眾多其它設(shè)置，這些設(shè)置具體化了本發(fā)明的原理，因此在本發(fā)明的精神 和范圍之內(nèi)。例如，雖然在此描述的電子支付處理終端是Tranz 3800和Omni 3750， 但是可使用其它類型的終端。此外，這些設(shè)備到商家服務(wù)器110的連接除 了可以是Ethernet或TCP/IP以夕卜，還可以是具有USB連接性的WI-FI集線 器、無線連接等。
權(quán)利要求
1. 一種用于處理電子支付交易的方法，包括從支付終端接收對于處理電子支付交易的請求，該請求包括格式類型; 確定該請求的格式類型；識別被配置用來處理所確定的格式類型的主機(jī)計(jì)算機(jī)；以及 將該請求傳輸?shù)剿R別的主機(jī)計(jì)算機(jī)。
2. 權(quán)利要求1的方法，還包括從所識別的主機(jī)接收指明該請求是否被批準(zhǔn)的通知。
3. 權(quán)利要求1的方法，還包括從所識別的主機(jī)接收指明該請求是否包含錯誤消息的通知。
4. 權(quán)利要求2的方法，還包括 將該通知發(fā)送到該支付終端。
5. 權(quán)利要求3的方法，還包括 將該通知發(fā)送到該支付終端。
6. 權(quán)利要求1的方法，其中該請求包括具有標(biāo)題信息的數(shù)據(jù)包。
7. 權(quán)利要求6的方法，還包括對該標(biāo)題信息加以編碼以使得能夠在 該支付終端與該主機(jī)計(jì)算機(jī)之間傳送該請求。
8. 權(quán)利要求7的方法，其中利用可擴(kuò)展標(biāo)記語言對該標(biāo)題信息進(jìn)行編碼。
9. 權(quán)利要求1的方法，其中對于處理電子支付交易的該請求涉及交易授權(quán)。
10. 權(quán)利要求1的方法，其中對于處理電子支付交易的該請求涉及交易結(jié)算。
11.—種用于結(jié)算多個電子支付的方法，包括從終端請求涉及多個電子支付結(jié)算的信息；接收具有用于所述多個電子支付中每個支付的結(jié)算信息的至少一個相應(yīng)數(shù)據(jù)包； 確定每個相應(yīng)數(shù)據(jù)包的格式類型；識別被配置用來對每個相應(yīng)數(shù)據(jù)包的所確定的格式類型進(jìn)行處理的主 機(jī)計(jì)算機(jī)；以及將每個相應(yīng)數(shù)據(jù)包傳輸?shù)剿R別的主機(jī)計(jì)算機(jī)，其中所識別的主機(jī)計(jì) 算機(jī)被配置用來處理所述每個相應(yīng)數(shù)據(jù)包的格式類型。
12. 權(quán)利要求11的方法，還包括從所識別的主機(jī)接收指明該結(jié)算是否被處理的通知。
13. 權(quán)利要求11的方法，還包括從所識別的主機(jī)接收指明該結(jié)算是否產(chǎn)生錯誤消息的通知。
14. 權(quán)利要求12的方法，還包括 將該通知發(fā)送到該支付終端。
15. 權(quán)利要求13的方法，還包括 將該通知發(fā)送到該支付終端。
16. 權(quán)利要求11的方法，其中該請求包括具有標(biāo)題信息的數(shù)據(jù)包。
17. 權(quán)利要求16的方法，還包括對該標(biāo)題信息進(jìn)行編碼以使得能夠 在該支付終端與該主機(jī)計(jì)算機(jī)之間傳送該請求。
18. 權(quán)利要求17的方法，其中利用可擴(kuò)展標(biāo)記語言對該標(biāo)題信息進(jìn)行編碼。
19. 一種用于處理電子支付交易的系統(tǒng)，包括接口，用于從支付終端接收對于處理電子支付交易的請求，該請求包括格式類型；以及處理器，用于確定該請求的格式類型；識別被配置用來處理所確定的格式類型的主機(jī)計(jì)算機(jī)；以及 將該請求傳輸?shù)剿R別的主機(jī)計(jì)算機(jī)。
20. 權(quán)利要求19的系統(tǒng)，其中該處理器還被配置用來從所識別的主機(jī) 接收指明該請求是否被批準(zhǔn)的通知。
21. 權(quán)利要求19的系統(tǒng)，其中該接口還被配置用來從所識別的主機(jī)接 收指明該請求是否包含錯誤消息的通知。
22. 權(quán)利要求20的系統(tǒng)，其中該處理器還被配置用來向該支付終端發(fā) 送該通知。
23. 權(quán)利要求21的系統(tǒng)，其中該處理器還被配置用來向該支付終端發(fā) 送該通知。
24. 權(quán)利要求19的系統(tǒng)，其中該請求包括具有標(biāo)題信息的數(shù)據(jù)包。
25. 權(quán)利要求24的系統(tǒng)，其中該處理器還被配置用來對該標(biāo)題信息進(jìn) 行編碼以使得能夠在該支付終端與該主機(jī)計(jì)算機(jī)之間傳送該請求。
26. 權(quán)利要求25的系統(tǒng)，其中該標(biāo)題信息利用可擴(kuò)展標(biāo)記語言來編碼。
27. 權(quán)利要求19的系統(tǒng)，其中對于處理電子支付交易的該請求涉及交 易授權(quán)。
28. 權(quán)利要求19的系統(tǒng)，其中對于處理電子支付交易的該請求涉及交易結(jié)算o
29. —種用于結(jié)算多個電子支付的系統(tǒng)，包括接口，用于接收具有用于所述多個電子支付中每個支付的結(jié)算信息的至少一個相應(yīng)數(shù)據(jù)包；以及處理器，用于確定每個相應(yīng)數(shù)據(jù)包的格式類型；識別被配置用來對每個相應(yīng)數(shù)據(jù)包的所確定的格式類型進(jìn)行處理的主機(jī)計(jì)算機(jī)；以及將每個相應(yīng)數(shù)據(jù)包傳輸?shù)剿R別的主機(jī)計(jì)算機(jī)，其中所標(biāo)識的主 機(jī)計(jì)算機(jī)被配置用來處理所述每個相應(yīng)數(shù)據(jù)包的格式類型。
30. 權(quán)利要求29的系統(tǒng)，其中該接口還被配置用來從所識別的主機(jī)接 收指明該結(jié)算是否被處理的通知。
31. 權(quán)利要求29的系統(tǒng)，其中該接口還被配置用來從所識別的主機(jī)接 收指明該結(jié)算是否產(chǎn)生錯誤消息的通知。
32. 權(quán)利要求30的系統(tǒng)，其中該處理器還被配置用來向該支付終端發(fā) 送該通知。
33. 權(quán)利要求31的系統(tǒng)，其中該處理器還被配置用來向該支付終端發(fā) 送該通知。
34. 權(quán)利要求29的系統(tǒng)，其中該請求包括具有標(biāo)題信息的數(shù)據(jù)包。
35. 權(quán)利要求34的系統(tǒng)，其中該處理器還被配置用來對該標(biāo)題信息進(jìn) 行編碼以使得能夠在該支付終端與該主機(jī)計(jì)算機(jī)之間傳送該請求。
36. 權(quán)利要求35的系統(tǒng)，其中該標(biāo)題信息利用可擴(kuò)展標(biāo)記語言來編碼。
37. 權(quán)利要求29的系統(tǒng)，其中對于處理電子支付交易的該請求通過串 行連接從該支付終端接收。
38. 權(quán)利要求29的系統(tǒng)，其中對于處理電子支付交易的該請求通過互 聯(lián)網(wǎng)協(xié)議連接從該支付終端接收。
39. 權(quán)利要求38的系統(tǒng)，其中該互聯(lián)網(wǎng)協(xié)議連接包括TCP/IP連接。
40. 權(quán)利要求19的系統(tǒng)，其中該處理器通過該互聯(lián)網(wǎng)將該請求傳輸?shù)?該主機(jī)計(jì)算機(jī)。
41. 權(quán)利要求19的系統(tǒng)，其中該處理器通過調(diào)制解調(diào)器將該請求傳輸 到該主機(jī)計(jì)算機(jī)。
全文摘要
提供用于處理交易的系統(tǒng)和方法，更具體地是用于接收、處理和傳輸電子支付交易信息的系統(tǒng)和方法。該系統(tǒng)和方法訪問交易軟件引擎，該引擎實(shí)行對電子支付請求的授權(quán)和對授權(quán)的電子支付的結(jié)算。根據(jù)本發(fā)明實(shí)施例，交易軟件引擎駐留于商家駐地，并且更具體地駐留在與一個或多個網(wǎng)絡(luò)終端通信的商家服務(wù)器或計(jì)算機(jī)之內(nèi)。利用這樣的系統(tǒng)，當(dāng)每個交易出現(xiàn)時，可由終端發(fā)送授權(quán)請求。雖然交易是在逐筆交易的基礎(chǔ)上處理的，但是在預(yù)定時間之后處理成批的結(jié)算請求。此外，軟件引擎使得能夠通過互聯(lián)網(wǎng)進(jìn)行傳輸。結(jié)果，與僅使用傳統(tǒng)電話線相比較，處理支付授權(quán)和結(jié)算的時間量有所減少。此外，交易軟件引擎能夠接受格式有變化的數(shù)據(jù)并且對這樣的數(shù)據(jù)重新編碼，從而可以由交易軟件引擎處理該數(shù)據(jù)。結(jié)果，交易軟件引擎可以處理從多種終端接收的和發(fā)送到多種終端的數(shù)據(jù)以及發(fā)送到多種數(shù)據(jù)交易提供商主機(jī)的和從多種數(shù)據(jù)交易提供商主機(jī)接收的數(shù)據(jù)。
文檔編號G06Q40/00GK101124603SQ200580008058
公開日2008年2月13日 申請日期2005年2月15日 優(yōu)先權(quán)日2004年3月12日
發(fā)明者特龍·恩古延, 邁克爾·帕勒莫, 道格拉斯·J·桑切斯 申請人:第一數(shù)據(jù)公司