JP7039110B2 - 支払い方法、装置、関連デバイス、システム及びコンピュータプログラム - Google Patents

Description

本出願は、２０１８年０５月１５日にて中国特許庁に提出され、出願番号が２０１８１０４６３７１２５であって、発明名称が「支払い方法、装置、関連デバイス及びシステム」である中国特許出願に基づく優先権を主張し、その全内容を本出願に参照により援用する。

本出願は、データ処理の技術分野に関わり、具体的に、支払い方法、装置、関連デバイス及びシステムに関わる。

現在、ユーザが仮想付加価値サービスを購入する場合、仮想付加価値サービスの購入に対する支払いは、支払いチャネルによって実現される必要があり、より一般的には、ユーザがアプリケーション内で仮想付加価値サービスの購入を行う場合、モバイルオペレーティングシステムによって提供される支払いチャネルを使用して実現でき、例えばｉＯＳ（ｉＯＳは、Ａｐｐｌｅ Ｉｎｃ．が開発したモバイルオペレーティングシステム）によって発行されたＩＡＰ（Ｉｎ ＡＰＰ Ｐｕｒｃｈａｓｅ：アプリ内支払い）、Ａｎｄｒｏｉｄ（アンドロイド（登録商標））によって発行されたＧＷ（Ｇｏｏｇｌｅ Ｗａｌｌｅｔ：グーグル・ウォレット）という支払いチャネルを使用して、アプリケーション内の仮想付加価値サービスの購入及び支払いを実現し、これらの支払いチャネルについて、主にアプリケーション内の仮想付加価値サービスの購入及び支払いをサポートするための、アプリ内支払いチャネルと見なされてもよい。

プラットフォームレベルのアプリケーションの台頭に伴い、１つのアプリケーション内でアクセスされる、仮想付加価値サービスを提供するマーチャントがますます多くなり、複数のマーチャントが１つのアプリケーションにアクセスする場合、如何に複数のマーチャントによって提供される仮想付加価値サービスに対して支払いのサポートを行うかということは、現在、解決すべき緊急の問題になる。

これに鑑みると、本出願の実施例は、１つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対して支払いサポートを行うための、支払い方法、装置、関連デバイス及びシステムを提供する。

前記目的を達成するために、本出願の実施例は、以下の技術案を提供する。

支払い方法であって、処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するステップであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、前記処理サーバが前記支払い注文の支払い伝票を取得するステップと、前記処理サーバが前記支払い伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするステップと、前記処理サーバがマッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するステップとを含む。

本出願の実施例は、支払い方法をさらに提供し、マーチャントデバイスが、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するステップと、前記マーチャントデバイスが、支払い注文生成リクエストを処理サーバに送信するステップであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするステップと、前記マーチャントデバイスが前記処理サーバによって送信されたサービス提供通知を受信するステップであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、送信されるステップと、前記マーチャントデバイスが、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するステップと、を含む。

本出願の実施例は、支払い方法をさらに提供し、ユーザデバイスが、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するステップであって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、前記ユーザデバイスが、前記支払い注文に対応する支払伝票を前記処理サーバに送信するステップと、前記ユーザデバイスが前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するステップであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるステップと、を含む。

本出願の実施例は、処理サーバに適用される支払い装置をさらに提供し、前記支払い装置は、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュールであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュールと、前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュールと、前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュールと、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュールと、を含む。

本出願の実施例は、少なくとも１つのメモリと少なくとも１つの処理チップとを含む処理サーバをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記処理サーバによって実行される支払い方法のステップを実現する。

本出願の実施例は、マーチャントデバイスに適用される支払い装置をさらに提供し、前記支払い装置は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュールと、支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュールであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するようにリクエストするために用いられる支払い注文生成リクエストモジュールと、前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュールであって、前記サービス提供通知が、前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、送信されるサービス提供通知受信モジュールと、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュールと、を含む。

本出願の実施例は、少なくとも１つのメモリと少なくとも１つの処理チップとを含むマーチャントデバイスをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記マーチャントデバイスによって実行される支払い方法のステップを実現する。

本出願の実施例は、ユーザデバイスに適用される支払い装置をさらに提供し、前記支払い装置は、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュールであって、前記支払い注文が、マーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュールと、前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュールと、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュールであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるサービス取得モジュールと、を含む。

本出願の実施例は、少なくとも１つのメモリと少なくとも１つの処理チップとを含むユーザデバイスをさらに提供し、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、前記由ユーザデバイスによって実行される支払い方法のステップを実現する。

本出願の実施例は、記憶媒体をさらに提供し、前記記憶媒体には、上記の処理サーバによって実行される支払い方法のステップ、又は上記のマーチャントデバイスによって実行される支払い方法のステップ、又は上記のユーザデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。

本出願の実施例は、上記の処理サーバと、上記のマーチャントデバイスと、上記のユーザデバイスとを含む支払いシステムをさらに提供する。

上記の技術案によれば、ユーザデバイスが仮想付加価値サービスを購入する場合、マーチャントデバイスは、仮想付加価値サービスに対応するマーチャント注文を生成でき、処理サーバは、支払いチャネルに適しており、かつ前記マーチャント注文にバインドされた支払い注文を決定し、このようにして、ユーザデバイスが支払い注文を支払って、仮想付加価値サービスを購入した後、処理サーバは、ユーザデバイスによって支払われた支払い注文に基づき、バインドされたマーチャント注文を照会し、サービスを提供するマーチャント注文を正確的にマーチャントデバイスに通知することを実現することができ、これによって、ユーザデバイスが支払いを完了した後、ユーザデバイスが購入した仮想付加価値サービスの正確的な提供が実現される。

同時、本出願の実施例において、ユーザの支払い行為と実際に購入された仮想付加価値サービスは、支払い注文とマーチャント注文とのバインドを介して関連付けることができるから、アプリケーション内に複数のマーチャントが存在する場合、ユーザは、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文（即ち、マーチャント注文）の照会を実現し、１つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができる。

本出願の実施例又は関連技術における技術案をより明らかに説明するために、以下は、実施例又は関連技術の説明において使用される必要がある図面を簡単に紹介し、明らかに、以下の説明における図面は、本出願の実施例のみであり、当業者にとって、創造的な作業なしに、提供された図面に基づいて他の図面を得ることができる。

本出願の実施例による支払いシステムのオプションの構成ブロック図である。 本出願の実施例による支払い方法のシグナリングフローチャートである。 物品ＩＤと取引価格との関係の概略図である。 ユーザデバイスに基づいて示される支払いプロセスの概略図である。 本出願の実施例による支払い方法の他のシグナリングフローチャートである。 マーチャント注文の注文状態の第１の概略図である。 マーチャント注文の注文状態の第２の概略図である。 本出願の実施例による支払い方法のオプションのフローチャートである。 マーチャント注文の状態のマークの概略図である。 ミニプログラムシナリオの支払い方法の例示図である。 本出願の実施例による支払い装置の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図。 本出願の実施例による処理サーバのハードウェア構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。 本出願の実施例による支払い装置の他の構成ブロック図である。

ユーザがアプリケーション内で仮想付加価値サービスを購入する場合、従来の支払い方式の実現は主に以下の通りである。支払いチャネルにはいずれも独自の物品管理システムがある（例えば、ＩＡＰ、ＧＷなどのアプリ内支払いチャネルには独自の物品管理システムが存在する）ため、これらの支払いチャネルの要件に従って、支払いを行うには、支払いチャネルに適した支払い注文（例えば、ＩＡＰ、ＧＷなどのアプリ内支払いチャネルに適したアプリ内支払い注文）を構築する必要があり、任意選択で、アプリケーションは、マーチャントによって提供される仮想付加価値サービスを物品ＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ、識別子）に仮想化し、当該物品ＩＤを支払いチャネルサーバに登録する必要があり、これに基づいて、ユーザは、従来の支払い方式で、仮想付加価値サービスを購入する場合、支払いチャネルをプルアップ（ＰＵＬＬ ＵＰ）し、支払いチャネルサーバと通信し、前記物品ＩＤに対応する支払い注文を支払うことで、仮想付加価値サービスを購入することができ、ユーザは、支払い注文に対する支払いを完了した後、仮想付加価値サービスを提供するように、マーチャントに通知するために、支払伝票を取得することができる。

支払いチャネルサーバは、例えばＩＡＰ支払いチャネルのサーバ、ＧＷ支払いチャネルのサーバなどの、支払いチャネルのサーバであり、支払いチャネルサーバは主に、支払いチャネルに対応するサーバによって実現される。

従来の支払い方式において、アプリケーションは主に、支払いチャネルサーバ上のアプリケーションのアカウントに基づいて、マーチャントによって提供される仮想付加価値サービスを物品ＩＤに仮想化し（例えば、ソーシャルネットワークアプリケーションが、マーチャントの有料購読サービスをオンラインし、支払いにＩＡＰ支払いを使用する必要がある場合、ソーシャルネットワークアプリケーションの職員は、ソーシャルネットワークアプリケーションの、ＩＡＰ支払いチャネルサーバに登録されたアカウントに基づき、マーチャントの有料購読サービスを物品ＩＤに仮想化し、当該物品ＩＤをＩＡＰ支払いチャネルサーバに登録する必要がある）、ユーザの支払いニーズを満たすための支払い注文を構築することであり、これは、アプリケーション内で１つのマーチャントのみがある場合、基本的な支払い要件を満たすことができるが、アプリケーション内で仮想付加価値サービスを提供する複数のマーチャントが存在する場合、従来の支払い方式には少なくとも以下の問題がある。

従来の支払い方式において、物品ＩＤは主に、支払いチャネルサーバ上のアプリケーションのアカウントに基づき登録され、仮想付加価値サービス注文に対するバインドをサポートしていなく、ユーザの支払い行為は実際の仮想付加価値サービス注文から分離されている。そのため、アプリケーション内に複数のマーチャントが存在する場合、ユーザは支払伝票を取得した後、支払伝票を介して仮想付加価値サービス注文を照会できない。

このように、１つのアプリケーションに仮想付加価値サービスを提供する複数のマーチャントがアクセスする場合、従来の支払い解決方式は、複数のマーチャントの仮想付加価値サービスに対して効果的な支払いサポートを提供することができない。

上記の欠陥を解決するために、本出願の実施例は、支払いシステムのアーキテクチャを調整するとともに、支払いロジックを調整する。本出願の実施例の技術案は、本出願の実施例における図面と併せて、以下に明らか且つ完全に説明され、明らかに、説明される実施例は全ての実施例ではなく、本出願の実施例の一部にすぎない。本出願における実施例に基づき、創造的な作業なしに当業者によって得られる他の全ての実施例は、本出願の保護範囲にあるものとする。

図１は本出願の実施例による支払いシステムのオプションの構成ブロック図であり、図１に示すように、当該支払いシステムは、ユーザデバイス１０と、マーチャントデバイス２０と、アプリケーションサーバ３０と、処理サーバ４０と、支払いチャネルサーバ５０とを含んでもよい。

ユーザデバイスは、仮想付加価値サービスを購入するユーザが使用する電子デバイス、例えば、スマートフォン、タブレットなどのユーザ端末であってもよい。

マーチャントデバイスは、仮想付加価値サービスを提供するマーチャントに対応する電子デバイスであってもよく、マーチャント端末又はマーチャントサーバのいずれかを使用して実現することができる。

アプリケーションサーバは、プラットフォームレベルのアプリケーションに対応するサービスデバイスであって、主にアプリケーションサービスをユーザに提供し（例えばソーシャルネットワークアプリケーションサーバはソーシャルネットワークサービスをユーザに提供し、電子商取引サーバは電子商取引サービスをユーザに提供するなど）、異なるサービス機能の拡張及び延伸をサポートし（例えば、ソーシャルネットワークアプリケーションサーバはソーシャルネットワークアプリケーションサービスを提供することに加えて、セルフメディア（ｓｅｌｆ－ｍｅｄｉａ）サービス、ミニプログラムサービスなどに拡張及び延伸されることもできる）、本出願の実施例において、マーチャントはアプリケーションサーバにアクセスし、アプリケーション内で仮想付加価値サービスを提供することができる。

