S5:在UI顯示用戶應(yīng)還金額，并接收用戶選擇還款金額。
[0484]步驟S6:進(jìn)行還款操作，對還款金額做校驗，用戶的還款金額不能超出用戶的應(yīng)還金額，避免出現(xiàn)還款溢出的情況發(fā)生。
[0485]步驟S7:現(xiàn)金貸還款后臺調(diào)用手Q支付后臺，生成唯一的用戶還款訂單，并將唯一的還款訂單識別序列號id返回UI。
[0486]步驟S8:UI調(diào)用手Q支付SDK進(jìn)行還款，接收用戶選擇的還款卡信息、手機(jī)驗證碼和支付密碼，手Q支付后臺驗證信息后，完成交易支付并將結(jié)果返回前端。
[0487]步驟S9:手Q支付SDK向手Q支付后臺，支付還款，
[0488]步驟SlO:手Q支付后臺同時調(diào)用現(xiàn)金貸后臺CGI，通知Π還款成功或者失敗的支付單交易結(jié)果。
[0489]圖17為一種基于用戶還款的流程圖，所述流程包括:
[0490]步驟S21:手Q支付后臺向現(xiàn)金貸還款CGI發(fā)送用戶還款完成的消息。
[0491]步驟S22:現(xiàn)金貸還款CGI向現(xiàn)金貸還款服務(wù)系統(tǒng)發(fā)送用戶支付信息。
[0492]步驟S23:現(xiàn)金貸還款服務(wù)系統(tǒng)向財付通基礎(chǔ)交易系統(tǒng)發(fā)送查詢支付單交易結(jié)果O
[0493]步驟S24:現(xiàn)金貸還款服務(wù)系統(tǒng)向第三方信貸系統(tǒng)發(fā)送銅鼓用戶還款單信息。
[0494]步驟S25:現(xiàn)金貸還款服務(wù)系統(tǒng)更新借款單狀態(tài)，例如是否為還清等。
[0495]步驟S26:現(xiàn)金貸還款服務(wù)系統(tǒng)通知用戶還款結(jié)果。
[0496]圖18為基于本發(fā)明實施例所述的支付平臺的借款單元狀態(tài)遷移圖。首先用戶簽約，以表達(dá)用戶借款意愿，此時借款單處于支付未審核狀態(tài)。
[0497]接著支付平臺對借款單進(jìn)行crf審核，若crf審核通過則借款單的狀態(tài)變遷為簽約成功待借款，若crf返回簽約失敗，表示借款單簽約審核失敗。
[0498]簽約審核失敗，則可能將所述借款單視為異常借款單或中止借款單處理，中止借款單的處理流程。
[0499]支付平臺對狀態(tài)為簽約成功等待貸款的借款單進(jìn)行放款；放款之后可能生成放款單失敗或放款單成功的放款結(jié)果。放款單失敗顯然表示放款失敗，放款當(dāng)成功顯然表示放款成功待還款。
[0500]放款成功之后，開始對還款日期是否超過還款期進(jìn)行確定，若借款單的狀態(tài)為未還款已逾期，基于用戶操作指示可進(jìn)行部分還款或全部還款。當(dāng)進(jìn)行部分還款之后，該借款單的狀態(tài)切換到部分還款已逾期的狀態(tài)。當(dāng)全部還清時，當(dāng)該借款單的狀態(tài)為已還款，并終止該借款單的處理。
[0501]在日期未超過還款期之前，基于用戶操作指示，也可以進(jìn)行部分還款或全部還清的操作。當(dāng)執(zhí)行了部分還款之后，接續(xù)監(jiān)控借款的還款期，若為到還款日期，則借款單狀態(tài)為部分還款未到期，否則部分還款已逾期。
[0502]到了還款日，支付平臺將執(zhí)行自動支付操作，執(zhí)行自動支付的日期為代扣日。在代扣日代扣時可能出現(xiàn)全部代扣成功，則借款單的狀態(tài)為已還款，并進(jìn)入終止借款單的處理；還可能出現(xiàn)部分代扣成功，則借款單的狀態(tài)為部分還款已逾期；還可能出現(xiàn)代扣失敗。代扣失敗后借款單的狀態(tài)可能會是未還款逾期(此時可能已還款為O)，若之前有償還部分，則可能出現(xiàn)借款單的狀態(tài)為部分還款已逾期。上述代扣日即為本發(fā)明實施例中所述支付日。
[0503]最后還清余額或全額還款后，則借款單的狀態(tài)更換為已還款并最終終止借款單的狀態(tài)遷移和處理。
[0504]在具體的實現(xiàn)過程中，所述客戶端與所述支付平臺之間可以基于Html5進(jìn)行信息交互。
[0505]在本申請所提供的幾個實施例中，應(yīng)該理解到，所揭露的設(shè)備和方法，可以通過其它的方式實現(xiàn)。以上所描述的設(shè)備實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，如:多個單元或組件可以結(jié)合，或可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另外，所顯示或討論的各組成部分相互之間的耦合、或直接耦合、或通信連接可以是通過一些接口，設(shè)備或單元的間接耦合或通信連接，可以是電性的、機(jī)械的或其它形式的。
[0506]上述作為分離部件說明的單元可以是、或也可以不是物理上分開的，作為單元顯示的部件可以是、或也可以不是物理單元，即可以位于一個地方，也可以分布到多個網(wǎng)絡(luò)單元上；可以根據(jù)實際的需要選擇其中的部分或全部單元來實現(xiàn)本實施例方案的目的。
[0507]另外，在本發(fā)明各實施例中的各功能單元可以全部集成在一個處理模塊中，也可以是各單元分別單獨作為一個單元，也可以兩個或兩個以上單元集成在一個單元中；上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用硬件加軟件功能單元的形式實現(xiàn)。
[0508]本領(lǐng)域普通技術(shù)人員可以理解:實現(xiàn)上述方法實施例的全部或部分步驟可以通過程序指令相關(guān)的硬件來完成，前述的程序可以存儲于一計算機(jī)可讀取存儲介質(zhì)中，該程序在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟；而前述的存儲介質(zhì)包括:移動存儲設(shè)備、只讀存儲器(ROM, Read-Only Memory)、隨機(jī)存取存儲器(RAM, Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。
[0509]以上所述，僅為本發(fā)明的【具體實施方式】，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)以所述權(quán)利要求的保護(hù)范圍為準(zhǔn)。
【主權(quán)項】
1.一種信息處理方法，其特征在于，所述方法包括: 支付平臺查詢待支付信息； 依據(jù)所述待支付信息控制第一賬戶向第二賬戶進(jìn)行支付操作，并形成支付結(jié)果； 依據(jù)所述支付結(jié)果，生成支付反饋信息； 向所述第一賬戶和所述第二賬戶的客戶端發(fā)送所述支付反饋信息； 當(dāng)所述支付結(jié)果表明支付成功時，更新所述第一賬戶和所述第二賬戶的收支信息； 所述第一賬戶和所述第二賬戶均為注冊在所述支付平臺的操作賬號。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于， 所述依據(jù)所述待支付信息控制第一賬戶向第二賬戶進(jìn)行支付操作，并形成支付結(jié)果，包括: 依據(jù)所述待支付信息，判斷第一賬戶是否為滿足預(yù)設(shè)自動支付條件的賬戶； 當(dāng)所述第一賬戶為滿足預(yù)設(shè)自動支付條件的賬戶時，控制所述第一賬戶向所述第二賬戶進(jìn)行自動支付操作。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于， 所述依據(jù)所述待支付信息，判斷第一賬戶是否為滿足預(yù)設(shè)自動支付條件的賬戶，包括: 當(dāng)所述第一賬號向所述第二賬戶支付的支付截止日到期或指定支付日到期時，確定所述第一賬戶為滿足預(yù)設(shè)自動支付條件的賬戶； 其中，所述指定支付日為所述第一賬戶的用戶指定的且早于所述支付截止日的支付曰。
4.根據(jù)權(quán)利要求2所述的方法，其特征在于， 所述待支付信息包括待支付金額； 所述控制第一賬戶向所述第二賬戶進(jìn)行自動支付操作，包括: 依據(jù)所述待支付信息控制所述第一賬戶向所述第二賬戶進(jìn)行N次自動支付操作； 其中，第η次自動支付操作的支付金額為第η金額； 第η+1次自動支付操作在第I次至第η次自動支付操作的支付失敗時進(jìn)行，且第η+1金額小于第η金額； 所述N為不小I的正整數(shù)；所述η為小于所述N的正整數(shù)； 第I金額不大于所述待支付金額。
5.根據(jù)權(quán)利要求2所述的方法，其特征在于， 所述控制第一賬戶向所述第二賬戶進(jìn)行自動支付操作， 包括: 查詢所述第一賬戶的可用余額； 當(dāng)所述第一賬戶有可用余額時，依據(jù)待支付金額以及所述可用余額使所述第一賬戶向所述第二賬戶進(jìn)行支付操作，并形成支付結(jié)果。
6.根據(jù)權(quán)利要求4所述的方法，其特征在于， 所述當(dāng)所述第一賬戶有可用余額時，依據(jù)待支付金額以及所述可用余額使所述第一賬戶向所述第二賬戶進(jìn)行支付，并形成支付結(jié)果，包括: 當(dāng)所述第一賬戶的可用余額不小于所述待支付金額時，控制所述第一賬戶向所述第二賬戶進(jìn)行全額支付。
7.根據(jù)權(quán)利要求5所述的方法，其特征在于， 所述當(dāng)所述第一賬戶有可用余額時，依據(jù)待支付金額以及所述可用余額使所述第一賬戶向所述第二賬戶進(jìn)行支付，并形成支付結(jié)果，包括: 當(dāng)所述第一賬戶的可用余額小于所述待支付金額時，控制所述第一賬戶向所述第二賬戶進(jìn)行部分支付。
8.根據(jù)權(quán)利要求2所述的方法，其特征在于， 所述方法還包括: 判斷所述第一賬戶是否為滿足預(yù)設(shè)自動延期條件的賬戶； 當(dāng)所述第一賬戶為滿足所述預(yù)設(shè)自動延期條件的賬戶時，向所述第二賬戶的客戶端發(fā)送支付延期請求； 接收所述第二賬戶的客戶端基于所述支付延期請求形成的延期響應(yīng)； 依據(jù)所述延期響應(yīng)重新確定支付日。
9.根據(jù)權(quán)利要求1所述的方法，其特征在于， 所述待支付信息包括第一賬戶需向所述第二賬戶支付的待支付金額； 所述依據(jù)所述待支付信息控制第一賬戶向第二賬戶進(jìn)行支付操作，并形成支付結(jié)果，包括: 向第一賬戶的客戶端發(fā)送所述待支付信息； 接收所述第一賬戶的客戶端返回的實際支付金額； 控制所述第一賬戶向所述第二賬戶支付所述實際支付金額。
10.根據(jù)權(quán)利要求1、2或9所述的方法，其特征在于， 所述方法還包括: 核算支付結(jié)果； 當(dāng)依據(jù)所述支付結(jié)果確定第一賬戶向第二賬戶的支付金額超過待支付金額時，控制所述第二賬戶向所述第一賬戶進(jìn)行返款操作。
11.根據(jù)權(quán)利要求1、2或9所述的方法，其特征在于， 所述方法還包括: 接收所述第一賬戶的客戶端發(fā)送的登錄請求； 基于所述登錄請求查詢所述第一賬戶的待支付信息；所述待支付信息包括支付日和待支付金額； 響應(yīng)所述登錄請求，允許所述客戶端登錄并向所述客戶端發(fā)送包括所述待支付信息的第一登錄附加信息或第二登錄附件信息； 所述第一登錄附加信息，用于控制所述客戶端在登錄后顯示第一界面；所述第二登錄附加信息，用于控制所述客戶端在登錄后顯示第二界面； 所述第一界面不同于所述第二界面。
12.根據(jù)權(quán)利要求1、2或9所述的方法，其特征在于， 所述方法還包括: 核算所述第一賬戶的收支信息和支付結(jié)果；所述收支信息包括所述第一賬戶支付的實際支付日；所述支付結(jié)果中包括支付平臺或所述第二賬戶收到支付的收到支付日； 當(dāng)所述第一賬戶的支付信息表明所述實際支付日早于收到支付日時，以所述實際支付日校正支付結(jié)果。
13.一種支付平臺，其特征在于，所述支付平臺包括: 第一查詢單元，用于查詢待支付信息； 支付單元，用于依據(jù)所述待支付信息控制第一賬戶向第二賬戶進(jìn)行支付操作，并形成支付結(jié)果； 生成單元，用于依據(jù)所述支付結(jié)果，生成支付反饋信息； 發(fā)送單元，用于向所述第一賬戶和所述第二賬戶的客戶端發(fā)送所述支付反饋信息； 更新單元，用于當(dāng)所述支付結(jié)果表明支付成功時，更新所述第一賬戶和所述第二賬戶的收支信息； 所述第一賬戶和所述第二賬戶均為注冊在所述支付平臺的操作賬號。
14.根據(jù)權(quán)利要求13所述的支付平臺，其特征在于，所述支付平臺還包括: 判斷單元，用于依據(jù)所述待支付信息，判斷第一賬戶是否為滿足預(yù)設(shè)自動支付條件的賬戶； 所述支付單元，用于當(dāng)所述第一賬戶為滿足預(yù)設(shè)自動支付條件的賬戶時，控制所述第一賬戶向所述第二賬戶進(jìn)行自動支付操作。
15.根據(jù)權(quán)利要求14所述的支付平臺，其特征在于， 所述判斷單元，用于當(dāng)所述第一賬號向所述第二賬戶支付的支付截止日到期或指定支付日到期時，確定所述第一賬戶為滿足預(yù)設(shè)自動支付條件的賬戶； 其中，所述指定支付日為所述第一賬戶的用戶指定的且早于所述支付截止日的支付曰。
16.根據(jù)權(quán)利要求14所述的支付平臺，其特征在于， 所述待支付信息包括待支付金額； 所述支付單元，具體用于依據(jù)所述待支付信息控制所述第一賬戶向所述第二賬戶進(jìn)行N次自動支付操作； 其中，第η次自動支付操作的支付金額為第η金額； 第η+1次自動支付操作在第I次至第η次自動支付操作的支付失敗時進(jìn)行，且第η+1金額小于第η金額； 所述N為不小I的正整數(shù)；所述η為小于所述N的正整數(shù)； 第I金額不大于所述待支付金額。
17.根據(jù)權(quán)利要求14所述的支付平臺，其特征在于， 所述支付平臺還包括: 第二查詢單元，用于當(dāng)所述第一賬戶為滿足預(yù)設(shè)自動支付條件的賬戶時，查詢所述第一賬戶的可用余額； 所述支付單元，具體用于當(dāng)所述第一賬戶有可用余額時，依據(jù)待支付金額以及所述可用余額使所述第一賬戶向所述第二賬戶進(jìn)行支付操作，并形成支付結(jié)果。
18.根據(jù)權(quán)利要求17所述的支付平臺，其特征在于， 所述支付單元，具體用于當(dāng)所述第一賬戶的可用余額不小于所述待支付金額時，控制所述第一賬戶向所述第二賬戶進(jìn)行全額支付。
19.根據(jù)權(quán)利要求17所述的支付平臺，其特征在于， 所述支付平臺，具體用于當(dāng)所述第一賬戶的可用余額小于所述待支付金額時，控制所述第一賬戶向所述第二賬戶進(jìn)行部分支付。
20.根據(jù)權(quán)利要求14所述的支付平臺，其特征在于， 所述判斷單元還用于判斷所述第一賬戶是否為滿足預(yù)設(shè)自動延期條件的賬戶； 所述支付平臺還包括: 延期單元，用于當(dāng)所述第一賬戶為滿足所述預(yù)設(shè)自動延期條件的賬戶時，向所述第二賬戶的客戶端發(fā)送支付延期請求； 接收單元，用于接收所述第二賬戶的客戶端基于所述支付延期請求形成的延期響應(yīng)； 確定單元，用于依據(jù)所述延期響應(yīng)重新確定支付日。
21.根據(jù)權(quán)利要求13所述的支付平臺，其特征在于，所述支付平臺還包括接收單元； 所述發(fā)送單元，還用于向第一賬戶的客戶端發(fā)送所述待支付信息； 所述接收單元，用于接收所述第一賬戶的客戶端返回的實際支付金額； 所述支付單元，還用于控制所述第一賬戶向所述第二賬戶支付所述實際支付金額。
22.根據(jù)權(quán)利要求13、14或21所述的支付平臺，其特征在于， 所述支付平臺還包括: 核算單元，用于核算支付結(jié)果； 所述支付單元，還用于當(dāng)依據(jù)所述支付結(jié)果確定第一賬戶向第二賬戶的支付金額超過待支付金額時，控制所述第二賬戶向所述第一賬戶進(jìn)行返款操作。
23.根據(jù)權(quán)利要求13、14或21所述的支付平臺，其特征在于， 所述支付平臺還包括接收單元及響應(yīng)單元: 所述接收單元，用于接收所述第一賬戶的客戶端發(fā)送的登錄請求； 所述第一查詢單元，還用于基于所述登錄請求查詢所述第一賬戶的待支付信息；所述待支付信息包括支付日和待支付金額； 所述響應(yīng)單元，用于響應(yīng)所述登錄請求，允許所述客戶端登錄并向所述客戶端發(fā)送包括所述待支付信息的第一登錄附加信息或第二登錄附件信息； 所述第一登錄附加信息，用于控制所述客戶端在登錄后顯示第一界面；所述第二登錄附加信息，用于控制所述客戶端在登錄后顯示第二界面； 所述第一界面不同于所述第二界面。
24.根據(jù)權(quán)利要求13、14或21所述的支付平臺，其特征在于， 所述支付平臺還包括: 核算單元，用于核算所述第一賬戶的收支信息和支付結(jié)果；所述收支信息包括所述第一賬戶支付的實際支付日；所述支付結(jié)果中包括支付平臺或所述第二賬戶收到支付的收到支付日； 校正單元，用于當(dāng)所述第一賬戶的支付信息表明所述實際支付日早于收到支付日時，以所述實際支付日校正支付結(jié)果。
【專利摘要】本發(fā)明公開了一種信息處理方法及支付平臺，所述方法包括：支付平臺查詢待支付信息；依據(jù)所述待支付信息控制第一賬戶向第二賬戶進(jìn)行支付操作，并形成支付結(jié)果；依據(jù)所述支付結(jié)果，生成支付反饋信息；向所述第一賬戶和所述第二賬戶的客戶端發(fā)送所述支付反饋信息；當(dāng)所述支付結(jié)果表明支付成功時，更新所述第一賬戶和所述第二賬戶的收支信息；其中，所述第一賬戶和所述第二賬戶均為注冊在所述支付平臺的操作賬號。
【IPC分類】G06Q20-38, G06Q20-08
【公開號】CN104616141
【申請?zhí)枴緾N201410708248
【發(fā)明人】李德勝, 李文, 郭振聲
【申請人】深圳市騰訊計算機(jī)系統(tǒng)有限公司
【公開日】2015年5月13日
【申請日】2014年11月27日