本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種支付方法及支付系統(tǒng)。

背景技術(shù)：

隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的發(fā)展，移動(dòng)終端的普及率越來越高，在電子交易平臺(tái)的交易過程中，用戶使用移動(dòng)終端的頻率也越來越高，并且在電子交易平臺(tái)的交易環(huán)節(jié)中，越來越多的人通過移動(dòng)終端進(jìn)行支付。

在電子交易過程中，用戶主要考慮的是支付操作的安全性，那么，如何提高在電子交易中支付操作的安全性，就成為一個(gè)亟待解決的技術(shù)問題。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的主要目的是提供一種支付方法及支付系統(tǒng)，旨在有效提升支付操作的安全性。

為實(shí)現(xiàn)上述目的，本發(fā)明提出的支付方法，包括如下步驟：

客戶端接收用戶輸入的下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至收款方服務(wù)器；

所述收款方服務(wù)器將所述下單請(qǐng)求按照預(yù)設(shè)的簽名規(guī)則進(jìn)行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端；

所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至支付平臺(tái)；

所述支付平臺(tái)解密所述請(qǐng)求數(shù)據(jù)，獲取所述訂單信息；驗(yàn)證所述訂單信息的簽名，并在驗(yàn)證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進(jìn)行加密，并將加密后的支付憑證發(fā)送至所述客戶端；

所述客戶端解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具進(jìn)行支付操作。

可選的，所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請(qǐng)求數(shù)據(jù)的步驟包括：

在所述訂單信息中添加二進(jìn)制協(xié)議頭。

可選的，所述將所述支付憑證預(yù)設(shè)的加密方式進(jìn)行加密的步驟包括：

在所述支付憑證中添加二進(jìn)制協(xié)議頭。

可選的，所述支付方法還包括：

支付成功后，所述支付平臺(tái)向所述收款方服務(wù)器反饋支付成功信息。

可選的，所述向所述收款方服務(wù)器反饋支付成功信息的步驟包括：

所述支付平臺(tái)接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器；

判斷所述支付成功信息是否發(fā)送成功；

如果否，則記錄發(fā)送失敗的原因，并在到達(dá)預(yù)設(shè)時(shí)間時(shí)，再次向發(fā)送所述支付成功信息；

當(dāng)發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

為實(shí)現(xiàn)上述目的，本發(fā)明提出一種支付系統(tǒng)，包括客戶端、收款方服務(wù)器、支付平臺(tái)及支付工具；其中，

所述客戶端，用于接收用戶輸入的下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至所述收款方服務(wù)器；

所述收款方服務(wù)器，用于將所述下單請(qǐng)求按照預(yù)設(shè)的簽名規(guī)則進(jìn)行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端；

所述客戶端，用于將所述訂單信息按照預(yù)設(shè)的格式生成請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至支付平臺(tái)；

所述支付平臺(tái)，用于解密所述請(qǐng)求數(shù)據(jù)，獲取所述訂單信息；驗(yàn)證所述訂單信息的簽名，并在驗(yàn)證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進(jìn)行加密，并將加密后的支付憑證發(fā)送至所述客戶端；

所述客戶端，用于解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具；

所述支付工具，用于執(zhí)行支付操作。

可選的，所述客戶端用于在所述請(qǐng)求數(shù)據(jù)中添加二進(jìn)制協(xié)議頭。

可選的，所述支付平臺(tái)用于在所述支付憑證中添加二進(jìn)制協(xié)議頭。

可選的，所述支付平臺(tái)，還用于在支付成功后，向所述收款方服務(wù)器反饋支付成功信息。

可選的，所述支付平臺(tái)包括：執(zhí)行模塊與判斷模塊；其中，

所述執(zhí)行模塊，用于接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器；

所述判斷模塊，用于判斷所述支付成功信息是否發(fā)送成功；

所述執(zhí)行模塊，還用于在所述支付成功信息發(fā)送失敗后，記錄發(fā)送失敗的原因，并在到達(dá)預(yù)設(shè)時(shí)間時(shí)，再次向發(fā)送所述支付成功信息；

所述執(zhí)行模塊，還用于在發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