ユーザデバイスとマーチャントデバイスは、アプリケーションのアプリケーションインストールパッケージによって、前記アプリケーションをインストールすることができ、このように、ユーザデバイスとマーチャントデバイスは、インストールされたアプリケーションによって、アプリケーションサーバとインタラクトすることができる。

処理サーバは、本出願の実施例の支払い方法を実現するための、アプリケーションサーバにアクセスする１組のサービスデバイスであり、オプションの実現において、処理サーバは、アプリケーションサーバに接続されるサービスデバイスであってもよく、処理サーバとユーザデバイス及びマーチャントデバイスとの間の通信は、アプリケーションサーバをブリッジとして使用することで実現されることができ、即ち、処理サーバとユーザデバイスとの間の通信は、アプリケーションサーバを中継として使用することで実現され、処理サーバとマーチャントデバイスとの間の通信は、アプリケーションサーバを中継として使用することで実現されることができる。

支払いチャネルサーバは支払いチャネルに対応するサービスデバイスであって、例として、Ａｎｄｒｏｉｄオペレーティングシステムでは、支払いチャネルサーバは、アンドロイド（登録商標）から発行されたＧＷ支払いチャネルに対応するＧＷ支払いチャネルサーバであってもよく、ｉＯＳオペレーティングシステムでは、支払いチャネルサーバはｉＯＳから発行されたＩＡＰ支払いチャネルに対応するＩＡＰ支払いチャネルサーバであってもよい。

なお、図１は、オプションのシステムアーキテクチャのみであり、他のオプションの実現において、処理サーバは、アプリケーションサーバの新たに追加されたサービス機能として実現されてもよく、即ち、以下の処理サーバが実行するステップフローは、アプリケーションサーバに追加配置されたサービス機能の実現と見なされてもよい。

上記のアプリ内支払いシステムに基づき、本出願の実施例によって提供される支払い方法を紹介する前に、本出願の実施例の使用背景をよりよく理解するために、以下は、マーチャントがアプリケーション内で仮想付加価値サービスを提供するいくつかの例示を挙げて、以下の例示において、ユーザは主にアプリケーションを介してマーチャントのサービスページをロードし、サービスページによって提供された仮想付加価値サービスから、仮想付加価値サービスを購入する。

ソーシャルネットワークアプリケーションを例として、ソーシャルネットワークアプリケーションにおけるセルフメディアアカウント（例えば公式アカウント（Ｏｆｆｉｃｉａｌ Ａｃｃｏｕｎｔｓ）など）は、マーチャントとして、有料購読などの仮想付加価値サービスをユーザに提供することができ、ユーザは、本出願の実施例によって提供される支払い案を介して、異なるマーチャントによって提供されるサブスクリプションサービスを購入することができる。

また、ソーシャルネットワークアプリケーションは、異なるプログラムのロード機能を拡張することができ、任意選択で、プログラムの作成者がプログラムを作成した後、プログラム内で、コンテンツの支払い、チャージなどの仮想付加価値サービスを提供するとともに、プログラムのリンクＱＲコード（登録商標）又はリンクアドレスを掲載することができ、ユーザがソーシャルネットワークアプリケーションを介して当該リンクＱＲコード（登録商標）をスキャンするか、又はリンクアドレスにアクセスした後、ソーシャルネットワークアプリケーションは、対応するページを介してプログラムページをロードし、このとき、ユーザが、プログラムページによって提供されるコンテンツの支払い、チャージなどの仮想付加価値サービスを購入する必要がある場合、本出願の実施例によって提供される支払いスキームによって実現されることができる。

任意選択で、異なるプログラムのロード機能を拡張するソーシャルネットワークアプリケーションの典型的な例は、ウィーチャット（ＷｅＣｈａｔ）のミニプログラム機能であり、ミニプログラムは、ダウンロード及びインストールを必要としなくても、使用できるプログラムであって、ユーザは、ウィーチャットを介して、ミニプログラムの２次元コードをスキャンするか、又はミニプログラムを検索することで、対応するミニプログラムのページをウィーチャットにロードすることができる。

また、有料知識アプリケーションを例として、登録済みユーザは、有料知識アプリケーションで自分の専門知識を販売して、マーチャントになることができ、ユーザは、本出願の実施例によって提供される支払いスキームによって、異なるマーチャントの専門知識を購入することができる。

上記の挙げられた例示から分かるように、同じアプリケーション内で仮想付加価値サービスを提供するマーチャントが複数いる場合（例えば仮想付加価値サービスを提供する複数のセルフメディアアカウント、異なるミニプログラムのマーチャント、専門知識を販売する異なるマーチャントなど）、本出願の実施例が実現しようとするのは、１つのアプリケーション内に、複数のマーチャントの仮想付加価値サービスに対して支払いサポートを提供することである。

なお、ユーザとマーチャントのキャラクターは厳密に区別されるものではなく、同一人物がユーザとマーチャントのキャラクターを切り替える場合もあり、例えば、１つのセルフメディアアカウントの所有者は、有料購読などの仮想付加価値サービスをユーザに提供するマーチャントとして機能してもよく、他のセルフメディアアカウントによって提供される仮想付加価値サービスを支払うユーザとして機能してもよい。

前述の紹介に基づき、本出願の実施例によって提供される支払い方法を以下に紹介する。オプションの実現として、図２は、本出願の実施例による支払い方法のシグナリングフローを示し、図２を参照し、当該フローは以下のステップを含んでもよい。

ステップＳ１０、ユーザデバイスは、ユーザデバイスが購入をリクエストする仮想付加価値サービスを少なくとも指示する支払いプルアップ（ＰＵＬＬ ＵＰ）リクエストを処理サーバに送信する。

任意選択で、ユーザデバイスはアプリケーションサーバによって、支払いプルアップリクエストを処理サーバに送信することができる。

任意選択で、例として、ユーザデバイスはアプリケーションを介してあるマーチャントのサービスページにアクセスした後（例えば、ユーザデバイスはソーシャルネットワークアプリケーションを介してあるマーチャントのミニプログラムページにアクセスする）、当該サービスページは、当該マーチャントによって提供される少なくとも１つの仮想付加価値サービスの支払いプル入口を有してもよく、１つの支払いプル入口が１つの仮想付加価値サービスに対応する。

任意選択で、ミニプログラムのシナリオでは、ユーザデバイスがアプリケーションを介してマーチャントのサービスページにアクセスするオプションの実現は以下の通りであり、ユーザデバイスはアプリケーションスを介して、マーチャントのプログラムページのリンクの２次元コードをスキャンするか、又は、アプリケーションを介してマーチャントのプログラムページのリンクアドレスにアクセスすることで、マーチャントのプログラムページをロードし、ロードされたプログラムページが当該マーチャントによって提供される少なくとも１つの仮想付加価値サービスの支払いプル入口を有する。

ユーザがある仮想付加価値サービスの支払いプル入口をクリックすることは、当該ユーザが購入を必要とする仮想付加価値サービスを選択し、当該仮想付加価値サービスの支払いをプルアップするようにリクエストしたと見なすことができ、これによって、ユーザがクリックした支払いプル入口に基づき、ユーザデバイスは相応的に支払いプルアップリクエストを構築し、支払いプルアップリクエストによって少なくとも前記仮想付加価値サービスを指示することができる。

なお、ユーザは、マーチャントのサービスページにおける仮想付加価値サービスの支払いプル入口をクリックし、仮想付加価値サービスに対する支払いをプルアップするように、リクエストする。

ステップＳ１１、処理サーバは前記支払いプルアップリクエストをマーチャントデバイスに送信する。

処理サーバは前記支払いプルアップリクエストをユーザがアクセスしたサービスページに対応するマーチャントデバイスに転送することができる。

任意選択で、処理サーバはアプリケーションサーバを介して支払いプルアップリクエストをマーチャントデバイスに送信することができる。

オプションの実現として、前記支払いプルアップリクエストにはマーチャント識別子が含まれ、処理サーバは前記支払いプルアップリクエストを前記マーチャント識別子に対応するマーチャントデバイスに送信することができ、マーチャントのサービスページは対応するマーチャント識別子に関連付けられ、ユーザデバイスがアプリケーションを介してあるマーチャントのサービスページにアクセスする場合、ユーザデバイスがアクセスしたサービスページに関連付けられたマーチャント識別子に基づき、当該マーチャント識別子に対応するマーチャントデバイスに、前記支払いプルアップリクエストを送信することができる。

任意選択で、処理サーバは各マーチャントに対応する商品識別子を設置してもよく、支払いプルアップリクエストに含まれる商品識別子（１つの商品識別子は、１つの仮想付加価値サービスを一意に識別することができる）によって、処理サーバは、前記商品識別子に対応するマーチャントを決定し、決定されたマーチャントに対応するマーチャントデバイスに、前記支払いプルアップリクエストを送信することができる。

ステップＳ１２、マーチャントデバイスは、前記支払いプルアップリクエストに基づき、前記仮想付加価値サービスに対応するマーチャント注文を生成する。

理解するように、本出願の実施例は、ユーザデバイスが仮想付加価値サービスに対する支払いをプルアップするようにリクエストした後、対応する支払い注文を直接構築しなく、ユーザデバイスが支払い注文に基づき直接支払いを行わなく、本出願の実施例において、新たに追加配置される処理サーバは、ユーザデバイスが仮想付加価値サービスに対する支払いをプルアップしたことを、マーチャントデバイスに通知する必要があり、これにより、マーチャントデバイスは、独自の管理可能な、前記仮想付加価値サービスに対応するマーチャント注文を生成する。

任意選択で、オプションの実現において、支払いプルアップリクエストには少なくとも前記仮想付加価値サービスに対応する商品識別子が含まれ、マーチャントデバイスが前記商品識別子に対応するマーチャント注文を構築することができる。

ここで説明する必要があるのは、仮想付加価値サービスは１種の仮想商品と見なすことができるため、商品識別子を使用して仮想付加価値サービスを識別することができ、１つの商品識別子は１つの仮想付加価値サービスを一意に識別する。

ステップＳ１３、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信する。

ここで言及される支払い注文生成リクエストは、対応する支払い注文を生成するように、処理サーバにリクエストするということを意味し、それによって、ユーザデバイスは、後続に支払い注文を利用して、仮想付加価値サービスを支払うことができる。

任意選択で、マーチャントデバイスはアプリケーションサーバによって、支払い注文生成リクエストを処理サーバに送信することができる。

ステップＳ１４、処理サーバは、前記マーチャント注文にバインドされた支払い注文を決定する。

ＩＡＰ、ＧＷなどの支払いチャネルにはいずれも独自の物品管理システムがあるため、支払いチャネルを使用して仮想付加価値サービスを支払う場合、支払いチャネルサーバに登録された物品ＩＤの支払いによって実現されることが理解できる。そのため、マーチャントデバイスは、独自の管理可能なマーチャント注文を構築した後、ＩＡＰ、ＧＷなどの支払いチャネルに適した支払い注文を生成するようにリクエストするために、支払い注文生成リクエストを処理サーバに送信する必要がある。

オプションの実現において、処理サーバは対応する物品ＩＤを決定することで、支払い注文に対する決定を実現することができる。

任意選択で、物品ＩＤは取引価格に対応できる。図３は、物品ＩＤと取引価格とのオプションの関係の概略図を示し、参照することができ、図３に示すように、１つの取引価格は、複数の対応する物品ＩＤを有してもよく、当該複数の物品ＩＤは順番に使用され、即ち、同じ取引価格の複数の物品ＩＤは、ポーリングという方式で取引価格との対応を行い、図３に示すように、取引価格１は６つの対応する物品ＩＤを有すると仮定すると、ユーザデバイスが取引価格１の仮想付加価値サービスに対する支払いをプルアップするように、連続且つ複数回リクエストするプロセスでは、１回目に取引価格１によって支払いをプルアップするようにリクエストする場合、物品ＩＤ１を使用して対応することができ、２回目に取引価格１によって支払いをプルアップするようにリクエストする場合、物品ＩＤ２を使用して対応することができ、このように類推すると、７回目に取引価格１によって支払いをプルアップするようにリクエストする場合、対応のために物品ＩＤ１にループする（即ち、７回目は１回目の物品ＩＤと重複する）。

