專利名稱：一種支付業(yè)務異常交易的處理方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及智能網(wǎng)數(shù)據(jù)通信領域，特別是涉及一種支付業(yè)務異常交易的處理方法 及系統(tǒng)。
背景技術：
隨著電信增值業(yè)務的開展，電信支付類業(yè)務被越來越多的使用，應用范圍也越來 越廣泛。隨著用戶數(shù)量不斷增加和應用范圍的擴展，用戶對業(yè)務系統(tǒng)的容錯性能也提出了 更高的要求，要求在系統(tǒng)異常的時候能自動完成對異常交易記錄的處理，方便用戶使用。在目前的電信支付類業(yè)務中，在系統(tǒng)出現(xiàn)錯誤時，不能對異常的交易情況進行自 動處理，依賴人工處理。用戶發(fā)覺交易異常時，需要撥打客服電話，通過客服人員手工完成 異常情況的處理，時效性差，效率低。針對這一情況，現(xiàn)有的專利文獻提出了一些改進的方法。專利申請?zhí)枮?200610150450.4的中國專利公開了一種系統(tǒng)異常信息處理方法及裝置，實現(xiàn)了對錯誤自 動記錄、檢測和保存功能，但該專利申請中沒有實現(xiàn)對異常交易的自動處理；專利申請?zhí)枮?200810142494. 1的中國專利公開了一種處理在線計費系統(tǒng)異常的方法，當OCS系統(tǒng)處于應 急狀態(tài)下，對呼叫進行控制，但沒有給出對已經(jīng)產(chǎn)生的異常交易信息如何進行處理的解決 方案。兩篇專利文獻提供的方法都沒能實現(xiàn)對異常交易的自動處理功能。

發(fā)明內(nèi)容
本發(fā)明要解決的技術問題是提供一種利用智能網(wǎng)日志信息，自動處理支付業(yè)務異 常交易的方法及系統(tǒng)，用以解決現(xiàn)有技術中對異常交易無法自動處理的問題。為解決上述技術問題，一方面，本發(fā)明提供一種支付業(yè)務異常交易的處理方法，所 述方法包括以下步驟在支付業(yè)務發(fā)生異常交易時，生成包含有交易記錄必要信息的異常交易日志；根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進行處理。進一步，在生成異常交易日志之后，還包括以下步驟根據(jù)所述異常交易日志中的 交易發(fā)生時間，判斷所述交易發(fā)生時間是否處于設定的允許自動處理的時間范圍內(nèi)，如果 是，則按照設定的異常處理規(guī)則對異常交易進行處理；如果否，則結(jié)束對異常交易的處理。進一步，按照設定的異常處理規(guī)則對異常交易進行處理，具體包括以下步驟判斷 異常交易屬于用戶金額異常，還是交易記錄狀態(tài)異常；當異常交易屬于用戶金額異常時，返 還用戶扣費金額；當異常交易屬于交易記錄狀態(tài)異常時，更新交易記錄的交易狀態(tài)。進一步，在返還用戶扣費金額之前，還包括以下步驟判斷所述返還用戶扣費金額 是否超過設定的自動處理金額上限值，如果是，則通知技術人員進行人工處理；如果否，則 返還用戶扣費金額。進一步，所述必要信息包括從數(shù)據(jù)庫中查找交易記錄的信息，以及與數(shù)據(jù)庫中交 易記錄的交易狀態(tài)進行對比的異常交易記錄狀態(tài)信息。
另一方面，本發(fā)明還提供一種支付業(yè)務異常交易的處理系統(tǒng)，包括進行支付業(yè)務 處理的業(yè)務處理單元，所述系統(tǒng)還包括異常日志生成單元，用于在所述業(yè)務處理單元發(fā)現(xiàn)支付業(yè)務發(fā)生異常交易時，生 成包含有交易記錄必要信息的異常交易日志；異常處理單元，用于根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交 易進行處理。進一步，所述異常處理單元進一步包括時間判斷子單元，用于根據(jù)所述異常交易 日志中的交易發(fā)生時間，判斷所述交易發(fā)生時間是否處于設定的允許自動處理的時間范圍 內(nèi)，如果是，則由所述異常處理單元按照設定的異常處理規(guī)則對異常交易進行處理；如果 否，則結(jié)束對異常交易的處理。進一步，所述異常處理單元進一步包括處理規(guī)則判斷子單元，用于判斷異常交易 屬于用戶金額異常，還是交易記錄狀態(tài)異常；當異常交易屬于用戶金額異常時，則由所述異 常處理單元返還用戶扣費金額；當異常交易屬于交易記錄狀態(tài)異常時，則由所述異常處理 單元更新交易記錄的交易狀態(tài)。進一步，所述必要信息包括從數(shù)據(jù)庫中查找交易記錄的信息，以及與數(shù)據(jù)庫中交 易記錄的交易狀態(tài)進行對比的異常交易記錄狀態(tài)信息。進一步，所述異常處理單元進一步包括金額限制判斷子單元，用于判斷所述返還 用戶扣費金額是否超過設定的自動處理金額上限值，如果是，則由信息通知單元通知技術 人員人工處理；如果否，則由所述異常處理單元返還用戶扣費金額。本發(fā)明有益效果如下本發(fā)明公開的支付業(yè)務異常交易的自動處理方法實現(xiàn)了對 支付業(yè)務異常交易的自動處理，省略了人工干預，降低了人工操作，提高了處理效率。支付 業(yè)務異常交易的自動處理系統(tǒng)結(jié)構(gòu)簡單，時效性高，異常處理單元還可以根據(jù)不同客戶需 求靈活配置異常處理規(guī)則，增加了機制的靈活性、適用性和擴展性。