本發(fā)明的技術(shù)方案，通過對(duì)客戶端、收款方服務(wù)器及支付平臺(tái)之間的交互數(shù)據(jù)按照不同的方式進(jìn)行加密，有效保證了交互數(shù)據(jù)的安全性，進(jìn)而保證了提升了支付操作的安全性。

附圖說明

為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對(duì)實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動(dòng)的前提下，還可以根據(jù)這些附圖示出的結(jié)構(gòu)獲得其他的附圖。

圖1為本發(fā)明支付方法一實(shí)施例的流程圖；

圖2為本發(fā)明支付方法另一實(shí)施例的流程圖；

圖3為圖2中向所述收款方服務(wù)器反饋支付成功信息的步驟的流程圖；

圖4為本發(fā)明支付系統(tǒng)一實(shí)施例的模塊示意圖；

圖5為實(shí)現(xiàn)本發(fā)明支付系統(tǒng)一實(shí)施例的流程示意圖；

圖6為圖4中支付平臺(tái)一實(shí)施例的模塊示意圖。

本發(fā)明目的的實(shí)現(xiàn)、功能特點(diǎn)及優(yōu)點(diǎn)將結(jié)合實(shí)施例，參照附圖做進(jìn)一步說明。

具體實(shí)施方式

應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

現(xiàn)在將參考附圖描述實(shí)現(xiàn)本發(fā)明各個(gè)實(shí)施例的移動(dòng)終端。在后續(xù)的描述中，使用用于表示元件的諸如“模塊”、“部件”或“單元”的后綴僅為了有利于本發(fā)明的說明，其本身并沒有特定的意義。因此，“模塊”與“部件”可以混合地使用。

本發(fā)明提出一種支付方法。本發(fā)明的支付方法應(yīng)用于移動(dòng)終端，但不限于移動(dòng)終端。下面以移動(dòng)終端為例進(jìn)行說明：

如圖1所示，圖1為本發(fā)明支付方法一實(shí)施例的流程圖。

本實(shí)施的支付方法，包括如下步驟：

步驟S100、客戶端接收用戶輸入的下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至收款方服務(wù)器。

具體的，所述客戶端安裝于移動(dòng)終端內(nèi)。所述客戶端為對(duì)應(yīng)所述收款方服務(wù)器的應(yīng)用程序(比如，游戲客戶端等)。用戶在移動(dòng)終端上下載與游戲商提供的服務(wù)器對(duì)應(yīng)的客戶端。

當(dāng)用戶需要對(duì)客戶端進(jìn)行充值等支付動(dòng)作時(shí)，用戶可以通過客戶端上的充值模塊觸發(fā)充值界面，并選擇或自行輸入充值類型、充值數(shù)額等，并確定。客戶端根據(jù)用戶輸入的充值類型與充值數(shù)額生成下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至收款方服務(wù)器。

步驟S200、所述收款方服務(wù)器將所述下單請(qǐng)求按照預(yù)設(shè)的簽名規(guī)則進(jìn)行簽名，以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端。

具體的，所述收款方服務(wù)器需要向第三方支付平臺(tái)進(jìn)行注冊(cè)，以獲取相關(guān)信息：appId、appKey、appSecurity等，其中，appId用于表示不同的應(yīng)用，而appSecurity用于對(duì)訂單請(qǐng)求進(jìn)行簽名。

當(dāng)所述收款方服務(wù)器接收到所述下單請(qǐng)求后，根據(jù)以下簽名規(guī)則對(duì)訂單請(qǐng)求進(jìn)行簽名，進(jìn)而生成訂單信息。

簽名規(guī)則：

1，參數(shù)排序，將所有參數(shù)名按字母順序進(jìn)行排序，若遇到相同首字母，則看第二個(gè)字母，沒有值的參數(shù)(如null和””情況)不要參與簽名；

2，參與簽名的數(shù)據(jù)不要做URL Encoding，一律以UTF-8編碼參與簽名；

3，參與簽名的數(shù)據(jù)中，必須有字段data_timestamp；

4，參數(shù)拼接，將所有參數(shù)按k1＝v1&k2＝v2&k3＝v3…格式進(jìn)行拼接；