明らかに、図３に示される取引価格と物品ＩＤとの関係はオプションの状況にすぎず、実際の適用において、支払いチャネルによって、取引価格と物品ＩＤとの関係も適合的に調整されてもよく、例えば１つの取引価格の１回の使用は、一意な物品ＩＤに対応する。

任意選択で、本出願の実施例において、処理サーバは少なくとも前記マーチャント注文の取引価格に基づき、前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文にバインドすることで、前記マーチャント注文にバインドされた支払い注文に対する決定を実現する。

説明する必要があるのは、ステップＳ１０からステップＳ１４は、処理サーバがマーチャントデバイスによって生成されるマーチャント注文にバインドされた支払い注文を決定するためのオプションの実現のみであり、前記マーチャント注文は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する。

ステップＳ１０からステップＳ１４において、処理サーバが主にユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信し、前記支払いプルアップリクエストは少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示し、これによって、マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された、少なくとも前記マーチャント注文があることを指示する支払い注文生成リクエストを取得し、さらに前記支払い注文生成リクエスト基づき、前記マーチャント注文にバインドされた支払い注文を決定する。しかしながら、これは、処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するためのオプションの実現にすぎず、本出願の実施例は、マーチャントデバイスがユーザデバイスが購入をリクエストした仮想付加価値サービスに対応するマーチャント注文を生成し後、処理サーバがマーチャント注文にバインドされた支払い注文を生成するという他の方式をサポートすることもできる。

ステップＳ１５、処理サーバは前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信する。

任意選択で、処理サーバはアプリケーションサーバを介して支払いプルアップ通知をユーザデバイスに送信することができる。

任意選択で、前記支払いプルアップ通知は、支払いチャネルをプルアップするようにユーザデバイスに通知することで、ユーザデバイスが前記支払い注文を支払うことができるために用いられてもよい。

即ち、マーチャントデバイスは、仮想付加価値サービスを購入するようにリクエストする行為に対して、自身が管理し得るマーチャント注文を生成し、処理サーバによって、支払いチャネルに適合し、前記マーチャント注文にバインドされた支払い注文を生成した後、処理サーバは、ユーザデバイスに支払いプルアップ通知を送信して、支払いチャネルをプルアップするように、ユーザデバイスに通知することができ、ユーザデバイスが支払いチャネルによって前記支払い注文を支払うようにする。

オプションの実現として、処理サーバは前記支払い注文に基づき、対応する支払い入口を生成し、処理サーバは、前記支払い入口をユーザデバイスに送信することで、支払いプルアップ通知を前記ユーザデバイスに送信することができ、これによって、ユーザデバイスが前記支払い入口を取得した後、支払いページを表示し、ユーザが前記支払いページで支払い認証入力操作を行った後、支払い注文に対する支払いを実現する。

任意選択で、オプションの実現として、ステップＳ１５において、マーチャントデバイスが、生成されたマーチャント注文にバインドされた支払い注文を決定するように、処理サーバはまずマーチャントデバイスに支払い注文を通知し、次に、支払いプルアップ通知をユーザデバイスに送信するように、マーチャントデバイスが処理サーバに通知し、即ち、ステップＳ１５において、処理サーバがマーチャントデバイスに支払い注文を通知し、マーチャントデバイスのフィードバック応答を取得した後、処理サーバが支払いプルアップ通知を前記ユーザデバイスに送信してもよい（即ち、処理サーバはマーチャントデバイスの通知に基づき、前記ユーザデバイスに支払いプルアップ通知を送信する）。

このように実現される主な目的は、マーチャントデバイスが、生成されたマーチャント注文にバインドされた支払い注文を決定して記録した後、ユーザデバイスの支払いをプルアップすることである。

無論、上記の実現はオプションの方式にすぎず、本出願の実施例は、処理サーバが支払いプルアップ通知を前記ユーザデバイスに送信すると同時に、マーチャント注文にバインドされた支払い注文をマーチャントデバイスに通知することをサポートすることもできる。

ステップＳ１６、ユーザデバイスは、支払いチャネルをプルアップして、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。

ユーザデバイスは、処理サーバによって送信された支払いプルアップ通知を受信した後、支払いチャネルをプルアップして、前記支払い注文に対する支払い認証入力操作を行うことができ（支払い認証入力操作は、支払いパスワード入力、支払い指紋入力、支払い顔入力などを含むが、これらに限定されていない）、これによって、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。

オプションの実現として、ユーザデバイスは、前記支払い注文の支払い入口を受信し、対応する支払いページを表示することができ、これによって、ユーザが支払いページで支払い認証入力操作を行って、ユーザデバイスが、支払いページでのユーザの支払い認証入力操作に応答した後、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。

一例として、本出願の実施例の支払いプロセスにおいて、ユーザデバイス側の表現は、図４に示される通りであってもよく、アプリケーション内のあるセルフメディアアカウント（例えば、図面において、名称が「有料論文」であるセルフメディアアカウント）の論文提供の有料購読を例として、ユーザが、当該セルフメディアアカウントのサービスページのある論文の有料購読ボタンをクリックした後、ユーザデバイスは、有料購読を指示するための支払いプルアップリクエストを構築することができ、これによって、マーチャント端末は、ユーザが有料購読をリクエストすることに対応するマーチャント注文を生成した後、対応する支払い注文を生成するように、処理サーバにリクエストし、処理サーバは、対応する支払い注文を生成し、マーチャント注文にバインドした後、支払い注文に対応する支払い入口をユーザデバイスに送信し、これによって、ユーザデバイスは、当該支払い入口を介して対応する支払いページを表示し、支払い認証入力操作を行って、前記支払い注文に対する支払いリクエストを支払いチャネルサーバに送信する。

ここで説明する必要があるのは、上記の支払いプルアップリクエストと、ここでの支払いリクエストは、２つの異なる段階にあるリクエストであり、支払いプルアップリクエストは主に、ユーザが支払いプル入口をクリックするときに生成され、主に支払いのプルアップをリクエストし、一方で、支払いリクエストは、支払いチャネルをプルアップし、ユーザが支払い認証入力操作を完了した後、形成される支払いリクエストであり、控除と支払いを行うように、支払いチャネルサーバにリクエストするためのリクエストである。

ステップＳ１７、ユーザデバイスは、支払いチャネルサーバによって送信された支払い注文の支払伝票を受信する。

ステップＳ１８、ユーザデバイスは前記支払伝票を処理サーバに送信する。

任意選択で、ステップＳ１５からステップＳ１８は、処理サーバが前記支払い注文の支払伝票を取得するオプションの実現のみである。ステップＳ１５からステップＳ１８において、処理サーバは主に前記支払い注文に基づき、支払いプルアップ通知をユーザデバイスに送信し、これによって、ユーザデバイスが支払いを完了した後、前記ユーザデバイスが前記支払い注文を支払ったことに対応する支払伝票を取得する。ただし、これは、処理サーバが前記支払い注文の支払伝票を取得するオプションの実現のみであり、本出願の実施例は、処理サーバが前記支払い注文の支払伝票を取得するための他の実現をサポートすることもできる。

任意選択で、支払いチャネルサーバはユーザの支払いリクエストに基づき、前記支払い注文に対するユーザの支払いを完了し、対応する支払伝票を生成し、前記支払伝票によって、ユーザが支払う支払い注文（例えば物品ＩＤ）を指示する。同時に、支払いチャネルサーバは、前記支払伝票をユーザデバイスに送信してから、ユーザデバイスによって前記支払伝票を処理サーバに送信することができる（任意選択で、ユーザデバイスはアプリケーションサーバを介して、前記支払伝票を処理サーバに送信することができる）。

任意選択で、支払伝票はさらに、支払いの支払い結果を指示することもできる。

任意選択で、支払い注文を示す物品ＩＤは、アプリケーションを介して支払いチャネルサーバに登録されるため、支払いチャネルサーバが、物品ＩＤに対応する支払伝票を生成した後、支払伝票をアプリケーションサーバに送信し、アプリケーションサーバによって、支払伝票を接続された処理サーバに伝送することができる。

ステップＳ１９、処理サーバは、前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングする。

任意選択で、支払伝票は、ユーザデバイスが支払いを完了した物品ＩＤを指示することができ、前記物品ＩＤにバインドされたマーチャント注文をマッチングすることで、ステップＳ１９を実現する。

オプションの実現において、以上で説明された１つの取引価格が、順番に使用される複数の物品ＩＤに対応する場合であれば、前記物品ＩＤにバインドされたマーチャント注文の数は、１つ以上である可能性があり、明らかに、前記物品ＩＤにバインドされたマーチャント注文の数が１つである場合、前記物品ＩＤによって、一意にバインドされたマーチャント注文をマッチングすることができる。

前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、ユーザデバイスが意思決定に参加する必要があり（例えば、前記ユーザデバイスは同じ取引価格で、同じ取引価格の仮想付加価値サービスを購入するように複数回リクエストするが、当該複数回の購入リクエストの場合、前記ユーザデバイスは最終的な支払いを完了していない）、処理サーバは、物品ＩＤにバインドされた複数のマーチャント注文をユーザデバイスに送信し、ユーザデバイスによって、前記支払い注文にバインドされた、マッチングされたマーチャント注文を決定することができる。

無論、上記はオプションの実現にすぎない。１つの取引価格の１回の使用が、一意の物品ＩＤに対応する場合、処理サーバは前記物品ＩＤに基づき、一意にバインドされたマーチャント注文をマッチングすることができる。

ステップＳ２０、処理サーバは、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信する。

任意選択で、処理サーバは、アプリケーションサーバによって前記サービス提供通知を前記マーチャントデバイスに送信することができる。

このように、前記ユーザデバイスが前記支払い注文を支払って、前記処理サーバが前記支払いに対応する支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングした後、マーチャントデバイスは、前記処理サーバによって送信されたサービス提供通知を受信することができる。

任意選択で、処理サーバは、前記支払い注文にバインドされたマーチャント注文をマッチングした後、サービス提供通知を前記マーチャントデバイスに送信することができる。マーチャントデバイスは、当該通知を受信した後、当該マーチャント注文によって指示される仮想付加価値サービスを決定し、対応する仮想付加価値サービスを前記ユーザデバイスに提供することができる。

さらに、処理サーバは、マッチングされたマーチャント注文の注文状態がサービス提供待ちの状態であることをユーザデバイスに通知することもできる。

さらに、マーチャントデバイスが当該通知を受信した後、ユーザデバイスは、サービスページをリフレッシュして、ユーザデバイスが、仮想付加価値サービスを使用する権限を有するようにし、これに対応して、処理サーバは、マッチングされたマーチャント注文の注文状態がサービス提供済みの状態であることをユーザデバイスに通知することができる。

任意選択で、本出願の実施例はアプリ内支払いシナリオに適用され、これに対応して、上記の支払いプルアップリクエストは、アプリ内支払いプルアップリクエストであってもよく、支払い注文生成リクエストは、アプリ内支払い注文生成リクエストであってもよく、支払い注文は、アプリ内支払い注文であってもよく、支払いチャネルは、アプリ内支払いチャネルであってもよく、支払いリクエストは、アプリ内支払いリクエストであってもよく、支払伝票は、アプリ内支払伝票であってもよい。

上記の支払い方法によれば、ユーザデバイスは、アプリケーション内で仮想付加価値サービスを購入する場合、マーチャントデバイスが、仮想付加価値サービスに対応するマーチャント注文を生成し、処理サーバによって、支払いチャネルに適し且つ前記マーチャント注文にバインドされた支払い注文を決定することができ、このようにして、ユーザデバイスが支払い注文を支払って、仮想付加価値サービスを購入した後、処理サーバが、ユーザデバイスによって支払われた支払い注文に基づき、バインドされたマーチャント注文を照会することができ、サービスを提供するマーチャント注文を正確的にマーチャントデバイスに通知することが実現され、これによって、ユーザデバイスが支払いを完了した後、ユーザデバイスが購入した仮想付加価値サービスに対する正確的な提供を実現する。

