[發明專利]訂單處理方法、裝置、電子設備及存儲介質

在審

• 申請號: 202011118364.1
• 申請日: 2020-10-19
• 公開（公告）號: CN112200634A
• 公開（公告）日: 2021-01-08
• 發明（設計）人: 彭星
• 申請（專利權）人: 平安國際智慧城市科技股份有限公司
• 主分類號: G06Q30/06
• 分類號: G06Q30/06
• 代理公司: 北京鴻元知識產權代理有限公司 11327
• 代理人: 董永輝;曹素云

本發明涉及數據處理，公開一種訂單處理方法、裝置、電子設備及存儲介質，方法包括：向應用服務器和應用平臺發起內購請求并生成相應訂單；接收應用服務器返回的平臺訂單號，以及應用平臺返回的交易訂單號并進行關聯，調用所述內購框架，在應用平臺端完成內購請求的支付操作；確定接收到應用平臺返回的支付收據，基于平臺訂單號、交易訂單號和收據生成訂單信息，保存訂單信息，并將訂單的訂單狀態設置為待同步狀態；當檢測到對應于內購請求的應用程序啟動時，將處于待同步狀態的訂單的訂單信息同步至應用服務器，以令應用服務器基于訂單信息發放與訂單對應的虛擬商品。本發明可以防止掉單、漏單現象，提高用戶的使用體驗。

技術領域

本發明涉及數據處理領域，尤其涉及一種訂單處理方法、裝置及計算機可讀存儲介質。

背景技術

隨著移動互聯網的快速發展，越來越多的應用上架到應用平臺(為手機、平板電腦等提供免費、收費游戲、軟件應用下載服務的平臺)，并衍生出大量的虛擬商品，這些應用可能是免費的，但是有些應用里面會有一些虛擬商品是收費的，需要進行支付，比如游戲應用內的虛擬道具、社交應用內的虛擬禮物等。這樣在應用內部收費的支付模式，稱之為內購。

目前內購是在應用中內嵌內購框架，應用使用內購框架與應用平臺進行數據傳輸。以蘋果公司為例，為保護用戶隱私，蘋果公司不給商品提供商出具用戶內購信息，也不追蹤商品提供商是否發放商品。一旦用戶內購的虛擬商品沒有到賬，與應用提供商出現分歧時，很難查詢到用戶是否真正內購了此虛擬商品，以蘋果手機為例，IOS(蘋果手機專用操作系統)內購的流程框架如圖1所示，其內購的步驟流程如下：

應用通過StoreKit(內購框架)連接到應用平臺，以提示并安全地處理付款；

應用平臺通過StoreKit將用戶內購的商品的相關信息返回到應用；

應用通過應用服務器驗證支付憑證。

對于自動訂閱的商品，蘋果會通知到應用服務器，但對于非自動訂閱的商品，訂單狀態的同步則依賴于應用。發明人發現，當用戶出現弱網或斷網或退出應用等操作時，應用與應用服務器斷開連接，訂單狀態無法及時同步，出現用戶支付成功而商品發放不成功的情況。從而出現掉單、漏單的情況，發明人意識到，這在給客戶帶來經濟損失的同時也給公司帶來了不良影響。

發明內容

本發明提供一種訂單處理方法、裝置、電子設備及存儲介質，其主要目的在于防止了內購時掉單、漏單現象。

為實現上述目的，本發明提供的一種訂單處理方法，包括：

終端向應用服務器和應用平臺發起內購請求并生成相應訂單，其中，利用內置的內購框架向所述應用平臺發起所述內購請求；

接收所述應用服務器返回的平臺訂單號，以及所述應用平臺返回的交易訂單號，將所述平臺訂單號和所述交易訂單號進行關聯，并調用所述內購框架，在所述應用平臺端完成所述內購請求的支付操作；

確定接收到所述應用平臺返回的支付收據，基于所述平臺訂單號、所述交易訂單號和所述收據生成訂單信息，保存所述訂單信息，并將所述訂單的訂單狀態設置為待同步狀態；

當檢測到對應于所述內購請求的應用程序啟動時，將處于待同步狀態的訂單的訂單信息同步至應用服務器，以令所述應用服務器基于所述訂單信息發放與所述訂單對應的虛擬商品。

本發明還提供一種訂單處理裝置，所述裝置包括：

內購請求模塊，用于向應用服務器和應用平臺發起內購請求并生成相應訂單，其中，利用內置的內購框架向所述應用平臺發起所述內購請求；

訂單關聯模塊，用于接收所述應用服務器返回的平臺訂單號，以及所述應用平臺返回的交易訂單號，將所述平臺訂單號和所述交易訂單號進行關聯，并調用所述內購框架，在所述應用平臺端完成所述內購請求的支付操作；