5，將第4步所得字符串后面加上“:”、appId、appSecurity，得到一個(gè)新的字符串，用md5對(duì)新字符串進(jìn)行摘要計(jì)算，得簽名字符串(也即，具有簽名的訂單信息)。

步驟S300、所述客戶端將所述訂單信息按照預(yù)設(shè)的格式生成請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至支付平臺(tái)(也即上述的第三方支付平臺(tái))。

具體的，當(dāng)所述客戶端接收到所述收款方服務(wù)器發(fā)送的訂單信息后，在所述訂單信息中添加二進(jìn)制協(xié)議頭，以生成加密的請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至所述第三方支付平臺(tái)。

在本步驟中，所述二進(jìn)制協(xié)議頭包含有64個(gè)字節(jié)，其中，0-3字節(jié)表示appId；4-5字節(jié)表示接口編號(hào)；6-7字節(jié)表示版本號(hào)；8-39字節(jié)表示一個(gè)會(huì)話；40字節(jié)表示加密方式；41-42用于校驗(yàn)；其他字節(jié)數(shù)保留。也即，所述請(qǐng)求數(shù)據(jù)包括二進(jìn)制協(xié)議頭與具有簽名的訂單信息。

步驟S400、所述支付平臺(tái)解密所述請(qǐng)求數(shù)據(jù)，獲取所述訂單信息；驗(yàn)證所述訂單信息的簽名，并在驗(yàn)證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進(jìn)行加密，并將加密后的支付憑證發(fā)送至所述客戶端。

具體的，當(dāng)所述支付平臺(tái)接收到所述請(qǐng)求數(shù)據(jù)后，先對(duì)所述請(qǐng)求數(shù)據(jù)進(jìn)行解密分析，以獲得包含在所述請(qǐng)求數(shù)據(jù)中的具有簽名的訂單信息。然后對(duì)簽名進(jìn)行驗(yàn)證，當(dāng)驗(yàn)證驗(yàn)證通過后，保存所述訂單信息，并根據(jù)所述訂單信息生成支付憑證。接著，在所述支付憑證中添加二進(jìn)制協(xié)議頭，以加密所述支付憑證。最后，將加密后的支付憑證發(fā)送至所述客戶端。

在本步驟中，所述二進(jìn)制協(xié)議頭包含有32字節(jié)，其中，0-1字節(jié)表示接口編號(hào)；2字節(jié)表示加密方式；3-4字節(jié)用戶校驗(yàn)；8-11字節(jié)表示錯(cuò)誤碼；其他字節(jié)保留。也即，鎖住支付憑證包括二進(jìn)制協(xié)議頭與支付憑證的真實(shí)信息。

步驟S500、所述客戶端解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具進(jìn)行支付操作。

具體的，當(dāng)所述客戶端接收到所述支付憑證后，解密所述支付憑證，以獲取支付憑證中包含的真實(shí)信息，并根據(jù)該真實(shí)信息調(diào)用支付工具(安裝于移動(dòng)終端內(nèi)的應(yīng)用程序，比如，微信、支付寶、手機(jī)銀行等)進(jìn)行支付操作。

本實(shí)施例的支付方法，通過對(duì)客戶端、收款方服務(wù)器及支付平臺(tái)之間的交互數(shù)據(jù)按照不同的方式進(jìn)行加密，有效保證了交互數(shù)據(jù)的安全性，進(jìn)而保證了提升了支付操作的安全性。

進(jìn)一步的，如圖2及圖3所示，圖2為本發(fā)明支付方法另一實(shí)施例的流程圖；圖3為圖2中向所述收款方服務(wù)器反饋支付成功信息的步驟的流程圖。

基于上述實(shí)施例，在本實(shí)施例中，所述支付方法還包括：

步驟S600、支付成功后，所述支付平臺(tái)向所述收款方服務(wù)器反饋支付成功信息。

在本實(shí)施例中，所述向所述收款方服務(wù)器反饋支付成功信息的步驟包括：

步驟S610、所述支付平臺(tái)接收所述支付工具反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器。