同時に、本出願の実施例において、ユーザの支払い行為と実際に購入した仮想付加価値サービスに対して、支払い注文とマーチャント注文とのバインドによって関連付けを実現することができるから、アプリケーション内に複数のマーチャントが存在する場合、ユーザは、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文（即ちマーチャント注文）の照会を実現し、１つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対して支払いサポートを実現することができる。

なお、上記の支払い方法において、ユーザが１つのマーチャントによって提供される仮想付加価値サービスに対して支払うシナリオを例として説明したが、複数のマーチャントのシナリオに拡張することができる。適応的に、複数のマーチャントのシナリオでは、マーチャント注文は、複数のマーチャントに対するものであり、相変わらず支払い注文とマーチャント注文とのバインドによって、ユーザが購入した異なる仮想付加価値サービスに対応するマーチャント注文を区分することができ、そして、複数のマーチャントが仮想付加価値サービスを提供するシナリオでは、各マーチャントのマーチャント注文に対する照会を実現することができ、以上の説明は、１つのマーチャントに基づいているが、複数のマーチャントのシナリオに拡張してもよく、ユーザが支払いを完了した後、異なるマーチャントのマーチャント注文に対する正確的なマッチングを実現する。

さらに、本出願の実施例は、マーチャント注文番号によって、マーチャント注文を一意に識別することができ、物品ＩＤが取引価格に対応する場合、マーチャントデバイスは、少なくともマーチャント注文の取引価格とマーチャント注文番号を処理サーバに入力することで、処理サーバからの物品ＩＤの出力を実現し、支払い注文の決定を完了することができる。

任意選択で、図５は、本出願の実施例による支払い方法の他のオプションのシグナリングフローを示し、図５に示すフローは、図２に示すフローのステップのいくつかの実現の詳細を示すが、図５は、オプションのフローのみを示し、図２に示すフローロジックの示唆で、図５と異なるフローを使用して、図２に示すフローロジックを実現することが完全に可能である。

図５を参照し、当該フローは以下のステップを含んでもよい。

ステップＳ３０、ユーザデバイスは、処理サーバに支払いプルアップリクエストを送信し、前記支払いプルアップリクエストは少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する商品識別子を指示する。

本出願の実施例において、商品識別子は、仮想付加価値サービスを一意に識別するために用いられてもよく、支払いプルアップリクエストに対応する商品識別子が含まれることによって、ユーザが購入をリクエストする仮想付加価値サービスに対する指示を実現することができる。

オプションの実現として、マーチャントのサービスページの１つの支払いプルアップ入口は、１つの仮想付加価値サービスの商品識別子と関連付けられ、ユーザが、仮想付加価値サービスの支払いプル入口をクリックした後、ユーザデバイスは、ユーザによってクリックされた支払いプル入口に関連付けられた商品識別子を決定することができ、これによって、少なくとも前記商品識別子が含まれる支払いプルアップリクエストを生成し、前記商品識別子によって、前記仮想付加価値サービスに対する指示を行う。

任意選択で、仮想付加価値サービスの商品識別子は、提供された仮想付加価値サービスに対してマーチャントによって設置された商品コード、出荷番号などであってもよく、１つの商品識別子は、対応する仮想付加価値サービスを一意に示すことができ、商品識別子は、支払いチャネルサーバに登録された物品ＩＤと異なる。

ステップＳ３１、処理サーバは、前記支払いプルアップリクエストをマーチャントデバイスに送信する。

ステップＳ３２、マーチャントデバイスは、前記支払いプルアップリクエストに基づき、前記商品識別子に対応するマーチャント注文を生成し、前記マーチャント注文には少なくとも取引価格と、前記マーチャント注文を一意に識別するマーチャント注文番号とが含まれる。

任意選択で、支払いプルアップリクエストに含まれる商品識別子に基づき、マーチャントデバイスは、前記商品識別子に対応するマーチャント注文を構築することができ、これによって、前記仮想付加価値サービスに対応するマーチャント注文の生成を実現する。

同時に、マーチャント注文において、取引価格を指示してもよく、取引価格は、仮想付加価値サービスに対するマーチャントの定価によって決定されてもよく、さらに、ユーザが一度に複数の仮想付加価値サービスを購入するようにリクエストする場合、前記支払いプルアップリクエストにはさらに、前記仮想付加価値サービスの取引数が含まれてもよく、マーチャントデバイスは、前記取引数と仮想付加価値サービスの単価に基づき、取引価格を決定することができる。

また、マーチャントデバイスによって生成されたマーチャント注文は、他のマーチャント及びこのマーチャントの他のマーチャント注文を区分するために、一意のマーチャント注文番号によって識別されることができる。

本出願の実施例において、生成されたマーチャント注文は少なくとも、ユーザデバイスが今回、仮想付加価値サービスを購入するようにリクエストする基本的な情報、及びマーチャント注文を一意に識別するマーチャント注文番号を表すことができる。

オプションの実現において、構築されたマーチャント注文には少なくとも、取引価格、及び前記マーチャント注文を一意に識別するマーチャント注文番号などが含まれ、さらに、マーチャント注文には、商品識別子、仮想付加価値サービスの取引数、一般配置情報、ユーザデバイスに対応するユーザの身分識別子（例えば、アプリケーション内のユーザのユーザアカウント）、マーチャントデバイスに対応するマーチャント身分識別子（例えば、アプリケーション内のマーチャントのマーチャントアカウント）などのうちの、少なくとも１つが含まれてもよい。

ステップＳ３３、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信し、前記支払い注文生成リクエストには少なくとも、前記取引価格と前記マーチャント注文番号とが含まれる。

支払い注文を表す物品ＩＤが取引価格に対応するため、マーチャントデバイスは、支払い注文生成リクエストを処理サーバに送信するときに、支払い注文生成リクエストには前記取引価格が含まれてもよい。同時に、支払い注文とマーチャント注文とのバインドを実現する際に、本出願の実施例は、マーチャント注文を一意に識別するマーチャント注文番号と、物品ＩＤとのバインドによって実現することができる。

ステップＳ３４、処理サーバは、前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文番号にバインドする。

本出願の実施例において、処理サーバは少なくとも、支払い注文リクエストによって入力される取引価格とマーチャント注文番号に基づいて、前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文番号にバインドすることで、物品ＩＤとマーチャント注文とのバインドを実現することができる。

オプションの実現として、処理サーバは、物品ＩＤプールを設置することができ、処理サーバは、前記物品ＩＤプールに、支払いチャネルサーバに登録される異なる取引価格に対応する物品ＩＤを記録することができ、また、１つの取引価格は、順番に使用される複数の物品ＩＤに対応し、このように、処理サーバが前記マーチャント注文の取引価格に対応する物品ＩＤを決定する場合、前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、物品ＩＤプールに記録された前記取引価格に対応する複数の物品ＩＤから、前記順序に対応する物品ＩＤを決定する。

さらに、前記物品ＩＤを決定した後、物品ＩＤをマーチャント注文番号にバインドすることができる。

ステップＳ３５、処理サーバは、前記物品ＩＤに基づき、支払いプルアップ通知を前記ユーザデバイスに送信する。

処理サーバは、前記物品ＩＤを決定した後、支払いプルアップ通知をユーザデバイスに送信して、支払いチャネルをプルアップするように、ユーザデバイスに通知することができ、これによって、ユーザデバイスが支払いチャネルを使用して前記物品ＩＤに対する支払いを行い、本出願の実施例において、物品ＩＤは、対応する支払い注文を表すために用いられる。

ステップＳ３６、ユーザデバイスは、支払いチャネルをプルアップし、前記物品ＩＤに対する支払いリクエストを支払いチャネルサーバに送信する。

ステップＳ３７、ユーザデバイスは、前記支払いチャネルサーバによって送信された前記物品ＩＤに対応する支払伝票を受信する。

支払いチャネルサーバは、ユーザの支払いリクエストに基づき、前記物品ＩＤに対するユーザの支払いを完了し、対応する支払伝票を生成し、前記支払伝票によって、ユーザが支払った物品ＩＤを指示し、同時に、支払いチャネルサーバは、前記支払伝票をユーザデバイスに送信し、ユーザデバイスによって、前記支払伝票を処理サーバに送信することができる。

ステップＳ３８、ユーザデバイスは、前記物品ＩＤに対応する支払伝票を処理サーバに送信する。

ステップＳ３９、処理サーバは、前記支払伝票に基づき、前記物品ＩＤにバインドされたマーチャント注文番号をマッチングする。

任意選択で、物品ＩＤにバインドされたマーチャント注文番号の数が１つである（即ち、１つの物品ＩＤが１つのマーチャント注文を一意にバインドする）場合、当該物品ＩＤに一意にバインドされたマーチャント注文番号をマッチングすることができる。

物品ＩＤにバインドされたマーチャント注文番号の数が複数である（即ち、前記物品ＩＤに複数のマーチャント注文がバインドされた）場合、ユーザデバイスの参加に基づき、前記物品ＩＤにバインドされたマーチャント注文番号をマッチングすることができ、処理サーバは、前記物品ＩＤにバインドされた複数のマーチャント注文番号に基づき、前記複数のマーチャント注文番号に対応するマーチャント注文をユーザデバイスに送信することができ、ユーザデバイスによって、当該複数のマーチャント注文からマッチングマーチャント注文が決定され、マッチングされたマーチャント注文が決定された後、ユーザデバイスは、決定されたマーチャント注文のマーチャント注文番号を処理サーバに通知することで、処理サーバは、前記物品ＩＤにバインドされたマーチャント注文番号をマッチングする。

例示として、物品ＩＤには複数のマーチャント注文がバインドされた場合の例は以下の通りであり、ソーシャルネットワークアプリケーションのあるセルフメディアアカウント（ｓｅｌｆ－ｍｅｄｉａ ａｃｃｏｕｎｔ）には、６元の有料購読文章が複数あると、ユーザがクリックごとに支払いを行った後、マーチャントデバイスがそれに応じて有料購読のマーチャント注文を生成し、ソーシャルネットワークアプリケーションサーバは、毎回、６元に対応する物品ＩＤによって支払い注文を生成し、６元の取引価格がポーリング可能な１０個の物品ＩＤに対応すると想定する。

このプロセスでは、ユーザはクリックごとに支払いを行うが、実際の支払い認証入力操作を実行していないと、第１回の支払いクリックに使用された６元に対応する物品ＩＤは、第１１回の支払いクリックに使用された６元に対応する物品ＩＤと重複し、即ち、同じ物品ＩＤが、第１回の支払いクリックの有料購読のマーチャント注文、及び第１１回の支払いクリックの有料購読のマーチャント注文にバインドされたことがあり、これによって、ユーザが第１１回の支払いクリックに対して支払い認証入力操作を行った後（即ち、第１１回の支払いクリックに対して実際の支払いを行った）、処理サーバは、現時点で、支払いチャネルサーバからフィードバックされた物品ＩＤが、ユーザの第１回の支払いクリックの有料購読のマーチャント注文にバインドされたか、それともユーザの第１１回の支払いクリックの有料購読のマーチャント注文にバインドされたかを決定できなく、この場合、２つの决定できないマーチャント注文が存在し、ユーザが意思決定に参加することを必要とする。

この状況の根本的な原因は以下の通りであり、ＩＡＰ、ＧＷなどのアプリ内支払いチャネルは、ユーザが実際に支払うのが、第１回の支払いクリックであるか、それとも第１１回の支払いクリックであるかを開発者に通知できないだけでなく、ユーザが第１回の支払いクリックの支払いをキャンセルする際に支払いチャネルサーバによって生成された支払いキャンセル通知でさえ信用できない。そのため、本出願の実施例で独特なのは、前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、ユーザが意思決定に参加するというメカニズムを導入することである。

ステップＳ４０、処理サーバは、マッチングされたマーチャント注文番号に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。

