用于增強型賬戶余額和狀態管理的交易系統及關聯的方法
【專利摘要】一種使用支付賬戶執行交易的計算機實施方法,通常由支付賬戶管理器(PAM)處理,該方法包括以下步驟:接收來自充值終端的第一消息,所述第一消息指示已經將資金轉移到支付賬戶;基于第一消息中的信息設置或調整支付賬戶的資金限度;接收來自第一終端的授權或預授權請求并且開始資金匯總;接收第二消息,所述第二消息指示在交易中能夠使用的資金的預定金額;凍結所述支付賬戶的等于預定金額的資金限度的金額;以及將授權響應發送到第一終端。結果,PAM可以發送數據以指示與支付賬戶關聯的卡不適于出行。在本發明的一個方面,交通授權能夠將繞過數據寫入到卡中以繞過拒絕列表,該拒絕列表原本會阻止將卡用于交通旅程。
【專利說明】
用于増強型賬戶余額和狀態管理的交易系統及關聯的方法
技術領域
[0001]本發明大體上但不完全地涉及預付費帳戶交易基礎設施,尤其是在使用即用即付功能的交通支付的背景下,但是它們的適用范圍還可以更廣。這樣的基礎設施主要是使得用戶能夠在負責管理賬戶的金融機構與另一第三方(諸如交通機構)之間同步賬戶余額和狀態,和/或將數據從第三方傳送到另一商業場所,該數據可被寫入卡中以隨后用于第三方的系統中。
【背景技術】
[0002]倫敦運輸局(TfL)經營著世界上最大的閉環預付費體系之一。據估計,截至2013年2月有5200萬張Oyster?卡在流通。
[0003]Oyster是專用的交通卡,該卡允許用戶在卡上存儲單程票、季票、預付費余額或這些內容的組合。該系統是以卡為中心的系統(在該系統中,該卡為該用戶最終保存正確的和當前的數據集合)。
[0004]當用戶將他們的Oyster卡刷在讀卡器/驗證器上時(“刷入”),讀卡器試圖在卡上建立有效產品并且從該位置為旅程選擇正確的產品。當使用預付費元素(被稱為Oyster即用即付(或僅為PAYG))時,讀卡器首先會查看卡上是否有足夠的資金來支付自該點起始的最低票價。如果有足夠的資金,則扣除最高票價(除了為固定票價的公交車和有軌電車之外)。扣除最高票價可能導致持卡人“透支”,但這充當一種刺激以使得持卡人總想要刷出。當退出交通網絡時(“刷出”),讀卡器將計算票價并且相應地更新卡上的余額。
[0005]2012年12月13日,TfL在他們的9000輛公交車上推出非接觸式支付,從而使得任何非接觸式卡都能夠執行待被用來支付單程公交票價的離線交易(即不需要在線上來進行交易授權)。發生的交易過程相當于標準離線零售支付的交易過程。在2014年初TfL旨在將該服務擴展到其他運輸模式,諸如鐵路、地鐵(地下鐵)、有軌電車和碼頭區輕軌,盡管這將使用不同的交易模式并且將額外支持需要在線授權的卡。
[0006]TfL正處于更新他們當前基礎設施的過程中,以使得可以使用任何非接觸式支付芯片卡在他們的公共運輸服務中進行支付。適當的交易模式將允許用戶在他們的標準發行信用卡/借記卡/預付費卡/簽賬卡上使用即用即付功能,而不是必須要有單獨的、專門發行的卡(諸如Oyster?卡)。
[0007]目前,季票只能以紙質票的形式或在Oyster?卡上使用。在較長的時期里,TfL在尋找將非接觸式支付卡與季票關聯起來。目前的系統需要在票或卡上存儲季票信息。將季票與非接觸式支付卡關聯起來將使得能夠在支付卡的外部管理這種信息,從而允許改善的且集中的信息管理。
[0008]最終,許多人期望這種技術取代現有的紙質票和Oyster?卡系統。但是,有一些用戶不使用銀行賬戶、不使用非接觸式支付卡或者不想使用直接關聯到他們的銀行賬戶的非接觸式卡。另外,還有一些有資格享受折扣或者免費出行的用戶,對他們來說銀行發行的卡可能是不適合的。
[0009]要做到這一點,為取代Oyster?卡系統而設計的任何新的交易模式最終將需要表現得至少與Oyster?卡系統(或在可以實施這種系統的任何其他城市中的任何等效系統)一樣好。目前存在Oyster?卡用戶可以管理不能被現有的非接觸式支付卡系統有效地處理的即用即付賬戶的一些方式。
[0010]例如,將他們的Oyster?卡余額使用到接近零的人們通常在檢票機處被拒絕進入,并且隨后在充值站用與他們的預期一趟旅程或多趟旅程的費用相等的金額對他們的Oyster?卡充值,該金額立即充到他們的卡上,然后他們行進通過檢票機。如以上更詳細描述的,僅必須可購得最低票價以能夠開始旅程,但是當用戶在終端刷入時會扣除最高票價。退出時,將計算票價并且更新余額。
[0011]目前的信用卡/借記卡/預付費卡/簽賬卡(以下簡稱“支付卡”)的即用即付交易模式無法匹配該功能。通過定期授權管理該風險,如果獲得批準,這將為交通機構(例如TfL)提供高達一定值(在英國交通機構諸如TfL的情況下為£20(截至2013年9月))的保護,如果卡發行機構批準該授權,他們將承擔高達該金額的所有交通支出的全部責任。對于將他們的賬戶余額使用到低于責任值(假設為£5)的用戶,發行機構很可能會拒絕交通授權,因為他們不希望承擔賠錢的風險。
[0012]但是,Oyster?卡將允許其賬戶中有£5的人們進行£ 1.40的旅程。相應地,目前的支付卡即用即付交易模式不提供與Oyster?卡系統相同的功能,并且因此將不會被視為對專門發行的交通卡的合適的替代,以便解決無銀行賬戶、那些銀行卡上沒有非接觸式功能或者選擇不使用他們的銀行發行的非接觸式卡的人們的需要。
[0013]目前的支付卡即用即付交易模式可以使用拒絕列表運行。該拒絕列表是因為多種原因而被阻止出行的卡的列表,這些原因包括資金不足、丟失或被盜的卡、重復逃票或工作人員濫用。TfL目前持有他們在整個倫敦的每個讀卡器中的拒絕列表。這些列表能夠被更新的速度受到交通機構的網絡架構的限制。列表更新可能需要花費長達半小時。
[0014]因此,當賬戶中資金不足的用戶嘗試使用他們的支付卡在讀卡器處進行支付并且隨后被列于拒絕列表上時,可能會出現問題。當用戶隨后已經將足夠的資金轉移到他們的支付卡關聯到的帳戶中時,直到讀卡器處的拒絕列表已被更新,他們才能夠進行旅程。此夕卜,通常需要用戶進行另外的動作來通知交通機構(諸如TfL)他們現在已經將資金增加到賬戶中并且他們想要從拒絕列表中刪除。此時,交通機構必須與用戶的卡發行機構進行核對,以核對將該卡從拒絕列表中刪除是確實可以的。如果發行機構同意這樣的批準,則(在TfL的情況下)可能花費長達半小時來更新拒絕列表,在此期間,用戶將無法使用運輸系統。
【發明內容】
[0015]根據本發明的第一方面,提供了一種使用支付帳戶執行交易的計算機實施方法,該方法包括以下步驟:接收來自充值終端的第一消息,該第一消息指示已經將資金轉移到支付賬戶;基于第一消息中的信息設置或調整支付賬戶的資金限度;接收來自第一終端的授權或預授權請求并且開始資金匯總;接收第二消息,該第二消息指示在交易中能夠使用的資金的預定金額;凍結所述支付賬戶的等于所述預定金額的資金限度的金額;以及將授權響應發送到第一終端。
[0016]可以通過支付帳戶管理器來執行該方法。
[0017]有利地,第一方面的方法使得能夠從支付帳戶的資金限度中凍結預定金額。在已知的系統中,授權一個標準額定金額,并且可以凍結基于卡體系的責任限制的金額一一該金額可能不以消息中發送的任何信息為基礎。
[0018]在一個實施方案中,也可以使用詳述支付賬戶中的任何現有資金的信息與第一消息中的信息一起用于設置或調整支付賬戶的資金限度。
[0019]在一個實施方案中,可能不存在第一消息,并且可以基于詳述支付賬戶中的任何現有資金的信息設置或調整支付賬戶的資金限度。
[0020]可以通過查詢支付賬戶獲得詳述支付賬戶中的任何現有資金的任何信息。
[0021]該方法還可以包括以下步驟:接收來自第二終端的第三消息,該第三消息指示所使用資金的實際金額;以及如果所使用資金的實際金額不同于預定金額,則調整所凍結的支付帳戶的資金限度的金額。
[0022]在一個實施方案中,第二終端可以是第一終端的一部分。
[0023]該方法還可以進一步包括或代替地進一步包括將指示資金限度的更新的未凍結金額的消息發送到第一終端的步驟。在這種情況下,只有當未被凍結的資金限度下降到閾值金額以下或上升到閾值金額以上時,才可以可選地發送指示資金限度的更新的、未被凍結的金額的消息。
[0024]在一個實施方案中,該方法還包括如果資金限度的未被凍結的金額小于所使用資金的最低可能實際金額,則將支付賬戶列于拒絕列表上的步驟。在該實施方案中,該方法還可以包括以下步驟:接收來自充值終端的第四消息,該第四消息指示已經將更多的資金轉移到支付賬戶;基于第四消息中的信息設置或調整支付賬戶的資金限度;以及如果支付賬戶的資金限度的未被凍結的金額超出所使用資金的最低可能實際金額,則從拒絕列表中刪除所述支付賬戶。可選地,該方法還包括在從拒絕列表中刪除支付賬戶之后繼續資金匯總的步驟。
[0025]在一個實施方案中,所述支付帳戶的資金限度是基于詳述支付賬戶中的任何現有資金的信息以及第一消息中的信息被設置的。
[0026]在一個實施方案中,資金限度的預定凍結金額等于在第一終端處使用的資金的實際金額的平均值或最高值或典型的最高值。
[0027]有利地,這意味著,該方法可以被優化以適合具體的標準。
[0028]在一個實施方案中,設置或調整資金限度的步驟還附加地考慮到先前可能已經支付到支付賬戶中的任何押金。
[0029]在一個實施方案中,該方法還包括發送資金匯總和結算任何剩余凍結資金的支付帳戶以及相應地調整資金限度的步驟。
[0030]將理解的是,在執行支付帳戶的任何結算之前可以接收多個消息(諸如第二消息)。
[0031 ]在一個實施方案中,授權或預授權請求以及第二消息包括單個消息。
[0032]根據本發明的第二方面,提供了一種處理支付賬戶上的資金的計算機實施方法,該方法包括以下步驟:接收來自第一終端的第一消息,該第一消息指示需要指定金額的資金;將第二消息發送到第一終端,該第二消息指示沒有可用的所需資金;接收來自充值終端的第三消息,該第三消息指示已經將資金增加到支付賬戶;以及將第四消息發送到第一終端,該第四消息指示在支付賬戶中現在有足夠資金;接收來自第一終端的數據;以及將該數據發送到充值終端以寫入到支付賬戶支付裝置。
[0033]可以通過支付帳戶管理器來執行該方法。
[0034]可以由與充值終端通信的交通后勤室提供該數據。
[0035]該數據可以包括拒絕列表繞過數據(bypassingdata)。在一個實施方案中,拒絕列表繞過數據可以使得支付賬戶支付裝置在指定時間內能夠繞過拒絕列表。
[0036]根據本發明的第三方面,提供了一種處理支付賬戶上的資金的計算機實施方法,該方法包括以下步驟:將第一消息發送到支付帳戶管理器(PAM),該第一消息指示需要指定金額的資金;接收來自PAM的第二消息,該第二消息指示沒有可用的所需資金;可選地經由PAM,接收來自充值終端的第三消息,該第三消息指示已經將資金增加到支付賬戶;建立拒絕列表繞過數據;以及可選地經由PAM,將拒絕列表繞過數據發送到充值終端,以寫入關聯到支付賬戶的支付設備。
[0037]可以通過交通機構基礎設施或實際上屬于任何其他適當類型的機構的基礎設施來執行該方法。
[0038]可以將除了僅是拒絕列表數據之外的數據寫入到支付設備。
[0039]根據本發明的第四方面,提供了一種處理支付賬戶上的資金的計算機實施方法,該方法包括以下步驟:接收來自第一終端的第一消息并且將該第一消息傳送到支付賬戶管理器(PAM),該第一消息指示需要指定金額的資金;接收來自PAM的第二消息并且將該第二消息傳送到第一終端,該第二消息指示沒有可用的所需資金;接收來自充值終端的第三消息并且將該第三消息傳送到PAM和/或第一終端,該第三消息指示已經將資金增加到支付賬戶;可選地接收來自PAM的第四消息并且將該第四消息傳送到第一終端,該第四消息指示現在有足夠的資金可用;接收來自第一終端的拒絕列表繞過數據,可選地將該拒絕列表繞過數據傳送到PAM;以及將該拒絕列表繞過數據傳送到充值終端,以在充值終端寫入關聯到支付賬戶的支付設備。
[0040]可以通過交通機構基礎設施或實際上屬于任何其他適當類型的機構的基礎設施來執行該方法。
[0041]可以將除了僅是拒絕列表數據之外的數據寫入到支付設備。
[0042]根據本發明的第五方面,提供了一種交易處理系統,該交易處理系統包括至少一個充值終端、至少一個第一終端以及至少一個處理器,所述至少一個處理器被配置成執行根據本發明的第一方面的方法。
[0043]可選地,所述至少一個處理器由支付賬戶管理器托管。
[0044]根據本發明的第六方面,提供了一種交易處理系統,該交易處理系統包括至少一個充值終端、至少一個第一終端以及至少一個處理器,所述至少一個處理器被配置成執行根據本發明的第三方面的方法。
[0045]根據本發明的第七方面,提供了一種支付賬戶管理器,所述支付賬戶管理器被配置成執行根據本發明的第二方面的方法。
【附圖說明】
[0046]現在將參照所附附圖僅通過示例方式描述本發明的實施方案,在附圖中:
[0047]圖1是示出了在用于交通應用的已知的支付卡即用即付交易模式中涉及的各方和它們如何交互的簡化版本的示意圖;
[0048]圖2是示出了根據本發明的示例性實施方案在用于交通應用的支付卡即用即付交易模式中涉及的各方的示意圖;
[0049]圖3是示出了已知系統(諸如圖1的系統,但更詳細)的各方的示意圖;
[0050]圖4是示出了根據本發明的示例性實施方案的系統(諸如圖2的系統,但更詳細)的示意圖;
[0051]圖5至24示出了根據本發明的示例性實施方案由PPAM經由中間網絡管理的充值終端、運輸支付終端、零售支付終端以及預付費賬戶之間的交互。
【具體實施方式】
[0052]本發明提供了防止上述情況的系統和計算機實施方法,上述情況即其中用戶無法進行旅行直到已經將他們從拒絕列表中刪除的情況,這可能發生在已知的支付卡即用即付交易模式中,以及其中用戶希望將他們的余額使用到接近為零的情況(例如,僅利用進行他們的旅行所需要的票價)。
[0053]應當注意的是,雖然附圖示出了運輸系統中系統的用途,但是不應認為這是本發明的唯一用途。例如,本發明可同樣地適用于忠實體系系統。
[0054]圖1是示出了在用于交通應用的已知的支付卡即用即付交易模式中涉及的各方以及它們如何交互的簡化版本的示意圖。圖1描繪了利用管理用戶(101)當前結算的和未結算的余額的預付費賬戶管理器(PPAM)102持有預付費賬戶的用戶101,包括全部屬于交通機構的由交通后勤室支持的交易基礎設施(包括支付終端和充值終端)并且管理拒絕列表的交通機構基礎設施(TAI) 103,以及負責(除了其他事情之外)票價計算的認知交通匯總器(aggregator) 103a。認知交通匯總器103a可以由交通后勤室管理并且可以由交通機構擁有且操作,或者認知交通匯總器103a可以由第三方提供者操作。
[0055]圖1示出用戶某一天在交通基礎設施103(即在非接觸式終端)如何第一次“刷入”(步驟I),在該情況下進行鐵路之旅。一旦在讀卡器或驗證器刷卡,則使用標準芯片卡技術對卡進行本地認證以便驗證該卡,并且確定該卡是否在拒絕列表上。還執行了零值交易。如果該卡驗證成功、零值交易成功并且卡不在拒絕列表上,則將允許用戶101開始他們的旅程。然后將與該刷卡關聯的數據發送到交通基礎設施103。一旦刷卡數據到達交通基礎設施103,認知交通匯總器103a將檢查刷卡數據并且確定是否需要初始授權。基于一組預定的以風險為基礎的規則,認知交通匯總器103a然后可以發起初始授權請求(步驟2)。該初始授權請求通常包括對于額定金額(如£0.10)的授權請求并且可能包括交易消息中的其他指示,使得PPAM 102(或實際上任何發行機構)可以清楚地將交易標識為交通“匯總”交易。該請求由TAI 103發送到PPAM 102oPPAM 102然后可以從用戶的賬戶凍結其承擔責任(未示出)的金額,例如£20,并且用發送回TAI 103的授權響應來作出響應(步驟3)。如果PPAM 102已經批準了該交易,則用戶101可以繼續持續旅行,但是如果PPAM 102拒絕該交易,則應該將用戶101增加到拒絕列表中(未示出)并且阻止用戶進行任何進一步的旅程,直到當他們已經將他們的賬戶重新恢復為良好信譽的時刻。
[0056]當用戶在他們的鐵路之旅結束時再次在TAI103“刷出”時(步驟4) ^TAI 103記錄旅程的費用。用戶101可以進行多次進一步的旅程,例如公交車之旅(步驟5),其被設置為固定價格并且僅需要單次刷卡,以及進一步的鐵路之旅(步驟6和7),這需要在旅程的開始刷入,接著一旦旅程已經完成則刷出。交通匯總器103a總計旅程的總金額。
[0057]典型地,在某一天結束時(S卩,某一天的最后可能旅程已經完成之后),進行結算處理(步驟8),其中從用戶的賬戶中扣除所有的結算費用(未示出)。結算處理也可同樣地在某一天中的任何時間點進行。在一些系統中一次授權(步驟2,步驟3)可以允許幾天內的多次結算(步驟8)也是可能的。這種系統是已知的,并且一些交通機構(諸如TfL)正計劃在不久的將來實施這種系統。
[0058]注意,在一些情況下,如果卡體系規則允許,可以在某一天繞過步驟2和3(例如,通過不是每天進行結算處理并且允許匯總持續多天的TAI 103,或者通過使得每單次授權能夠發生多次結算處理的TAI 103。在后一種情況下,將不時地需要隨后的風險管理授權)。
[0059]圖2是示出本發明的一個實施方案的示意圖。所涉及的各方與圖1中的那些相同。但是,在TAI 103與PPAM 102之間已經引入了增強的雙向通信。
[0060]步驟I至4類似于圖1的系統中發生的步驟。用戶某一天在交通基礎設施103的第一次“刷入”(步驟I)發起初始授權請求(步驟2),該請求由TAI 103發送到PPAM 102,但是,如圖1所示,只要用戶的卡是真實的并且用戶不在拒絕列表上,則將允許用戶出行。
[0061]然而,在本發明中,不是發送額定金額(例如£0.10),TAI103發送表示從他們的當前位置的正常最高票價的金額(例如,TAI 103可以確定從用戶的當前位置,典型的用戶將不會支付超過£6.50,然而可能有顯著高于該金額的絕對最高票價,但是將僅由極少數乘客實施該操作。在本示例中,TAI 103將包括£6.50作為步驟2中的交易金額)JPAM 102然后從用戶的預付費賬戶中凍結等于該正常最高票價的金額,并且以發送回TAI 103的授權響應來響應授權請求(步驟3)。
[0062]該授權響應可以包括用戶的可用余額。TAI 103能夠以與如圖1中解釋授權響應相同的方式來解釋步驟3中的授權響應(即所批準的授權允許TAI 103開始新的匯總周期,而所拒絕的授權通常將涉及TAI 103阻止用戶隨后出行(例如通過使用拒絕列表))。
[0063]當用戶再次在TAI103“刷出”時(步驟4),由TAI 103記錄旅程的費用。但是,在步驟4之后,TAI通過發送指示用戶101進行的最后旅程的費用的信息來更新PPAM(步驟4a)。一旦已知隨后旅程5和6/7的費用,則以如圖1中的模式再次將它們匯總,但是TAI 103現在將匯總的費用和/或單獨的旅程費用發送到PPAM 102(步驟5a和7a)。相應地,PPAM 102被提供以關于用戶的一整天交通活動的詳細信息。該信息使得PPAM 102能夠對其提供預付費賬戶的用戶生成更加詳細的風險分析。
[0064]在某一天結束時,進行結算處理(步驟8),其中從用戶的賬戶扣除所有的匯總費用(未示出)。
[0065]另外(并且未在圖2中示出),PPAM102可以將指示用戶的可用余額已經下降到一組預定義閾值之一以下的消息發送到TAI 103oTAI 103然后可以決定阻止用戶出行,直到當PPAM 102通知TAI 103該帳戶再次處于良好信譽的這種時刻。可以發送到TAI 103的另一消息可以指示已經將卡報道為丟失/被盜的卡。
[0066]圖3是更詳細地示出已知系統諸如圖1的系統的各方的示意圖,S卩TAI103,PPAM102和中間網絡201,該中間網絡還包括收單機構(acquirer)接口平臺206和PPAM接口平臺207,諸如MasterCard?接口平臺。這些接口平臺利用中間網絡201促進了TAI 103與PPAM102的連通。TAI 103包括交通后勤室202、交易基礎設施203和收單賬戶管理器204。交易基礎設施203可以是交通機構的系統的一部分或者可以外包給獨立的服務提供商。收單賬戶管理器204是一個第三方,該第三方提供機制以允許商家(例如交通機構)經過支付網絡(例如中間網絡201)將交易數據發送至發行機構(例如PPAM 102)以用于授權、結算和清算,并且該第三方代表交通機構與PPAM 102交互。還示出了作為TAI 103的一部分的示例性終端205和由用戶101持有的支付卡(支付卡)208。
[0067]將理解的是,無論在整個說明書中何處描述了支付卡的使用方式,還可以設想出具有適當的非接觸式支付功能的任何支付設備。例如,可以使用移動電話、平板電腦、鑰匙扣、貼紙、手表、手鐲或包含在非卡式要素內并且具有非接觸式支付功能的任何其他設備。
[0068]雖然所描述的具體實例指的是預付費帳戶和預付費帳戶管理器(PPAM),但是本發明還可以應用于關聯到支付設備的任何適當形式的支付帳戶。因此,對于這樣的支付賬戶,PPAM更通常被稱為支付帳戶管理器(PAM)。
[0069]圖3示出TAI 103如何經由中間網絡201與PPAM 102連通。該簡化的示意圖示出第一次“刷入”授權請求(步驟2)、授權響應(步驟3)和一天結束時的結算(步驟8)的示例性步驟。
[0070]在如圖2中描述的系統中使用如圖3中描述的這種系統的缺點在于,由于任何中間匯總消息和任何拒絕列表管理行為,在收單賬戶管理器204上的負荷可能相當大,尤其是在交通機構的運輸系統的高峰使用期間更加如此。第三方收單賬戶管理器204因此有可能將用于處理該負荷的額外的花銷傳遞至TAI 103。
[0071]圖4是示出根據本發明的一個實施方案的系統的示意圖。圖4的系統類似于圖3的系統,但是還包括附加的交易基礎設施接口平臺301,該平臺使得能夠經由中間網絡201在交易基礎設施203與PPAM 102之間直接通信。
[0072]這樣,避免了在收單帳戶管理器204上的負荷,并且其結果是,還避免了收單帳戶管理器204的任何潛在的額外花銷。
[0073]可替換地,可以在交易基礎設施203與PPAM 102之間建立直接連接。
[0074]為了保持符合行業標準安全要求(諸如支付卡行業數據安全標準(PCIDSS)),TAI的交通后勤室202和它們的讀卡器205能夠實施將卡號(主賬號或者簡單的PAN)混淆的某些方式。通常可以采用現有形式的特征標記將PAN饋入數學算法以建立[合理的]唯一標識符。這種標識符不應容易地允許任何惡意的個人或組織恢復原始PAN。
[0075]這種特征標記允許TAI103以簡單的方式來管理他們的PCI要求,但是仍然需要將出行時以及在票價計算時使用的標記卡細節轉換回原始PAN,以使得其可以用于促進支付交易。
[0076]該操作通常是在TAI的交易基礎設施203在安全的環境下進行的。該處理確保了永遠不能在讀卡器205(或任何等效的車票/收益檢驗設備)處獲得結算的卡數據或經由后勤室202聘用的TAI的員工中的一員獲得結算的卡數據。由于安全的環境,交易基礎設施203聘用的員工通常也不能夠訪問結算的PAN數據。
[0077]可替代地,可以經由中間網絡201并通過額外的接口平臺在交通后勤室202與PPAM102之間建立直接連接。這將需要交通后勤室202通過實施類似于上述或與上述相同的PAN特征標記技術來處理PCI DSS負擔。
[0078]可替代地,可以在交通后勤室202與PPAM 102之間建立直接連接,但是,這將產生如上相同的PCI DSS問題。
[0079]所有的替代方案還避免了以上提及的在收單賬戶管理器204上的負荷,并且,其結果為,還避免了收單賬戶管理器204上的任何潛在額外負擔。但是,這種配置仍將與本發明的其他方面一同作用,并且不需要由希望實施該行為的TAI 103完全排除。
[0080]中間網絡201可以是由第三方運行的網絡,諸如由MasterCard?運行的Banknet?網絡。
[0081]可替代地,可以使用專門開發的應用程序接口(API)或專門開發的網絡API來代替中間網絡201。
[0082]圖5至圖24是表示示例本發明的系統和方法的過程的一系列流程示意圖。
[0083]這些圖中的每一個都示出了一個時鐘,該時鐘提供該圖中所示過程可能發生在一天中的示例性時間的指示。示出的時間不是要求的時間,并且將理解的是,在每幅圖中示出的每個過程可以在一天中的任何時間發生。
[0084]雖然在這些圖中的一些圖(參見例如圖11)中,將“未結算”的資金分為“未結算的零售支出”和“未結算的交通支出”示出,但這僅是為了說明的目的并且為了容易理解。持卡人將優選地僅看到表示總計未結算支出的總額的單個“未結算資金”余額和表示任何剩余可用資金的單個“購買額度”余額。
[0085]用于警報的任何金額或閾值僅是示范性的,并且很可能基于交通機構與PPAM之間的協議。
[0086]所有的圖5至24示出了經由上述的中間網絡201由PPAM 102管理的充值終端501、運輸支付終端502、零售支付終端502a以及預付費賬戶503之間的交互。
[0087]運輸支付終端502形成TAI 103的一部分。在任何一個TAI 103中有可能有多個運輸支付終端502 JAI 103與外部實體交互,并且在圖5至24中,其中運輸支付終端502被示為發送和接收消息,這被用來將較寬的TAI 103表示為整個發送和接收消息,而不必是運輸支付終端502本身。
[0088]充值終端501、運輸支付終端502和零售支付終端502a均可以是屬于和/或由運輸機構運行的TAI 103的一部分,并且這種終端可以位于屬于運輸機構的營業場所。但是,充值終端501和零售支付終端502a通常將由第三方運行和/或屬于第三方,并且位于運輸機構的營業場所的外部(例如商家零售營業場所),并且通常將完全獨立于TAI 103。本發明關注于在這些位置如何使用才可以(通過中間網絡201和PPAM 102)以適當的方式通信至TAI103(例如TAI 103不需要意識到用戶在標準零售環境下進行的購買,但是將需要意識到,是否該購買意味著現在網絡中沒有足夠的資金用于旅程)。
[0089]在本節中,充值終端501被稱為終端的地方,還應該被理解為充值站。通常終端不與中間網絡201直接通信。出于示例性目的以及簡化性目的,商家和它們的收單機構均從附圖和解釋中排除,但是應該認為它們形成充值站或充值終端501的一部分。
[0090]上述內容也適用于零售位置和零售終端502a。
[0091 ]在任何這些部件被描述為將消息或信息發送到例如中間網絡201或PPAM 102的地方,應當理解的是,這也是指TAI 103作為發送消息或信息的整體。
[0092]圖5示出用戶101購買/獲取關聯到由PPAM102管理的預付費賬戶503的支付卡208。用戶101在充值終端501為卡支付£5的押金,并且進一步對卡充值£20。押金和充值金額當然可以是任何適當的值,并且將理解的是,這些值僅是示例性的。
[0093]然后由充值終端501將指示已經充值£20的消息發送到PPAM 102 JPAM 102然后在該20 £的預付費賬戶503中建立購買額度(資金限度)并且還記錄£ 5的押金。
[0094]圖6示出用戶101在運輸支付終端502刷他們的支付卡208以開始旅程(“刷入”)。在此,執行標準卡核對,這些核對是任何適當的已知和/或當前使用的卡核對,并且對著拒絕列表601核對卡。如果核對成功,則允許用戶101開始他們的旅程。TAI 103然后經由中間網絡201將交通匯總授權(或預授權)請求發送到PPAM 102。
[0095]將表示來自指定運輸支付終端502的正常最高票價的金額與授權或預授權請求的一部分一起或者作為授權或預授權請求的一部分從TAI 103發送到PPAM 102。示例性金額是£7.50 JPAM 102然后將從預付費賬戶的購買額度(資金限度)中凍結£7.50。使用正常最高值為PPAM 102提供了使得其能夠更好管理用戶的賬戶的購買額度余額的信息。
[0096]如上所解釋的,在現有交易系統中,為了授權與預授權請求的一部分一起或作為預授權請求的一部分發送到PPAM 102的金額僅是額定金額,諸如£0.10。已知的PPAM然后通常將會凍結他們正承擔責任的值,例如£ 20。
[0097]因此,本發明為PPAM102提供了從預付費帳戶103中凍結的準確、合適的金額的指示,而現有交易系統不是這樣。這對于賬戶持有人的影響在于他們將不太可能因為缺少資金而被拒絕交易,并且從而為那些通過僅用于他們的旅行的足夠資金(例如,接近為零的余額)管理他們的賬戶的用戶提供可靠機制。
[0098]圖7示出PPAM 102經由中間網絡201將授權響應發送回TAI 103。剩余的購買額度(資金限度)也可以返回到TAI 103。這可以由運輸支付終端502保存以用于進一步使用。注意到,在該示例性場景中,PPAM 102已經批準了該交易。在交易被拒絕的情況下,TAI 103通常將用戶的卡增加到拒絕列表以阻止進一步出行。
[0099]圖8示出用戶101在旅程結束時在運輸支付終端502刷他們的支付卡208(“刷出”)。計算出實際票價;在該情況下是£3,并且經由中間網絡201將其發送回PPAM 1021PAM然后將凍結的/未結算的金額從£ 7.50減少到£ 3。在此,由于額定金額與實際票價之間的任何差異,可以對金額做出任何適當的調整。購買額度(資金限度)目前保持為£17。
[0100]圖9示出用戶101在運輸支付終端502刷他們的支付卡208以便開始進一步的旅程(“刷入”)。在這種情況下,在TAI 103與PPAM 102之間不需要發送消息,因為已經發送了適當的授權或預授權請求。由于早先的交易,PPAM 102已經意識到持卡人正在出行,并且因此他們準許交通機構來允許進一步出行。
[0101]圖10示出用戶101“刷出”。實際票價由TAI 103經由中間網絡201傳送到PPAM 102。在這種情況下,費用為E51PAM 102然后相應地調整預付費賬戶的凍結的金額和購買額度(資金限度)金額,從而留下£8凍結和£12購買額度。
[0102]圖11示出用戶101在零售購買終端502a使用支付卡208進行零售購買。由零售購買終端502a經由中間網絡201將指示購買值的標準授權消息發送到PPAM 102,在該情況下購買值是£ 11.5(LPPAM 102然后從購買額度中凍結進一步的金額£ 11.50作為未結算的零售支出,在購買額度中留下50p。
[0103]圖12示出PPAM102經由中間網絡201將指示目前在預付費賬戶的購買額度(資金限度)中資金不足的消息發送到TAI 103。運輸支付終端502然后將關聯到賬戶的支付卡208增加至拒絕列表。更新的拒絕列表然后被發送到讀卡器205。這因此允許PPAM 102和TAI103阻止將卡用于運輸直到當用戶101已經使他們的賬戶503獲得良好的信譽的這種時刻,從而減少所涉及的全部各方的關聯責任風險,但仍為用戶提供一種機制以維持低余額和出行。
[0104]在示例性實施方案中,可以提供通常與不同的運輸模式關聯的不同的最低票價對應的不同拒絕列表閾值。這樣,支付卡208可能對于更昂貴的運輸模式來說在拒絕列表上,但是如果在預付費賬戶503中有足夠的可用資金來支付最低票價,則仍能夠以更便宜的運輸模式出行。
[0105]例如,最低的鐵路票價可以是£3.50,但是公交車票價可以是£1.20。因此,應該允許在他們的PPAM賬戶中有£ 2.00購買額度的持卡人開始公交車之旅,但是將不會允許他們開始鐵路之旅,這是因為由于他們的卡下降到鐵路拒絕列表閾值以下已經將他們的卡增加到鐵路拒絕列表。
[0106]圖13示出用戶在充值終端501將卡進一步充值£20。然后由充值終端501將指示已經充值£ 20的消息通常經由中間網絡201發送到PPAM 102OPPAM 102然后將預付費賬戶503的購買額度(資金限度)增加附加的£ 20,該購買額度目前保持為£ 20.50。
[0107]可選地,將充值終端501連接到PPAM 102和TAI 103的中間網絡201可以將從充值終端501接收的指示已經充值£ 20的消息直接轉發至TAI103。
[0108]圖14示出PPAM102將指示已經對預付費賬戶的當前購買額度(可用資金)充值(以及可選地其現在可能高于閾值)的消息發送給TAI 103。交通機構然后基于傳送的信息決定是否應該將支付卡208從拒絕列表中刪除,或者在存在多個拒絕列表的情況下從全部或選定的一些拒絕列表中刪除。
[0109]在存在與不同的最低票價值關聯的多個拒絕列表的情況下,根據充值后的購買額度(資金限度)可以選擇性地進行以上操作。
[0110]假定將從拒絕列表中刪除支付卡208JljTAI 103然后將開始從他們的拒絕列表中刪除支付卡208。取決于交通機構的通信基礎設施,這需要花費一些時間。因此,盡管已經對卡進行了充值,但是如果用戶的支付卡208仍在拒絕列表上,則當用戶101開始出行時,將不會允許他們開始他們的旅程。
[0111]一旦從拒絕列表中刪除支付卡208,則沒有觸發/不需要進一步的預授權請求,因為支付卡208是專門發行的,并且先前的匯總可以簡單地繼續。
[0112]圖15示出在交通機構決定從(一個或多個)拒絕列表中刪除支付卡208之后,在TAI103建立拒絕列表繞過數據。即使卡仍在拒絕列表上,拒絕列表繞過數據也使得支付卡208能夠在終端處使用。這是通過TAI 103準備一段數據并且最終將其寫回到支付卡208來實現的。一旦該數據被安全地寫入到卡上(這可以使用現有技術來實現),則如果該卡出現在交通系統中盡管其仍在拒絕列表上,該段數據會允許支付卡208繞過拒絕列表核對并且授權持卡人訪問系統。繞過數據在卡上的事實向TAI 103和終端502指示:支付卡208和關聯的賬戶503再次處于良好的信譽,并且在這種情況下,越過拒絕列表核對實際上是安全的。
[0113]對于其中存在與不同的最低票價值關聯的多個拒絕列表的情況,拒絕列表繞過數據可以根據預付費賬戶503的購買額度(資金限度)選擇性地繞過拒絕列表。
[0114]然后經由中間網絡201將拒絕列表繞過數據發送到PPAM102。
[0115]可替代地,將充值終端501連接到PPAM 102和運輸支付終端502的中間網絡201可以允許TAI 103將拒絕列表繞過數據直接發送到充值終端501。
[0116]圖16示出PPAM102經由中間網絡201將拒絕列表繞過數據發送到充值終端501。然后通過接觸式接口或者非接觸式接口將拒絕列表繞過數據寫入到支付卡208。將數據安全地寫入到支付卡208的過程可以使用現有方法。
[0117]圖17示出在用對于出行而言足夠的資金成功充值之后,但是在運輸支付終端502處已經將支付卡208從一個拒絕列表或多個拒絕列表中刪除之前,用戶101在運輸支付終端502刷支付卡208(“刷入”)。先前,在允許用戶出行之前他們將必須等待運輸支付終端502更新拒絕列表,但是拒絕列表繞過數據繞過拒絕列表并且允許用戶101開始他們的旅程。
[0118]圖18示出已經完成他們的旅程的用戶101“刷出”,在這種情況下費用為£4。經由中間網絡201將實際票價發送回PPAM 102。PPAM然后相應地將凍結的/未結算的金額變更為總共£23.50并且留下可用資金£16.50。
[0119]圖19示出發生在一天結束時的結算未結算金額的一天結束的結算過程,賬戶中僅留下剩余的£■ 16.50的購買額度(資金限度)以及£ 5的押金。
[0120]圖20示出第二天由用戶101利用支付卡208進行的零售購買。由零售支付終端502a將對£6.50購買的標準授權請求發送到PPAM 102,并且將凍結的/未結算的金額相應地調整為£6.50,余下£10的購買額度(可用資金)。
[0121]圖21示出用戶101隨后在運輸支付終端502刷他們的支付卡208以開始旅程(“刷入”)。此處,進行了標準卡核對,并且對照拒絕列表601核對該卡。如果核對成功,則允許用戶101開始他們的旅程。TAI 103然后經由中間網絡201將交通匯總授權(或預授權)請求發送到PPAM 102。
[0122]再次,將TAI103處的表示正常最高票價的額定金額與預授權一起發送到PPAM102。示例性金額為£7.50 JPAM 102然后從預付費賬戶的購買額度(資金限度)中凍結£7.50,余下£2.50的購買額度。
[0123]圖22示出PPAM 102經由中間網絡201將授權響應發送回TAI 103。再次,剩余的購買額度(資金限度)也可以被返回到TAI 103。
[0124]圖23示出用戶101在旅程結束時在運輸支付終端502刷他們的支付卡208(“刷出”)。計算出實際票價,在這種情況下是£13,并且經由中間網絡201將其發送回PPAM 102。這超出了剩余的購買額度(資金限度),并且僅余下£2的押金余額(和-£3的“負”購買額度)。
[0125]圖24示出PPAM102隨后經由中間網絡201將指示現在對于最低票價存在資金不足的消息發送到TAI 103。結果是,支付卡208列于終端502處的拒絕列表上,如參照圖12所描述的過程。
[0126]以上提及的如通過參照圖13至16所描述的從拒絕列表中刪除卡的過程可以重復并且用戶101可以繼續使用他們的支付卡208。在這種情況下,充值到卡中的任何金額首先必須用于還清卡的押金的任何支出,然后用余額更新購買額度。例如,如果余額是-£2.00(使用了 £2.00的押金),并且充值為£20,其結果將是£5.00的押金和£18的購買額度。
[0127]TAI 103本身可以被認為是組成如上所述的其組成實體的終端。
[0128]不應將此處的流程圖和對其的描述理解為對其中描述的方法步驟規定了固定的執行順序。相反地,可以以可行的任何順序執行方法步驟。盡管已經結合具體示例性實施方案對本發明進行描述,但是應該理解的是,可以對所公開的實施方案做出對于本領域技術人員而言明了的各種改變、替換和變更,而不脫離如在所附權利要求中闡明的本發明的精神和范圍。
【主權項】
1.一種使用支付賬戶執行交易的計算機實施方法,所述方法包括以下步驟: 接收來自充值終端的第一消息,所述第一消息指示已經將資金轉移到所述支付賬戶; 基于所述第一消息中的信息設置或調整所述支付賬戶的資金限度; 接收來自第一終端的授權或預授權請求并且開始資金匯總; 接收第二消息,所述第二消息指示在交易中能夠使用的資金的預定金額; 凍結所述支付帳戶的等于所述預定金額的資金限度的金額;以及 將授權響應發送到所述第一終端。2.根據權利要求1所述的方法,還包括以下步驟: 接收來自第二終端的第三消息,所述第三消息指示所使用資金的實際金額;以及如果所使用資金的實際金額不同于所述預定金額,則調整所述支付帳戶的資金限度的凍結金額。3.根據權利要求1或權利要求2所述的方法,還包括以下步驟: 將指示所述資金限度的更新的未凍結金額的消息發送到所述第一終端。4.根據權利要求3所述的方法,其中,僅當未凍結的資金限度下降到閾值金額以下或上升到閾值金額以上時,才發送指示所述資金限度的更新的未凍結金額的消息。5.根據任一前述權利要求所述的方法,還包括以下步驟: 如果資金限度的未凍結金額小于所使用資金的最低可能實際金額,則將所述支付賬戶列于拒絕列表上。6.根據權利要求5所述的方法,還包括以下步驟: 接收來自充值終端的第四消息,所述第四消息指示已經將另一些資金轉移到所述支付賬戶; 基于所述第四消息中的信息設置或調整所述支付賬戶的資金限度;以及如果所述支付帳戶的資金限度的未凍結金額超過所使用資金的最低可能實際金額,則從所述拒絕列表中刪除所述支付帳戶。7.根據權利要求6所述的方法,還包括以下步驟: 在從所述拒絕列表中刪除所述支付帳戶之后,繼續所述資金匯總。8.根據任一前述權利要求所述的方法,其中,所述支付賬戶的所述資金限度是基于詳述所述支付賬戶中的任何現有資金的信息以及所述第一消息中的信息被設置的。9.根據任一前述權利要求所述的方法,其中,所述資金限度的預定凍結金額等于在所述第一終端所使用資金的實際金額的平均值或最高值或典型的最高值。10.根據任一前述權利要求所述的方法,其中,設置或調整所述資金限度的步驟還考慮到可能先前已經支付到所述支付賬戶中的任何押金。11.根據任一前述權利要求所述的方法,還包括以下步驟: 發送所述資金匯總和結算任何剩余的凍結資金的所述支付賬戶以及相應地調整所述資金限度。12.根據任一前述權利要求所述的方法,其中,所述授權或預授權請求以及所述第二消息包括單個消息。13.—種處理支付賬戶上的資金的計算機實施方法,所述方法包括以下步驟: 接收來自第一終端的第一消息,所述第一消息指示需要指定金額的資金; 將第二消息發送到所述第一終端,所述第二消息指示沒有可用的所需資金; 接收來自充值終端的第三消息,所述第三消息指示已經將資金增加到所述支付賬戶;以及 將第四消息發送到所述第一終端,所述第四消息指示所述支付帳戶中現在有足夠的資金; 接收來自所述第一終端的數據;以及 將所述數據發送到所述充值終端,以寫入到支付帳戶支付裝置。14.根據權利要求13所述的方法,其中,所述數據由與所述充值終端通信的交通后勤室提供。15.根據權利要求13或權利要求14所述的方法,其中,所述數據包括拒絕列表繞過數據。16.根據權利要求15所述的方法,其中,所述拒絕列表繞過數據使得所述支付帳戶支付裝置能夠在指定時期繞過拒絕列表。17.—種處理支付賬戶上的資金的計算機實施方法,所述方法包括以下步驟: 將第一消息發送到支付賬戶管理器(PAM),所述第一消息指示需要指定金額的資金; 接收來自所述PAM的第二消息,所述第二消息指示沒有可用的所需資金; 可選地經由所述PAM,接收來自充值終端的第三消息,所述第三消息指示已經將資金增加到所述支付賬戶; 建立拒絕列表繞過數據;以及 可選地經由所述PAM,將所述拒絕列表繞過數據發送到所述充值終端,以寫入到關聯至所述支付賬戶的支付設備。18.—種處理支付賬戶上的資金的計算機實施方法,所述方法包括以下步驟: 接收來自第一終端的第一消息并且將所述第一消息傳送到支付賬戶管理器(PAM),所述第一消息指示需要指定金額的資金; 接收來自所述PAM的第二消息并且將所述第二消息傳送到所述第一終端,所述第二消息指示沒有可用的所需資金; 接收來自充值終端的第三消息并且將所述第三消息傳送到所述PAM和/或所述第一終端,所述第三消息指示已經將資金增加到所述支付賬戶; 可選地,接收來自所述PAM的第四消息并且將所述第四消息傳送到所述第一終端,所述第四消息指示現在有足夠的資金可用; 接收來自所述第一終端的拒絕列表繞過數據,可選地將所述拒絕列表繞過數據傳送到所述PAM;以及 將所述拒絕列表繞過數據傳送到所述充值終端,以在所述充值終端將所述拒絕列表繞過數據寫入到關聯至所述支付賬戶的支付設備。19.一種交易處理系統,包括至少一個充值終端、至少一個第一終端和至少一個處理器,所述至少一個處理器被配置為執行根據權利要求1至12中任一項所述的方法。20.根據權利要求19所述的交易處理系統,其中,所述至少一個處理器由支付賬戶管理器托管。21.—種交易處理系統,包括至少一個充值終端、至少一個第一終端以及至少一個處理器,所述至少一個處理器被配置為執行根據權利要求17或權利要求18所述的方法。22.—種支付帳戶管理器,所述支付賬戶管理器被配置為執行根據權利要求13至16中任一項所述的方法。
【文檔編號】G06Q20/02GK105849755SQ201480061110
【公開日】2016年8月10日
【申請日】2014年9月26日
【發明人】詹姆斯·C·諾伊, 邁克爾·J·考恩, 杰森·菲爾德, 賽治薩·喬治, 大衛·A·羅伯茨
【申請人】萬事達卡國際股份有限公司