具體的，當(dāng)支付成功后，所述支付工具向所述支付平臺(tái)反饋支付成功信息，以通知所述支付平臺(tái)對(duì)訂單狀態(tài)進(jìn)行變更。所述支付平臺(tái)將訂單狀態(tài)變更為已付款后，向所述收款方服務(wù)器發(fā)送支付成功信息，以通知所述收款方服務(wù)器對(duì)訂單狀態(tài)進(jìn)行變更。

步驟S620、判斷所述支付成功信息是否發(fā)送成功；

如果是，則流程結(jié)束。

如果否，則執(zhí)行步驟S630。

步驟S630、記錄發(fā)送失敗的原因，并在到達(dá)預(yù)設(shè)時(shí)間時(shí)，再次向發(fā)送所述支付成功信息。

具體的，當(dāng)所述支付平臺(tái)向所述收款方服務(wù)器發(fā)送了支付成功信息后，判斷是否接收到相應(yīng)的反饋，如果否，則認(rèn)定該次發(fā)送失敗。當(dāng)判定為發(fā)送失敗后，記錄該次發(fā)送失敗的原因，并在預(yù)設(shè)的時(shí)間到達(dá)后，再次向所述收款方服務(wù)器發(fā)送該支付成功信息。如此循環(huán)，至發(fā)送成功，或發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)(比如8次)后停止發(fā)送。

步驟S640、當(dāng)發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件。

具體的，當(dāng)發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器發(fā)送預(yù)警郵件

值得一提的是，在預(yù)警郵件中設(shè)置有回調(diào)機(jī)制，運(yùn)營人員收到發(fā)送的預(yù)警郵件后，并更改了出錯(cuò)的問題，可以在郵件中點(diǎn)擊“手動(dòng)回調(diào)”按鈕，再次執(zhí)行上述通知收款方服務(wù)器支付成功信息的步驟。

本實(shí)施例的技術(shù)方案，通過多次送達(dá)及郵件預(yù)警機(jī)制，極大地提升了支付成功的幾率，保證了用戶的體驗(yàn)度。

本發(fā)明還提出一種支付系統(tǒng)。本發(fā)明的支付系統(tǒng)應(yīng)用于移動(dòng)終端，但不限于移動(dòng)終端。下面以移動(dòng)終端為例進(jìn)行說明：

如圖4所示，圖4為本發(fā)明支付系統(tǒng)一實(shí)施例的模塊示意圖。

本實(shí)施例的支付系統(tǒng)包括客戶端110、收款方服務(wù)器120、支付平臺(tái)130及支付工具140；其中，所述客戶端110，用于接收用戶輸入的下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至所述收款方服務(wù)器120；所述收款方服務(wù)器120，用于將所述下單請(qǐng)求按照預(yù)設(shè)的簽名規(guī)則進(jìn)行簽名以生成訂單信息，并將所述訂單信息發(fā)送至所述客戶端110；所述客戶端110，用于將所述訂單信息按照預(yù)設(shè)的格式生成請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至支付平臺(tái)130；所述支付平臺(tái)130，用于解密所述請(qǐng)求數(shù)據(jù)，獲取所述訂單信息；驗(yàn)證所述訂單信息的簽名，并在驗(yàn)證成功后生成支付憑證；將所述支付憑證按照預(yù)設(shè)的加密方式進(jìn)行加密，并將加密后的支付憑證發(fā)送至所述客戶端110；所述客戶端110，用于解密所述支付憑證，并根據(jù)所述支付憑證中的支付信息調(diào)用支付工具140；所述支付工具140，用于執(zhí)行支付操作。

具體的，所述客戶端110安裝于移動(dòng)終端內(nèi)。所述客戶端110為對(duì)應(yīng)所述收款方服務(wù)器120的應(yīng)用程序(比如，游戲客戶端110等)。用戶在移動(dòng)終端上下載與游戲商提供的服務(wù)器對(duì)應(yīng)的客戶端110。當(dāng)用戶需要對(duì)客戶端110進(jìn)行充值等支付動(dòng)作時(shí)，用戶可以通過客戶端110上的充值模塊觸發(fā)充值界面，并選擇或自行輸入充值類型、充值數(shù)額等，并確定。客戶端110根據(jù)用戶輸入的充值類型與充值數(shù)額生成下單請(qǐng)求，并將所述下單請(qǐng)求發(fā)送至收款方服務(wù)器120。