処理サーバは、前記物品ＩＤにバインドされたマーチャント注文番号をマッチングした後、前記マーチャント注文番号が含まれるサービス提供通知を前記マーチャントデバイスに送信して、前記マーチャント注文番号のマーチャント注文によって指示される仮想付加価値サービスをユーザに提供するように、マーチャントデバイスに通知する。それに応じて、マーチャントデバイスは、サービス提供通知を受信した後、前記マーチャント注文番号によって識別されるマーチャント注文を決定し、前記マーチャント注文によって指示される商品識別子によって、ユーザデバイスに提供される仮想付加価値サービスを決定することができる。

さらに、処理サーバは、前記マーチャント注文番号に基づき、前記マーチャント注文番号に対応するマーチャント注文が既に、サービス提供待ちの状態に入ったことを、ユーザデバイスに通知する。

さらに、処理サーバは、マーチャントデバイスによって送信されたマーチャント注文を取得してもよく（例えば、ステップＳ３３において、マーチャントデバイスは、支払い注文生成リクエストとともに、マーチャント注文を処理サーバに送信してもよく、マーチャントデバイスは、単独でマーチャント注文を処理サーバにアップロードしてもよい）、これによって、処理サーバは、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定して、サービス提供待ちのマーチャント注文に対するユーザデバイスの照会をサポートすることができる。

それに応じて、図６ａに示すように、ユーザデバイスは、マーチャント注文の注文状態を処理サーバに照会し、注文状態ページをロードし、前記処理サーバからフィードバックされたサービス提供待ちのマーチャント注文を表示することができる。

それに応じて、マーチャントデバイスは、処理サーバによって送信された通知を受信した後、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定し、当該マーチャント注文の商品識別子基づき、対応する仮想付加価値サービスを決定することができ、これによって、対応する仮想付加価値サービスをユーザデバイスに提供する。

一例において、マーチャントデバイスは、マッチングされたマーチャント注文番号に対応するマーチャント注文を決定し、当該マーチャント注文に基づき、提供する必要がある仮想付加価値サービスを決定した後、仮想付加価値サービスが既に提供されたことをユーザデバイスに通知し、仮想付加価値サービスの利用権限をユーザデバイスに持たせるために、サービスページをリフレッシュするようにユーザデバイスを制御することができる。

それに応じて、図６ｂに示すように、処理サーバは、マーチャント注文の注文状態をサービス提供済みに更新し、注文状態ページで前記マーチャント注文の状態をサービス提供済みとして表示する。

前記支払い方法によれば、ユーザデバイスが物品ＩＤを支払う前に、処理サーバは、物品ＩＤをマーチャント注文番号にバインドし、マーチャント注文番号によってマーチャント注文を識別することで、ユーザデバイスが物品ＩＤに対する支払いを完了した後、物品ＩＤにバインドされたマーチャント注文番号によって、ユーザが購入した仮想付加価値サービスのマーチャント注文を照会し、ユーザの支払い行為と実際に購入した仮想付加価値サービスは、物品ＩＤとマーチャント注文番号とのバインドによって関連付けを実現することができる。そのため、アプリケーション内に複数のマーチャントが存在する場合、ユーザは物品ＩＤによって、バインドされたマーチャント注文番号を照会することで、購入された仮想付加価値サービス注文（即ち、マーチャント注文）に対する照会を実現し、１つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができる。

任意選択で、前記支払い注文にバインドされたマーチャント注文をマッチングするときに、マーチャント注文の正確的なマッチングを実現するために、本出願の実施例において、物品ＩＤにバインドされたマーチャント注文の状態を設置することができ、処理サーバの観点から、図７は本出願の実施例による支払い方法のオプションのプロセスを示し、当該プロセスは処理サーバによって実行されてもよく、図７を参照し、当該プロセスは以下のステップを含んでもよい。

ステップＳ１００、処理サーバは、ユーザデバイスによって送信された支払いプルアップリクエストを取得し、前記支払いプルアップリクエストは少なくとも仮想付加価値サービスを指示する。

ステップＳ１１０、処理サーバは、前記支払いプルアップリクエストをマーチャントデバイスに送信する。

このように、処理サーバは、ユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信することができる。

ステップＳ１２０、処理サーバは、マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された支払い注文生成リクエストを取得し、前記支払い注文生成リクエストは、支払い注文を決定するようにリクエストするために用いられる。

ステップＳ１３０、処理サーバは、前記マーチャント注文の取引価格、及び前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文にバインドする。

任意選択で、前記取引価格は、前記支払い注文生成リクエストに含まれてもよい。

任意選択で、前記支払い注文生成リクエストにはさらに、前記マーチャント注文を一意に識別するマーチャント注文番号が含まれてもよく、処理サーバは、前記物品ＩＤを前記マーチャント注文番号にバインドすることで、前記物品ＩＤと前記マーチャント注文番号とのバインドを実現する。

ステップＳ１４０、処理サーバは、前記マーチャント注文の状態を非マッチングとしてマークする。

本出願の実施例において、前記物品ＩＤを前記マーチャント注文にバインドした後、前記マーチャント注文が非マッチング状態にあるから、本出願の実施例は、前記マーチャント注文の状態を非マッチングとしてマークすることができる。

理解できるように、前記支払い注文にバインドされたマーチャント注文をマッチングすることは、支払伝票を取得した後に行われるため、ユーザデバイスが、支払いをプルアップするように連続且つ複数回リクエストしたが、支払伝票が取得されていないプロセスに（例えば、ユーザデバイスは、支払いをプルするように連続且つ複数回リクエストする場合、マーチャントデバイスが毎回対応してマーチャント注文を生成し、処理サーバも毎回対応して物品ＩＤを決定したが、ユーザデバイスが、支払いチャネルがプルアップされた後、支払いをキャンセルした）、状態が非マッチングである複数のマーチャント注文が存在する場合があり、同じ物品ＩＤの状態が非マッチングである、複数のマーチャント注文が存在する場合もある（例えば、１つの取引価格は、順番に使用される複数の物品ＩＤに対応し、ユーザデバイスが同じ取引価格の仮想付加価値サービスに対する支払いをプルアップするようにリクエストする回数が、前記取引価格に対応する物品ＩＤのポーリング回数に達した場合、処理サーバは、前記物品ＩＤによって、前記取引価格の仮想付加価値サービスのマーチャント注文を繰り返してバインドすることができる）。

ステップＳ１５０、処理サーバは、前記物品ＩＤに基づき、前記ユーザデバイスに支払いプルアップ通知を送信する。

ステップＳ１６０、処理サーバは、ユーザデバイスが前記物品ＩＤを支払ったことに対応する支払伝票を取得する。

任意選択で、ユーザデバイスは、前記支払いプルアップ通知を受信した後、支払いチャネルをプルアップし、支払い認証入力操作を行って、前記物品ＩＤに対する支払いリクエストを支払いチャネルサーバに送信することができ、これによって、支払いチャネルサーバは、支払い検証に合格した後、前記物品ＩＤに対応する支払伝票を生成し、前記支払伝票をユーザデバイスに送信することができ、これによって、ユーザデバイスは、支払伝票を処理サーバに送信する。

任意選択で、支払いチャネルサーバは、前記物品ＩＤに対応する支払伝票を生成した後、直接的に前記支払伝票をユーザデバイスに送信してもよい。

ステップＳ１７０、前記物品ＩＤにバインドされた、状態が非マッチングであるマーチャント注文の数が１つ場合、処理サーバは、前記物品ＩＤに一意にバインドされた状態が非マッチングであるマーチャント注文をマッチングする。

ステップＳ１８０、前記物品ＩＤにバインドされた状態が非マッチングであるマーチャント注文の数が複数である場合、処理サーバは、当該複数のマーチャント注文を前記ユーザデバイスに送信し、当該複数のマーチャント注文から前記ユーザデバイスによって判定されたマーチャント注文を、マッチングマーチャント注文とする。

任意選択で、ステップＳ１７０及びステップＳ１８０において、マーチャント注文はマーチャント注文番号で表されてもよい。

ステップＳ１９０、処理サーバは、マッチングされたマーチャント注文の状態を、マッチング済みとしてマークし、前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、処理サーバは、前記物品ＩＤにバインドされた、マッチングされていないマーチャント注文の状態をマッチング済みとしてマークする。

任意選択で、物品ＩＤにバインドされたマーチャント注文から、マッチングされたマーチャント注文を決定した後、マッチングされたマーチャント注文の状態をマッチング済みとしてマークしてもよく、前記物品ＩＤにバインドされた、マッチングされていないマーチャント注文の状態についても、後続にマッチングに参加しないように、マッチング済みとしてマークされる。

例示として、アプリ内支払いを例に挙げ、図８に示すように、ユーザが同じ取引価格のアプリ内支払いを複数回プルアップしたが、全て実際に支払わっていないプロセス中に、処理サーバは、物品ＩＤをマーチャント注文にバインドした後、このときバインドされたマーチャント注文の状態を非マッチングとしてマークし、同じ物品ＩＤにバインドされた、状態が非マッチングであるマーチャント注文の数は複数である場合がある。

ユーザデバイスは、前記物品ＩＤに対するアプリ内支払いを完了した後、処理サーバは、アプリ内支払伝票によって指示される物品ＩＤに従って、ユーザが意思決定に参加することによって、前記物品ＩＤにバインドされた、状態が非マッチングであるマーチャント注文から、マーチャント注文をマッチングし、マッチングされたマーチャント注文の状態は、マッチング済みとしてマークされ、同時に、前記物品ＩＤにバインドされた、マッチングされていない他のマーチャント注文の状態も、マッチング済みとしてマークされる。

ステップＳ２００、処理サーバは、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。

任意選択で、ステップＳ１９０とステップＳ２００との間は、前後順序がなくてもよい。

本出願の実施例は、物品ＩＤにバインドされたマーチャント注文が複数である場合、ユーザが意思決定に参加するメカニズムを追加し、マーチャント注文の状態の設置によって、１回のマーチャント注文のマッチングが行なれた後、今回、マッチングされていないマーチャント注文とマッチングされたマーチャント注文とはいずれもマッチング済みとしてマークされることが保障されることができ、これによって、後続にマッチングに参加しなくなり、マーチャント注文のマッチングの正確性が大幅に保障されることができる。

任意選択で、処理サーバは、前記支払伝票に基づき、前記支払いチャネルサーバの決済データを決定してもよく、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャントの身分情報、前記ユーザデバイスに対応するユーザの身分情報、前記マーチャント注文のマーチャント注文番号などのうちの少なくとも１つが含まれる。

処理サーバは、決済金額を決定した後、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分することができる。

１つの適用例として、以下、ソーシャルネットワークアプリケーションのミニプログラムのアプリケーション内の支払いをシナリオとして説明する。ユーザは、異なるマーチャントのミニプログラムで、異なる仮想付加価値サービスに対してアプリケーション内の支払いを行ってもよく、同じマーチャントのミニプログラムで、異なる又は同じ仮想付加価値サービスに対して、アプリケーション内の支払いを行ってもよい。

図９に示すように、ユーザデバイスは、ミニプログラムのフロントエンドＳＤＫを使用して、ソーシャルネットワークアプリケーションサーバのミニプログラムのバックグランドＳＤＫとインタラクトし、ユーザデバイスは、アプリケーション内の支払いＳＤＫを使用して、支払いチャネルサーバとインタラクトし、マーチャントデバイスはさらにマーチャント端末とマーチャントサーバに分割することができ、マーチャント端末は、ミニプログラムのフロントエンドＳＤＫを介して、ソーシャルネットワークアプリケーションサーバのミニプログラムのバックグランドＳＤＫとインタラクトしてもよい。

同時に、ソーシャルネットワークアプリケーションサーバからミニプログラムのバックグランドＳＤＫが細分化され、処理サーバは、ソーシャルネットワークアプリケーションサーバに接続され、ミニプログラムのバックグランドＳＤＫを介して、マーチャントデバイス及びユーザデバイスと通信でき（なお、図９において、例示の便宜上、ミニプログラムのバックグランドＳＤＫを介して、処理サーバとマーチャントデバイス、及びユーザデバイスとの間のインタラクションを行う例示の一部が省略される）、さらに、処理サーバから注文処理サービス、チャネルゲートウェイサービス、チャネルサポートサービス、物品ＩＤプールサービス、出荷ゲートウェイサービス、決済サービスなどの細分化サービス機能が細分化され、これらのサービス機能は、プログラムサービス、又はサーバを介して実現されてもよい。

