IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ▲騰▼▲訊▼科技(深▲セン▼)有限公司の特許一覧

特許7039110支払い方法、装置、関連デバイス、システム及びコンピュータプログラム
<>
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図1
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図2
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図3
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図4
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図5
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図6a
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図6b
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図7
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図8
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図9
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図10
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図11
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図12
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図13
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図14
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図15
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図16
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図17
  • 特許-支払い方法、装置、関連デバイス、システム及びコンピュータプログラム 図18
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-11
(45)【発行日】2022-03-22
(54)【発明の名称】支払い方法、装置、関連デバイス、システム及びコンピュータプログラム
(51)【国際特許分類】
   G06Q 20/12 20120101AFI20220314BHJP
【FI】
G06Q20/12
【請求項の数】 24
(21)【出願番号】P 2020545730
(86)(22)【出願日】2019-04-11
(65)【公表番号】
(43)【公表日】2021-06-17
(86)【国際出願番号】 CN2019082281
(87)【国際公開番号】W WO2019218817
(87)【国際公開日】2019-11-21
【審査請求日】2020-09-01
(31)【優先権主張番号】201810463712.5
(32)【優先日】2018-05-15
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】517392436
【氏名又は名称】▲騰▼▲訊▼科技(深▲セン▼)有限公司
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】▲鮑▼ ▲東▼坡
(72)【発明者】
【氏名】王 松健
(72)【発明者】
【氏名】▲デン▼ 建威
(72)【発明者】
【氏名】▲呉▼ ▲鋭▼洲
(72)【発明者】
【氏名】▲曾▼ 丹
(72)【発明者】
【氏名】▲費▼ ▲強▼
(72)【発明者】
【氏名】▲陳▼ ▲寧▼国
【審査官】岡北 有平
(56)【参考文献】
【文献】国際公開第2017/050069(WO,A1)
【文献】国際公開第2016/020971(WO,A1)
【文献】特開2009-026115(JP,A)
【文献】特開2007-102590(JP,A)
【文献】米国特許出願公開第2010/0223153(US,A1)
【文献】特開2008-129635(JP,A)
【文献】特表2003-534604(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
支払い方法であって、
処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するステップであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、
前記処理サーバが前記支払い注文の支払伝票を取得するステップと、
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするステップと、
前記処理サーバがマッチングされた前記マーチャント注文の状態をマッチング済みとしてマークするステップと、
前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークするステップと、
前記処理サーバがマッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するステップと、を含む支払い方法。
【請求項2】
前記処理サーバが前記マーチャントデバイスによって生成された前記マーチャント注文にバインドされた前記支払い注文を決定する前記ステップは、
前記処理サーバが、前記ユーザデバイスの支払いプルアップリクエストを前記マーチャントデバイスに送信するステップであって、前記支払いプルアップリクエストが少なくとも前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスを指示するステップと、
前記処理サーバが、前記マーチャントデバイスによって送信された支払い注文生成リクエストを取得するステップであって、前記支払い注文生成リクエストが、前記仮想付加価値サービスに対応する前記マーチャント注文があることを少なくとも指示するステップと、
前記処理サーバが、前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた前記支払い注文を決定するステップと、を含む請求項1に記載の支払い方法。
【請求項3】
前記処理サーバが前記支払い注文の前記支払伝票を取得する前記ステップは、
前記処理サーバが前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信するステップと、
前記処理サーバが、前記支払い注文に対する前記ユーザデバイスによる支払いに対応する前記支払伝票を取得するステップと、を含む請求項1又は2に記載の支払い方法。
【請求項4】
前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた前記支払い注文を決定する前記ステップは、
前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定するステップと、
前記処理サーバが、前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文にバインドするステップであって、前記物品IDが支払いチャネルサーバに登録されるステップと、を含む請求項2に記載の支払い方法。
【請求項5】
前記支払い注文生成リクエストには少なくとも、前記マーチャント注文を一意に識別するためのマーチャント注文番号、及び前記マーチャント注文の前記取引価格が含まれ、
前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文の前記取引価格を決定する前記ステップは、
前記処理サーバが、前記支払い注文生成リクエストに含まれる前記マーチャント注文の前記取引価格を決定するステップを含み、
前記処理サーバが前記物品IDを前記マーチャント注文にバインドする前記ステップは、
前記処理サーバが、前記物品IDを前記マーチャント注文番号にバインドするステップを含む請求項4に記載の支払い方法。
【請求項6】
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングする前記ステップは、
前記物品IDにバインドされたマーチャント注文の数が1つである場合、前記処理サーバが、前記物品IDに一意にバインドされたマーチャント注文をマッチングするステップと、
前記物品IDにバインドされたマーチャント注文の数が複数である場合、前記処理サーバが、前記物品IDにバインドされた複数のマーチャント注文を前記ユーザデバイスに送信し、前記複数のマーチャント注文から前記ユーザデバイスによって決定されたマーチャント注文を、マッチングされた前記マーチャント注文とするステップと、を含み、
前記ユーザデバイスが同じ取引価格の仮想付加価値サービスに対する支払いをプルアップすることをリクエストする回数が、前記取引価格に対応する物品IDのポーリング回数に達した場合、前記物品IDによって、前記取引価格のマーチャント注文を繰り返してバインドする請求項5に記載の支払い方法。
【請求項7】
前記処理サーバが前記取引価格に対応する物品IDを決定する前記ステップは、
前記処理サーバが、前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、前記取引価格に対応する複数の物品IDから、前記順序に対応する物品IDを決定し、1つの取引価格が、順番に使用される複数の物品IDに対応するステップを含む請求項6に記載の支払い方法。
【請求項8】
前記処理サーバが、前記物品IDを前記マーチャント注文にバインドした後、前記マーチャント注文の状態を非マッチングとしてマークするステップと
をさらに含む請求項6に記載の支払い方法。
【請求項9】
前記支払伝票に基づき、決済データを決定するステップであって、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャント身分情報、前記ユーザデバイスに対応するユーザ身分情報、前記マーチャント注文のマーチャント注文番号のうちの少なくとも1つが含まれるステップと、
前記決済金額に基づき、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分するステップと、
をさらに含む請求項1に記載の支払い方法。
【請求項10】
支払い方法であって、
マーチャントデバイスが、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するステップと、
前記マーチャントデバイスが、支払い注文生成リクエストを処理サーバに送信するステップであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするステップと、
前記マーチャントデバイスが、前記処理サーバによって送信されたサービス提供通知を受信するステップであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文のマッチング後に、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークした後、送信されるステップと、
前記マーチャントデバイスが、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するステップと、
を含む支払い方法。
【請求項11】
前記マーチャントデバイスが、前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスに対応する前記マーチャント注文を生成する前記ステップは、
前記マーチャントデバイスが、前記ユーザデバイスの支払いプルアップリクエストを取得し、前記支払いプルアップリクエストが少なくとも前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスを指示するステップと、
前記マーチャントデバイスが、前記仮想付加価値サービスに対応する前記マーチャント注文を生成するステップと、を含む請求項10に記載の支払い方法。
【請求項12】
前記マーチャント注文は少なくとも、
前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格を含み、
前記マーチャントデバイスが前記支払い注文生成リクエストを前記処理サーバに送信する前記ステップは、
前記マーチャントデバイスが、少なくとも前記マーチャント注文番号と前記取引価格とが含まれる前記支払い注文生成リクエストを前記処理サーバに送信するステップ、を含む請求項11に記載の支払い方法。
【請求項13】
前記支払い注文は、前記取引価格に対応する物品IDで表され、1つの取引価格は、順番に使用される複数の物品IDに対応する請求項12に記載の支払い方法。
【請求項14】
前記マーチャントデバイスが、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供した後、マッチングされた前記マーチャント注文の注文状態をサービス提供済みの状態に更新するように、前記処理サーバに通知するステップ、をさらに含む請求項10に記載の支払い方法。
【請求項15】
支払い方法であって、
ユーザデバイスが、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するステップであって、前記支払い注文が、マーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、
前記ユーザデバイスが、前記支払い注文に対応する支払伝票を前記処理サーバに送信するステップと、
前記ユーザデバイスが、前記マーチャントデバイスによって提供された仮想付加価値サービスを取得するステップであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように、前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるステップと、
を含む支払い方法。
【請求項16】
前記ユーザデバイスがアプリケーションを介してマーチャントのサービスページにアクセスするステップと、
前記ユーザデバイスが、前記サービスページの仮想付加価値サービスの支払いプルアップ入口でクリック操作が実行されたことを検出した後、支払いプルアップリクエストを前記処理サーバに送信し、前記支払いプルアップリクエストが少なくとも前記仮想付加価値サービスを指示するステップと、
をさらに含む請求項15に記載の支払い方法。
【請求項17】
処理サーバに適用される支払い装置であって、
マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュールであって、前記マーチャント注文がユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュールと、
前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュールと、
前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュールと、
マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークするように配置される状態マークモジュールと、
マッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュールと、を含む支払い装置。
【請求項18】
少なくとも1つのメモリと少なくとも1つの処理チップを含む処理サーバであって、
前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項1から9のいずれか1項に記載の支払い方法のステップを実現する処理サーバ。
【請求項19】
マーチャントデバイスに適用される支払い装置であって、
ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュールと、
支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュールであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするために用いられる支払い注文生成リクエストモジュールと、
前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュールであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文のマッチング後に、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークした後、送信されるサービス提供通知受信モジュールと、
前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュールと、を含む支払い装置。
【請求項20】
少なくとも1つのメモリと少なくとも1つの処理チップを含むマーチャントデバイスであって、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項10から14のいずれか1項に記載の支払い方法のステップを実現するマーチャントデバイス。
【請求項21】
ユーザデバイスに適用される支払い装置であって、
処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュールであって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュールと、
前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュールと、
前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュールであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供することを前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるサービス取得モジュールと、を含む支払い装置。
【請求項22】
少なくとも1つのメモリと少なくとも1つの処理チップとを含むユーザデバイスであって、
前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項15又は16に記載の支払い方法のステップを実現するユーザデバイス。
【請求項23】
コンピュータに請求項1乃至16の何れか一項に記載の方法を実行させるコンピュータプログラム。
【請求項24】
支払いシステムであって、請求項18に記載の処理サーバと、請求項20に記載のマーチャントデバイスと、請求項22に記載のユーザデバイスとを含む支払いシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、2018年05月15日にて中国特許庁に提出され、出願番号が2018104637125であって、発明名称が「支払い方法、装置、関連デバイス及びシステム」である中国特許出願に基づく優先権を主張し、その全内容を本出願に参照により援用する。
【0002】
本出願は、データ処理の技術分野に関わり、具体的に、支払い方法、装置、関連デバイス及びシステムに関わる。
【背景技術】
【0003】
現在、ユーザが仮想付加価値サービスを購入する場合、仮想付加価値サービスの購入に対する支払いは、支払いチャネルによって実現される必要があり、より一般的には、ユーザがアプリケーション内で仮想付加価値サービスの購入を行う場合、モバイルオペレーティングシステムによって提供される支払いチャネルを使用して実現でき、例えばiOS(iOSは、Apple Inc.が開発したモバイルオペレーティングシステム)によって発行されたIAP(In APP Purchase:アプリ内支払い)、Android(アンドロイド(登録商標))によって発行されたGW(Google Wallet:グーグル・ウォレット)という支払いチャネルを使用して、アプリケーション内の仮想付加価値サービスの購入及び支払いを実現し、これらの支払いチャネルについて、主にアプリケーション内の仮想付加価値サービスの購入及び支払いをサポートするための、アプリ内支払いチャネルと見なされてもよい。
【発明の概要】
【発明が解決しようとする課題】
【0004】
プラットフォームレベルのアプリケーションの台頭に伴い、1つのアプリケーション内でアクセスされる、仮想付加価値サービスを提供するマーチャントがますます多くなり、複数のマーチャントが1つのアプリケーションにアクセスする場合、如何に複数のマーチャントによって提供される仮想付加価値サービスに対して支払いのサポートを行うかということは、現在、解決すべき緊急の問題になる。
【0005】
これに鑑みると、本出願の実施例は、1つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対して支払いサポートを行うための、支払い方法、装置、関連デバイス及びシステムを提供する。
【課題を解決するための手段】
【0006】
前記目的を達成するために、本出願の実施例は、以下の技術案を提供する。
【0007】
支払い方法であって、処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するステップであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、前記処理サーバが前記支払い注文の支払い伝票を取得するステップと、前記処理サーバが前記支払い伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするステップと、前記処理サーバがマッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するステップとを含む。
【0008】
本出願の実施例は、支払い方法をさらに提供し、マーチャントデバイスが、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するステップと、前記マーチャントデバイスが、支払い注文生成リクエストを処理サーバに送信するステップであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするステップと、前記マーチャントデバイスが前記処理サーバによって送信されたサービス提供通知を受信するステップであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、送信されるステップと、前記マーチャントデバイスが、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するステップと、を含む。
【0009】
本出願の実施例は、支払い方法をさらに提供し、ユーザデバイスが、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するステップであって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、前記ユーザデバイスが、前記支払い注文に対応する支払伝票を前記処理サーバに送信するステップと、前記ユーザデバイスが前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するステップであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるステップと、を含む。
【0010】
本出願の実施例は、処理サーバに適用される支払い装置をさらに提供し、前記支払い装置は、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュールであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュールと、前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュールと、前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュールと、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュールと、を含む。
【0011】
本出願の実施例は、少なくとも1つのメモリと少なくとも1つの処理チップとを含む処理サーバをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記処理サーバによって実行される支払い方法のステップを実現する。
【0012】
本出願の実施例は、マーチャントデバイスに適用される支払い装置をさらに提供し、前記支払い装置は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュールと、支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュールであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するようにリクエストするために用いられる支払い注文生成リクエストモジュールと、前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュールであって、前記サービス提供通知が、前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、送信されるサービス提供通知受信モジュールと、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュールと、を含む。
【0013】
本出願の実施例は、少なくとも1つのメモリと少なくとも1つの処理チップとを含むマーチャントデバイスをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記マーチャントデバイスによって実行される支払い方法のステップを実現する。
【0014】
本出願の実施例は、ユーザデバイスに適用される支払い装置をさらに提供し、前記支払い装置は、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュールであって、前記支払い注文が、マーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュールと、前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュールと、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュールであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるサービス取得モジュールと、を含む。
【0015】
本出願の実施例は、少なくとも1つのメモリと少なくとも1つの処理チップとを含むユーザデバイスをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記由ユーザデバイスによって実行される支払い方法のステップを実現する。
【0016】
本出願の実施例は、記憶媒体をさらに提供し、前記記憶媒体には、上記の処理サーバによって実行される支払い方法のステップ、又は上記のマーチャントデバイスによって実行される支払い方法のステップ、又は上記のユーザデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。
【0017】
本出願の実施例は、上記の処理サーバと、上記のマーチャントデバイスと、上記のユーザデバイスとを含む支払いシステムをさらに提供する。
【0018】
上記の技術案によれば、ユーザデバイスが仮想付加価値サービスを購入する場合、マーチャントデバイスは、仮想付加価値サービスに対応するマーチャント注文を生成でき、処理サーバは、支払いチャネルに適しており、かつ前記マーチャント注文にバインドされた支払い注文を決定し、このようにして、ユーザデバイスが支払い注文を支払って、仮想付加価値サービスを購入した後、処理サーバは、ユーザデバイスによって支払われた支払い注文に基づき、バインドされたマーチャント注文を照会し、サービスを提供するマーチャント注文を正確的にマーチャントデバイスに通知することを実現することができ、これによって、ユーザデバイスが支払いを完了した後、ユーザデバイスが購入した仮想付加価値サービスの正確的な提供が実現される。
【0019】
同時、本出願の実施例において、ユーザの支払い行為と実際に購入された仮想付加価値サービスは、支払い注文とマーチャント注文とのバインドを介して関連付けることができるから、アプリケーション内に複数のマーチャントが存在する場合、ユーザは、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文(即ち、マーチャント注文)の照会を実現し、1つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができる。
【図面の簡単な説明】
【0020】
本出願の実施例又は関連技術における技術案をより明らかに説明するために、以下は、実施例又は関連技術の説明において使用される必要がある図面を簡単に紹介し、明らかに、以下の説明における図面は、本出願の実施例のみであり、当業者にとって、創造的な作業なしに、提供された図面に基づいて他の図面を得ることができる。
【0021】
図1】本出願の実施例による支払いシステムのオプションの構成ブロック図である。
図2】本出願の実施例による支払い方法のシグナリングフローチャートである。
図3】物品IDと取引価格との関係の概略図である。
図4】ユーザデバイスに基づいて示される支払いプロセスの概略図である。
図5】本出願の実施例による支払い方法の他のシグナリングフローチャートである。
図6a】マーチャント注文の注文状態の第1の概略図である。
図6b】マーチャント注文の注文状態の第2の概略図である。
図7】本出願の実施例による支払い方法のオプションのフローチャートである。
図8】マーチャント注文の状態のマークの概略図である。
図9】ミニプログラムシナリオの支払い方法の例示図である。
図10】本出願の実施例による支払い装置の構成ブロック図である。
図11】本出願の実施例による支払い装置の他の構成ブロック図である。
図12】本出願の実施例による支払い装置の他の構成ブロック図である。
図13】本出願の実施例による支払い装置の他の構成ブロック図。
図14】本出願の実施例による処理サーバのハードウェア構成ブロック図である。
図15】本出願の実施例による支払い装置の他の構成ブロック図である。
図16】本出願の実施例による支払い装置の他の構成ブロック図である。
図17】本出願の実施例による支払い装置の他の構成ブロック図である。
図18】本出願の実施例による支払い装置の他の構成ブロック図である。
【発明を実施するための形態】
【0022】
ユーザがアプリケーション内で仮想付加価値サービスを購入する場合、従来の支払い方式の実現は主に以下の通りである。支払いチャネルにはいずれも独自の物品管理システムがある(例えば、IAP、GWなどのアプリ内支払いチャネルには独自の物品管理システムが存在する)ため、これらの支払いチャネルの要件に従って、支払いを行うには、支払いチャネルに適した支払い注文(例えば、IAP、GWなどのアプリ内支払いチャネルに適したアプリ内支払い注文)を構築する必要があり、任意選択で、アプリケーションは、マーチャントによって提供される仮想付加価値サービスを物品ID(Identification、識別子)に仮想化し、当該物品IDを支払いチャネルサーバに登録する必要があり、これに基づいて、ユーザは、従来の支払い方式で、仮想付加価値サービスを購入する場合、支払いチャネルをプルアップ(PULL UP)し、支払いチャネルサーバと通信し、前記物品IDに対応する支払い注文を支払うことで、仮想付加価値サービスを購入することができ、ユーザは、支払い注文に対する支払いを完了した後、仮想付加価値サービスを提供するように、マーチャントに通知するために、支払伝票を取得することができる。
【0023】
支払いチャネルサーバは、例えばIAP支払いチャネルのサーバ、GW支払いチャネルのサーバなどの、支払いチャネルのサーバであり、支払いチャネルサーバは主に、支払いチャネルに対応するサーバによって実現される。
【0024】
従来の支払い方式において、アプリケーションは主に、支払いチャネルサーバ上のアプリケーションのアカウントに基づいて、マーチャントによって提供される仮想付加価値サービスを物品IDに仮想化し(例えば、ソーシャルネットワークアプリケーションが、マーチャントの有料購読サービスをオンラインし、支払いにIAP支払いを使用する必要がある場合、ソーシャルネットワークアプリケーションの職員は、ソーシャルネットワークアプリケーションの、IAP支払いチャネルサーバに登録されたアカウントに基づき、マーチャントの有料購読サービスを物品IDに仮想化し、当該物品IDをIAP支払いチャネルサーバに登録する必要がある)、ユーザの支払いニーズを満たすための支払い注文を構築することであり、これは、アプリケーション内で1つのマーチャントのみがある場合、基本的な支払い要件を満たすことができるが、アプリケーション内で仮想付加価値サービスを提供する複数のマーチャントが存在する場合、従来の支払い方式には少なくとも以下の問題がある。
【0025】
従来の支払い方式において、物品IDは主に、支払いチャネルサーバ上のアプリケーションのアカウントに基づき登録され、仮想付加価値サービス注文に対するバインドをサポートしていなく、ユーザの支払い行為は実際の仮想付加価値サービス注文から分離されている。そのため、アプリケーション内に複数のマーチャントが存在する場合、ユーザは支払伝票を取得した後、支払伝票を介して仮想付加価値サービス注文を照会できない。
【0026】
このように、1つのアプリケーションに仮想付加価値サービスを提供する複数のマーチャントがアクセスする場合、従来の支払い解決方式は、複数のマーチャントの仮想付加価値サービスに対して効果的な支払いサポートを提供することができない。
【0027】
上記の欠陥を解決するために、本出願の実施例は、支払いシステムのアーキテクチャを調整するとともに、支払いロジックを調整する。本出願の実施例の技術案は、本出願の実施例における図面と併せて、以下に明らか且つ完全に説明され、明らかに、説明される実施例は全ての実施例ではなく、本出願の実施例の一部にすぎない。本出願における実施例に基づき、創造的な作業なしに当業者によって得られる他の全ての実施例は、本出願の保護範囲にあるものとする。
【0028】
図1は本出願の実施例による支払いシステムのオプションの構成ブロック図であり、図1に示すように、当該支払いシステムは、ユーザデバイス10と、マーチャントデバイス20と、アプリケーションサーバ30と、処理サーバ40と、支払いチャネルサーバ50とを含んでもよい。
【0029】
ユーザデバイスは、仮想付加価値サービスを購入するユーザが使用する電子デバイス、例えば、スマートフォン、タブレットなどのユーザ端末であってもよい。
【0030】
マーチャントデバイスは、仮想付加価値サービスを提供するマーチャントに対応する電子デバイスであってもよく、マーチャント端末又はマーチャントサーバのいずれかを使用して実現することができる。
【0031】
アプリケーションサーバは、プラットフォームレベルのアプリケーションに対応するサービスデバイスであって、主にアプリケーションサービスをユーザに提供し(例えばソーシャルネットワークアプリケーションサーバはソーシャルネットワークサービスをユーザに提供し、電子商取引サーバは電子商取引サービスをユーザに提供するなど)、異なるサービス機能の拡張及び延伸をサポートし(例えば、ソーシャルネットワークアプリケーションサーバはソーシャルネットワークアプリケーションサービスを提供することに加えて、セルフメディア(self-media)サービス、ミニプログラムサービスなどに拡張及び延伸されることもできる)、本出願の実施例において、マーチャントはアプリケーションサーバにアクセスし、アプリケーション内で仮想付加価値サービスを提供することができる。
【0032】
ユーザデバイスとマーチャントデバイスは、アプリケーションのアプリケーションインストールパッケージによって、前記アプリケーションをインストールすることができ、このように、ユーザデバイスとマーチャントデバイスは、インストールされたアプリケーションによって、アプリケーションサーバとインタラクトすることができる。
【0033】
処理サーバは、本出願の実施例の支払い方法を実現するための、アプリケーションサーバにアクセスする1組のサービスデバイスであり、オプションの実現において、処理サーバは、アプリケーションサーバに接続されるサービスデバイスであってもよく、処理サーバとユーザデバイス及びマーチャントデバイスとの間の通信は、アプリケーションサーバをブリッジとして使用することで実現されることができ、即ち、処理サーバとユーザデバイスとの間の通信は、アプリケーションサーバを中継として使用することで実現され、処理サーバとマーチャントデバイスとの間の通信は、アプリケーションサーバを中継として使用することで実現されることができる。
【0034】
支払いチャネルサーバは支払いチャネルに対応するサービスデバイスであって、例として、Androidオペレーティングシステムでは、支払いチャネルサーバは、アンドロイド(登録商標)から発行されたGW支払いチャネルに対応するGW支払いチャネルサーバであってもよく、iOSオペレーティングシステムでは、支払いチャネルサーバはiOSから発行されたIAP支払いチャネルに対応するIAP支払いチャネルサーバであってもよい。
【0035】
なお、図1は、オプションのシステムアーキテクチャのみであり、他のオプションの実現において、処理サーバは、アプリケーションサーバの新たに追加されたサービス機能として実現されてもよく、即ち、以下の処理サーバが実行するステップフローは、アプリケーションサーバに追加配置されたサービス機能の実現と見なされてもよい。
【0036】
上記のアプリ内支払いシステムに基づき、本出願の実施例によって提供される支払い方法を紹介する前に、本出願の実施例の使用背景をよりよく理解するために、以下は、マーチャントがアプリケーション内で仮想付加価値サービスを提供するいくつかの例示を挙げて、以下の例示において、ユーザは主にアプリケーションを介してマーチャントのサービスページをロードし、サービスページによって提供された仮想付加価値サービスから、仮想付加価値サービスを購入する。
【0037】
ソーシャルネットワークアプリケーションを例として、ソーシャルネットワークアプリケーションにおけるセルフメディアアカウント(例えば公式アカウント(Official Accounts)など)は、マーチャントとして、有料購読などの仮想付加価値サービスをユーザに提供することができ、ユーザは、本出願の実施例によって提供される支払い案を介して、異なるマーチャントによって提供されるサブスクリプションサービスを購入することができる。
【0038】
また、ソーシャルネットワークアプリケーションは、異なるプログラムのロード機能を拡張することができ、任意選択で、プログラムの作成者がプログラムを作成した後、プログラム内で、コンテンツの支払い、チャージなどの仮想付加価値サービスを提供するとともに、プログラムのリンクQRコード(登録商標)又はリンクアドレスを掲載することができ、ユーザがソーシャルネットワークアプリケーションを介して当該リンクQRコード(登録商標)をスキャンするか、又はリンクアドレスにアクセスした後、ソーシャルネットワークアプリケーションは、対応するページを介してプログラムページをロードし、このとき、ユーザが、プログラムページによって提供されるコンテンツの支払い、チャージなどの仮想付加価値サービスを購入する必要がある場合、本出願の実施例によって提供される支払いスキームによって実現されることができる。
【0039】
任意選択で、異なるプログラムのロード機能を拡張するソーシャルネットワークアプリケーションの典型的な例は、ウィーチャット(WeChat)のミニプログラム機能であり、ミニプログラムは、ダウンロード及びインストールを必要としなくても、使用できるプログラムであって、ユーザは、ウィーチャットを介して、ミニプログラムの2次元コードをスキャンするか、又はミニプログラムを検索することで、対応するミニプログラムのページをウィーチャットにロードすることができる。
【0040】
また、有料知識アプリケーションを例として、登録済みユーザは、有料知識アプリケーションで自分の専門知識を販売して、マーチャントになることができ、ユーザは、本出願の実施例によって提供される支払いスキームによって、異なるマーチャントの専門知識を購入することができる。
【0041】
上記の挙げられた例示から分かるように、同じアプリケーション内で仮想付加価値サービスを提供するマーチャントが複数いる場合(例えば仮想付加価値サービスを提供する複数のセルフメディアアカウント、異なるミニプログラムのマーチャント、専門知識を販売する異なるマーチャントなど)、本出願の実施例が実現しようとするのは、1つのアプリケーション内に、複数のマーチャントの仮想付加価値サービスに対して支払いサポートを提供することである。
【0042】
なお、ユーザとマーチャントのキャラクターは厳密に区別されるものではなく、同一人物がユーザとマーチャントのキャラクターを切り替える場合もあり、例えば、1つのセルフメディアアカウントの所有者は、有料購読などの仮想付加価値サービスをユーザに提供するマーチャントとして機能してもよく、他のセルフメディアアカウントによって提供される仮想付加価値サービスを支払うユーザとして機能してもよい。
【0043】
前述の紹介に基づき、本出願の実施例によって提供される支払い方法を以下に紹介する。オプションの実現として、図2は、本出願の実施例による支払い方法のシグナリングフローを示し、図2を参照し、当該フローは以下のステップを含んでもよい。
【0044】
ステップS10、ユーザデバイスは、ユーザデバイスが購入をリクエストする仮想付加価値サービスを少なくとも指示する支払いプルアップ(PULL UP)リクエストを処理サーバに送信する。
【0045】
任意選択で、ユーザデバイスはアプリケーションサーバによって、支払いプルアップリクエストを処理サーバに送信することができる。
【0046】
任意選択で、例として、ユーザデバイスはアプリケーションを介してあるマーチャントのサービスページにアクセスした後(例えば、ユーザデバイスはソーシャルネットワークアプリケーションを介してあるマーチャントのミニプログラムページにアクセスする)、当該サービスページは、当該マーチャントによって提供される少なくとも1つの仮想付加価値サービスの支払いプル入口を有してもよく、1つの支払いプル入口が1つの仮想付加価値サービスに対応する。
【0047】
任意選択で、ミニプログラムのシナリオでは、ユーザデバイスがアプリケーションを介してマーチャントのサービスページにアクセスするオプションの実現は以下の通りであり、ユーザデバイスはアプリケーションスを介して、マーチャントのプログラムページのリンクの2次元コードをスキャンするか、又は、アプリケーションを介してマーチャントのプログラムページのリンクアドレスにアクセスすることで、マーチャントのプログラムページをロードし、ロードされたプログラムページが当該マーチャントによって提供される少なくとも1つの仮想付加価値サービスの支払いプル入口を有する。
【0048】
ユーザがある仮想付加価値サービスの支払いプル入口をクリックすることは、当該ユーザが購入を必要とする仮想付加価値サービスを選択し、当該仮想付加価値サービスの支払いをプルアップするようにリクエストしたと見なすことができ、これによって、ユーザがクリックした支払いプル入口に基づき、ユーザデバイスは相応的に支払いプルアップリクエストを構築し、支払いプルアップリクエストによって少なくとも前記仮想付加価値サービスを指示することができる。
【0049】
なお、ユーザは、マーチャントのサービスページにおける仮想付加価値サービスの支払いプル入口をクリックし、仮想付加価値サービスに対する支払いをプルアップするように、リクエストする。
【0050】
ステップS11、処理サーバは前記支払いプルアップリクエストをマーチャントデバイスに送信する。
【0051】
処理サーバは前記支払いプルアップリクエストをユーザがアクセスしたサービスページに対応するマーチャントデバイスに転送することができる。
【0052】
任意選択で、処理サーバはアプリケーションサーバを介して支払いプルアップリクエストをマーチャントデバイスに送信することができる。
【0053】
オプションの実現として、前記支払いプルアップリクエストにはマーチャント識別子が含まれ、処理サーバは前記支払いプルアップリクエストを前記マーチャント識別子に対応するマーチャントデバイスに送信することができ、マーチャントのサービスページは対応するマーチャント識別子に関連付けられ、ユーザデバイスがアプリケーションを介してあるマーチャントのサービスページにアクセスする場合、ユーザデバイスがアクセスしたサービスページに関連付けられたマーチャント識別子に基づき、当該マーチャント識別子に対応するマーチャントデバイスに、前記支払いプルアップリクエストを送信することができる。
【0054】
任意選択で、処理サーバは各マーチャントに対応する商品識別子を設置してもよく、支払いプルアップリクエストに含まれる商品識別子(1つの商品識別子は、1つの仮想付加価値サービスを一意に識別することができる)によって、処理サーバは、前記商品識別子に対応するマーチャントを決定し、決定されたマーチャントに対応するマーチャントデバイスに、前記支払いプルアップリクエストを送信することができる。
【0055】
ステップS12、マーチャントデバイスは、前記支払いプルアップリクエストに基づき、前記仮想付加価値サービスに対応するマーチャント注文を生成する。
【0056】
理解するように、本出願の実施例は、ユーザデバイスが仮想付加価値サービスに対する支払いをプルアップするようにリクエストした後、対応する支払い注文を直接構築しなく、ユーザデバイスが支払い注文に基づき直接支払いを行わなく、本出願の実施例において、新たに追加配置される処理サーバは、ユーザデバイスが仮想付加価値サービスに対する支払いをプルアップしたことを、マーチャントデバイスに通知する必要があり、これにより、マーチャントデバイスは、独自の管理可能な、前記仮想付加価値サービスに対応するマーチャント注文を生成する。
【0057】
任意選択で、オプションの実現において、支払いプルアップリクエストには少なくとも前記仮想付加価値サービスに対応する商品識別子が含まれ、マーチャントデバイスが前記商品識別子に対応するマーチャント注文を構築することができる。
【0058】
ここで説明する必要があるのは、仮想付加価値サービスは1種の仮想商品と見なすことができるため、商品識別子を使用して仮想付加価値サービスを識別することができ、1つの商品識別子は1つの仮想付加価値サービスを一意に識別する。
【0059】
ステップS13、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信する。
【0060】
ここで言及される支払い注文生成リクエストは、対応する支払い注文を生成するように、処理サーバにリクエストするということを意味し、それによって、ユーザデバイスは、後続に支払い注文を利用して、仮想付加価値サービスを支払うことができる。
【0061】
任意選択で、マーチャントデバイスはアプリケーションサーバによって、支払い注文生成リクエストを処理サーバに送信することができる。
【0062】
ステップS14、処理サーバは、前記マーチャント注文にバインドされた支払い注文を決定する。
【0063】
IAP、GWなどの支払いチャネルにはいずれも独自の物品管理システムがあるため、支払いチャネルを使用して仮想付加価値サービスを支払う場合、支払いチャネルサーバに登録された物品IDの支払いによって実現されることが理解できる。そのため、マーチャントデバイスは、独自の管理可能なマーチャント注文を構築した後、IAP、GWなどの支払いチャネルに適した支払い注文を生成するようにリクエストするために、支払い注文生成リクエストを処理サーバに送信する必要がある。
【0064】
オプションの実現において、処理サーバは対応する物品IDを決定することで、支払い注文に対する決定を実現することができる。
【0065】
任意選択で、物品IDは取引価格に対応できる。図3は、物品IDと取引価格とのオプションの関係の概略図を示し、参照することができ、図3に示すように、1つの取引価格は、複数の対応する物品IDを有してもよく、当該複数の物品IDは順番に使用され、即ち、同じ取引価格の複数の物品IDは、ポーリングという方式で取引価格との対応を行い、図3に示すように、取引価格1は6つの対応する物品IDを有すると仮定すると、ユーザデバイスが取引価格1の仮想付加価値サービスに対する支払いをプルアップするように、連続且つ複数回リクエストするプロセスでは、1回目に取引価格1によって支払いをプルアップするようにリクエストする場合、物品ID1を使用して対応することができ、2回目に取引価格1によって支払いをプルアップするようにリクエストする場合、物品ID2を使用して対応することができ、このように類推すると、7回目に取引価格1によって支払いをプルアップするようにリクエストする場合、対応のために物品ID1にループする(即ち、7回目は1回目の物品IDと重複する)。
【0066】
明らかに、図3に示される取引価格と物品IDとの関係はオプションの状況にすぎず、実際の適用において、支払いチャネルによって、取引価格と物品IDとの関係も適合的に調整されてもよく、例えば1つの取引価格の1回の使用は、一意な物品IDに対応する。
【0067】
任意選択で、本出願の実施例において、処理サーバは少なくとも前記マーチャント注文の取引価格に基づき、前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文にバインドすることで、前記マーチャント注文にバインドされた支払い注文に対する決定を実現する。
【0068】
説明する必要があるのは、ステップS10からステップS14は、処理サーバがマーチャントデバイスによって生成されるマーチャント注文にバインドされた支払い注文を決定するためのオプションの実現のみであり、前記マーチャント注文は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する。
【0069】
ステップS10からステップS14において、処理サーバが主にユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信し、前記支払いプルアップリクエストは少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示し、これによって、マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された、少なくとも前記マーチャント注文があることを指示する支払い注文生成リクエストを取得し、さらに前記支払い注文生成リクエスト基づき、前記マーチャント注文にバインドされた支払い注文を決定する。しかしながら、これは、処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するためのオプションの実現にすぎず、本出願の実施例は、マーチャントデバイスがユーザデバイスが購入をリクエストした仮想付加価値サービスに対応するマーチャント注文を生成し後、処理サーバがマーチャント注文にバインドされた支払い注文を生成するという他の方式をサポートすることもできる。
【0070】
ステップS15、処理サーバは前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信する。
【0071】
任意選択で、処理サーバはアプリケーションサーバを介して支払いプルアップ通知をユーザデバイスに送信することができる。
【0072】
任意選択で、前記支払いプルアップ通知は、支払いチャネルをプルアップするようにユーザデバイスに通知することで、ユーザデバイスが前記支払い注文を支払うことができるために用いられてもよい。
【0073】
即ち、マーチャントデバイスは、仮想付加価値サービスを購入するようにリクエストする行為に対して、自身が管理し得るマーチャント注文を生成し、処理サーバによって、支払いチャネルに適合し、前記マーチャント注文にバインドされた支払い注文を生成した後、処理サーバは、ユーザデバイスに支払いプルアップ通知を送信して、支払いチャネルをプルアップするように、ユーザデバイスに通知することができ、ユーザデバイスが支払いチャネルによって前記支払い注文を支払うようにする。
【0074】
オプションの実現として、処理サーバは前記支払い注文に基づき、対応する支払い入口を生成し、処理サーバは、前記支払い入口をユーザデバイスに送信することで、支払いプルアップ通知を前記ユーザデバイスに送信することができ、これによって、ユーザデバイスが前記支払い入口を取得した後、支払いページを表示し、ユーザが前記支払いページで支払い認証入力操作を行った後、支払い注文に対する支払いを実現する。
【0075】
任意選択で、オプションの実現として、ステップS15において、マーチャントデバイスが、生成されたマーチャント注文にバインドされた支払い注文を決定するように、処理サーバはまずマーチャントデバイスに支払い注文を通知し、次に、支払いプルアップ通知をユーザデバイスに送信するように、マーチャントデバイスが処理サーバに通知し、即ち、ステップS15において、処理サーバがマーチャントデバイスに支払い注文を通知し、マーチャントデバイスのフィードバック応答を取得した後、処理サーバが支払いプルアップ通知を前記ユーザデバイスに送信してもよい(即ち、処理サーバはマーチャントデバイスの通知に基づき、前記ユーザデバイスに支払いプルアップ通知を送信する)。
【0076】
このように実現される主な目的は、マーチャントデバイスが、生成されたマーチャント注文にバインドされた支払い注文を決定して記録した後、ユーザデバイスの支払いをプルアップすることである。
【0077】
無論、上記の実現はオプションの方式にすぎず、本出願の実施例は、処理サーバが支払いプルアップ通知を前記ユーザデバイスに送信すると同時に、マーチャント注文にバインドされた支払い注文をマーチャントデバイスに通知することをサポートすることもできる。
【0078】
ステップS16、ユーザデバイスは、支払いチャネルをプルアップして、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。
【0079】
ユーザデバイスは、処理サーバによって送信された支払いプルアップ通知を受信した後、支払いチャネルをプルアップして、前記支払い注文に対する支払い認証入力操作を行うことができ(支払い認証入力操作は、支払いパスワード入力、支払い指紋入力、支払い顔入力などを含むが、これらに限定されていない)、これによって、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。
【0080】
オプションの実現として、ユーザデバイスは、前記支払い注文の支払い入口を受信し、対応する支払いページを表示することができ、これによって、ユーザが支払いページで支払い認証入力操作を行って、ユーザデバイスが、支払いページでのユーザの支払い認証入力操作に応答した後、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。
【0081】
一例として、本出願の実施例の支払いプロセスにおいて、ユーザデバイス側の表現は、図4に示される通りであってもよく、アプリケーション内のあるセルフメディアアカウント(例えば、図面において、名称が「有料論文」であるセルフメディアアカウント)の論文提供の有料購読を例として、ユーザが、当該セルフメディアアカウントのサービスページのある論文の有料購読ボタンをクリックした後、ユーザデバイスは、有料購読を指示するための支払いプルアップリクエストを構築することができ、これによって、マーチャント端末は、ユーザが有料購読をリクエストすることに対応するマーチャント注文を生成した後、対応する支払い注文を生成するように、処理サーバにリクエストし、処理サーバは、対応する支払い注文を生成し、マーチャント注文にバインドした後、支払い注文に対応する支払い入口をユーザデバイスに送信し、これによって、ユーザデバイスは、当該支払い入口を介して対応する支払いページを表示し、支払い認証入力操作を行って、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。
【0082】
ここで説明する必要があるのは、上記の支払いプルアップリクエストと、ここでの支払いリクエストは、2つの異なる段階にあるリクエストであり、支払いプルアップリクエストは主に、ユーザが支払いプル入口をクリックするときに生成され、主に支払いのプルアップをリクエストし、一方で、支払いリクエストは、支払いチャネルをプルアップし、ユーザが支払い認証入力操作を完了した後、形成される支払いリクエストであり、控除と支払いを行うように、支払いチャネルサーバにリクエストするためのリクエストである。
【0083】
ステップS17、ユーザデバイスは、支払いチャネルサーバによって送信された支払い注文の支払伝票を受信する。
【0084】
ステップS18、ユーザデバイスは前記支払伝票を処理サーバに送信する。
【0085】
任意選択で、ステップS15からステップS18は、処理サーバが前記支払い注文の支払伝票を取得するオプションの実現のみである。ステップS15からステップS18において、処理サーバは主に前記支払い注文に基づき、支払いプルアップ通知をユーザデバイスに送信し、これによって、ユーザデバイスが支払いを完了した後、前記ユーザデバイスが前記支払い注文を支払ったことに対応する支払伝票を取得する。ただし、これは、処理サーバが前記支払い注文の支払伝票を取得するオプションの実現のみであり、本出願の実施例は、処理サーバが前記支払い注文の支払伝票を取得するための他の実現をサポートすることもできる。
【0086】
任意選択で、支払いチャネルサーバはユーザの支払いリクエストに基づき、前記支払い注文に対するユーザの支払いを完了し、対応する支払伝票を生成し、前記支払伝票によって、ユーザが支払う支払い注文(例えば物品ID)を指示する。同時に、支払いチャネルサーバは、前記支払伝票をユーザデバイスに送信してから、ユーザデバイスによって前記支払伝票を処理サーバに送信することができる(任意選択で、ユーザデバイスはアプリケーションサーバを介して、前記支払伝票を処理サーバに送信することができる)。
【0087】
任意選択で、支払伝票はさらに、支払いの支払い結果を指示することもできる。
【0088】
任意選択で、支払い注文を示す物品IDは、アプリケーションを介して支払いチャネルサーバに登録されるため、支払いチャネルサーバが、物品IDに対応する支払伝票を生成した後、支払伝票をアプリケーションサーバに送信し、アプリケーションサーバによって、支払伝票を接続された処理サーバに伝送することができる。
【0089】
ステップS19、処理サーバは、前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングする。
【0090】
任意選択で、支払伝票は、ユーザデバイスが支払いを完了した物品IDを指示することができ、前記物品IDにバインドされたマーチャント注文をマッチングすることで、ステップS19を実現する。
【0091】
オプションの実現において、以上で説明された1つの取引価格が、順番に使用される複数の物品IDに対応する場合であれば、前記物品IDにバインドされたマーチャント注文の数は、1つ以上である可能性があり、明らかに、前記物品IDにバインドされたマーチャント注文の数が1つである場合、前記物品IDによって、一意にバインドされたマーチャント注文をマッチングすることができる。
【0092】
前記物品IDにバインドされたマーチャント注文の数が複数である場合、ユーザデバイスが意思決定に参加する必要があり(例えば、前記ユーザデバイスは同じ取引価格で、同じ取引価格の仮想付加価値サービスを購入するように複数回リクエストするが、当該複数回の購入リクエストの場合、前記ユーザデバイスは最終的な支払いを完了していない)、処理サーバは、物品IDにバインドされた複数のマーチャント注文をユーザデバイスに送信し、ユーザデバイスによって、前記支払い注文にバインドされた、マッチングされたマーチャント注文を決定することができる。
【0093】
無論、上記はオプションの実現にすぎない。1つの取引価格の1回の使用が、一意の物品IDに対応する場合、処理サーバは前記物品IDに基づき、一意にバインドされたマーチャント注文をマッチングすることができる。
【0094】
ステップS20、処理サーバは、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信する。
【0095】
任意選択で、処理サーバは、アプリケーションサーバによって前記サービス提供通知を前記マーチャントデバイスに送信することができる。
【0096】
このように、前記ユーザデバイスが前記支払い注文を支払って、前記処理サーバが前記支払いに対応する支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングした後、マーチャントデバイスは、前記処理サーバによって送信されたサービス提供通知を受信することができる。
【0097】
任意選択で、処理サーバは、前記支払い注文にバインドされたマーチャント注文をマッチングした後、サービス提供通知を前記マーチャントデバイスに送信することができる。マーチャントデバイスは、当該通知を受信した後、当該マーチャント注文によって指示される仮想付加価値サービスを決定し、対応する仮想付加価値サービスを前記ユーザデバイスに提供することができる。
【0098】
さらに、処理サーバは、マッチングされたマーチャント注文の注文状態がサービス提供待ちの状態であることをユーザデバイスに通知することもできる。
【0099】
さらに、マーチャントデバイスが当該通知を受信した後、ユーザデバイスは、サービスページをリフレッシュして、ユーザデバイスが、仮想付加価値サービスを使用する権限を有するようにし、これに対応して、処理サーバは、マッチングされたマーチャント注文の注文状態がサービス提供済みの状態であることをユーザデバイスに通知することができる。
【0100】
任意選択で、本出願の実施例はアプリ内支払いシナリオに適用され、これに対応して、上記の支払いプルアップリクエストは、アプリ内支払いプルアップリクエストであってもよく、支払い注文生成リクエストは、アプリ内支払い注文生成リクエストであってもよく、支払い注文は、アプリ内支払い注文であってもよく、支払いチャネルは、アプリ内支払いチャネルであってもよく、支払いリクエストは、アプリ内支払いリクエストであってもよく、支払伝票は、アプリ内支払伝票であってもよい。
【0101】
上記の支払い方法によれば、ユーザデバイスは、アプリケーション内で仮想付加価値サービスを購入する場合、マーチャントデバイスが、仮想付加価値サービスに対応するマーチャント注文を生成し、処理サーバによって、支払いチャネルに適し且つ前記マーチャント注文にバインドされた支払い注文を決定することができ、このようにして、ユーザデバイスが支払い注文を支払って、仮想付加価値サービスを購入した後、処理サーバが、ユーザデバイスによって支払われた支払い注文に基づき、バインドされたマーチャント注文を照会することができ、サービスを提供するマーチャント注文を正確的にマーチャントデバイスに通知することが実現され、これによって、ユーザデバイスが支払いを完了した後、ユーザデバイスが購入した仮想付加価値サービスに対する正確的な提供を実現する。
【0102】
同時に、本出願の実施例において、ユーザの支払い行為と実際に購入した仮想付加価値サービスに対して、支払い注文とマーチャント注文とのバインドによって関連付けを実現することができるから、アプリケーション内に複数のマーチャントが存在する場合、ユーザは、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文(即ちマーチャント注文)の照会を実現し、1つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対して支払いサポートを実現することができる。
【0103】
なお、上記の支払い方法において、ユーザが1つのマーチャントによって提供される仮想付加価値サービスに対して支払うシナリオを例として説明したが、複数のマーチャントのシナリオに拡張することができる。適応的に、複数のマーチャントのシナリオでは、マーチャント注文は、複数のマーチャントに対するものであり、相変わらず支払い注文とマーチャント注文とのバインドによって、ユーザが購入した異なる仮想付加価値サービスに対応するマーチャント注文を区分することができ、そして、複数のマーチャントが仮想付加価値サービスを提供するシナリオでは、各マーチャントのマーチャント注文に対する照会を実現することができ、以上の説明は、1つのマーチャントに基づいているが、複数のマーチャントのシナリオに拡張してもよく、ユーザが支払いを完了した後、異なるマーチャントのマーチャント注文に対する正確的なマッチングを実現する。
【0104】
さらに、本出願の実施例は、マーチャント注文番号によって、マーチャント注文を一意に識別することができ、物品IDが取引価格に対応する場合、マーチャントデバイスは、少なくともマーチャント注文の取引価格とマーチャント注文番号を処理サーバに入力することで、処理サーバからの物品IDの出力を実現し、支払い注文の決定を完了することができる。
【0105】
任意選択で、図5は、本出願の実施例による支払い方法の他のオプションのシグナリングフローを示し、図5に示すフローは、図2に示すフローのステップのいくつかの実現の詳細を示すが、図5は、オプションのフローのみを示し、図2に示すフローロジックの示唆で、図5と異なるフローを使用して、図2に示すフローロジックを実現することが完全に可能である。
【0106】
図5を参照し、当該フローは以下のステップを含んでもよい。
【0107】
ステップS30、ユーザデバイスは、処理サーバに支払いプルアップリクエストを送信し、前記支払いプルアップリクエストは少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する商品識別子を指示する。
【0108】
本出願の実施例において、商品識別子は、仮想付加価値サービスを一意に識別するために用いられてもよく、支払いプルアップリクエストに対応する商品識別子が含まれることによって、ユーザが購入をリクエストする仮想付加価値サービスに対する指示を実現することができる。
【0109】
オプションの実現として、マーチャントのサービスページの1つの支払いプルアップ入口は、1つの仮想付加価値サービスの商品識別子と関連付けられ、ユーザが、仮想付加価値サービスの支払いプル入口をクリックした後、ユーザデバイスは、ユーザによってクリックされた支払いプル入口に関連付けられた商品識別子を決定することができ、これによって、少なくとも前記商品識別子が含まれる支払いプルアップリクエストを生成し、前記商品識別子によって、前記仮想付加価値サービスに対する指示を行う。
【0110】
任意選択で、仮想付加価値サービスの商品識別子は、提供された仮想付加価値サービスに対してマーチャントによって設置された商品コード、出荷番号などであってもよく、1つの商品識別子は、対応する仮想付加価値サービスを一意に示すことができ、商品識別子は、支払いチャネルサーバに登録された物品IDと異なる。
【0111】
ステップS31、処理サーバは、前記支払いプルアップリクエストをマーチャントデバイスに送信する。
【0112】
ステップS32、マーチャントデバイスは、前記支払いプルアップリクエストに基づき、前記商品識別子に対応するマーチャント注文を生成し、前記マーチャント注文には少なくとも取引価格と、前記マーチャント注文を一意に識別するマーチャント注文番号とが含まれる。
【0113】
任意選択で、支払いプルアップリクエストに含まれる商品識別子に基づき、マーチャントデバイスは、前記商品識別子に対応するマーチャント注文を構築することができ、これによって、前記仮想付加価値サービスに対応するマーチャント注文の生成を実現する。
【0114】
同時に、マーチャント注文において、取引価格を指示してもよく、取引価格は、仮想付加価値サービスに対するマーチャントの定価によって決定されてもよく、さらに、ユーザが一度に複数の仮想付加価値サービスを購入するようにリクエストする場合、前記支払いプルアップリクエストにはさらに、前記仮想付加価値サービスの取引数が含まれてもよく、マーチャントデバイスは、前記取引数と仮想付加価値サービスの単価に基づき、取引価格を決定することができる。
【0115】
また、マーチャントデバイスによって生成されたマーチャント注文は、他のマーチャント及びこのマーチャントの他のマーチャント注文を区分するために、一意のマーチャント注文番号によって識別されることができる。
【0116】
本出願の実施例において、生成されたマーチャント注文は少なくとも、ユーザデバイスが今回、仮想付加価値サービスを購入するようにリクエストする基本的な情報、及びマーチャント注文を一意に識別するマーチャント注文番号を表すことができる。
【0117】
オプションの実現において、構築されたマーチャント注文には少なくとも、取引価格、及び前記マーチャント注文を一意に識別するマーチャント注文番号などが含まれ、さらに、マーチャント注文には、商品識別子、仮想付加価値サービスの取引数、一般配置情報、ユーザデバイスに対応するユーザの身分識別子(例えば、アプリケーション内のユーザのユーザアカウント)、マーチャントデバイスに対応するマーチャント身分識別子(例えば、アプリケーション内のマーチャントのマーチャントアカウント)などのうちの、少なくとも1つが含まれてもよい。
【0118】
ステップS33、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信し、前記支払い注文生成リクエストには少なくとも、前記取引価格と前記マーチャント注文番号とが含まれる。
【0119】
支払い注文を表す物品IDが取引価格に対応するため、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信するときに、支払い注文生成リクエストには前記取引価格が含まれてもよい。同時に、支払い注文とマーチャント注文とのバインドを実現する際に、本出願の実施例は、マーチャント注文を一意に識別するマーチャント注文番号と、物品IDとのバインドによって実現することができる。
【0120】
ステップS34、処理サーバは、前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文番号にバインドする。
【0121】
本出願の実施例において、処理サーバは少なくとも、支払い注文リクエストによって入力される取引価格とマーチャント注文番号に基づいて、前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文番号にバインドすることで、物品IDとマーチャント注文とのバインドを実現することができる。
【0122】
オプションの実現として、処理サーバは、物品IDプールを設置することができ、処理サーバは、前記物品IDプールに、支払いチャネルサーバに登録される異なる取引価格に対応する物品IDを記録することができ、また、1つの取引価格は、順番に使用される複数の物品IDに対応し、このように、処理サーバが前記マーチャント注文の取引価格に対応する物品IDを決定する場合、前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、物品IDプールに記録された前記取引価格に対応する複数の物品IDから、前記順序に対応する物品IDを決定する。
【0123】
さらに、前記物品IDを決定した後、物品IDをマーチャント注文番号にバインドすることができる。
【0124】
ステップS35、処理サーバは、前記物品IDに基づき、支払いプルアップ通知を前記ユーザデバイスに送信する。
【0125】
処理サーバは、前記物品IDを決定した後、支払いプルアップ通知をユーザデバイスに送信して、支払いチャネルをプルアップするように、ユーザデバイスに通知することができ、これによって、ユーザデバイスが支払いチャネルを使用して前記物品IDに対する支払いを行い、本出願の実施例において、物品IDは、対応する支払い注文を表すために用いられる。
【0126】
ステップS36、ユーザデバイスは、支払いチャネルをプルアップし、前記物品IDに対する支払いリクエストを支払いチャネルサーバに送信する。
【0127】
ステップS37、ユーザデバイスは、前記支払いチャネルサーバによって送信された前記物品IDに対応する支払伝票を受信する。
【0128】
支払いチャネルサーバは、ユーザの支払いリクエストに基づき、前記物品IDに対するユーザの支払いを完了し、対応する支払伝票を生成し、前記支払伝票によって、ユーザが支払った物品IDを指示し、同時に、支払いチャネルサーバは、前記支払伝票をユーザデバイスに送信し、ユーザデバイスによって、前記支払伝票を処理サーバに送信することができる。
【0129】
ステップS38、ユーザデバイスは、前記物品IDに対応する支払伝票を処理サーバに送信する。
【0130】
ステップS39、処理サーバは、前記支払伝票に基づき、前記物品IDにバインドされたマーチャント注文番号をマッチングする。
【0131】
任意選択で、物品IDにバインドされたマーチャント注文番号の数が1つである(即ち、1つの物品IDが1つのマーチャント注文を一意にバインドする)場合、当該物品IDに一意にバインドされたマーチャント注文番号をマッチングすることができる。
【0132】
物品IDにバインドされたマーチャント注文番号の数が複数である(即ち、前記物品IDに複数のマーチャント注文がバインドされた)場合、ユーザデバイスの参加に基づき、前記物品IDにバインドされたマーチャント注文番号をマッチングすることができ、処理サーバは、前記物品IDにバインドされた複数のマーチャント注文番号に基づき、前記複数のマーチャント注文番号に対応するマーチャント注文をユーザデバイスに送信することができ、ユーザデバイスによって、当該複数のマーチャント注文からマッチングマーチャント注文が決定され、マッチングされたマーチャント注文が決定された後、ユーザデバイスは、決定されたマーチャント注文のマーチャント注文番号を処理サーバに通知することで、処理サーバは、前記物品IDにバインドされたマーチャント注文番号をマッチングする。
【0133】
例示として、物品IDには複数のマーチャント注文がバインドされた場合の例は以下の通りであり、ソーシャルネットワークアプリケーションのあるセルフメディアアカウント(self-media account)には、6元の有料購読文章が複数あると、ユーザがクリックごとに支払いを行った後、マーチャントデバイスがそれに応じて有料購読のマーチャント注文を生成し、ソーシャルネットワークアプリケーションサーバは、毎回、6元に対応する物品IDによって支払い注文を生成し、6元の取引価格がポーリング可能な10個の物品IDに対応すると想定する。
【0134】
このプロセスでは、ユーザはクリックごとに支払いを行うが、実際の支払い認証入力操作を実行していないと、第1回の支払いクリックに使用された6元に対応する物品IDは、第11回の支払いクリックに使用された6元に対応する物品IDと重複し、即ち、同じ物品IDが、第1回の支払いクリックの有料購読のマーチャント注文、及び第11回の支払いクリックの有料購読のマーチャント注文にバインドされたことがあり、これによって、ユーザが第11回の支払いクリックに対して支払い認証入力操作を行った後(即ち、第11回の支払いクリックに対して実際の支払いを行った)、処理サーバは、現時点で、支払いチャネルサーバからフィードバックされた物品IDが、ユーザの第1回の支払いクリックの有料購読のマーチャント注文にバインドされたか、それともユーザの第11回の支払いクリックの有料購読のマーチャント注文にバインドされたかを決定できなく、この場合、2つの决定できないマーチャント注文が存在し、ユーザが意思決定に参加することを必要とする。
【0135】
この状況の根本的な原因は以下の通りであり、IAP、GWなどのアプリ内支払いチャネルは、ユーザが実際に支払うのが、第1回の支払いクリックであるか、それとも第11回の支払いクリックであるかを開発者に通知できないだけでなく、ユーザが第1回の支払いクリックの支払いをキャンセルする際に支払いチャネルサーバによって生成された支払いキャンセル通知でさえ信用できない。そのため、本出願の実施例で独特なのは、前記物品IDにバインドされたマーチャント注文の数が複数である場合、ユーザが意思決定に参加するというメカニズムを導入することである。
【0136】
ステップS40、処理サーバは、マッチングされたマーチャント注文番号に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。
【0137】
処理サーバは、前記物品IDにバインドされたマーチャント注文番号をマッチングした後、前記マーチャント注文番号が含まれるサービス提供通知を前記マーチャントデバイスに送信して、前記マーチャント注文番号のマーチャント注文によって指示される仮想付加価値サービスをユーザに提供するように、マーチャントデバイスに通知する。それに応じて、マーチャントデバイスは、サービス提供通知を受信した後、前記マーチャント注文番号によって識別されるマーチャント注文を決定し、前記マーチャント注文によって指示される商品識別子によって、ユーザデバイスに提供される仮想付加価値サービスを決定することができる。
【0138】
さらに、処理サーバは、前記マーチャント注文番号に基づき、前記マーチャント注文番号に対応するマーチャント注文が既に、サービス提供待ちの状態に入ったことを、ユーザデバイスに通知する。
【0139】
さらに、処理サーバは、マーチャントデバイスによって送信されたマーチャント注文を取得してもよく(例えば、ステップS33において、マーチャントデバイスは、支払い注文生成リクエストとともに、マーチャント注文を処理サーバに送信してもよく、マーチャントデバイスは、単独でマーチャント注文を処理サーバにアップロードしてもよい)、これによって、処理サーバは、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定して、サービス提供待ちのマーチャント注文に対するユーザデバイスの照会をサポートすることができる。
【0140】
それに応じて、図6aに示すように、ユーザデバイスは、マーチャント注文の注文状態を処理サーバに照会し、注文状態ページをロードし、前記処理サーバからフィードバックされたサービス提供待ちのマーチャント注文を表示することができる。
【0141】
それに応じて、マーチャントデバイスは、処理サーバによって送信された通知を受信した後、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定し、当該マーチャント注文の商品識別子基づき、対応する仮想付加価値サービスを決定することができ、これによって、対応する仮想付加価値サービスをユーザデバイスに提供する。
【0142】
一例において、マーチャントデバイスは、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定し、当該マーチャント注文に基づき、提供する必要がある仮想付加価値サービスを決定した後、仮想付加価値サービスが既に提供されたことをユーザデバイスに通知し、仮想付加価値サービスの利用権限をユーザデバイスに持たせるために、サービスページをリフレッシュするようにユーザデバイスを制御することができる。
【0143】
それに応じて、図6bに示すように、処理サーバは、マーチャント注文の注文状態をサービス提供済みに更新し、注文状態ページで前記マーチャント注文の状態をサービス提供済みとして表示する。
【0144】
前記支払い方法によれば、ユーザデバイスが物品IDを支払う前に、処理サーバは、物品IDをマーチャント注文番号にバインドし、マーチャント注文番号によってマーチャント注文を識別することで、ユーザデバイスが物品IDに対する支払いを完了した後、物品IDにバインドされたマーチャント注文番号によって、ユーザが購入した仮想付加価値サービスのマーチャント注文を照会し、ユーザの支払い行為と実際に購入した仮想付加価値サービスは、物品IDとマーチャント注文番号とのバインドによって関連付けを実現することができる。そのため、アプリケーション内に複数のマーチャントが存在する場合、ユーザは物品IDによって、バインドされたマーチャント注文番号を照会することで、購入された仮想付加価値サービス注文(即ち、マーチャント注文)に対する照会を実現し、1つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができる。
【0145】
任意選択で、前記支払い注文にバインドされたマーチャント注文をマッチングするときに、マーチャント注文の正確的なマッチングを実現するために、本出願の実施例において、物品IDにバインドされたマーチャント注文の状態を設置することができ、処理サーバの観点から、図7は本出願の実施例による支払い方法のオプションのプロセスを示し、当該プロセスは処理サーバによって実行されてもよく、図7を参照し、当該プロセスは以下のステップを含んでもよい。
【0146】
ステップS100、処理サーバは、ユーザデバイスによって送信された支払いプルアップリクエストを取得し、前記支払いプルアップリクエストは少なくとも仮想付加価値サービスを指示する。
【0147】
ステップS110、処理サーバは、前記支払いプルアップリクエストをマーチャントデバイスに送信する。
【0148】
このように、処理サーバは、ユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信することができる。
【0149】
ステップS120、処理サーバは、マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された支払い注文生成リクエストを取得し、前記支払い注文生成リクエストは、支払い注文を決定するようにリクエストするために用いられる。
【0150】
ステップS130、処理サーバは、前記マーチャント注文の取引価格、及び前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文にバインドする。
【0151】
任意選択で、前記取引価格は、前記支払い注文生成リクエストに含まれてもよい。
【0152】
任意選択で、前記支払い注文生成リクエストにはさらに、前記マーチャント注文を一意に識別するマーチャント注文番号が含まれてもよく、処理サーバは、前記物品IDを前記マーチャント注文番号にバインドすることで、前記物品IDと前記マーチャント注文番号とのバインドを実現する。
【0153】
ステップS140、処理サーバは、前記マーチャント注文の状態を非マッチングとしてマークする。
【0154】
本出願の実施例において、前記物品IDを前記マーチャント注文にバインドした後、前記マーチャント注文が非マッチング状態にあるから、本出願の実施例は、前記マーチャント注文の状態を非マッチングとしてマークすることができる。
【0155】
理解できるように、前記支払い注文にバインドされたマーチャント注文をマッチングすることは、支払伝票を取得した後に行われるため、ユーザデバイスが、支払いをプルアップするように連続且つ複数回リクエストしたが、支払伝票が取得されていないプロセスに(例えば、ユーザデバイスは、支払いをプルするように連続且つ複数回リクエストする場合、マーチャントデバイスが毎回対応してマーチャント注文を生成し、処理サーバも毎回対応して物品IDを決定したが、ユーザデバイスが、支払いチャネルがプルアップされた後、支払いをキャンセルした)、状態が非マッチングである複数のマーチャント注文が存在する場合があり、同じ物品IDの状態が非マッチングである、複数のマーチャント注文が存在する場合もある(例えば、1つの取引価格は、順番に使用される複数の物品IDに対応し、ユーザデバイスが同じ取引価格の仮想付加価値サービスに対する支払いをプルアップするようにリクエストする回数が、前記取引価格に対応する物品IDのポーリング回数に達した場合、処理サーバは、前記物品IDによって、前記取引価格の仮想付加価値サービスのマーチャント注文を繰り返してバインドすることができる)。
【0156】
ステップS150、処理サーバは、前記物品IDに基づき、前記ユーザデバイスに支払いプルアップ通知を送信する。
【0157】
ステップS160、処理サーバは、ユーザデバイスが前記物品IDを支払ったことに対応する支払伝票を取得する。
【0158】
任意選択で、ユーザデバイスは、前記支払いプルアップ通知を受信した後、支払いチャネルをプルアップし、支払い認証入力操作を行って、前記物品IDに対する支払いリクエストを支払いチャネルサーバに送信することができ、これによって、支払いチャネルサーバは、支払い検証に合格した後、前記物品IDに対応する支払伝票を生成し、前記支払伝票をユーザデバイスに送信することができ、これによって、ユーザデバイスは、支払伝票を処理サーバに送信する。
【0159】
任意選択で、支払いチャネルサーバは、前記物品IDに対応する支払伝票を生成した後、直接的に前記支払伝票をユーザデバイスに送信してもよい。
【0160】
ステップS170、前記物品IDにバインドされた、状態が非マッチングであるマーチャント注文の数が1つ場合、処理サーバは、前記物品IDに一意にバインドされた状態が非マッチングであるマーチャント注文をマッチングする。
【0161】
ステップS180、前記物品IDにバインドされた状態が非マッチングであるマーチャント注文の数が複数である場合、処理サーバは、当該複数のマーチャント注文を前記ユーザデバイスに送信し、当該複数のマーチャント注文から前記ユーザデバイスによって判定されたマーチャント注文を、マッチングマーチャント注文とする。
【0162】
任意選択で、ステップS170及びステップS180において、マーチャント注文はマーチャント注文番号で表されてもよい。
【0163】
ステップS190、処理サーバは、マッチングされたマーチャント注文の状態を、マッチング済みとしてマークし、前記物品IDにバインドされたマーチャント注文の数が複数である場合、処理サーバは、前記物品IDにバインドされた、マッチングされていないマーチャント注文の状態をマッチング済みとしてマークする。
【0164】
任意選択で、物品IDにバインドされたマーチャント注文から、マッチングされたマーチャント注文を決定した後、マッチングされたマーチャント注文の状態をマッチング済みとしてマークしてもよく、前記物品IDにバインドされた、マッチングされていないマーチャント注文の状態についても、後続にマッチングに参加しないように、マッチング済みとしてマークされる。
【0165】
例示として、アプリ内支払いを例に挙げ、図8に示すように、ユーザが同じ取引価格のアプリ内支払いを複数回プルアップしたが、全て実際に支払わっていないプロセス中に、処理サーバは、物品IDをマーチャント注文にバインドした後、このときバインドされたマーチャント注文の状態を非マッチングとしてマークし、同じ物品IDにバインドされた、状態が非マッチングであるマーチャント注文の数は複数である場合がある。
【0166】
ユーザデバイスは、前記物品IDに対するアプリ内支払いを完了した後、処理サーバは、アプリ内支払伝票によって指示される物品IDに従って、ユーザが意思決定に参加することによって、前記物品IDにバインドされた、状態が非マッチングであるマーチャント注文から、マーチャント注文をマッチングし、マッチングされたマーチャント注文の状態は、マッチング済みとしてマークされ、同時に、前記物品IDにバインドされた、マッチングされていない他のマーチャント注文の状態も、マッチング済みとしてマークされる。
【0167】
ステップS200、処理サーバは、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。
【0168】
任意選択で、ステップS190とステップS200との間は、前後順序がなくてもよい。
【0169】
本出願の実施例は、物品IDにバインドされたマーチャント注文が複数である場合、ユーザが意思決定に参加するメカニズムを追加し、マーチャント注文の状態の設置によって、1回のマーチャント注文のマッチングが行なれた後、今回、マッチングされていないマーチャント注文とマッチングされたマーチャント注文とはいずれもマッチング済みとしてマークされることが保障されることができ、これによって、後続にマッチングに参加しなくなり、マーチャント注文のマッチングの正確性が大幅に保障されることができる。
【0170】
任意選択で、処理サーバは、前記支払伝票に基づき、前記支払いチャネルサーバの決済データを決定してもよく、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャントの身分情報、前記ユーザデバイスに対応するユーザの身分情報、前記マーチャント注文のマーチャント注文番号などのうちの少なくとも1つが含まれる。
【0171】
処理サーバは、決済金額を決定した後、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分することができる。
【0172】
1つの適用例として、以下、ソーシャルネットワークアプリケーションのミニプログラムのアプリケーション内の支払いをシナリオとして説明する。ユーザは、異なるマーチャントのミニプログラムで、異なる仮想付加価値サービスに対してアプリケーション内の支払いを行ってもよく、同じマーチャントのミニプログラムで、異なる又は同じ仮想付加価値サービスに対して、アプリケーション内の支払いを行ってもよい。
【0173】
図9に示すように、ユーザデバイスは、ミニプログラムのフロントエンドSDKを使用して、ソーシャルネットワークアプリケーションサーバのミニプログラムのバックグランドSDKとインタラクトし、ユーザデバイスは、アプリケーション内の支払いSDKを使用して、支払いチャネルサーバとインタラクトし、マーチャントデバイスはさらにマーチャント端末とマーチャントサーバに分割することができ、マーチャント端末は、ミニプログラムのフロントエンドSDKを介して、ソーシャルネットワークアプリケーションサーバのミニプログラムのバックグランドSDKとインタラクトしてもよい。
【0174】
同時に、ソーシャルネットワークアプリケーションサーバからミニプログラムのバックグランドSDKが細分化され、処理サーバは、ソーシャルネットワークアプリケーションサーバに接続され、ミニプログラムのバックグランドSDKを介して、マーチャントデバイス及びユーザデバイスと通信でき(なお、図9において、例示の便宜上、ミニプログラムのバックグランドSDKを介して、処理サーバとマーチャントデバイス、及びユーザデバイスとの間のインタラクションを行う例示の一部が省略される)、さらに、処理サーバから注文処理サービス、チャネルゲートウェイサービス、チャネルサポートサービス、物品IDプールサービス、出荷ゲートウェイサービス、決済サービスなどの細分化サービス機能が細分化され、これらのサービス機能は、プログラムサービス、又はサーバを介して実現されてもよい。
【0175】
図9に戻ると、ミニプログラムの有料購読に対するユーザの支払いを例として、ユーザが有料購読に対する支払いをプルアップするようにリクエストするときに、処理サーバは、ミニプログラムのバックグランドSDKを介して、ユーザデバイスのミニプログラムのフロントエンドSDKとマーチャント端末のミニプログラムのフロントエンドSDKとの間で、有料購読のアプリケーション内の支払いプルアップリクエストをインタラクトすることができ、その後、本出願の適用例のプロセスは以下を含んでもよい。
【0176】
(1)(図中の丸1に対応。以下同じ。)マーチャント端末は、有料購読のマーチャント注文を生成し、マーチャント端末のミニプログラムのフロントエンドSDKを介して、支払い注文生成リクエストをミニプログラムのバックグランドSDKに送信し、支払い注文生成リクエストにはマーチャント注文の取引価格及びマーチャント注文番号とが含まれる。
【0177】
(2)(図中の丸2に対応。以下同じ。)ミニプログラムのバックグランドSDKは処理サーバの注文処理サービスに、支払い注文生成リクエストを転送し、このプロセスでは、注文処理サービスに前記取引価格と前記マーチャント注文番号とを入力し、注文処理サービスは、物品IDプールに記録された各取引価格に対応する物品IDに基づき、前記取引価格に対応する物品IDを出力し、前記物品IDを前記マーチャント注文番号にバインドする。
【0178】
(3)(図中の丸3に対応。以下同じ。)ミニプログラムのバックグランドSDKは、前記物品IDをユーザデバイスのミニプログラムのフロントエンドSDKに送信し、任意選択で、このプロセスの実現において、ミニプログラムのバックグランドSDKは、まず、前記物品IDをマーチャント端末に送信し、マーチャント端末によって、生成されたマーチャント注文にバインドされた物品IDを決定して記録し、次に、マーチャント端末によって、ミニプログラムのバックグランドSDKを介して、前記物品IDをユーザデバイスのミニプログラムのフロントエンドSDKに送信し、無論、ミニプログラムのバックグランドSDKが前記物品IDをユーザデバイスのミニプログラムのフロントエンドSDKに直接送信し、同時に、ミニプログラムのバックグランドSDKからマーチャント端末に前記物品IDを通知することをサポートしてもよい。
【0179】
(4)(図中の丸4に対応。以下同じ。)ユーザデバイスは、アプリ内支払いSDKを介して、アプリ内支払いチャネルをプルアップし、前記物品IDに対してアプリ内支払いを行う。
【0180】
(5)(図中の丸5に対応。以下同じ。)ユーザデバイスは、アプリ内支払いSDKを介して、支払いチャネルサーバによってフィードバックされた前記物品IDに対応するアプリ内支払伝票を、チャネルゲートウェイサービスに送信する。
【0181】
(6)(図中の丸6に対応。以下同じ。)チャネルサポートサービスは、チャネルゲートウェイサービスによってフィードバックされた前記物品IDに対応するアプリ内支払伝票に基づき、マーチャント注文のマッチング処理を行うことで、注文処理サービスによって出力された前記物品IDにバインドされたマーチャント注文から、マーチャント注文をマッチングする。
【0182】
(7)(図中の丸7に対応。以下同じ。)出荷ゲートウェイは、マッチングされたマーチャント注文に基づき、ユーザデバイスに対応するサービスを提供するように、マーチャントサーバに通知することで、マーチャントサーバは、マッチングされたマーチャント注文に基づき、ユーザデバイスに有料購読サービスを提供すると決定した。
【0183】
(8)(図中の丸8に対応。以下同じ。)決済サービスは、マーチャントの決済売上、勘定照合データなどをマーチャントサーバに送信する。
【0184】
上記の例では、ソーシャルネットワークアプリケーションのミニプログラムのマーチャントによって提供される仮想付加価値サービスを例として説明したが、実際の適用において、本出願の実施例は、単一アプリケーション内のマルチマーチャント及びシングルマーチャントのシナリオが含まれる、アプリケーション内の全ての仮想付加価値サービスの支払いシナリオに拡張することもでき、また、IAPとGWの2つの支払いチャネル以外、チャネルサポートは動的にプラグイン可能で配置可能であるため、本出願の実施例によって提供される支払い方法は同様に、電子商取引のショッピングシナリオで使用される支払いチャネルなど、他の支払いチャネルにも適用可能である。
【0185】
同様に、本出願の実施例によって提供される支払い方法は、モバイルプラットフォームに適用可能であるだけでなく、現在の全ての他のプラットフォーム、例えばPC、Webエンドをサポートすることもできる。
【0186】
本出願の実施例によって提供される支払い方法は、少なくとも以下の利点を有する。
【0187】
従来の支払い方式は、複数のマーチャントの仮想付加価値サービスをサポートしていない。一方で、本出願の実施例は、アプリケーション内に複数のマーチャントが存在する場合、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文(即ち、マーチャント注文)に対する照会を実現し、1つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができ、本出願の実施例は、ソーシャルネットワークアプリケーションのミニプログラム、公式アカウントにマルチマーチャント支払いソリューションを提供するだけでなく、他の同様のアプリケーションにおけるマルチマーチャントシナリオにも同様に適用可能である。
【0188】
支払い注文にバインドされたマーチャント注文をマッチングするときに、複数のバインドされたマーチャント注文が存在する場合、ユーザが意思決定に参加するメカニズムに基づき、支払い注文によって実際に支払われたマーチャント注文のマッチングを保障し、ソーシャルネットワークアプリケーションのミニプログラム、公式アカウントなどのマルチマーチャントシナリオに、正確な支払い保障を提供することができる。
【0189】
本出願の実施例によって提供される支払い方法によれば、マーチャントは、アプリケーションが仮想付加価値サービスを提供するときに、自分のマーチャント注文の管理を実現することができ、これにより、マーチャントに大きな利便性を提供する。
【0190】
マーチャントが照合するように、マーチャントに支払いチャネルの決済売上を提供することをサポートする。
【0191】
処理サーバの観点から、本出願の実施例によって提供される支払い装置を以下に紹介する。以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するために、処理サーバがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互参照すればよい。
【0192】
図10は、本出願の実施例による支払い装置の構成ブロック図であり、当該装置は処理サーバに適用され、図10を参照し、当該装置は、
マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュール100であって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュール100と、
前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュール110と、
前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュール120と、
マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュール130と、を含む。
【0193】
任意選択で、支払い注文決定モジュール100が、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置されることは、
ユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信し、前記支払いプルアップリクエストが少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示することと、
マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された、前記マーチャント注文があることを少なくとも指示する支払い注文生成リクエストを取得することと、
前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた支払い注文を決定することを含んでもよい。
【0194】
任意選択で、支払伝票取得モジュール110が、前記支払い注文の支払伝票を取得するように配置されることは、
前記支払い注文に基づき、前記ユーザデバイスに支払いプルアップ通知を送信することと、
前記ユーザデバイスが前記支払い注文を支払ったことに対応する支払伝票を取得することと、を含んでもよい。
【0195】
任意選択で、支払い注文決定モジュール100が、前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた支払い注文を決定するように配置されることは、
前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定することと、
前記取引価格に対応する物品IDを決定し、前記物品IDを前記マーチャント注文にバインドし、前記物品IDが支払いチャネルサーバに登録されることと、を含んでもよい。
【0196】
任意選択で、前記支払い注文生成リクエストには少なくとも、前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格が含まれ、
前記支払い注文決定モジュール100が、前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定するように配置されることは、
前記支払い注文生成リクエストに含まれる前記マーチャント注文の取引価格を決定することを含んでもよく、
前記支払い注文決定モジュール100が、前記物品IDを前記マーチャント注文にバインドするように配置されることは、
前記物品IDを前記マーチャント注文番号にバインドすることを含んでもよい。
【0197】
任意選択で、マーチャント注文マッチングモジュール120が、前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングするように配置されることは、
前記物品IDにバインドされたマーチャント注文の数が1つである場合、前記物品IDに一意にバインドされたマーチャント注文をマッチングすることと、
前記物品IDにバインドされたマーチャント注文の数が複数である場合、当該複数のマーチャント注文を前記ユーザデバイスに送信し、当該複数のマーチャント注文から前記ユーザデバイスによって決定されたマーチャント注文を、マッチングマーチャント注文とすることと、を含んでもよく、
前記ユーザデバイスが、同じ取引価格の仮想付加価値サービスに対する支払いをプルアップすることをリクエストする回数が、前記取引価格に対応する物品IDのポーリング回数に達した場合、前記物品IDによって、前記取引価格のマーチャント注文を繰り返してバインドする。
【0198】
任意選択で、支払い注文決定モジュール100が、前記マーチャント注文の取引価格を決定するように配置されることは、
前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、前記取引価格に対応する複数の物品IDから、前記順序に対応する物品IDを決定し、1つの取引価格が、順番に使用される複数の物品IDに対応することを含んでもよい。
【0199】
任意選択で、図11は、本出願の実施例による支払い装置の他の構成ブロック図であり、図10及び図11に示すように、当該装置はさらに、
前記物品IDを前記マーチャント注文にバインドした後、前記マーチャント注文の状態を非マッチングとしてマークし、マッチングされたマーチャント注文の状態をマッチング済みとしてマークするように配置される状態マークモジュール140を含んでもよい。
【0200】
任意選択で、さらに、状態マークモジュール140は、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記物品IDにバインドされたマーチャント注文の数が複数である場合、前記物品IDにバインドされた、マッチングされていないマーチャント注文の状態をマッチング済みとしてマークするように配置されてもよい。
【0201】
任意選択で、マッチングされたマーチャント注文は、マッチングされたマーチャント注文番号で表され、サービス提供通知モジュール130が、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するように配置されることは、
マッチングされたマーチャント注文番号に基づき、当該マーチャント注文番号が含まれるサービス提供通知を前記マーチャントデバイスに送信することで、当該マーチャント注文番号のマーチャント注文によって指示される仮想付加価値サービスを前記ユーザデバイスに提供するように、前記マーチャントデバイスに通知することを含んでもよい。
【0202】
任意選択で、支払伝票取得モジュール110が、前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信するように配置されることは、
前記物品IDに対応する支払い入口を生成することと、
前記ユーザデバイスが前記支払い入口に基づき対応する支払いページを表示するように、前記支払い入口を前記ユーザデバイスに送信することと、を含んでもよい。
【0203】
任意選択で、図12は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、図10及び図12に示すように、当該装置はさらに、
マーチャントデバイスにサービス提供通知を送信した後、マッチングされたマーチャント注文の注文状態がサービス提供待ちの状態であることを、ユーザデバイスに通知し、及び、前記マーチャントデバイスが前記ユーザデバイスに仮想付加価値サービスを提供した後、マッチングされたマーチャント注文の注文状態がサービス提供済みの状態であることを、ユーザデバイスに通知するように配置される注文状態通知モジュール150を含む。
【0204】
任意選択で、前記支払いプルアップリクエストには少なくとも、前記仮想付加価値サービスに対応する商品識別子が含まれ、1つの商品識別子が1つの仮想付加価値サービスを一意に識別し、前記マーチャント注文が前記商品識別子に対応する。
【0205】
任意選択で、図13は本出願の実施例による支払い装置の他の構成ブロック図であり、図10及び図13に示すように、当該装置はさらに、
前記支払伝票に基づき、決済データを決定し、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャント身分情報、前記ユーザデバイスに対応するユーザ身分情報、及び前記マーチャント注文のマーチャント注文番号のうちの少なくとも1つが含まれ、及び、決済金額に基づき、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分するように配置される決済モジュール160を含む。
【0206】
本出願の実施例は、処理サーバをさらに提供し、当該処理サーバは、上記の処理サーバに適用されるプログラムモジュールをロードすることによって、本出願の実施例によって提供される支払い方法を実現することができ、処理サーバのオプションのハードウェア構成は、図14に示すように、少なくとも1つの処理チップ1と、少なくとも1つの通信インタフェース2と、少なくとも1つのメモリ3と、少なくとも1つの通信バス4とを含んでもよい。
【0207】
本出願の実施例において、処理チップ1、通信インタフェース2、メモリ3、通信バス4の数は少なくとも1つであり、処理チップ1、通信インタフェース2、メモリ3は、通信バス4を介して相互に通信する。
【0208】
任意選択で、通信インタフェース2は、通信モジュールのインタフェース(例えば、GSMモジュールのインタフェース)であってもよく、処理チップ1は、1つの中央演算処理装置CPU、又は、ASIC(Application Specific Integrated Circuit、特定用途向け集積回路)、又は、本出願の実施例を実施するように配置される1つ以上の集積回路であり得る。
【0209】
メモリ3は、高速RAMメモリを含んでもよく、不揮発性メモリ(non-volatile memory)、例えば少なくとも1つの磁気ディスクメモリを含んでもよい。
【0210】
メモリ3にはプログラムが記憶されてもよく、処理チップ1は、メモリ3に記憶されるプログラムを呼び出すことで、前記処理サーバによって実行される支払い方法のステップを実現する。
【0211】
本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、上記の処理サーバによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。
【0212】
任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定し、前記マーチャント注文は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応し、
前記支払い注文の支払伝票を取得し、
前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、
マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。
【0213】
任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。
【0214】
マーチャントデバイスの観点から、本出願の実施例によって提供される支払い装置を以下に紹介し、以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するためにマーチャントデバイスがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互に参照すればよい。
【0215】
図15は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、当該装置はマーチャントデバイスに適用され、図15を参照し、当該装置は、
ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュール200と、
支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュール210であって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた支払い注文を生成するようにリクエストするために用いられる支払い注文生成リクエストモジュール210と、
前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュール220と、
前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュール230と、を含んでもよい。
【0216】
任意選択で、マーチャント注文生成モジュール200が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されることは、
ユーザデバイスの支払いプルアップリクエストを取得し、前記支払いプルアップリクエストが少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示することと、
前記仮想付加価値サービスに対応するマーチャント注文を生成することと、を含んでもよい。
【0217】
任意選択で、前記マーチャント注文には少なくとも、前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格が含まれる。
【0218】
支払い注文生成リクエストモジュール210が、支払い注文生成リクエストを処理サーバに送信するように配置されることは、
少なくとも前記マーチャント注文番号及び前記取引価格が含まれる支払い注文生成リクエストを処理サーバに送信し、前記支払い注文が前記マーチャント注文番号にバインドされたことを含んでもよい。
【0219】
任意選択で、前記支払い注文は、前記取引価格に対応する物品IDで表され、1つの取引価格は、順番に使用される複数の物品IDに対応する。
【0220】
任意選択で、サービス提供モジュール230が、前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供するように配置されることは、
前記サービス提供通知に含まれるマーチャント注文番号に基づき、当該マーチャント注文番号に対応するマーチャント注文を決定することと、
当該マーチャント注文によって指示される仮想付加価値サービスを決定することと、
決定した仮想付加価値サービスを前記ユーザデバイスに提供することと、を含んでもよい。
【0221】
任意選択で、前記支払いプルアップリクエストには少なくとも、前記仮想付加価値サービスに対応する商品識別子が含まれ、1つの商品識別子が1つの仮想付加価値サービスを一意に識別する。
【0222】
マーチャント注文生成モジュール200が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されることは、前記商品識別子に対応するマーチャント注文を生成することを含んでもよい。
【0223】
任意選択で、図16は本出願の実施例による支払い装置の他の構成ブロック図であり、図15及び図16に示すように、当該装置は、
マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供した後、マッチングされたマーチャント注文の注文状態をサービス提供済みの状態に更新するように、前記処理サーバに通知するように配置される注文状態通知更新モジュール240を含んでもよい。
【0224】
本出願の実施例は、マーチャントデバイスをさらに提供し、当該マーチャントデバイスは、上記のマーチャントデバイスに適用されるプログラムモジュールをロードすることで、本出願の実施例によって提供される支払い方法を実現することができる。
【0225】
マーチャントデバイスのオプションのハードウェア構成について、図14を参照すればよく、任意選択で、マーチャントデバイスは、少なくとも1つのメモリと少なくとも1つの処理チップとを含んでもよく、当該メモリにはプログラムが記憶され、当該処理チップは、前記プログラムを呼び出すことで、前記マーチャントデバイスによって実行される支払い方法のステップを実現する。
【0226】
本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、前記マーチャントデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。
【0227】
任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成し、
支払い注文生成リクエストを処理サーバに送信し、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた支払い注文を生成するように処理サーバにリクエストするために用いられ、
前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記処理サーバによって送信されたサービス提供通知を受信し、
前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供する。
【0228】
任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。
【0229】
ユーザデバイスの観点から、本出願の実施例によって提供される支払い装置を以下に紹介し、以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するために、ユーザデバイスがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互に参照すればよい。
【0230】
図17は本出願の実施例による支払い装置の他の構成ブロック図であり、当該装置はユーザデバイスに適用され、図17を参照し、当該装置は、
処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュール300であって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュール300と、
前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュール310と、
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュール320と、を備える。
【0231】
任意選択で、支払い装置は、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得する前に、さらに、少なくとも前記仮想付加価値サーバを指示する支払いプルアップリクエストを処理サーバに送信することで、前記処理サーバが前記支払いプルアップリクエストをマーチャントデバイスに送信し、前記マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成するために用いられてもよい。
【0232】
任意選択で、支払いプルアップ通知取得モジュール300が、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置されることは、
処理サーバが、前記マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定した後、前記処理サーバによって送信された支払いプルアップ通知を取得することを含んでもよい。
【0233】
任意選択で、支払い装置が、少なくとも前記仮想付加価値サーバを指示する支払いプルアップリクエストを処理サーバに送信するように配置されることは、
アプリケーションを介してマーチャントのサービスページにアクセスすることと、
前記サービスページの仮想付加価値サービスの支払いプル入口がクリックされることで、支払いプルアップリクエストを生成し、前記支払いプルアップリクエストが少なくとも前記仮想付加価値サービスを指示することと、を含んでもよい。
【0234】
任意選択で、前記アプリケーションを介してマーチャントのサービスページにアクセスすることは、
アプリケーションによって、マーチャントのプログラムページのリンク2次元コードをスキャンするか、又は、アプリケーションによって、プログラムページのリンクのアドレスにアクセスすることで、マーチャントのプログラムページをロードすることを含んでもよく、前記プログラムページは、マーチャントによって提供される少なくとも1つの仮想付加価値サービスの支払いプルアップ入口を有する。
【0235】
任意選択で、前記支払いプルアップリクエストを生成することは、
クリックされた支払いプルアップ入口に関連付けられる商品識別子を決定し、少なくとも前記商品識別子が含まれる支払いプルアップリクエストを生成することを含んでもよい。
【0236】
任意選択で、支払いプルアップ通知取得モジュール300が、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置されることは、支払い注文の支払い入口を取得することを含んでもよい。
【0237】
任意選択で、支払伝票送信モジュール310が、前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置されることは、
前記支払いプルアップ通知に基づき、前記支払い注文を支払うことと、
支払いに対応する支払伝票を取得することと、
前記支払伝票を処理サーバに送信することと、を含んでもよい。
【0238】
任意選択で、支払伝票送信モジュール310が、前記支払いプルアップ通知に基づき、前記支払い注文を支払うように配置されることは、
前記支払い入口に基づき、対応する支払いページを表示することと、
支払いページでのユーザの支払い認証入力操作に応答して、支払いチャネルサーバに前記支払い注文に対する支払いリクエストを送信することとを含んでもよい。
【0239】
任意選択で、前記支払い注文は、前記マーチャント注文の取引価格に対応する物品IDで表され、1つの取引価格は、順番に使用される複数の物品IDに対応し、前記マーチャント注文は、一意に識別されるマーチャント注文番号によって識別される。
【0240】
図18は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、図17及び図18に示すように、当該装置はさらに、
前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記処理サーバによって送信された、マッチングされたマーチャント注文の注文状態がサービス提供待ちである通知を取得し、及び、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得した後、前記処理サーバによって送信された、マッチングされたマーチャント注文の注文状態がサービス提供済みである通知を取得するように配置される、注文状態通知取得モジュール330を含んでもよい。
【0241】
本出願の実施例は、ユーザデバイスをさらに提供し、当該ユーザデバイスは、前記ユーザデバイスに適用されるプログラムモジュールをロードすることで、本出願の実施例によって提供される支払い方法を実現することができる。
【0242】
ユーザデバイスのオプションのハードウェア構成について、図14を参照すればよく、任意選択で、ユーザデバイスは、少なくとも1つのメモリと少なくとも1つの処理チップとを含んでもよく、当該メモリにはプログラムが記憶され、当該処理チップは、前記プログラムを呼び出すことで、前記ユーザデバイスによって実行される支払い方法のステップを実現する。
【0243】
本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、前記ユーザデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。
【0244】
任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得し、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応し、
前記支払い注文に対応する支払伝票を、前記処理サーバに送信し、
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得する。
【0245】
任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。
【0246】
本出願の実施例は、支払いシステムをさらに提供し、当該支払いシステムの構成は、図1に示すように、ユーザデバイスと、マーチャントデバイスと、処理サーバとを含み、ユーザデバイス、マーチャントデバイス及び処理サーバがそれぞれ実現する機能について、前述の説明を参照することができ、ここでは繰り返さない。
【0247】
本明細書における各実施例は、漸進的に説明され、各実施例が主に他の実施例との相違点を説明し、各実施例の間の同じ又は類似する部分について、互いに参照すればよい。実施例に開示された装置にとって、実施例に開示された方法に対応するから、説明は比較的に簡単であり、関連部分は、方法部分の説明を参照すればよい。
【0248】
本明細書に開示された実施例で説明される各例示的なユニット及びアルゴリズムステップは、電子ハードウェア、コンピューターソフトウェア又は両者の組み合わせで実現できることを専門家はさらに理解することができ、ハードウェアとソフトウェアとの互換可能性を明らかに説明するために、以上の説明では、機能に従って、各例示的な構成及びステップを既に一般的に説明した。これらの機能がハードウェアによって実行されるか、それともソフトウェアによって実行されるかは、技術案の特定の応用及び設計制約条件に依存する。当業者は、特定の応用ごとに、異なる方法で、説明される機能を実現することができるが、このような実現は本出願の範囲を超えるとみなされるべきではない。
【0249】
本明細書に開示された実施例で説明される方法又はアルゴリズムのステップは、ハードウェア、処理チップによって実行されるソフトウェアモジュール、又は両者の組み合わせによって直接に実施されることができる。ソフトウェアモジュールは、ランダムアクセスメモリ(RAM)、内部メモリ、読み取り専用メモリ(ROM)、電気的にプログラム可能なROM、電気的に消去及びプログラム可能なROM、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、又は技術分野で既知の他の任意の形の記憶媒体に配置されてもよい。
【0250】
開示された実施例に対する前述の説明は、当業者が本出願を実現又は利用することができることを可能にする。これらの実施例に対する様々な補正は、当業者にとって自明であり、本明細書で定義された一般的な原理は、本出願の核心思想又は範囲から逸脱することなく、他の実施例で実現されることができる。従って、本出願は、本明細書に示されたこれらの実施例に限定されず、本明細書に開示された原理及び新規の特徴と一致する最も広い範囲に適合すべきである。
【符号の説明】
【0251】
1 処理チップ
2 通信インタフェース
3 メモリ
4 通信バス
10 ユーザデバイス
20 マーチャントデバイス
30 アプリケーションサーバ
40 処理サーバ
50 支払いチャネルサーバ
100 支払い注文決定モジュール
110 支払伝票取得モジュール
120 マーチャント注文マッチングモジュール
130 サービス提供通知モジュール
140 状態マークモジュール
150 注文状態通知モジュール
160 決済モジュール
200 マーチャント注文生成モジュール
210 支払い注文生成リクエストモジュール
220 サービス提供通知受信モジュール
230 サービス提供モジュール
240 注文状態通知更新モジュール
300 支払いプルアップ通知取得モジュール
310 支払伝票送信モジュール
320 サービス取得モジュール
330 注文状態通知取得モジュール
図1
図2
図3
図4
図5
図6a
図6b
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18