所述收款方服務(wù)器120需要向第三方支付平臺(tái)130進(jìn)行注冊(cè)，以獲取相關(guān)信息：appId、appKey、appSecurity等，其中，appId用于表示不同的應(yīng)用，而appSecurity用于對(duì)訂單請(qǐng)求進(jìn)行簽名。當(dāng)所述收款方服務(wù)器120接收到所述下單請(qǐng)求后，根據(jù)以下簽名規(guī)則對(duì)訂單請(qǐng)求進(jìn)行簽名，進(jìn)而生成訂單信息。

簽名規(guī)則：

1，參數(shù)排序，將所有參數(shù)名按字母順序進(jìn)行排序，若遇到相同首字母，則看第二個(gè)字母，沒有值的參數(shù)(如null和””情況)不要參與簽名；

2，參與簽名的數(shù)據(jù)不要做URL Encoding，一律以UTF-8編碼參與簽名；

3，參與簽名的數(shù)據(jù)中，必須有字段data_timestamp；

4，參數(shù)拼接，將所有參數(shù)按k1＝v1&k2＝v2&k3＝v3…格式進(jìn)行拼接；

5，將第4步所得字符串后面加上“:”、appId、appSecurity，得到一個(gè)新的字符串，用md5對(duì)新字符串進(jìn)行摘要計(jì)算，得簽名字符串(也即，具有簽名的訂單信息)。

當(dāng)所述客戶端110接收到所述收款方服務(wù)器120發(fā)送的訂單信息后，在所述訂單信息中添加二進(jìn)制協(xié)議頭，以生成加密的請(qǐng)求數(shù)據(jù)，并將所述請(qǐng)求數(shù)據(jù)發(fā)送至所述第三方支付平臺(tái)130。所述二進(jìn)制協(xié)議頭包含有64個(gè)字節(jié)，其中，0-3字節(jié)表示appId；4-5字節(jié)表示接口編號(hào)；6-7字節(jié)表示版本號(hào)；8-39字節(jié)表示一個(gè)會(huì)話；40字節(jié)表示加密方式；41-42用于校驗(yàn)；其他字節(jié)數(shù)保留。也即，所述請(qǐng)求數(shù)據(jù)包括二進(jìn)制協(xié)議頭與具有簽名的訂單信息。

當(dāng)所述支付平臺(tái)130接收到所述請(qǐng)求數(shù)據(jù)后，先對(duì)所述請(qǐng)求數(shù)據(jù)進(jìn)行解密分析，以獲得包含在所述請(qǐng)求數(shù)據(jù)中的具有簽名的訂單信息。然后對(duì)簽名進(jìn)行驗(yàn)證，當(dāng)驗(yàn)證通過后，保存所述訂單信息，并根據(jù)所述訂單信息生成支付憑證。接著，在所述支付憑證中添加二進(jìn)制協(xié)議頭，以加密所述支付憑證。最后，將加密后的支付憑證發(fā)送至所述客戶端110。所述二進(jìn)制協(xié)議頭包含有32字節(jié)，其中，0-1字節(jié)表示接口編號(hào)；2字節(jié)表示加密方式；3-4字節(jié)用戶校驗(yàn)；8-11字節(jié)表示錯(cuò)誤碼；其他字節(jié)保留。也即，鎖住支付憑證包括二進(jìn)制協(xié)議頭與支付憑證的真實(shí)信息。

當(dāng)所述客戶端110接收到所述支付憑證后，解密所述支付憑證，以獲取支付憑證中包含的真實(shí)信息，并根據(jù)該真實(shí)信息調(diào)用支付工具140(安裝于移動(dòng)終端內(nèi)的應(yīng)用程序，比如，微信、支付寶、手機(jī)銀行等)進(jìn)行支付操作。

本實(shí)施例的支付系統(tǒng)，通過對(duì)客戶端110、收款方服務(wù)器120及支付平臺(tái)130之間的交互數(shù)據(jù)按照不同的方式進(jìn)行加密，有效保證了交互數(shù)據(jù)的安全性，進(jìn)而保證了提升了支付操作的安全性。