図９に戻ると、ミニプログラムの有料購読に対するユーザの支払いを例として、ユーザが有料購読に対する支払いをプルアップするようにリクエストするときに、処理サーバは、ミニプログラムのバックグランドＳＤＫを介して、ユーザデバイスのミニプログラムのフロントエンドＳＤＫとマーチャント端末のミニプログラムのフロントエンドＳＤＫとの間で、有料購読のアプリケーション内の支払いプルアップリクエストをインタラクトすることができ、その後、本出願の適用例のプロセスは以下を含んでもよい。

（１）（図中の丸１に対応。以下同じ。）マーチャント端末は、有料購読のマーチャント注文を生成し、マーチャント端末のミニプログラムのフロントエンドＳＤＫを介して、支払い注文生成リクエストをミニプログラムのバックグランドＳＤＫに送信し、支払い注文生成リクエストにはマーチャント注文の取引価格及びマーチャント注文番号とが含まれる。

（２）（図中の丸２に対応。以下同じ。）ミニプログラムのバックグランドＳＤＫは処理サーバの注文処理サービスに、支払い注文生成リクエストを転送し、このプロセスでは、注文処理サービスに前記取引価格と前記マーチャント注文番号とを入力し、注文処理サービスは、物品ＩＤプールに記録された各取引価格に対応する物品ＩＤに基づき、前記取引価格に対応する物品ＩＤを出力し、前記物品ＩＤを前記マーチャント注文番号にバインドする。

（３）（図中の丸３に対応。以下同じ。）ミニプログラムのバックグランドＳＤＫは、前記物品ＩＤをユーザデバイスのミニプログラムのフロントエンドＳＤＫに送信し、任意選択で、このプロセスの実現において、ミニプログラムのバックグランドＳＤＫは、まず、前記物品ＩＤをマーチャント端末に送信し、マーチャント端末によって、生成されたマーチャント注文にバインドされた物品ＩＤを決定して記録し、次に、マーチャント端末によって、ミニプログラムのバックグランドＳＤＫを介して、前記物品ＩＤをユーザデバイスのミニプログラムのフロントエンドＳＤＫに送信し、無論、ミニプログラムのバックグランドＳＤＫが前記物品ＩＤをユーザデバイスのミニプログラムのフロントエンドＳＤＫに直接送信し、同時に、ミニプログラムのバックグランドＳＤＫからマーチャント端末に前記物品ＩＤを通知することをサポートしてもよい。

（４）（図中の丸４に対応。以下同じ。）ユーザデバイスは、アプリ内支払いＳＤＫを介して、アプリ内支払いチャネルをプルアップし、前記物品ＩＤに対してアプリ内支払いを行う。

（５）（図中の丸５に対応。以下同じ。）ユーザデバイスは、アプリ内支払いＳＤＫを介して、支払いチャネルサーバによってフィードバックされた前記物品ＩＤに対応するアプリ内支払伝票を、チャネルゲートウェイサービスに送信する。

（６）（図中の丸６に対応。以下同じ。）チャネルサポートサービスは、チャネルゲートウェイサービスによってフィードバックされた前記物品ＩＤに対応するアプリ内支払伝票に基づき、マーチャント注文のマッチング処理を行うことで、注文処理サービスによって出力された前記物品ＩＤにバインドされたマーチャント注文から、マーチャント注文をマッチングする。

（７）（図中の丸７に対応。以下同じ。）出荷ゲートウェイは、マッチングされたマーチャント注文に基づき、ユーザデバイスに対応するサービスを提供するように、マーチャントサーバに通知することで、マーチャントサーバは、マッチングされたマーチャント注文に基づき、ユーザデバイスに有料購読サービスを提供すると決定した。

（８）（図中の丸８に対応。以下同じ。）決済サービスは、マーチャントの決済売上、勘定照合データなどをマーチャントサーバに送信する。

上記の例では、ソーシャルネットワークアプリケーションのミニプログラムのマーチャントによって提供される仮想付加価値サービスを例として説明したが、実際の適用において、本出願の実施例は、単一アプリケーション内のマルチマーチャント及びシングルマーチャントのシナリオが含まれる、アプリケーション内の全ての仮想付加価値サービスの支払いシナリオに拡張することもでき、また、ＩＡＰとＧＷの２つの支払いチャネル以外、チャネルサポートは動的にプラグイン可能で配置可能であるため、本出願の実施例によって提供される支払い方法は同様に、電子商取引のショッピングシナリオで使用される支払いチャネルなど、他の支払いチャネルにも適用可能である。

同様に、本出願の実施例によって提供される支払い方法は、モバイルプラットフォームに適用可能であるだけでなく、現在の全ての他のプラットフォーム、例えばＰＣ、Ｗｅｂエンドをサポートすることもできる。

本出願の実施例によって提供される支払い方法は、少なくとも以下の利点を有する。

従来の支払い方式は、複数のマーチャントの仮想付加価値サービスをサポートしていない。一方で、本出願の実施例は、アプリケーション内に複数のマーチャントが存在する場合、支払い注文によって、バインドされたマーチャント注文を照会することで、購入された仮想付加価値サービス注文（即ち、マーチャント注文）に対する照会を実現し、１つのアプリケーション内で、複数のマーチャントによって提供される仮想付加価値サービスに対する支払いサポートを実現することができ、本出願の実施例は、ソーシャルネットワークアプリケーションのミニプログラム、公式アカウントにマルチマーチャント支払いソリューションを提供するだけでなく、他の同様のアプリケーションにおけるマルチマーチャントシナリオにも同様に適用可能である。

支払い注文にバインドされたマーチャント注文をマッチングするときに、複数のバインドされたマーチャント注文が存在する場合、ユーザが意思決定に参加するメカニズムに基づき、支払い注文によって実際に支払われたマーチャント注文のマッチングを保障し、ソーシャルネットワークアプリケーションのミニプログラム、公式アカウントなどのマルチマーチャントシナリオに、正確な支払い保障を提供することができる。

本出願の実施例によって提供される支払い方法によれば、マーチャントは、アプリケーションが仮想付加価値サービスを提供するときに、自分のマーチャント注文の管理を実現することができ、これにより、マーチャントに大きな利便性を提供する。

マーチャントが照合するように、マーチャントに支払いチャネルの決済売上を提供することをサポートする。

処理サーバの観点から、本出願の実施例によって提供される支払い装置を以下に紹介する。以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するために、処理サーバがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互参照すればよい。

図１０は、本出願の実施例による支払い装置の構成ブロック図であり、当該装置は処理サーバに適用され、図１０を参照し、当該装置は、
マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュール１００であって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュール１００と、
前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュール１１０と、
前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュール１２０と、
マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュール１３０と、を含む。

任意選択で、支払い注文決定モジュール１００が、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置されることは、
ユーザデバイスの支払いプルアップリクエストをマーチャントデバイスに送信し、前記支払いプルアップリクエストが少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示することと、
マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成した後、前記マーチャントデバイスによって送信された、前記マーチャント注文があることを少なくとも指示する支払い注文生成リクエストを取得することと、
前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた支払い注文を決定することを含んでもよい。

任意選択で、支払伝票取得モジュール１１０が、前記支払い注文の支払伝票を取得するように配置されることは、
前記支払い注文に基づき、前記ユーザデバイスに支払いプルアップ通知を送信することと、
前記ユーザデバイスが前記支払い注文を支払ったことに対応する支払伝票を取得することと、を含んでもよい。

任意選択で、支払い注文決定モジュール１００が、前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた支払い注文を決定するように配置されることは、
前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定することと、
前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文にバインドし、前記物品ＩＤが支払いチャネルサーバに登録されることと、を含んでもよい。

任意選択で、前記支払い注文生成リクエストには少なくとも、前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格が含まれ、
前記支払い注文決定モジュール１００が、前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定するように配置されることは、
前記支払い注文生成リクエストに含まれる前記マーチャント注文の取引価格を決定することを含んでもよく、
前記支払い注文決定モジュール１００が、前記物品ＩＤを前記マーチャント注文にバインドするように配置されることは、
前記物品ＩＤを前記マーチャント注文番号にバインドすることを含んでもよい。

任意選択で、マーチャント注文マッチングモジュール１２０が、前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングするように配置されることは、
前記物品ＩＤにバインドされたマーチャント注文の数が１つである場合、前記物品ＩＤに一意にバインドされたマーチャント注文をマッチングすることと、
前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、当該複数のマーチャント注文を前記ユーザデバイスに送信し、当該複数のマーチャント注文から前記ユーザデバイスによって決定されたマーチャント注文を、マッチングマーチャント注文とすることと、を含んでもよく、
前記ユーザデバイスが、同じ取引価格の仮想付加価値サービスに対する支払いをプルアップすることをリクエストする回数が、前記取引価格に対応する物品ＩＤのポーリング回数に達した場合、前記物品ＩＤによって、前記取引価格のマーチャント注文を繰り返してバインドする。

任意選択で、支払い注文決定モジュール１００が、前記マーチャント注文の取引価格を決定するように配置されることは、
前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、前記取引価格に対応する複数の物品ＩＤから、前記順序に対応する物品ＩＤを決定し、１つの取引価格が、順番に使用される複数の物品ＩＤに対応することを含んでもよい。

任意選択で、図１１は、本出願の実施例による支払い装置の他の構成ブロック図であり、図１０及び図１１に示すように、当該装置はさらに、
前記物品ＩＤを前記マーチャント注文にバインドした後、前記マーチャント注文の状態を非マッチングとしてマークし、マッチングされたマーチャント注文の状態をマッチング済みとしてマークするように配置される状態マークモジュール１４０を含んでもよい。

任意選択で、さらに、状態マークモジュール１４０は、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、前記物品ＩＤにバインドされた、マッチングされていないマーチャント注文の状態をマッチング済みとしてマークするように配置されてもよい。

任意選択で、マッチングされたマーチャント注文は、マッチングされたマーチャント注文番号で表され、サービス提供通知モジュール１３０が、マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するように配置されることは、
マッチングされたマーチャント注文番号に基づき、当該マーチャント注文番号が含まれるサービス提供通知を前記マーチャントデバイスに送信することで、当該マーチャント注文番号のマーチャント注文によって指示される仮想付加価値サービスを前記ユーザデバイスに提供するように、前記マーチャントデバイスに通知することを含んでもよい。

任意選択で、支払伝票取得モジュール１１０が、前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信するように配置されることは、
前記物品ＩＤに対応する支払い入口を生成することと、
前記ユーザデバイスが前記支払い入口に基づき対応する支払いページを表示するように、前記支払い入口を前記ユーザデバイスに送信することと、を含んでもよい。

任意選択で、図１２は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、図１０及び図１２に示すように、当該装置はさらに、
マーチャントデバイスにサービス提供通知を送信した後、マッチングされたマーチャント注文の注文状態がサービス提供待ちの状態であることを、ユーザデバイスに通知し、及び、前記マーチャントデバイスが前記ユーザデバイスに仮想付加価値サービスを提供した後、マッチングされたマーチャント注文の注文状態がサービス提供済みの状態であることを、ユーザデバイスに通知するように配置される注文状態通知モジュール１５０を含む。

任意選択で、前記支払いプルアップリクエストには少なくとも、前記仮想付加価値サービスに対応する商品識別子が含まれ、１つの商品識別子が１つの仮想付加価値サービスを一意に識別し、前記マーチャント注文が前記商品識別子に対応する。

任意選択で、図１３は本出願の実施例による支払い装置の他の構成ブロック図であり、図１０及び図１３に示すように、当該装置はさらに、
前記支払伝票に基づき、決済データを決定し、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャント身分情報、前記ユーザデバイスに対応するユーザ身分情報、及び前記マーチャント注文のマーチャント注文番号のうちの少なくとも１つが含まれ、及び、決済金額に基づき、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分するように配置される決済モジュール１６０を含む。