圖1是本發(fā)明實施例1 一種支付業(yè)務異常交易的處理方法的流程圖；圖2是本發(fā)明實施例2 —種支付業(yè)務異常交易的處理方法的流程圖；圖3是本發(fā)明實施例3 —種支付業(yè)務異常交易的處理系統(tǒng)的結(jié)構(gòu)示意圖；圖4是本發(fā)明實施例4 一種支付業(yè)務異常交易的處理系統(tǒng)的結(jié)構(gòu)示意圖。
具體實施例方式為了解決現(xiàn)有技術中對支付業(yè)務中異常交易無法自動處理的問題，本發(fā)明提供了 一種支付業(yè)務異常交易的處理方法及系統(tǒng)，以下結(jié)合附圖以及實施例，對本發(fā)明進行進一 步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不限定本發(fā)明。如圖1所示，本發(fā)明實施例1所述的支付業(yè)務異常交易的處理方法是利用智能網(wǎng) 業(yè)務產(chǎn)生的日志，按照預先設定的異常處理規(guī)則，進行自動處理，具體包括以下步驟S101，在支付業(yè)務發(fā)生異常交易時，生成包含有交易記錄必要信息的異常交易日ο用戶在使用支付類業(yè)務時候，系統(tǒng)因異常原因?qū)е聵I(yè)務的交易記錄異常，異常交易主要是由數(shù)據(jù)庫操作異常、外部接口異?；蛘哂脩舢惓Ｍ顺龅仍蛟斐?。在發(fā)生異常交 易后，系統(tǒng)會自動捕獲該異常交易，并在指定位置生成一個異常交易日志。異常交易日志為 文本日志，或者數(shù)據(jù)庫記錄日志。異常交易日志記錄交易的必要信息，這些必要信息不僅包 括從數(shù)據(jù)庫中查找交易記錄的信息，也包括與數(shù)據(jù)庫中交易記錄的交易狀態(tài)進行對比的異 常交易記錄狀態(tài)信息，如交易流水號(用于查找異常交易記錄)、交易類型、發(fā)生異常時的 交易當前狀態(tài)(用于比較異常交易記錄狀態(tài))、扣費方式和交易發(fā)生的時間等。S102，根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進行處理。通過異常交易日志記錄的信息，查找數(shù)據(jù)庫中對應的交易記錄，按照預先設定的 異常處理規(guī)則過濾查找出來的交易結(jié)果，如果是用戶費用異常，則判斷是否返還用戶扣費 金額，可以直接返還扣費金額的，系統(tǒng)直接自動返還，需要人工返還的，則通過發(fā)送短信通 知相關人員進行人工返還；如果交易記錄狀態(tài)不正確，需要根據(jù)異常處理規(guī)則，更新交易記 錄。本實施例中異常處理規(guī)則是指根據(jù)異常交易類型的不同，對異常交易設定的不同 的處理方法。通常情況下，異常交易包括用戶金額異常和交易記錄狀態(tài)異常兩種情況，而 用戶金額異常通常包括兩種情況，一種是如果異常交易日志的交易狀態(tài)是扣費超時，這時 可能存在扣費成功，但系統(tǒng)認為交易失敗的情況，即SP(SerVice Provider，服務提供者) 扣費成功而沒有提供服務，這種情況屬于用戶金額異常，需要返還用戶扣費金額；另外一種 是如果異常交易日志的交易狀態(tài)是沖正超時或者失敗，這種情況是在扣費成功而通知SP 提供服務失敗時，支付業(yè)務自動進行沖正操作，由于異常原因沖正超時或者失敗，屬于用戶 金額異常，需要返還用戶金額。交易記錄狀態(tài)異常通常是異常交易日志的交易狀態(tài)是交易 成功，而交易記錄的交易狀態(tài)是扣費成功，這說明由于異常原因，沒有及時從扣費成功的中 間狀態(tài)更新到交易成功的最終狀態(tài)，這種情況屬于交易記錄狀態(tài)的異常，需要更新最終交 易狀態(tài)為交易成功。因此，針對上述情況，本實施例的異常處理規(guī)則為，當異常交易屬于用 戶金額異常時，返還用戶扣費金額；當異常交易屬于交易記錄狀態(tài)異常時，更新交易記錄的 交易狀態(tài)。但是，對于一些不屬于上述情況的特殊情況，用戶可以根據(jù)實際情況，另行設置 異常處理規(guī)則，例如，有些客戶希望在發(fā)生用戶金額異常時，不返還用戶的扣費金額，而是 提供一些其它服務，因此，對于這類情況，用戶可以設置新的異常處理規(guī)則，在發(fā)生用戶金 額異常時，不返還扣費金額，而是提供制定的服務或其它處理措施。由此可見，由于異常處 理規(guī)則的不同，得到不同的處理結(jié)果。如圖2所示，本發(fā)明實施例2涉及一種支付業(yè)務異常交易的處理方法，具體包括以 下步驟S201，系統(tǒng)由于異常原因，導致業(yè)務的交易記錄異常，支付業(yè)務產(chǎn)生異常交易。S202，系統(tǒng)自動捕獲該異常交易，并在指定位置生成一個異常交易日志。異常交易 日志記錄交易的必要信息，這些必要信息不僅包括從數(shù)據(jù)庫中查找交易記錄的信息，也包 括與數(shù)據(jù)庫中交易記錄的交易狀態(tài)進行對比的異常交易記錄狀態(tài)信息，如交易流水號(用 于查找異常交易記錄)、交易類型、發(fā)生異常時的交易當前狀態(tài)(用于比較異常交易記錄狀 態(tài))、扣費方式和交易發(fā)生的時間等。S203，系統(tǒng)定時到指定文件系統(tǒng)路徑，或者數(shù)據(jù)庫中掃描是否生成了新的異常交 易日志，當有新產(chǎn)生的異常交易日志時，獲取該異常交易日志的信息。
S204，系統(tǒng)從異常交易日志中獲取交易發(fā)生時間，檢查該時間是否在設定的允許 自動處理的時間范圍內(nèi)。如果是，則轉(zhuǎn)步驟S206，如果否，則轉(zhuǎn)步驟S205。設置該步驟的目 的是，由于支付業(yè)務通常都需要在特定的時間段內(nèi)對帳，由于對帳的要求，該時間段內(nèi)的帳 務數(shù)據(jù)不能變動，因此，對于該時間段內(nèi)的數(shù)據(jù)不能修改?；谏鲜隹紤]，系統(tǒng)對于需要對 帳的時間段內(nèi)的異常交易不進行自動處理。S205，系統(tǒng)通過發(fā)送消息給技術人員，通知技術人員進行人工處理?？梢酝ㄟ^短信 的方式告訴技術人員，也可以通過其它方式進行告知，例如語音電話或電子郵件等方式。S206，查找數(shù)據(jù)庫中交易記錄的交易狀態(tài)和異常交易日志信息中異常記錄的交易 狀態(tài)，判斷異常交易的類型是否屬于用戶金額異常。如果異常交易日志的交易狀態(tài)是扣費 超時，或異常交易日志的交易狀態(tài)是沖正超時或者失敗，則判定該異常交易為用戶金額異 常，并轉(zhuǎn)步驟207。如果該異常交易的類型非用戶金額異常，則轉(zhuǎn)步驟S212。S207，根據(jù)異常交易日志中記錄的用戶扣費金額，判斷返回金額是否超過設定的 自動處理金額上限值，如果是，則轉(zhuǎn)步驟S205，如果否，則轉(zhuǎn)步驟S208。設置該步驟的目的 是基于安全的目的考慮。因為任何系統(tǒng)都存在發(fā)生故障或出現(xiàn)錯誤的潛在可能，這樣，對于 返還金額較大或巨大的情況，就存在發(fā)生較大或巨大經(jīng)濟損失的可能性，為了降低發(fā)生經(jīng) 濟損失的可能性，通常需要進行人工審核，以確保正確、無誤。因此，基于安全的角度考慮， 對自動進行返還金額的操作，需要設置上限制，以降低發(fā)生錯誤時的風險。S208，根據(jù)異常交易日志中記錄的扣費方式，判斷扣費方式是否屬于本地帳戶扣 費，如果是，則轉(zhuǎn)步驟S210，如果否，則轉(zhuǎn)步驟S209。本實施例中的本地是指用戶扣費帳戶 屬于本系統(tǒng)直接管理的帳戶，而不是通過轉(zhuǎn)帳或其它手段進行的交易。S209，用戶采用外部帳戶扣費方式，比如通過銀聯(lián)扣費，由于存在扣費帳戶的扣費 金額還沒有到帳的可能，因此，為了降低可能存在的風險，需要發(fā)送退費數(shù)據(jù)包進行退費， 而不能直接進行本地退費。調(diào)用外部扣費接口的返還金額機制，通過發(fā)送預先配置的用于 退費的數(shù)據(jù)包完成退費(數(shù)據(jù)包中的退費金額等信息是從異常交易日志中獲取的)。完成 退費之后，轉(zhuǎn)步驟S211。S210，用戶采用直接在本地帳戶中扣減費用的扣費方式，則執(zhí)行預先配置好的退 費腳本，完成本地退費，然后轉(zhuǎn)步驟S211。S211，在對支付業(yè)務中的異常交易完成自動處理之后，發(fā)送處理結(jié)果給客戶。處理 結(jié)果可以通過短信的方式發(fā)送給客戶，也可以通過其它方式，例如電子郵件或語音電話等。 處理結(jié)果的內(nèi)容主要包括處理時間，用戶使用的業(yè)務類型，出錯原因，處理方式(返還多 少金額或者更新交易記錄狀態(tài))等。S212，查找數(shù)據(jù)庫中交易記錄的交易狀態(tài)和異常交易日志信息中異常記錄的交易 狀態(tài)，判斷異常交易的類型是否屬于交易記錄狀態(tài)異常。當異常交易日志的交易狀態(tài)是交 易成功，而數(shù)據(jù)庫中交易記錄的交易狀態(tài)是扣費成 功，則判定交易記錄狀態(tài)異常，在此情況 下，轉(zhuǎn)步驟S214，否則，轉(zhuǎn)步驟S213。S213，當判定異常交易的類型既不屬于用戶金額異常，也不屬于交易記錄狀態(tài)異 常，對于此種情況，有兩種處理方式，一種處理方式是，該異常交易屬于本實施例支付業(yè)務 異常交易處理辦法無法自動處理的異常情況，在這種情況下，系統(tǒng)通過發(fā)送消息給技術人 員，通知技術人員進行人工處理。另外一種處理方式是該異常交易屬于針對特殊客戶發(fā)生的特殊情況，該客戶能夠預見到該異常交易，因此，客戶可以提前在系統(tǒng)中設置針對該異常 交易的異常處理規(guī)則，對該異常交易情況進行自動處理。S214，通過執(zhí)行預先配置好的更新交易狀態(tài)的數(shù)據(jù)庫腳本完成狀態(tài)更新，使異常 交易日志中記錄的交易狀態(tài)和數(shù)據(jù)庫中交易記錄的交易狀態(tài)一致。如圖3所示，本發(fā)明實施例3涉及一種支付業(yè)務異常交易處理系統(tǒng)，該系統(tǒng)包括業(yè)務處理單元301，主要用于用戶鑒權(quán)、支付方式管理、支付業(yè)務邏輯處理、捕獲異 常、為用戶提供各種支付服務，電信支付業(yè)務主要在該單元運行。異常日志生成單元302，主要在業(yè)務處理單元301捕獲支付業(yè)務發(fā)生異常交易時， 在指定位置生成一個異常交易日志。異常交易日志為文本日志，或者數(shù)據(jù)庫記錄日志。異 常交易日志記錄交易的必要信息，這些必要信息不僅包括查找異常交易記錄的信息，也包 括對比異常交易記錄狀態(tài)的信息，如交易流水號(用于查找異常交易記錄)、交易類型、發(fā) 生異常時的交易當前狀態(tài)(用于比較異常交易記錄狀態(tài))、扣費方式和交易發(fā)生的時間等。 如果異常交易日志為文本日志，則異常日志生成單元以文本日志的形式記錄異常信息，存 儲在指定的系統(tǒng)路徑，并且可以進一步配置日志文件的大小。如果異常交易日志為數(shù)據(jù)庫 記錄日志，則異常日志生成單元在指定的數(shù)據(jù)庫表中插入記錄異常信息記錄。異常處理單元303，根據(jù)異常日志生成單元302生成的異常交易日志，按照設定的 異常處理規(guī)則對異常交易進行處理，具體為當異常交易屬于用戶金額異常時，返還用戶扣 費金額；當異常交易屬于交易記錄狀態(tài)異常時，更新交易記錄的交易狀態(tài)。如圖4所示，本發(fā)明實施例4涉及一種支付業(yè)務異常交易處理系統(tǒng)，該系統(tǒng)包括 業(yè)務處理單元401、異常日志生成單元402、日志定時掃描單元403、異常處理單元404和信 息通知單元405。其中，業(yè)務處理單元401與異常日志生成單元402之間通過發(fā)送消息與響 應來傳遞信息，日志定時掃描單元403、異常處理單元404和信息通知單元405之間利用進 程間通信機制來傳遞信息。業(yè)務處理單元401主要用于用戶鑒權(quán)、支付方式管理、支付業(yè)務邏輯處理、捕獲異 常、為用戶提供各種支付服務，電信支付業(yè)務主要在該單元運行。異常日志生成單元402主要在業(yè)務處理單元401捕獲支付業(yè)務發(fā)生異常交易時， 在指定位置生成一個異常交易日志。異常交易日志為文本日志，或者數(shù)據(jù)庫記錄日志。異 常交易日志記錄交易的必要信息，這些必要信息不僅包括查找異常交易記錄的信息，也包 括對比異常交易記錄狀態(tài)的信息，如交易流水號(用于查找異常交易記錄)、交易類型、發(fā) 生異常時的交易當前狀態(tài)(用于比較異常交易記錄狀態(tài))、扣費方式和交易發(fā)生的時間等。 如果異常交易日志為文本日志，則異常日志生成單元以文本日志的形式記錄異常信息，存 儲在指定的系統(tǒng)路徑，并且可以進一步配置日志文件的大小。如果異常交易日志為數(shù)據(jù)庫 記錄日志，則異常日志生成單元在指定的數(shù)據(jù)庫表中插入記錄異常信息記錄。日志定時掃描單元403用于定時在異常日志生成單元402生成異常交易日志的 指定文件系統(tǒng)路徑或者數(shù)據(jù)庫中掃描是否生成了新的異常交易日志，當有新產(chǎn)生的異常交 易日志時，獲取該異常交易日志的信息，并將該異常交易日志的信息發(fā)送給異常處理單元 404。如果異常交易日志是文本日志，使用FTP (FileTransfer Protocol，文件傳輸協(xié)議)機 制獲取日志，通過過濾文本日志內(nèi)容判斷是否有新產(chǎn)生的日志。如果異常交易日志是數(shù)據(jù) 庫記錄日志，使用存儲過程讀取記錄，掃描相應數(shù)據(jù)庫表判斷是否增加了日志記錄，以判斷是否有新產(chǎn)生的日志。異常處理單元404進一步包括時間判斷子單元4041、處理規(guī)則判斷子單元4042、 金額限制判斷子單元4043、退費方式判斷子單元4044和外部消息發(fā)送子單元4045。異常處理單元404收到日志定時掃描單元403發(fā)送的異常交易日志的信息后，首 先，時間判斷子單元4041會對比異常交易日志信息中的交易發(fā)生時間，檢查該時間是否在 允許的自動處理時間范圍以內(nèi)。如果不在該時間范圍內(nèi)，則結(jié)束本次對異常交易的自動處 理，可以通知技術人員進行人工處理。如果在允許的自動處理時間范圍內(nèi)，處理規(guī)則判斷子 單元4042再查找數(shù)據(jù)庫中交易記錄的交易狀態(tài)與異常交易日志信息中異常記錄的交易狀 態(tài)屬于哪種情況，從而判斷出異常交易類型。異常交易類型主要包括用戶金額異常和交易 記錄狀態(tài)異常。常見的異常情況有以下幾種如果異常交易日志的交易狀態(tài)是扣費超時，這 時可能存在扣費成功但系統(tǒng)認為交易失敗的情況，即SP扣費成功而沒有提供服務，這種情 況屬于用戶金額異常，需要返還用戶扣費金額；如果異常交易日志的交易狀態(tài)是交易成功， 而數(shù)據(jù)庫中交易記錄的交易狀態(tài)是扣費成功，這說明由于異常原因沒有及時從扣費成功的 中間狀態(tài)更新到交易成功的最終狀態(tài)，這種情況屬于交易記錄狀態(tài)的異常，需要更新最終 交易狀態(tài)為交易成功；如果異常交易日志的交易狀態(tài)是沖正超時或者失敗，這也屬于用戶 金額異常，需要返還用戶金額，這種情況是在扣費成功而通知SP提供服務失敗時，支付業(yè) 務自動進行沖正操作，由于異常原因沖正超時或者失敗。如果是用戶金額異常，則通過金額限制判斷子單元4043判斷需要返還的金額是 否超過設定的自動處理金額上限值，如果超過，則需要通過信息通知單元405通知技術人 員進行人工審核處理。如果不超過金額限制，再根據(jù)異常交易日志信息里的扣費方式，由退 費方式判斷子單元4044判斷是通過內(nèi)部數(shù)據(jù)庫中直接退費，還是通過外部消息發(fā)送子單 元4045給外部扣費接口發(fā)送退費消息完成金額返還。用戶采用直接在本地帳戶中扣減費 用的扣費方式，則執(zhí)行預先配置好的退費腳本完成退費。用戶采用外部帳戶扣費方式，比如 通過銀聯(lián)扣費，則通過外部扣費接口返還金額機制，通過外部消息發(fā)送子單元4045發(fā)送預 先配置的用于退費的數(shù)據(jù)包完成退費(數(shù)據(jù)包中的退費金額等信息是從異常日志中獲取 的)。如果是交易記錄狀態(tài)異常，則直接通過執(zhí)行預先配置好的更新交易狀態(tài)的數(shù)據(jù)庫 腳本完成狀態(tài)更新。如果當前使用的異常處理規(guī)則方案無法自動處理發(fā)生的異常交易情況，那么異常 處理單元404把技術支持人員的聯(lián)系方式傳給信息通知單元405，信息通知單元405通知技 術人員人工處理這條異常。通常情況下，信息通知單元405采用短信通知的方式進行通知， 當然，也可以通過電話或電子郵件的方式進行通知。異常處理單元404完成自動處理以后，把處理結(jié)果發(fā)送給信息通知單元405，信息 通知單元405按照短信網(wǎng)關協(xié)議把處理結(jié)果組包發(fā)送給短信網(wǎng)關，短信網(wǎng)關再轉(zhuǎn)發(fā)到用戶 手機上，讓用戶能實時的了解交易處理情況。處理結(jié)果的內(nèi)容主要包括處理時間，用戶使 用的業(yè)務類型，出錯原因，處理方式(返還多少金額或者更新交易記錄狀態(tài))等。通過上述實施例可以看出，本發(fā)明實施例公開的支付業(yè)務異常交易的自動處理方 法實現(xiàn)了對支付業(yè)務異常交易的自動處理，省略了人工干預，降低了人工操作，提高了處理 效率。支付業(yè)務異常交易的自動處理系統(tǒng)結(jié)構(gòu)簡單，時效性高，異常處理單元還可以根據(jù)不9同客戶需求靈活配置異常處理規(guī)則，增加了機制的靈活性、適用性和擴展性。 盡管為示例目的，已經(jīng)公開了本發(fā)明的優(yōu)選實施例，本領域的技術人員將意識到各種改進、增加和取代也是可能的，因此，本發(fā)明的范圍應當不限于上述實施例。
權(quán)利要求
1.一種支付業(yè)務異常交易的處理方法，其特征在于，所述方法包括以下步驟在支付業(yè)務發(fā)生異常交易時，生成包含有交易記錄必要信息的異常交易日志；根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進行處理。
2.如權(quán)利要求1所述的支付業(yè)務異常交易的處理方法，其特征在于，在生成異常交易 日志之后，還包括以下步驟根據(jù)所述異常交易日志中的交易發(fā)生時間，判斷所述交易發(fā)生時間是否處于設定的允 許自動處理的時間范圍內(nèi)，如果是，則按照設定的異常處理規(guī)則對異常交易進行處理；如果 否，則結(jié)束對異常交易的處理。
3.如權(quán)利要求1所述的支付業(yè)務異常交易的處理方法，其特征在于，按照設定的異常 處理規(guī)則對異常交易進行處理，具體包括以下步驟判斷異常交易屬于用戶金額異常，還是交易記錄狀態(tài)異常；當異常交易屬于用戶金額異常時，返還用戶扣費金額；當異常交易屬于交易記錄狀態(tài) 異常時，更新交易記錄的交易狀態(tài)。
4.如權(quán)利要求3所述的支付業(yè)務異常交易的處理方法，其特征在于，在返還用戶扣費 金額之前，還包括以下步驟判斷所述返還用戶扣費金額是否超過設定的自動處理金額上限值，如果是，則通知技 術人員進行人工處理；如果否，則返還用戶扣費金額。
5.如權(quán)利要求1所述的支付業(yè)務異常交易的處理方法，其特征在于，所述必要信息包 括從數(shù)據(jù)庫中查找交易記錄的信息，以及與數(shù)據(jù)庫中交易記錄的交易狀態(tài)進行對比的異常 交易記錄狀態(tài)信息。
6.一種支付業(yè)務異常交易的處理系統(tǒng)，包括進行支付業(yè)務處理的業(yè)務處理單元，其特 征在于，所述系統(tǒng)還包括異常日志生成單元，用于在所述業(yè)務處理單元發(fā)現(xiàn)支付業(yè)務發(fā)生異常交易時，生成包 含有交易記錄必要信息的異常交易日志；異常處理單元，用于根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進 行處理。
7.如權(quán)利要求6所述的支付業(yè)務異常交易的處理系統(tǒng)，其特征在于，所述異常處理單 元進一步包括時間判斷子單元，用于根據(jù)所述異常交易日志中的交易發(fā)生時間，判斷所述交易發(fā)生 時間是否處于設定的允許自動處理的時間范圍內(nèi)，如果是，則由所述異常處理單元按照設 定的異常處理規(guī)則對異常交易進行處理；如果否，則結(jié)束對異常交易的處理。
8.如權(quán)利要求6所述的支付業(yè)務異常交易的處理系統(tǒng)，其特征在于，所述異常處理單 元進一步包括處理規(guī)則判斷子單元，用于判斷異常交易屬于用戶金額異常，還是交易記錄狀態(tài)異常； 當異常交易屬于用戶金額異常時，則由所述異常處理單元返還用戶扣費金額；當異常交易 屬于交易記錄狀態(tài)異常時，則由所述異常處理單元更新交易記錄的交易狀態(tài)。
9.如權(quán)利要求6所述的支付業(yè)務異常交易的處理系統(tǒng)，其特征在于，所述必要信息包 括從數(shù)據(jù)庫中查找交易記錄的信息，以及與數(shù)據(jù)庫中交易記錄的交易狀態(tài)進行對比的異常 交易記錄狀態(tài)信息。
10.如權(quán)利要求9所述的支付業(yè)務異常交易的處理系統(tǒng)，其特征在于，所述異常處理單 元進一步包括金額限制判斷子單元，用于判斷所述返還用戶扣費金額是否超過設定的自動處理金額 上限值，如果是，則由信息通知單元通知技術人員人工處理；如果否，則由所述異常處理單 元返還用戶扣費金額。
全文摘要
本發(fā)明公開了一種支付業(yè)務異常交易的處理方法，所述方法包括在支付業(yè)務發(fā)生異常交易時，生成包含有交易記錄必要信息的異常交易日志；根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進行處理。所述系統(tǒng)包括進行支付業(yè)務處理的業(yè)務處理單元；異常日志生成單元，用于在所述業(yè)務處理單元發(fā)現(xiàn)支付業(yè)務發(fā)生異常交易時，生成包含有交易記錄必要信息的異常交易日志；異常處理單元，用于根據(jù)所述異常交易日志，按照設定的異常處理規(guī)則對異常交易進行處理。本發(fā)明實現(xiàn)了對支付業(yè)務異常交易的自動處理，省略了人工干預，降低了人工操作，提高了處理效率。具有結(jié)構(gòu)簡單，時效性高，機制靈活等優(yōu)點。
文檔編號H04W4/24GK102045682SQ20091018085
公開日2011年5月4日 申請日期2009年10月19日 優(yōu)先權(quán)日2009年10月19日
發(fā)明者易佳, 賴天建, 馬俊輝 申請人:中興通訊股份有限公司