進(jìn)一步的，如圖圖5及6所示，圖5為實(shí)現(xiàn)本發(fā)明支付系統(tǒng)一實(shí)施例的流程示意圖；圖6為圖4中支付平臺(tái)一實(shí)施例的模塊示意圖。

基于上述實(shí)施例，在本實(shí)施例中，所述支付平臺(tái)130，還用于在支付成功后，向所述收款方服務(wù)器120反饋支付成功信息。

所述支付平臺(tái)130包括：執(zhí)行模塊132與判斷模塊134；其中，所述執(zhí)行模塊132，用于接收所述支付工具140反饋的支付成功信息，并將所述支付成功信息發(fā)送至所述收款方服務(wù)器120；所述判斷模塊134，用于判斷所述支付成功信息是否發(fā)送成功；所述執(zhí)行模塊132，還用于在所述支付成功信息發(fā)送失敗后，記錄發(fā)送失敗的原因，并在到達(dá)預(yù)設(shè)時(shí)間時(shí)，再次向發(fā)送所述支付成功信息；所述執(zhí)行模塊132，還用于在發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器120發(fā)送預(yù)警郵件。

具體的，當(dāng)支付成功后，所述支付工具140向所述支付平臺(tái)130反饋支付成功信息，以通知所述支付平臺(tái)130對(duì)訂單狀態(tài)進(jìn)行變更。所述支付平臺(tái)130將訂單狀態(tài)變更為已付款后，向所述收款方服務(wù)器120發(fā)送支付成功信息，以通知所述收款方服務(wù)器120對(duì)訂單狀態(tài)進(jìn)行變更。

當(dāng)所述支付平臺(tái)130向所述收款方服務(wù)器120發(fā)送了支付成功信息后，判斷是否接收到相應(yīng)的反饋，如果是，則結(jié)束，如果否，則認(rèn)定該次發(fā)送失敗。當(dāng)判定為發(fā)送失敗后，記錄該次發(fā)送失敗的原因，并在預(yù)設(shè)的時(shí)間到達(dá)后，再次向所述收款方服務(wù)器120發(fā)送該支付成功信息。如此循環(huán)，至發(fā)送成功，或發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)(比如8次)后停止發(fā)送。

當(dāng)發(fā)送失敗次數(shù)大于或等于預(yù)設(shè)次數(shù)時(shí)，保留最后一次發(fā)送失敗的原因，并向所述收款方服務(wù)器120發(fā)送預(yù)警郵件

值得一提的是，在預(yù)警郵件中設(shè)置有回調(diào)機(jī)制，運(yùn)營人員收到發(fā)送的預(yù)警郵件后，并更改了出錯(cuò)的問題，可以在郵件中點(diǎn)擊“手動(dòng)回調(diào)”按鈕，再次執(zhí)行上述通知收款方服務(wù)器120支付成功信息的步驟。

本實(shí)施例的技術(shù)方案，通過多次送達(dá)及郵件預(yù)警機(jī)制，極大地提升了支付成功的幾率，保證了用戶的體驗(yàn)度。

需要說明的是，在本文中，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下，由語句“包括一個(gè)……”限定的要素，并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。

上述本發(fā)明實(shí)施例序號(hào)僅僅為了描述，不代表實(shí)施例的優(yōu)劣。

通過以上的實(shí)施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到上述實(shí)施例方法可借助軟件加必需的通用硬件平臺(tái)的方式來實(shí)現(xiàn)，當(dāng)然也可以通過硬件，但很多情況下前者是更佳的實(shí)施方式?；谶@樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計(jì)算機(jī)軟件產(chǎn)品存儲(chǔ)在一個(gè)存儲(chǔ)介質(zhì)(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺(tái)終端設(shè)備(可以是移動(dòng)終端，計(jì)算機(jī)，服務(wù)器，空調(diào)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個(gè)實(shí)施例所述的方法。

以上僅為本發(fā)明的優(yōu)選實(shí)施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運(yùn)用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護(hù)范圍內(nèi)。