本出願の実施例は、処理サーバをさらに提供し、当該処理サーバは、上記の処理サーバに適用されるプログラムモジュールをロードすることによって、本出願の実施例によって提供される支払い方法を実現することができ、処理サーバのオプションのハードウェア構成は、図１４に示すように、少なくとも１つの処理チップ１と、少なくとも１つの通信インタフェース２と、少なくとも１つのメモリ３と、少なくとも１つの通信バス４とを含んでもよい。

本出願の実施例において、処理チップ１、通信インタフェース２、メモリ３、通信バス４の数は少なくとも１つであり、処理チップ１、通信インタフェース２、メモリ３は、通信バス４を介して相互に通信する。

任意選択で、通信インタフェース２は、通信モジュールのインタフェース（例えば、ＧＳＭモジュールのインタフェース）であってもよく、処理チップ１は、１つの中央演算処理装置ＣＰＵ、又は、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、特定用途向け集積回路）、又は、本出願の実施例を実施するように配置される１つ以上の集積回路であり得る。

メモリ３は、高速ＲＡＭメモリを含んでもよく、不揮発性メモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えば少なくとも１つの磁気ディスクメモリを含んでもよい。

メモリ３にはプログラムが記憶されてもよく、処理チップ１は、メモリ３に記憶されるプログラムを呼び出すことで、前記処理サーバによって実行される支払い方法のステップを実現する。

本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、上記の処理サーバによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。

任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定し、前記マーチャント注文は、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応し、
前記支払い注文の支払伝票を取得し、
前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、
マッチングされたマーチャント注文に基づき、前記ユーザデバイスに対応する仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信する。

任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。

マーチャントデバイスの観点から、本出願の実施例によって提供される支払い装置を以下に紹介し、以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するためにマーチャントデバイスがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互に参照すればよい。

図１５は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、当該装置はマーチャントデバイスに適用され、図１５を参照し、当該装置は、
ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュール２００と、
支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュール２１０であって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた支払い注文を生成するようにリクエストするために用いられる支払い注文生成リクエストモジュール２１０と、
前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュール２２０と、
前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュール２３０と、を含んでもよい。

任意選択で、マーチャント注文生成モジュール２００が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されることは、
ユーザデバイスの支払いプルアップリクエストを取得し、前記支払いプルアップリクエストが少なくとも、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスを指示することと、
前記仮想付加価値サービスに対応するマーチャント注文を生成することと、を含んでもよい。

任意選択で、前記マーチャント注文には少なくとも、前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格が含まれる。

支払い注文生成リクエストモジュール２１０が、支払い注文生成リクエストを処理サーバに送信するように配置されることは、
少なくとも前記マーチャント注文番号及び前記取引価格が含まれる支払い注文生成リクエストを処理サーバに送信し、前記支払い注文が前記マーチャント注文番号にバインドされたことを含んでもよい。

任意選択で、前記支払い注文は、前記取引価格に対応する物品ＩＤで表され、１つの取引価格は、順番に使用される複数の物品ＩＤに対応する。

任意選択で、サービス提供モジュール２３０が、前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供するように配置されることは、
前記サービス提供通知に含まれるマーチャント注文番号に基づき、当該マーチャント注文番号に対応するマーチャント注文を決定することと、
当該マーチャント注文によって指示される仮想付加価値サービスを決定することと、
決定した仮想付加価値サービスを前記ユーザデバイスに提供することと、を含んでもよい。

任意選択で、前記支払いプルアップリクエストには少なくとも、前記仮想付加価値サービスに対応する商品識別子が含まれ、１つの商品識別子が１つの仮想付加価値サービスを一意に識別する。

マーチャント注文生成モジュール２００が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されることは、前記商品識別子に対応するマーチャント注文を生成することを含んでもよい。

任意選択で、図１６は本出願の実施例による支払い装置の他の構成ブロック図であり、図１５及び図１６に示すように、当該装置は、
マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供した後、マッチングされたマーチャント注文の注文状態をサービス提供済みの状態に更新するように、前記処理サーバに通知するように配置される注文状態通知更新モジュール２４０を含んでもよい。

本出願の実施例は、マーチャントデバイスをさらに提供し、当該マーチャントデバイスは、上記のマーチャントデバイスに適用されるプログラムモジュールをロードすることで、本出願の実施例によって提供される支払い方法を実現することができる。

マーチャントデバイスのオプションのハードウェア構成について、図１４を参照すればよく、任意選択で、マーチャントデバイスは、少なくとも１つのメモリと少なくとも１つの処理チップとを含んでもよく、当該メモリにはプログラムが記憶され、当該処理チップは、前記プログラムを呼び出すことで、前記マーチャントデバイスによって実行される支払い方法のステップを実現する。

本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、前記マーチャントデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。

任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成し、
支払い注文生成リクエストを処理サーバに送信し、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた支払い注文を生成するように処理サーバにリクエストするために用いられ、
前記処理サーバが前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされたマーチャント注文をマッチングした後、前記処理サーバによって送信されたサービス提供通知を受信し、
前記サービス提供通知に基づき、マッチングされたマーチャント注文に対応する仮想付加価値サービスを前記ユーザデバイスに提供する。

任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。

ユーザデバイスの観点から、本出願の実施例によって提供される支払い装置を以下に紹介し、以下で説明する支払い装置は、本出願の実施例によって提供される支払い方法を実現するために、ユーザデバイスがセットアップする必要があるプログラムモジュールと見なされてもよく、以下で説明する支払い装置の内容は、上記の支払い方法の内容と相互に参照すればよい。

図１７は本出願の実施例による支払い装置の他の構成ブロック図であり、当該装置はユーザデバイスに適用され、図１７を参照し、当該装置は、
処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュール３００であって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュール３００と、
前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュール３１０と、
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュール３２０と、を備える。

任意選択で、支払い装置は、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得する前に、さらに、少なくとも前記仮想付加価値サーバを指示する支払いプルアップリクエストを処理サーバに送信することで、前記処理サーバが前記支払いプルアップリクエストをマーチャントデバイスに送信し、前記マーチャントデバイスが前記仮想付加価値サービスに対応するマーチャント注文を生成するために用いられてもよい。

任意選択で、支払いプルアップ通知取得モジュール３００が、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置されることは、
処理サーバが、前記マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定した後、前記処理サーバによって送信された支払いプルアップ通知を取得することを含んでもよい。

任意選択で、支払い装置が、少なくとも前記仮想付加価値サーバを指示する支払いプルアップリクエストを処理サーバに送信するように配置されることは、
アプリケーションを介してマーチャントのサービスページにアクセスすることと、
前記サービスページの仮想付加価値サービスの支払いプル入口がクリックされることで、支払いプルアップリクエストを生成し、前記支払いプルアップリクエストが少なくとも前記仮想付加価値サービスを指示することと、を含んでもよい。

任意選択で、前記アプリケーションを介してマーチャントのサービスページにアクセスすることは、
アプリケーションによって、マーチャントのプログラムページのリンク２次元コードをスキャンするか、又は、アプリケーションによって、プログラムページのリンクのアドレスにアクセスすることで、マーチャントのプログラムページをロードすることを含んでもよく、前記プログラムページは、マーチャントによって提供される少なくとも１つの仮想付加価値サービスの支払いプルアップ入口を有する。

任意選択で、前記支払いプルアップリクエストを生成することは、
クリックされた支払いプルアップ入口に関連付けられる商品識別子を決定し、少なくとも前記商品識別子が含まれる支払いプルアップリクエストを生成することを含んでもよい。

任意選択で、支払いプルアップ通知取得モジュール３００が、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置されることは、支払い注文の支払い入口を取得することを含んでもよい。

任意選択で、支払伝票送信モジュール３１０が、前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置されることは、
前記支払いプルアップ通知に基づき、前記支払い注文を支払うことと、
支払いに対応する支払伝票を取得することと、
前記支払伝票を処理サーバに送信することと、を含んでもよい。

任意選択で、支払伝票送信モジュール３１０が、前記支払いプルアップ通知に基づき、前記支払い注文を支払うように配置されることは、
前記支払い入口に基づき、対応する支払いページを表示することと、
支払いページでのユーザの支払い認証入力操作に応答して、支払いチャネルサーバに前記支払い注文に対する支払いリクエストを送信することとを含んでもよい。

任意選択で、前記支払い注文は、前記マーチャント注文の取引価格に対応する物品ＩＤで表され、１つの取引価格は、順番に使用される複数の物品ＩＤに対応し、前記マーチャント注文は、一意に識別されるマーチャント注文番号によって識別される。

図１８は、本出願の実施例によって提供される支払い装置の他の構成ブロック図であり、図１７及び図１８に示すように、当該装置はさらに、
前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記処理サーバによって送信された、マッチングされたマーチャント注文の注文状態がサービス提供待ちである通知を取得し、及び、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得した後、前記処理サーバによって送信された、マッチングされたマーチャント注文の注文状態がサービス提供済みである通知を取得するように配置される、注文状態通知取得モジュール３３０を含んでもよい。

本出願の実施例は、ユーザデバイスをさらに提供し、当該ユーザデバイスは、前記ユーザデバイスに適用されるプログラムモジュールをロードすることで、本出願の実施例によって提供される支払い方法を実現することができる。

ユーザデバイスのオプションのハードウェア構成について、図１４を参照すればよく、任意選択で、ユーザデバイスは、少なくとも１つのメモリと少なくとも１つの処理チップとを含んでもよく、当該メモリにはプログラムが記憶され、当該処理チップは、前記プログラムを呼び出すことで、前記ユーザデバイスによって実行される支払い方法のステップを実現する。

本出願の実施例は、記憶媒体をさらに提供し、当該記憶媒体には、前記ユーザデバイスによって実行される支払い方法のステップを実現するために、処理チップによって実行されるのに適するプログラムが記憶される。

任意選択で、前記プログラムは主に以下の機能を実現し、即ち、
処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得し、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応し、
前記支払い注文に対応する支払伝票を、前記処理サーバに送信し、
前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされたマーチャント注文をマッチングし、前記処理サーバが、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するようにマーチャントデバイスに通知した後、前記マーチャントデバイスによって提供される仮想付加価値サービスを取得する。

任意選択で、前記プログラムの機能の細分化及び拡張機能について、上記の支払い方法の内容を参照すればよい。

本出願の実施例は、支払いシステムをさらに提供し、当該支払いシステムの構成は、図１に示すように、ユーザデバイスと、マーチャントデバイスと、処理サーバとを含み、ユーザデバイス、マーチャントデバイス及び処理サーバがそれぞれ実現する機能について、前述の説明を参照することができ、ここでは繰り返さない。

本明細書における各実施例は、漸進的に説明され、各実施例が主に他の実施例との相違点を説明し、各実施例の間の同じ又は類似する部分について、互いに参照すればよい。実施例に開示された装置にとって、実施例に開示された方法に対応するから、説明は比較的に簡単であり、関連部分は、方法部分の説明を参照すればよい。

本明細書に開示された実施例で説明される各例示的なユニット及びアルゴリズムステップは、電子ハードウェア、コンピューターソフトウェア又は両者の組み合わせで実現できることを専門家はさらに理解することができ、ハードウェアとソフトウェアとの互換可能性を明らかに説明するために、以上の説明では、機能に従って、各例示的な構成及びステップを既に一般的に説明した。これらの機能がハードウェアによって実行されるか、それともソフトウェアによって実行されるかは、技術案の特定の応用及び設計制約条件に依存する。当業者は、特定の応用ごとに、異なる方法で、説明される機能を実現することができるが、このような実現は本出願の範囲を超えるとみなされるべきではない。

本明細書に開示された実施例で説明される方法又はアルゴリズムのステップは、ハードウェア、処理チップによって実行されるソフトウェアモジュール、又は両者の組み合わせによって直接に実施されることができる。ソフトウェアモジュールは、ランダムアクセスメモリ（ＲＡＭ）、内部メモリ、読み取り専用メモリ（ＲＯＭ）、電気的にプログラム可能なＲＯＭ、電気的に消去及びプログラム可能なＲＯＭ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ－ＲＯＭ、又は技術分野で既知の他の任意の形の記憶媒体に配置されてもよい。

開示された実施例に対する前述の説明は、当業者が本出願を実現又は利用することができることを可能にする。これらの実施例に対する様々な補正は、当業者にとって自明であり、本明細書で定義された一般的な原理は、本出願の核心思想又は範囲から逸脱することなく、他の実施例で実現されることができる。従って、本出願は、本明細書に示されたこれらの実施例に限定されず、本明細書に開示された原理及び新規の特徴と一致する最も広い範囲に適合すべきである。

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 注文状態通知取得モジュール

Claims (24)

1. 支払い方法であって、
   処理サーバが、マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するステップであって、前記マーチャント注文が、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、
   前記処理サーバが前記支払い注文の支払伝票を取得するステップと、
   前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするステップと、
   前記処理サーバがマッチングされた前記マーチャント注文の状態をマッチング済みとしてマークするステップと、
   前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークするステップと、
   前記処理サーバがマッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を、前記マーチャントデバイスに送信するステップと、を含む支払い方法。
2. 前記処理サーバが前記マーチャントデバイスによって生成された前記マーチャント注文にバインドされた前記支払い注文を決定する前記ステップは、
   前記処理サーバが、前記ユーザデバイスの支払いプルアップリクエストを前記マーチャントデバイスに送信するステップであって、前記支払いプルアップリクエストが少なくとも前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスを指示するステップと、
   前記処理サーバが、前記マーチャントデバイスによって送信された支払い注文生成リクエストを取得するステップであって、前記支払い注文生成リクエストが、前記仮想付加価値サービスに対応する前記マーチャント注文があることを少なくとも指示するステップと、
   前記処理サーバが、前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた前記支払い注文を決定するステップと、を含む請求項１に記載の支払い方法。
3. 前記処理サーバが前記支払い注文の前記支払伝票を取得する前記ステップは、
   前記処理サーバが前記支払い注文に基づき、支払いプルアップ通知を前記ユーザデバイスに送信するステップと、
   前記処理サーバが、前記支払い注文に対する前記ユーザデバイスによる支払いに対応する前記支払伝票を取得するステップと、を含む請求項１又は２に記載の支払い方法。
4. 前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文にバインドされた前記支払い注文を決定する前記ステップは、
   前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文の取引価格を決定するステップと、
   前記処理サーバが、前記取引価格に対応する物品ＩＤを決定し、前記物品ＩＤを前記マーチャント注文にバインドするステップであって、前記物品ＩＤが支払いチャネルサーバに登録されるステップと、を含む請求項２に記載の支払い方法。
5. 前記支払い注文生成リクエストには少なくとも、前記マーチャント注文を一意に識別するためのマーチャント注文番号、及び前記マーチャント注文の前記取引価格が含まれ、
   前記処理サーバが前記支払い注文生成リクエストに基づき、前記マーチャント注文の前記取引価格を決定する前記ステップは、
   前記処理サーバが、前記支払い注文生成リクエストに含まれる前記マーチャント注文の前記取引価格を決定するステップを含み、
   前記処理サーバが前記物品ＩＤを前記マーチャント注文にバインドする前記ステップは、
   前記処理サーバが、前記物品ＩＤを前記マーチャント注文番号にバインドするステップを含む請求項４に記載の支払い方法。
6. 前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングする前記ステップは、
   前記物品ＩＤにバインドされたマーチャント注文の数が１つである場合、前記処理サーバが、前記物品ＩＤに一意にバインドされたマーチャント注文をマッチングするステップと、
   前記物品ＩＤにバインドされたマーチャント注文の数が複数である場合、前記処理サーバが、前記物品ＩＤにバインドされた複数のマーチャント注文を前記ユーザデバイスに送信し、前記複数のマーチャント注文から前記ユーザデバイスによって決定されたマーチャント注文を、マッチングされた前記マーチャント注文とするステップと、を含み、
   前記ユーザデバイスが同じ取引価格の仮想付加価値サービスに対する支払いをプルアップすることをリクエストする回数が、前記取引価格に対応する物品ＩＤのポーリング回数に達した場合、前記物品ＩＤによって、前記取引価格のマーチャント注文を繰り返してバインドする請求項５に記載の支払い方法。
7. 前記処理サーバが前記取引価格に対応する物品ＩＤを決定する前記ステップは、
   前記処理サーバが、前記ユーザデバイスが今回、前記取引価格を利用する順序に従って、前記取引価格に対応する複数の物品ＩＤから、前記順序に対応する物品ＩＤを決定し、１つの取引価格が、順番に使用される複数の物品ＩＤに対応するステップを含む請求項６に記載の支払い方法。
8. 前記処理サーバが、前記物品ＩＤを前記マーチャント注文にバインドした後、前記マーチャント注文の状態を非マッチングとしてマークするステップと、
   をさらに含む請求項６に記載の支払い方法。
9. 前記支払伝票に基づき、決済データを決定するステップであって、前記決済データには、前記仮想付加価値サービスに対応する商品識別子、前記マーチャント注文の取引価格、取引通貨、決済金額、前記マーチャントデバイスに対応するマーチャント身分情報、前記ユーザデバイスに対応するユーザ身分情報、前記マーチャント注文のマーチャント注文番号のうちの少なくとも１つが含まれるステップと、
   前記決済金額に基づき、所定の比例に従って、前記マーチャントデバイスに対応するマーチャントに対して、決済金額を配分するステップと、
   をさらに含む請求項１に記載の支払い方法。
10. 支払い方法であって、
    マーチャントデバイスが、ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するステップと、
    前記マーチャントデバイスが、支払い注文生成リクエストを処理サーバに送信するステップであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするステップと、
    前記マーチャントデバイスが、前記処理サーバによって送信されたサービス提供通知を受信するステップであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文のマッチング後に、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークした後、送信されるステップと、
    前記マーチャントデバイスが、前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するステップと、
    を含む支払い方法。
11. 前記マーチャントデバイスが、前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスに対応する前記マーチャント注文を生成する前記ステップは、
    前記マーチャントデバイスが、前記ユーザデバイスの支払いプルアップリクエストを取得し、前記支払いプルアップリクエストが少なくとも前記ユーザデバイスが購入をリクエストする前記仮想付加価値サービスを指示するステップと、
    前記マーチャントデバイスが、前記仮想付加価値サービスに対応する前記マーチャント注文を生成するステップと、を含む請求項１０に記載の支払い方法。
12. 前記マーチャント注文は少なくとも、
    前記マーチャント注文を一意に識別するマーチャント注文番号、及び前記マーチャント注文の取引価格を含み、
    前記マーチャントデバイスが前記支払い注文生成リクエストを前記処理サーバに送信する前記ステップは、
    前記マーチャントデバイスが、少なくとも前記マーチャント注文番号と前記取引価格とが含まれる前記支払い注文生成リクエストを前記処理サーバに送信するステップ、を含む請求項１１に記載の支払い方法。
13. 前記支払い注文は、前記取引価格に対応する物品ＩＤで表され、１つの取引価格は、順番に使用される複数の物品ＩＤに対応する請求項１２に記載の支払い方法。
14. 前記マーチャントデバイスが、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供した後、マッチングされた前記マーチャント注文の注文状態をサービス提供済みの状態に更新するように、前記処理サーバに通知するステップ、をさらに含む請求項１０に記載の支払い方法。
15. 支払い方法であって、
    ユーザデバイスが、処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するステップであって、前記支払い注文が、マーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するステップと、
    前記ユーザデバイスが、前記支払い注文に対応する支払伝票を前記処理サーバに送信するステップと、
    前記ユーザデバイスが、前記マーチャントデバイスによって提供された仮想付加価値サービスを取得するステップであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供するように、前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるステップと、
    を含む支払い方法。
16. 前記ユーザデバイスがアプリケーションを介してマーチャントのサービスページにアクセスするステップと、
    前記ユーザデバイスが、前記サービスページの仮想付加価値サービスの支払いプルアップ入口でクリック操作が実行されたことを検出した後、支払いプルアップリクエストを前記処理サーバに送信し、前記支払いプルアップリクエストが少なくとも前記仮想付加価値サービスを指示するステップと、
    をさらに含む請求項１５に記載の支払い方法。
17. 処理サーバに適用される支払い装置であって、
    マーチャントデバイスによって生成されたマーチャント注文にバインドされた支払い注文を決定するように配置される支払い注文決定モジュールであって、前記マーチャント注文がユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払い注文決定モジュールと、
    前記支払い注文の支払伝票を取得するように配置される支払伝票取得モジュールと、
    前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングするように配置されるマーチャント注文マッチングモジュールと、
    マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークするように配置される状態マークモジュールと、
    マッチングされた前記マーチャント注文に基づき、前記ユーザデバイスに前記仮想付加価値サービスを提供するためのサービス提供通知を前記マーチャントデバイスに送信するように配置されるサービス提供通知モジュールと、を含む支払い装置。
18. 少なくとも１つのメモリと少なくとも１つの処理チップを含む処理サーバであって、
    前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項１から９のいずれか１項に記載の支払い方法のステップを実現する処理サーバ。
19. マーチャントデバイスに適用される支払い装置であって、
    ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応するマーチャント注文を生成するように配置されるマーチャント注文生成モジュールと、
    支払い注文生成リクエストを処理サーバに送信するように配置される支払い注文生成リクエストモジュールであって、前記支払い注文生成リクエストが、前記マーチャント注文にバインドされた前記支払い注文を生成するように前記処理サーバにリクエストするために用いられる支払い注文生成リクエストモジュールと、
    前記処理サーバによって送信されたサービス提供通知を受信するように配置されるサービス提供通知受信モジュールであって、前記サービス提供通知が、前記処理サーバによって、前記支払い注文に対応する支払伝票を取得し、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文のマッチング後に、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークした後、送信されるサービス提供通知受信モジュールと、
    前記サービス提供通知に基づき、マッチングされた前記マーチャント注文に対応する前記仮想付加価値サービスを前記ユーザデバイスに提供するように配置されるサービス提供モジュールと、を含む支払い装置。
20. 少なくとも１つのメモリと少なくとも１つの処理チップを含むマーチャントデバイスであって、前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項１０から１４のいずれか１項に記載の支払い方法のステップを実現するマーチャントデバイス。
21. ユーザデバイスに適用される支払い装置であって、
    処理サーバによって送信された、少なくとも支払い注文を指示する支払いプルアップ通知を取得するように配置される支払いプルアップ通知取得モジュールであって、前記支払い注文がマーチャントデバイスによって生成されたマーチャント注文にバインドされ、前記マーチャント注文が、前記ユーザデバイスが購入をリクエストする仮想付加価値サービスに対応する支払いプルアップ通知取得モジュールと、
    前記支払い注文に対応する支払伝票を、前記処理サーバに送信するように配置される支払伝票送信モジュールと、
    前記マーチャントデバイスによって提供される仮想付加価値サービスを取得するように配置されるサービス取得モジュールであって、前記仮想付加価値サービスが、前記処理サーバが前記支払伝票に基づき、前記支払い注文にバインドされた前記マーチャント注文をマッチングし、マッチングされた前記マーチャント注文の状態をマッチング済みとしてマークし、前記支払い注文にバインドされた前記マーチャント注文をマッチングした後、前記マーチャント注文の数が複数である場合、マッチングされていない前記マーチャント注文の状態をマッチング済みとしてマークし、マッチングされたマーチャント注文に対応する仮想付加価値サービスを提供することを前記マーチャントデバイスに通知した後、前記マーチャントデバイスによって提供されるサービス取得モジュールと、を含む支払い装置。
22. 少なくとも１つのメモリと少なくとも１つの処理チップとを含むユーザデバイスであって、
    前記メモリにはプログラムが記憶され、前記処理チップが前記プログラムを呼び出すことで、請求項１５又は１６に記載の支払い方法のステップを実現するユーザデバイス。
23. コンピュータに請求項１乃至１６の何れか一項に記載の方法を実行させるコンピュータプログラム。
24. 支払いシステムであって、請求項１８に記載の処理サーバと、請求項２０に記載のマーチャントデバイスと、請求項２２に記載のユーザデバイスとを含む支払いシステム。

Images