JP2017517061A - 仮想カード値を用いる取引の実行 - Google Patents

Abstract

仮想カード値を用いる取引の実行が開示される。仮想カード値を用いる取引の実行は、取引に対応する仮想カード値を生成し、仮想カード値と取引に対応する取引金額とを含む要求をカード管理サーバに送信し、仮想カード値および取引金額が適切に格納された旨の表示をカード管理サーバから受信し、業者サーバに関連付けられている識別情報および仮想カード値に少なくとも部分的に基づいて業者関連ロケータを生成し、業者関連ロケータをクライアント・デバイスに送信し、カードレス支払サーバに関連付けられているユーザ・アカウントから業者サーバに関連付けられている資金アカウントに取引金額を転送する要求をカード管理サーバから受信することを備える。【選択図】図５

Description

従来、業者は、複数のカード発行体と統合された支払システムを有している。たとえば、カード発行体は、銀行および／またはクレジット・カード会社を含み得る。カード発行体は、物理的なカードを顧客に発行することができる。たとえば、そのようなカード所有顧客がオンラインで購入を要望するときは、カード発行体によりその顧客に発行された物理的なデビット・カードまたはクレジット・カードのアカウント番号および／またはカード番号を、業者に提供することができる。業者は、顧客により供給されたカード情報を使用して、ユーザのアカウント／カードに購入金額を請求することができる。最終的に、カード発行体は、ユーザのオンライン購入に関連付けられている資金を業者に転送する処理を簡素化することができる。クレジット・カードまたはデビット・カードのサイン・アップは、典型的にはかなりの時間を要する処理であり、法的規制に左右される。よって、海外に住んでいる人など、一部の顧客は、オンライン購入用にクレジット・カードまたはデビット・カードを取得するのが難しいことがある。

本発明のさまざまな実施形態が、以下の詳細な説明および添付の図面で開示される。

仮想カード値を用いて取引を実行するシステムの実施形態を示す図である。

カードレス支払サーバの例を示す図である。

オンライン支払プラットフォームで新規ユーザ・アカウントを作成する処理の実施形態を示すフロー図である。

オンライン支払プラットフォームのユーザを認証する処理の実施形態を示すフロー図である。

仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。

取引に対応する仮想カード値を生成する処理の実施形態を示すフロー図である。

取引が仮想カード値を用いて実行される例を示すシーケンス図である。

仮想カード値を用いて完了した取引に関連付けられている返金を実行する処理の実施形態を示すフロー図である。

仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。

仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。

電子商取引ウェブサイトの精算処理に関連付けられている支払方法の選択を促すユーザ・インターフェイスの例を示す図である。

取引を完了するために使用するものとして選択されたオンライン支払プラットフォームに関連付けられているユーザ認証情報を促すユーザ・インターフェイスの例を示す図である。

取引に適用されるユーザ資金源の選択を促すユーザ・インターフェイスの例を示す図である。

取引完了情報を提示するユーザ・インターフェイスの例を示す図である。

本発明は、処理として、装置として、システムとして、組成物として、コンピュータ可読ストレージ媒体で実施されるコンピュータ・プログラム製品として、ならびに／または結合先のメモリにより格納および／もしくは提供された命令を実行するように構成されているプロセッサ等のプロセッサとして、などの多数の方法で実装することができる。本明細書では、これらの実装、または本発明がとり得る他の任意の形態が、手法と呼ばれ得る。一般的に、開示される処理のステップの順序は、本発明の範囲内で変更することができる。特に指示のない限り、タスクを実行するように構成されているものとして説明される、プロセッサやメモリなどの構成要素は、そのタスクを所定時間で実行するように一時的に構成されている汎用構成要素またはそのタスクを実行するように製造された専用構成要素として実装され得る。本明細書で使用される「プロセッサ」という用語は、コンピュータ・プログラム命令等のデータを処理するように構成されている１つまたは複数のデバイス、回路、および／または処理コアを表す。

本発明の１つまたは複数の実施形態の詳細な説明が、本発明の原理を示す添付の図面と共に、以下に提供される。本発明はそのような実施形態と組み合わせて説明されるが、本発明はいかなる実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、多数の代替物、変形物、および等価物を包含する。本発明を完全に理解できるよう、多数の具体的な詳細が以下の説明で示される。これらの詳細は、例示を目的として提供されるものであり、本発明は、これらの具体的な詳細の一部またはすべてを伴わずに、特許請求の範囲に応じて実践され得る。明確性を目的として、本発明に関連する技術分野で知られている技術資料については、本発明が無用に不明瞭にならないよう、詳しく説明していない。

一部のシナリオでは、オンライン電子商取引プラットフォームのユーザは、物理的なデビット・カードもしくはクレジット・カードを所有せず、および／またはカード管理サービスにより発行される物理的なデビット・カードもしくはクレジット・カードを受け取る資格が（たとえば、規制問題に起因して）ない。カード管理サービスの例として、銀行やクレジット・カード会社がある。そのような種類のカード管理サービスは、カード管理サービスによる物理的なカードの発行を受けたユーザが、そのユーザのカードのアカウント情報（たとえば、クレジット・カード情報および／またはセキュリティ番号）を提供することにより業者に購入の支払いができる態様で多用な業者の支払システムと伝統的に統合された支払システム（たとえば、販売時点管理システム、クレジット・カード支払端末、サーバ）を有している可能性がある。しかし、物理的なデビット・カードもしくはクレジット・カードを所有しないユーザ、および／またはカード管理サービスにより発行された物理的なデビット・カードもしくはクレジット・カードを受け取る資格がないユーザは、それらの業者で購入を行うための便利な代替方法を、仮に存在したとしても、持たない可能性がある。

多くのユーザは、オンライン支払プラットフォームにアカウントを所有している。オンライン支払プラットフォームの例として、Ａｌｉｐａｙ（登録商標）がある。従来、オンライン支払プラットフォームは、そのユーザに必ずしも物理的なカードを発行するとは限らないが、ユーザがオンライン支払プラットフォームに統合されたオンライン業者に対して、ユーザがオンライン支払プラットフォームで自らのユーザ・アカウントに関連付けられている資金を通じて、オンライン支払いをできるようにする場合がある。たとえば、オンライン業者で購入を行うために、オンライン支払プラットフォームのユーザは、自分のオンライン支払プラットフォームにログインし、購入金額の転送元となる資金源を選択することができる。

しかし、カード管理サービスにより発行された物理的なカードを受け入れる一部の業者は、オンライン支払プラットフォームに統合されていない。そのため、従来、オンライン支払プラットフォームのアカウントは所有しているが、カード管理サービスにより発行された物理的なカードを所有していないユーザは、支払システムがカード管理サービスのシステムと伝統的に統合されているがオンライン支払プラットフォームとは統合されていない一部の業者から、購入することができない場合があった。

よって、オンライン支払プラットフォームのユーザがそれぞれのオンライン支払プラットフォーム・アカウントに関連付けられている資金を使用して、システムがオンライン支払プラットフォームのシステムと統合されていないが１つまたは複数のカード管理サービスのシステムと伝統的に統合されている業者に対して、支払いができるようにすることが望まれる。そのような取引は、業者サーバと伝統的に統合されているカード管理サーバを、オンライン支払プラットフォームに関連付けられているカードレス支払サーバと協調してそのような取引ごとに仮想カード値を発行するように構成することにより、実現することができる。

仮想カード値を用いて取引を実行する実施形態が本明細書で説明される。さまざまな実施形態では、オンライン支払プラットフォームのユーザは、取引に対して発行された仮想カード値を通じて、自らのオンライン支払プラットフォーム・アカウントに関連付けられている資金により、業者に対して取引の支払いを行うことができる。さまざまな実施形態では、仮想カード値は、一連の英数字を含む。一部の実施形態では、仮想カード値は、単一の取引に対してのみ有効である。さまざまな実施形態では、一意の仮想カード値が各取引に対して生成される。さまざまな実施形態では、取引に対応する仮想カード値は、カードレス支払サーバにより生成される。この値が仮想と呼ばれるのは、実際の物理的なカードを発行する必要がないからである。さまざまな実施形態では、カードレス支払サーバは、オンライン支払プラットフォームの構成要素として実装することができる。仮想カード値は、既に業者と統合されたカード管理サーバにより、取引を完了するために使用される。

図１は、仮想カード値を用いて取引を実行するシステムの実施形態を示す図である。この例では、システム１００は、クライアント・デバイス１０２と、ネットワーク１０４と、業者サーバ１０６と、カードレス支払サーバ１０８と、カード管理サーバ１１０とを含む。ネットワーク１０４は、１つまたは複数の高速データ・ネットワークおよび／または電気通信ネットワークを含む。

クライアント・デバイス１０２はスマート・フォンとして示されているが、クライアント・デバイス１０２の他の例として、ラップトップ・コンピュータ、デスクトップ・コンピュータ、モバイル・デバイス、タブレット・デバイス、および／または任意のコンピューティング・デバイスがある。さまざまな実施形態では、ウェブ・ブラウザ・アプリケーションがクライアント・デバイス１０２で実行されている。ユーザであるアリスは、クライアント・デバイス１０２で実行されているウェブ・ブラウザを使用してオンライン支払プラットフォーム（たとえば、Ａｌｉｐａｙ（登録商標））に関連付けられているウェブサイトにアクセスすることにより、オンライン支払プラットフォームに関連付けられているユーザ・アカウントを既に作成している。さらに、アリスは、既にオンライン支払プラットフォームのアカウントに資金を預け、および／またはオンライン支払プラットフォームで自らのアカウントを使用して実行される将来の（たとえば、オンライン）購入で使用する１つまたは複数の資金源を特定している可能性がある。さまざまな実施形態では、カードレス支払サーバ１０８は、少なくとも部分的には、オンライン支払プラットフォームにより運用される。

アリスは、クライアント・デバイス１０２で実行されているウェブ・ブラウザを使用して、業者サーバ１０６により運用される電子商取引ウェブサイトを閲覧することができる。業者サーバ１０６は、カード管理サーバ１１０と伝統的に統合されており、カード管理サーバ１１０は、物理的なクレジット・カードおよび／またはデビット・カードを発行するカード管理サービスに関連付けられている。カード管理サービスの例として、Ｖｉｓａ（登録商標）、Ｍａｓｔｅｒｃａｒｄ（登録商標）、Ｄｉｓｃｏｖｅｒ（登録商標）、およびＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）などのクレジット・カード会社がある。業者サーバ１０６がカード管理サーバ１１０と既に統合されているため、カード管理サービスから物理的なカードを発行されているユーザは、物理的なカードに関連付けられているアカウント情報を業者サーバ１０６に提出することにより、業者サーバ１０６により運用されるウェブサイトで購入を行うことができ、最終的に業者サーバ１０６は、カード管理サーバ１１０と直接やり取りして、そのユーザの資金を転送して購入金額をカバーする作業を調整する。業者サーバ１０６はカードレス支払サーバ１０８と統合されておらず、したがって従来、オンライン支払プラットフォームにアカウントを所有するユーザは、業者サーバ１０６に直接資金を支払うことはできない。

さまざまな実施形態では、カード管理サーバ１１０がカードレス支払サーバ１０８と協調してオンライン支払プラットフォームにアカウントを所有するユーザがカード管理サーバ１１０により認識される仮想カード値を通じて業者サーバ１０６に支払いができるようにする態様で、オンライン支払プラットフォームとカード管理サービスとの間で調整がなされている。

したがって、アリスは、カードレス支払サーバ１０８が業者サーバ１０６と統合されていなくても、カードレス支払サーバ１０８に関連付けられているオンライン支払プラットフォームの自らのアカウントを使用して、業者サーバ１０６により運用されるウェブサイトで購入を行うことができる。以下で詳細に説明するように、アリスは、カード管理サーバ１１０に関連付けられているカード管理サービスにより発行された物理的なカードを所有しているか否かに関係なく、オンライン支払プラットフォームのアカウントに関連付けられている資金を使用して、業者サーバ１０６で購入を行うことができる。

たとえば、アリスが業者サーバ１０６により運用されるウェブサイトで取引の完了を選択したことに応じて、クライアント・デバイス１０２で実行されているウェブ・ブラウザは、業者サーバ１０６に支払要求を送信する。クライアント・デバイス１０２からの支払要求の受信に応じて、業者サーバ１０６は、クライアント・デバイス１０２で実行されているウェブ・ブラウザをカードレス支払サーバ１０８にリダイレクトするように構成されている。クライアント・デバイス１０２で実行されているウェブ・ブラウザからの要求の受信に応じて、カードレス支払サーバ１０８は、オンライン支払プラットフォームのアカウントに関連付けられているユーザ認証情報を促すページに関連付けられているデータを送信するように構成されている。クライアント・デバイス１０２で実行されているウェブ・ブラウザは、オンライン支払プラットフォームのアカウントに関連付けられているユーザ認証情報（たとえば、ログイン名およびパスワード）を促すページを、アリスに提示することができる。続いてアリスは、クライアント・デバイス１０２で実行されているウェブ・ブラウザを通じて、自らの認証情報をカードレス支払サーバ１０８に提出することができる。カードレス支払サーバ１０８がアリスを認証した場合、カードレス支払サーバ１０８は、以下で詳細に説明するように、アリスの当該特定の取引に対応する（たとえば、一意の）仮想カード値を生成する。続いてカードレス支払サーバ１０８は、生成された仮想カード値を、取引に関連する他の情報（たとえば、アリスが要望する購入の価格である、取引金額）と共に、カード管理サーバ１１０に送信する。さまざまな実施形態では、カードレス支払サーバ１０８は、アリスのプライバシーを保護するために、アリスに関連付けられている一切の追加ユーザ情報を、仮想カード値と共にカード管理サーバ１１０に送信しない。

カード管理サーバ１１０は、受信した仮想カード値と取引に対応する取引情報とを格納し、それらの情報が正常に格納されたときに、カードレス支払サーバ１０８に表示（通知）を返すように構成されている。カード管理サーバ１１０が仮想カード値および取引金額を正常に格納した旨の表示の受信に応じて、カードレス支払サーバ１０８は、クライアント・デバイス１０２で実行されているウェブ・ブラウザに、データ（たとえば、業者関連ロケータ）を送信するように構成されている。このデータは、仮想カード値と取引金額とを含んでおり、クライアント・デバイス１０２で実行されているウェブ・ブラウザを業者サーバ１０６にリダイレクトし、業者サーバ１０６に仮想カード値と取引金額とを含む事前承認要求をカード管理サーバ１１０に送信させるために使用することができる。業者サーバ１０６からの事前承認要求の受信に応じて、カード管理サーバ１１０は、取引に対応する仮想カード値に対応するデータを格納して、取引金額が業者サーバ１０６に関連付けられている資金アカウントに最終的に支払われることが承認されたことを示す。またカード管理サーバ１１０は、仮想カード値に関連付けられている事前承認確認を業者サーバ１０６に送信する。カード管理サーバ１１０からの事前承認確認の受信に応じて、業者サーバ１０６は、取引が完了した旨のデータを格納し、クライアント・デバイス１０２で実行されているウェブ・ブラウザに、取引が正常に完了したことをアリスに通知するページに関連付けられているデータを送信する。

最終的に（たとえば、毎日の設定時刻に）、業者サーバ１０６は、少なくとも上述したアリスの取引に対応する仮想カード値を含む取込要求を、カード管理サーバ１１０に送信する。業者サーバ１０６からの取込要求の受信に応じて、カード管理サーバ１１０は、仮想カード値に対応する取引金額を仮想カード値に関連付けられているユーザ資金源から業者サーバ１０６に関連付けられている資金アカウントに転送する要求を、カードレス支払サーバ１０８に送信する。カード管理サーバ１１０からの資金転送要求の受信に応じて、カードレス支払サーバ１０８は、この取引に適用するものとしてアリスにより選択された資金源を検索し、検索された資金源から業者サーバ１０６に関連付けられている資金アカウントに取引金額を転送する要求を（たとえば、検索されたユーザ資金源に関連付けられている金融機関またはオンライン支払システムに）送信するように構成されている。

そのため、アリスは、カード管理サーバ１１０に関連付けられているカード管理サービスにより発行された物理的なカードを所有していても、所有していなくても、自らのオンライン支払プラットフォーム・アカウントを使用して、業者サーバ１０６で購入を行うことができる。業者からは、アリスがカード管理サーバ１１０に関連付けられているカード管理サービスにより発行された物理的なクレジット・カードおよび／またはデビット・カードで支払いを行ったように見える。アリスからは、アリスが自らのオンライン支払プラットフォーム・アカウントを直接使用して、業者サーバ１０６により運用されるウェブサイトで購入を行ったように見え、アリスは、仮想カード値が自らの取引に対して生成されたこと、および／またはオンライン支払プラットフォームと提携している（カード管理サーバ１１０に関連付けられている）特定のカード管理サービスで使用されたことに気付かない可能性がある。一部の実施形態では、業者サーバ１０６が複数のカード管理サービスと伝統的に統合されている場合、それらのカード管理サービスの１つまたは複数をカードレス支払サーバ１０８と協調するように調整して、仮想カード値を本明細書で上述したように使用することができる。

図２は、カードレス支払サーバの例を示す図である。一部の実施形態では、図１のシステム１００のカードレス支払サーバ１０８は、図２の例を使用して実装することができる。ユーザ・アカウント・データベース２０２および取引データベース２０４は、それぞれ１つまたは複数のデータベースを使用して実装することができる。認証エンジン２０６、仮想カード値生成エンジン２０８、業者関連ロケータ生成エンジン２１０、および資金転送エンジン２１２は、それぞれソフトウェアおよび／またはハードウェアの一方または両方を使用して実装することができる。

ユーザ・アカウント・データベース２０２は、カードレス支払サーバが関連付けられているオンライン支払プラットフォームで作成されたユーザ・アカウントに関連付けられている情報を格納するように構成されている。たとえば、ユーザ・アカウントに関連付けられている情報は、ユーザ識別子、ユーザ認証情報（たとえば、ログイン名およびパスワード）、ユーザにより行われた各取引に対応する（たとえば、一意の）仮想カード値、ユーザのオンライン支払プラットフォーム・アカウントに預けられた資金の金額（存在する場合）、ユーザに対して格納された１つまたは複数の（たとえば、外部）資金源（たとえば、銀行口座番号）、および取引データベース２０４の対応するエントリに関連付けられているデータを含み得る。

取引データベース２０４は、仮想カード値を用いて実行されたさまざまな取引に関連付けられている情報を、ユーザ・アカウント・データベース２０２に情報が格納された対応するユーザ・アカウントに対して格納するように構成されている。たとえば、取引に関連付けられている情報は、取引識別子（たとえば、カードレス支払サーバで内部的に維持される一意識別子）、仮想カード値、取引金額、取引に含まれるユーザ・アカウントに関連付けられているユーザ識別子、および取引のステータス（たとえば、保留中、完了、返金等）を含み得る。

認証エンジン２０６は、自らのオンライン支払プラットフォーム・アカウントを使用して業者で取引を実行することを要求するユーザを認証するように構成されている。たとえば、業者サーバへの支払いを行うユーザ要求に応じて、業者サーバは、ユーザのウェブ・ブラウザを、１つまたは複数の入力フィールドを通じてユーザ認証情報を提出するよう促す、カードレス支払サーバにより運用されるウェブ・ページにリダイレクトする。認証エンジン２０６は、提出されたユーザ認証情報を、ユーザ・アカウント・データベース２０２に格納された一群のユーザ認証情報と比較して、一致するものが存在するか判断する。一致するものが見つかった場合、認証エンジン２０６は、認証の成功を示すデータをウェブ・ブラウザに送信し、一部の実施形態では、認証エンジン２０６は、現在の取引で使用する特定の資金源を選択するようユーザに促すデータをさらに送信する。ユーザが正常に認証された場合、一部の実施形態では、認証エンジン２０６は仮想カード値生成エンジン２０８にメッセージを送信して、認証されたユーザに関連付けられている取引に対して仮想カード値を生成する必要があることを示し、オプションで、業者と統合されたカード管理サービスに関連付けられている情報を送信する。一致するものが見つからない場合、認証エンジン２０６は、認証の失敗を示すデータをウェブ・ブラウザに送信し、一部の実施形態では、認証エンジン２０６はさらに、認証情報を再提出するようユーザに促す。

仮想カード値生成エンジン２０８は、各取引に対応する仮想カード値を生成するように構成されている。一部の実施形態では、各取引に対して一意の仮想カード値が生成される。さまざまな実施形態では、仮想カード値は、一連の英数字を含む。一部の実施形態では、仮想カード値は、それぞれの値が１つまたは複数の英数字を含む可能性がある３つの値を連結したものを含む。たとえば、第１の値は、取引に関連付けられているユーザ・アカウントに関連付けられている情報に基づいて決定することができ、第２の値は、仮想カード値の発行者に関連付けられている情報（たとえば、業者、オンライン支払プラットフォーム、および／またはカードレス支払サーバに関連付けられている一意識別コード）に基づいて決定することができ、第３の値は、第１の値、第２の値、および第３の値を連結した結果が一意の値となるような文字シーケンスとして選択することができる。一部の実施形態では、仮想カード値生成エンジン２０８は、取引に対応する仮想カード値を、ユーザ・アカウント・データベース２０２および／または取引データベース２０４の対応するエントリに格納するために送信するように構成されている。

業者関連ロケータ生成エンジン２１０は、クライアント・デバイスで実行されているウェブ・ブラウザに送信するデータを生成するように構成され、また、取引に対応する仮想カード値および取引金額をウェブ・ブラウザから業者サーバに転送させるように構成されている。さまざまな実施形態では、「業者関連ロケータ」は、取引に対応する仮想カード値および取引金額をウェブ・ブラウザから業者サーバに転送させるために使用できるデータを含む。たとえば、業者関連ロケータは、リダイレクト・ステータス・コード（たとえば、３０２）を含む（たとえば、ＨＴＴＰ）要求と、業者および／または仮想カード値に関連付けられている情報を含む統一リソース・ロケータ（ＵＲＬ）とを含む。一部の実施形態では、業者関連ロケータは、取引に対応する事前承認情報を業者サーバからカード管理サーバに送信させるようにさらに構成されている。一部の実施形態では、業者関連ロケータは、仮想カード値と取引に対応する取引金額とが正常に格納されたことをカード管理サーバが確認したことに応じて、生成される。

資金転送エンジン２１２は、カード管理サーバからの要求を受信および処理して、取引を表す仮想カード値に対応する取引金額を、取引に含まれるユーザ・アカウントに関連付けられている資金源から、取引に含まれる業者に関連付けられている資金アカウントに転送するように構成されている。一部の実施形態では、資金転送エンジン２１２は、要求に含まれる仮想カード値を使用して、一致する仮想カード値を含む、取引データベース２０４で格納されたエントリを参照し、参照された情報を（たとえば、ユーザ・アカウント・データベース２０２に格納された情報に加えて）使用して、（たとえば、ユーザにより指定される）取引の適切な資金源を検索し、検索された資金源から業者に関連付けられている資金アカウントへの取引金額の転送を（たとえば、資金アカウントまたは実行するオンライン支払システムに関連付けられている１つまたは複数の金融機関が実行することを）要求するように構成されている。

この例では、データベースおよびエンジンはカードレス支払サーバ１０８内で実装されるものとして示されているが、一部の実施形態において、１つまたは複数のデータベースおよび／またはエンジンは、他のデバイスで実装され、カードレス支払サーバからアクセスすることが可能である。

図３は、オンライン支払プラットフォームで新規ユーザ・アカウントを作成する処理の実施形態を示すフロー図である。一部の実施形態では、処理３００は、図１のシステム１００のカードレス支払サーバ１０８で実装される。

処理３００は、オンライン支払プラットフォームでユーザの新規アカウントを作成する例を表す。

ステップ３０２では、新規ユーザの認証情報情報が受信される。たとえば、ユーザは、ウェブ・ブラウザを使用してオンライン支払プラットフォームに関連付けられているページにアクセスし、そのページに表示されている新規ユーザ・アカウントの作成に関連付けられているコントロールを選択することにより、オンライン支払プラットフォームで新規ユーザ・アカウントを作成することができる。ユーザの選択に応じて、ユーザに関連付けられている情報を求める入力フィールドを（たとえば、フォーム内に）含む別のページが、ユーザに送信される。ユーザがフォームで提出する情報には、ユーザが指定したログイン名と、ユーザが指定したパスワードとが含まれる。一部の実施形態では、オンライン支払プラットフォーム・アカウントに関連付けられているユーザ認証情報は、ログイン名と、パスワードとを含む。

ステップ３０４では、カードレス支払サービスに関連付けられている新規ユーザ・アカウントが作成される。新規ユーザ・アカウントは、ユーザが提出した認証情報情報を、ユーザが提出した他の情報（たとえば、名前、誕生日、住所等）に加えて格納することに、少なくとも部分的に基づいて作成される。

ステップ３０６では、新規ユーザ・アカウントに関連付けられている情報が送信される。一部の実施形態では、この情報は、新規ユーザ・アカウントに割り当てられたユーザ識別子を含む。新規ユーザ・アカウントに割り当てられたユーザ識別子は、ユーザにより使用されるウェブ・ブラウザに送信することができる。

ステップ３０８では、１つまたは複数の資金源に関連付けられているデータが受信される。一部の実施形態では、ユーザはオプションで、将来の取引を完了するために資金を引き出すことができる１つまたは複数の資金源を特定するデータを提出することができる。資金源の例として、銀行口座がある。一部の実施形態では、ユーザは、将来の取引時に資金が外部の資金源で検索されるのではなく、ユーザのオンライン支払プラットフォーム・アカウントから直接転送されるように、（たとえば、指定された金額を預けることで）指定された金額を特定された資金源の少なくとも１つからオンライン支払プラットフォーム・アカウントに転送することを選択することもできる。

図４は、オンライン支払プラットフォームのユーザを認証する処理の実施形態を示すフロー図である。一部の実施形態では、処理４００は、図１のシステム１００のカードレス支払サーバ１０８で実装される。

処理４００は、仮想カード値を用いる取引の実行をユーザに許可する前に、オンライン支払プラットフォーム・アカウントによりユーザを認証する例を表す。

ステップ４０２では、取引および業者サーバに関連付けられている要求が受信される。たとえば、要求は、ユーザのクライアント・デバイスで実行されているウェブ・ブラウザから送信される。要求は、（たとえば、業者サーバにより運用されているウェブサイトで販売されている製品の購入のために）ユーザが業者サーバで完了することを要望する取引に関連付けられている情報を含む。取引に関連付けられている情報は、たとえば、取引金額（たとえば、所望の購入の総費用）と、関連する業者に関連付けられている識別情報とを含み得る。

ステップ４０４では、ログイン・ページ・データが送信される。オンライン支払プラットフォームのログイン・ページに関連付けられているデータ（たとえば、ログイン・ページのＵＲＬおよび／またはウェブ・ブラウザによりレンダリングしてログイン・ページを表示することができるデータ）が、ユーザのウェブ・ブラウザに送信される。

ステップ４０６では、オンライン支払プラットフォームのユーザに関連付けられている認証情報が受信される。ログイン・ページは、オンライン支払プラットフォームでのユーザの認証情報を提出するよう、ユーザに促す。

ステップ４０８では、認証が成功したか否かが判断される。認証が成功した場合、制御が４１０に渡される。認証が成功しなかった場合、処理４００は終了する。たとえば、受信されたユーザ認証情報が、格納されている一群のユーザ認証情報と比較されて、一致するものが存在するか判断される。一致するものが見つかった場合、認証は成功し、一部の実施形態では、ユーザは現在の取引で使用する特定の資金源を選択するよう促される。一致するものが見つからない場合、認証は成功せず、処理４００は終了する。

ステップ４１０では、仮想カード値を使用して取引を進めることが許可される。ユーザはオンライン支払プラットフォームで正常に認証されているため、仮想カード値が取引に対応して生成され、取引を完了するために使用されることが許可される。

図５は、仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。一部の実施形態では、処理５００は、図１のシステム１００のカードレス支払サーバ１０８で実装される。

ステップ５０２では、取引に対応する仮想カード値が生成される。さまざまな実施形態では、各取引に対して仮想カード値が生成される。たとえば、取引は、ユーザがウェブサイトまたはウェブサイト・アクセスを有する実店舗で業者により販売されている１つまたは複数の商品への支払いを選択することにより、開始される可能性がある。一部の実施形態では、各取引に対して一意の仮想カード値が生成される。一部の実施形態では、仮想カード値は、取引に含まれるユーザに関連付けられている情報、取引に含まれる業者に関連付けられている情報、および／またはカードレス支払サーバに関連付けられているオンライン支払プラットフォームに関連付けられている情報に少なくとも部分的に基づいて生成される。一部の実施形態では、カードレス支払サーバは、仮想カード値を取引に関連付けられている他の情報（たとえば、取引識別子、取引金額、およびユーザ識別子）と共に格納する。

ステップ５０４では、カードレス支払サーバからカード管理サーバに要求が送信される。要求は、仮想カード値と、取引に対応する取引金額とを含み、カード管理サーバに仮想カード値と取引金額とを格納させるように構成されている。生成された仮想カード値と取引金額とを含む要求が、カード管理サーバに送信される。一部の実施形態では、カード管理サーバへの要求は、ＸＭＬファイルを含むウェブ・サービス呼び出しとして送信される。一部の実施形態では、カード管理サーバへの要求は、基本アクセス認証を含むＨＴＴＰ要求として送信される。基本アクセス認証は、カードレス支払サーバおよび／またはオンライン支払プラットフォームのユーザ名およびパスワードを含み得る。たとえば、基本アクセス認証は、カードレス支払サーバがこの種の要求をカード管理サーバに送信するたびに実行される。一部の実施形態では、ユーザのプライバシーを保護するために、取引に含まれるユーザに関連付けられている情報はカード管理サーバに送信される要求に含まれない。

ステップ５０６では、仮想カード値および取引金額が正常に格納された旨の表示がカード管理サーバから受信される。要求に応じて、カード管理サーバは、新規仮想カードに対応する仮想カード値および取引金額を含む、要求に関連付けられている情報を格納する。たとえば、仮想カードの限度額は取引金額に設定され、仮想カードの残額はゼロに設定され、有効期限はユーザが構成した将来的な（たとえば、現時点に対する）日数（たとえば、３６５）に設定される。新規仮想カードに関連付けられている情報を正常に格納した後、カード管理サーバはカードレス支払サーバに表示を返す。

ステップ５０８では、業者サーバに関連付けられている識別情報と仮想カード値とに少なくとも部分的に基づいて、業者関連ロケータが生成される。

ステップ５１０では、業者関連ロケータがクライアント・デバイスに送信される。業者関連ロケータは、クライアント・デバイスを業者サーバにリダイレクトし、業者サーバに事前承認要求をカード管理サーバへ送信させて取引を完了させるように構成され、事前承認要求は、仮想カード値と、取引金額とを含む。表示の受信に応じて、カードレス支払サーバは、取引に含まれるユーザにより使用されているクライアント・デバイスで実行されているウェブ・ブラウザに送信する業者関連ロケータを（たとえば、ＨＴＴＰ要求で）生成する。さまざまな実施形態では、業者関連ロケータは、ＵＲＬへのリダイレクト命令（たとえば、ＨＴＴＰステータス・コード３０２）を含むＨＴＴＰ要求を含む。業者関連ロケータに関連付けられているＵＲＬは、業者サーバにより指定された形式に関連付けられる。たとえば、業者関連ロケータは、業者および／または仮想カード値に関連付けられている情報を含む。「Ｍｅｒｃｈａｎｔ」という業者および「ｖｃａｒｄｖａｌｕｅ」という仮想カード値に対して生成された業者関連ロケータに含まれるＵＲＬの例として、https://www.merchant.com/PayResultNotification.do?vcardvalueがある。一部の実施形態では、業者関連ロケータの形式は、取引に関連付けられている業者により指定される。業者が異なれば、業者関連ロケータに指定する形式も異なる可能性がある。

一部の実施形態では、業者関連ロケータは、ユーザにより使用されているクライアント・デバイスで実行されているウェブ・ブラウザを（たとえば、リダイレクト用のＨＴＴＰステータス・コード３０２を含むＬｏｃａｔｉｏｎヘッダを使用して）業者サーバに関連付けられているページ（業者関連ロケータに含まれるＵＲＬに対応）にリダイレクトし、仮想カード値と取引金額とを含む要求を業者サーバに送信させるように構成されている。業者サーバは、カード管理サーバに事前承認要求を送信する。事前承認要求は、仮想カード値に対応する仮想カードに請求される取引金額を承認するようカード管理サーバに求める要求を含む。事前承認要求の受信に応じて、カード管理サーバは、承認を付与し、事前承認確認を業者サーバに返送することができ、業者サーバは、取引に対応する取引金額の支払いが承認されたことを示すデータを格納する。たとえば、事前承認は、支払いの承認が最初に付与され、承認された支払いに関連付けられている適切な資金が後で業者の資金アカウントに転送されるという決済手法（たとえば、この決済手法は「承認と取込み」とも呼ばれる）の、第１の部分であり得る。取引に対応する取引金額の支払いが承認されたことを示すデータを格納した後、業者サーバは、取引完了確認を示すページ・データをウェブ・ブラウザに送信することができる。

一部の実施形態では、業者関連ロケータを含むＨＴＴＰ要求は、シグネチャを含む。シグネチャは、カードレス支払サーバおよび／またはオンライン支払プラットフォームによりキーを使用して生成された暗号化データを含む。またシグネチャは、ウェブ・ブラウザによって業者サーバにリダイレクトされるように構成され、業者サーバは、ローカルに格納されたキーを使用してシグネチャを復号して、業者関連ロケータを認証し、そのロケータが承認された発信源からのものであることを検証する。たとえば、シグネチャは、アプリケーションレベルの認証フォームを含む。

ステップ５１２では、カードレス支払サーバに関連付けられているユーザ・アカウントから業者サーバに関連付けられている資金アカウントに取引金額を転送する要求が、カード管理サーバから受信される。一部の実施形態では、取引の仮想カード値に対応する取込要求（たとえば、「承認と取込み」決済手法の第２の部分）を、業者サーバからカード管理サーバに送信することができ、カード管理サーバは、取引金額を転送する要求をカードレス支払サーバに送信する。一部の実施形態では、要求の受信に応じて、カードレス支払サーバは、取引に含まれるユーザにより取引に使用するものとして以前に選択された資金源を検索する。カードレス支払サーバは、たとえば、識別されたユーザ資金源に関連付けられている金融機関（たとえば、銀行）またはユーザ資金に関連付けられているオンライン支払プラットフォームへの要求を発行することにより、特定されたユーザ資金源から業者に関連付けられている資金アカウントへの取引金額の転送を開始することができる。

図６は、取引に対応する仮想カード値を生成する処理の実施形態を示すフロー図である。一部の実施形態では、処理６００は、図１のシステム１００のカードレス支払サーバ１０８で実装される。一部の実施形態では、処理６００を使用して、図５の処理５００のステップ５０２を実装することができる。

ステップ６０２では、取引に関連付けられているユーザに関連付けられている情報に少なくとも部分的に基づいて、第１の値が決定される。第１の値（たとえば、１つまたは複数の英数字を含む）は、取引に含まれるユーザ・アカウントに対して格納された情報の少なくとも一部を使用して生成することができる。たとえば、ユーザ・アカウントに対して格納された情報の少なくとも一部（たとえば、ユーザ識別子文字列）を、構成されたハッシュ手法を使用してハッシュし、作成されたハッシュを第１の値として使用することができる。

ステップ６０４では、発行者に関連付けられている情報に少なくとも部分的に基づいて、第２の値が決定される。第２の値（たとえば、１つまたは複数の英数字を含む）は、取引に関連付けられている発行者に対して格納された情報の少なくとも一部を使用して生成することができる。たとえば、取引に関連付けられている発行者は、カードレス支払サーバに関連付けられているオンライン支払プラットフォームおよび取引に関連付けられている業者の一方または両方を表す可能性がある。たとえば、発行者に対して格納された情報の少なくとも一部（たとえば、発行者に関連付けられている識別子文字列）を、構成されたハッシュ手法を使用してハッシュし、作成されたハッシュを第２の値として使用することができる。

ステップ６０６では、第３の値が、第１の値、第２の値、および第３の値の組合せが一意の値を含むものとなるように決定される。さまざまな実施形態では、各取引に対して一意の仮想カード値が生成される。ユーザは複数の取引を実行することができ、それらの取引の少なくともいくつかは同じ発行者を含む可能性があるため、第１の値と第２の値の組合せ（たとえば、連結）は、一意の値とならない場合がある。よって、一部の実施形態では、英数字のシーケンスを含む第３の値を、第１の値、第２の値、および第３の値の組合せ（たとえば、連結）が一意の値を含むものとなるように生成することができる。たとえば、第３の値を文字のランダムなシーケンスとして生成し、第１の値および第２の値に連結して、組み合わされた値を（たとえば、以前に生成された仮想カード値に対して）確実に一意にすることができる。

ステップ６０８では、第１の値、第２の値、および第３の値に少なくとも部分的に基づいて、仮想カード値が生成される。一部の実施形態では、仮想カード値は、第１の値、第２の値、および第３の値の連結として生成される。一部の実施形態では、仮想カード値は、第１の値と第２の値との間に区切り文字（たとえば、「―」）を含み、第２の値と第３の値との間にさらに区切り文字を含むように生成される可能性がある。

図７は、取引が仮想カード値を用いて実行される例を示すシーケンス図である。一部の実施形態では、図７のクライアント・ウェブ・ブラウザは、図１のシステム１００のクライアント・デバイス１０２で実行されているウェブ・ブラウザにより実装することができる。一部の実施形態では、図７の業者サーバは、図１のシステム１００の業者サーバ１０６により実装することができる。一部の実施形態では、図７のカードレス支払サーバは、図１のシステム１００のカードレス支払サーバ１０８により実装することができる。一部の実施形態では、図７のカード管理サーバは、図１のシステム１００のカード管理サーバ１１０により実装することができる。

ステップ７０１では、クライアント・ウェブ・ブラウザは、取引を実行する要求を業者サーバに送信する。たとえば、取引は、ウェブサイト上で業者サーバに関連付けられている業者により販売されている１つまたは複数の商品の、ユーザにより開始された購入を含む。精算処理時に、ウェブサイトは支払方法を選択するようユーザに促しており、それに応じて、ユーザはカードレス支払サーバに関連付けられているオンライン支払プラットフォーム（たとえば、Ａｌｉｐａｙ（登録商標））の自らのアカウントを使用する支払方法を選択している。たとえば、取引の要求は、取引金額（たとえば、発送手数料および税金を含む、ユーザが購入を要望する商品の合計金額）を含む。たとえば、取引の要求は、ＨＴＴＰ要求として実装することができる。取引の要求の受信に応じて、ステップ７０２において、業者サーバはカードレス支払関連ロケータを生成する。一部の実施形態では、カードレス支払関連ロケータは、ＵＲＬを含む（たとえば、ＨＴＴＰ）要求を含む。たとえば、カードレス支払関連ロケータは、現在の取引に固有のパラメータ値を含む。カードレス支払関連ロケータに含まれるＵＲＬの例として、https://www.alipay.com/cooperate/gateway.do?total_fee=13&currency=USD&notify_url=http%3A%2F%2Fwww.tabao.com&service=create_forex_trade&agent=2088002007018916&partner=2088002007018916&out_trade_no=16177126201&subject=42560013718&return_url=http%3A%2F%2Fwww.tabao.com&body=71819701647&sign=UzZ7bRelBtSVB63jsfI9vbu3d21442SJV88po0XvIptqWGM4rxP5EQ%3D%3D&sign_type=DSAがある。カードレス支払関連ロケータは、オンライン支払プラットフォームおよび／またはカードレス支払サーバにより指定された形式に基づいて生成することができる。たとえば、カードレス支払関連ロケータは、取引金額を含み得る。カードレス支払関連ロケータと、リダイレクト用のＨＴＴＰステータス・コード３０２を含むＬｏｃａｔｉｏｎヘッダとを含むＨＴＴＰ応答が、ステップ７０３において業者サーバによりクライアント・ウェブ・ブラウザに送信される。

ステップ７０４では、業者サーバからのカードレス支払関連ロケータを使用して、クライアント・ウェブ・ブラウザをカードレス支払サーバにリダイレクトすることができる。ステップ７０５では、クライアント・ウェブ・ブラウザからの要求に応じて、カードレス支払サーバは、オンライン支払プラットフォームのアカウントに関連付けられているユーザ認証情報を促すページに関連付けられているデータを送信する。クライアント・ウェブ・ブラウザは、ユーザ認証情報を促すページを表示することができ、ステップ７０６において、ユーザはそのページを通じて自らのユーザ認証情報をカードレス支払サーバに提出することができる。提出されたユーザ認証情報を認証することができる場合、一部の実施形態では、カードレス支払サーバは取引に適用する所望の資金源を選択するようユーザに促すページに関連付けられているデータを送信することができる（図示せず）。

提出されたユーザ認証情報を認証することができる場合、ステップ７０７において、カードレス支払サーバは、取引に対応する仮想カード値を生成する。たとえば、カードレス支払サーバは、図６の処理６００のような処理を使用して、取引に対応する仮想カード値を生成することができる。一部の実施形態では、カードレス支払サーバは、仮想カード値と、（たとえば、ローカルに）生成された取引識別子とを含む、取引に関連付けられている情報を格納する。ステップ７０８において、カードレス支払サーバは、仮想カード値と取引金額とを含む要求を、カード管理サーバに送信する。一部の実施形態では、ステップ７０８において送信される要求は、ＨＴＴＰ基本認証の認証情報を含む。一部の実施形態では、ステップ７０８において送信される要求は、ウェブ・サービス呼び出しを含む。カードレス支払サーバからの要求の受信に応じて、カード管理サーバは、仮想カード値および取引金額を、（たとえば、残高、有効期限等の他の情報と共に）新規仮想カードに関連付けられている情報として格納する。そのような情報を格納した後、ステップ７０９において、カード管理サーバは、仮想カード値および取引金額が正常に格納されたことを示す確認をカードレス支払サーバに送信する。確認の受信に応じて、カードレス支払サーバは、ステップ７１０において、仮想カード値と取引金額とを含む業者関連ロケータを生成し、ステップ７１１において、業者関連ロケータ（たとえば、ＨＴＴＰ要求）をクライアント・ウェブ・ブラウザに送信する。ステップ７１２では、業者関連ロケータを使用して、クライアント・ウェブ・ブラウザは業者サーバにリダイレクト去れ得る。業者関連ロケータに含まれる仮想カード値および取引金額は、業者サーバに渡される。一部の実施形態では、業者関連ロケータに関連付けられている要求は、カードレス支払サーバにより生成された暗号化シグネチャをさらに含み、業者サーバは、ローカルに格納されたキーを使用してシグネチャを復号することにより、ロケータの発信源を認証することができる。ステップ７１３では、業者サーバは、仮想カード値を含む事前承認要求をカード管理サーバに送信する。事前承認要求は、取引金額をさらに含む可能性がある。たとえば、事前承認は、「承認と取込み」支払決済ソリューションの第１の部分である。カード管理サーバは、事前承認要求に含まれる仮想カード値による支払いの承認を付与することができる。ここで、支払いとは、取引金額の支払いである。たとえば、カード管理サーバは、取引金額（たとえば、仮想カードの限度額）の請求が承認された旨のデータを、関連する仮想カード値と共に格納することができる。次に、ステップ７１４では、カード管理サーバは、事前承認確認を業者サーバに送信して、支払いが承認されたことを業者サーバに通知することができる。事前承認確認の受信に応じて、業者サーバは、取引が承認されたことを示すデータを格納し、ステップ７１５では、取引完了情報がクライアント・ウェブ・ブラウザに送信され得る。たとえば、取引完了情報は、業者サーバにより生成された取引確認番号を含む可能性がある。たとえば、クライアント・ウェブ・ブラウザは、取引完了をユーザに提示して、取引が正常に完了したことをユーザに通知することができる。一部の実施形態では、この時点で、業者サーバはユーザにより購入された商品の配送を準備することができる。自らのオンライン支払プラットフォームを使用して取引の支払いを行うことを選択したユーザは、取引に対して生成された仮想カード値および／またはカード管理サーバの関与を把握しない可能性がある。

ステップ７１６では、業者サーバは、仮想カード値に対応する取込要求をカード管理サーバに送信することができる。一部の実施形態では、取込要求は、複数の取引に対応する取込みを要求するバッチ・ファイルを含む可能性がある。取込要求の受信に応じて、ステップ７１７では、カード管理サーバは、限度額（たとえば、取引金額）が支払いとして承認された仮想カード値に取込みが対応することを確認し、取込要求に含まれる仮想カード値に関連付けられている取引金額を転送する要求をカードレス支払サーバに送信する。カードレス支払サーバは、ユーザにより取引に対して選択された資金源の資金の、業者サーバに関連付けられている資金アカウントへの転送を開始することができる。

本明細書で説明されるシステムの実施形態では、支払いに加えて、返金も処理する。図８は、仮想カード値を用いて完了した取引に関連付けられている返金を実行する処理の実施形態を示すフロー図である。一部の実施形態では、処理８００は、図１のシステム１００のカードレス支払サーバ１０８で実装される。

処理８００は、仮想カード値を用いて完了した取引の返金を実行する例を表す。処理８００の前に、取引に関連付けられている取引金額が、取引に含まれるユーザに関連付けられている資金源から、取引に含まれる業者に関連付けられている資金アカウントに転送されている。

ステップ８０２では、完了した取引に関連付けられている返金要求が業者サーバから受信される。返金要求は、完了した取引に対応する仮想カード値を含む。たとえば、ユーザは、以前に完了した取引に含まれる業者サーバに関連付けられているウェブサイトで、その取引の返金を開始することができる。たとえば、ユーザは、取引に関連付けられている取引確認番号を業者サーバに提供することができる。業者サーバは、その取引確認番号に対応する、業者サーバによって以前に生成および格納された仮想カード値を、仮想カード値と取引確認番号との間の格納済みマッピングに基づいて決定することができる。続いて業者サーバは、決定された仮想カード値をカードレス支払サーバに送信することができる。一部の他の実施形態では、業者サーバは、カード管理サーバで返金処理を完了するために、決定された仮想カード値をカード管理サーバに送信することができる。

ステップ８０４では、仮想カード値に対応する取引識別子が、取引識別子と仮想カード値との間の格納済みマッピングに少なくとも部分的に基づいて決定される。カードレス支払サーバにより以前に生成および格納された取引識別子は、仮想カード値と取引識別子との間のローカルに格納されたマッピングに基づいて決定することができる。

ステップ８０６では、取引識別子と共に格納されたデータが取り出される。決定された取引識別子と共にカードレス支払サーバで格納されたデータを取り出すことができる。一部の実施形態では、このように取り出された、決定された取引識別子と共に格納されたデータは、ユーザ識別子、ユーザ識別子に関連付けられている資金源、業者識別子、および／または取引金額を含む。

ステップ８０８では、業者サーバに関連付けられている資金アカウントからユーザ資金源に資金を転送する要求が、取り出されたデータに少なくとも部分的に基づいて生成される。たとえば、業者識別子に関連付けられている資金アカウントからユーザ識別子に関連付けられている資金源に取引金額を転送する要求が生成される。一部の実施形態では、業者サーバ、および／または業者識別子に関連付けられている資金アカウントに関連付けられている金融機関に、要求を送信することができる。

図９は、仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。一部の実施形態では、処理９００は、図１のシステム１００の業者サーバ１０６で実装される。

処理９００は、仮想カード値を用いて取引を実行する例を、業者サーバの視点から表す。

ステップ９０２では、取引に関連付けられている支払要求がクライアント・デバイスから受信される。支払要求は、取引に関連付けられている取引金額を含む。たとえば、ユーザは、業者サーバに関連付けられているウェブサイトで販売されている１つまたは複数の商品を購入することを選択し、その購入の支払いに自らのオンライン支払プラットフォーム・アカウントを使用することを選択している。たとえば、支払要求は、ＨＴＴＰ要求を含む。オンライン支払プラットフォームに関連付けられているカードレス支払サーバは、ユーザのオンライン支払プラットフォーム・アカウントと、業者に関連付けられている資金アカウントとの間の支払いを簡素化するように構成されている。

ステップ９０４では、支払要求に少なくとも部分的に基づいてカードレス支払関連ロケータが生成される。さまざまな実施形態では、カードレス支払関連ロケータは、ＨＴＴＰ要求とＵＲＬとを含む。一部の実施形態では、カードレス支払関連ロケータは、カードレス支払サーバおよび／またはオンライン支払プラットフォームにより指定された形式（たとえば、パラメータ・タイプ）に基づいて生成される。たとえば、カードレス支払関連ロケータは、現在の取引に固有のパラメータ値を含む。

ステップ９０６では、カードレス支払関連ロケータがクライアント・デバイスに送信される。カードレス支払関連ロケータは、クライアント・デバイスをカードレス支払サーバにリダイレクトするように構成され、カードレス支払サーバは、取引をカード管理サーバで完了するために使用することができる仮想カード値を生成するように構成されている。さまざまな実施形態では、カードレス支払関連ロケータは、クライアント・デバイスのウェブ・ブラウザ等に、ＨＴＴＰ要求として送信される。ＨＴＴＰ要求は、クライアント・デバイスをカードレス支払サーバに（たとえば、リダイレクト用のＨＴＴＰステータス・コード３０２を含むＬｏｃａｔｉｏｎヘッダを使用して）リダイレクトするように構成することができる。続いてカードレス支払サーバは、ユーザのオンライン支払プラットフォーム・アカウントに関連付けられているユーザ認証情報を提出するようユーザに促すページに関連付けられているデータを送信することができる。

ステップ９０８では、仮想カード値および取引金額がカード管理サーバにより正常に格納された旨の表示が受信される。クライアント・デバイスからの表示は、カードレス支払サーバにより生成された業者関連ロケータに少なくとも部分的に基づいて生成される。ユーザが提出した認証情報を認証することができる場合、カードレス支払サーバは、取引に対応する仮想カード値を生成し、仮想カード値と取引金額とをカード管理サーバに送信することができる。次に、仮想カード値および取引金額の正常な格納に関連付けられている応答が、カードレス支払サーバに返送される。カードレス支払サーバは、仮想カード値と取引金額とを含む業者関連ロケータを生成し、その業者関連ロケータをＨＴＴＰ要求でクライアント・デバイスに送信する。仮想カード値と取引金額とを含む表示が、業者関連ロケータにより業者サーバにリダイレクトされたクライアント・デバイスを通じて、業者サーバに渡される。

ステップ９１０では、表示に応じて、事前承認要求がカード管理サーバに送信される。事前承認要求は、仮想カード値と、取引金額とを含む。表示に含まれる仮想カード値および取引金額に基づき、業者サーバは、仮想カード値と取引金額とを含む事前承認要求をカード管理サーバに送信する。

ステップ９１２では、取引に関連付けられている事前承認確認がカード管理サーバから受信される。たとえば、カード管理サーバは、仮想カード値に関連付けられている取引に対応する取引金額の支払いを承認することを決定することができる。取引に関連付けられている事前承認確認の受信に応じて、業者サーバは、取引の支払いが正常に承認されたことを示すデータを格納することができる。事前承認がカード管理サーバにより付与された場合、業者サーバは、クライアント・デバイスで実行されているウェブ・ブラウザによりユーザに提示される取引完了情報を送信することができる。

ステップ９１４では、カードレス支払サーバに関連付けられているユーザ・アカウントから業者サーバに関連付けられている資金アカウントに取引金額を転送する取込要求が、カード管理サーバに送信される。カード管理サーバにより事前承認が付与されてからしばらく経過した後、業者サーバは、カードレス支払サーバに関連付けられているユーザ・アカウントから業者（サーバ）に関連付けられている資金アカウントに取引金額を転送する取込要求を、カード管理サーバに送信することができる。一部の実施形態では、取込要求は仮想カード値を含む。一部の実施形態では、取込要求は、他の取引に対応する複数の他の取込要求と共に、バッチ形式で送信される。続いてカード管理サーバは、カードレス支払サーバと通信して資金の転送を完了することができる。

たとえば、取込要求は、取込要求と返金要求の両方を含む取込ファイルに含まれる。たとえば、取込ファイルは、ファイル・ヘッダ（たとえば、ファイルの提供者、ファイルのバージョン等のファイル・レベルの情報を含む、ファイルの最初の行）、取込ヘッダ（たとえば、取込要求の概要情報を含む、ファイルの２番目の行）、取込項目（たとえば、取込要求を表す）、返金ヘッダ（たとえば、返金要求の概要情報を含む）、および返金項目（たとえば、返金要求を表す）の５つのセクションを含む。ファイル・ヘッダ・セクションは、具体的には、たとえば、ｒｅｃｏｒｄ＿ｔｙｐｅ（たとえば、提出されている要求の種類）、ｓｕｍｂｉｔ＿ｐａｒｔｙ、ｒｅｃｉｐｉｅｎｔ＿ｐａｒｔｙ、ｓｕｂｍｉｔ＿ｄｔ（たとえば、提出日時）、ｆｏｒｍ＿ｖｅｒｓｉｏｎ（たとえば、ファイルのバージョン）、およびｆｉｌｅ＿ｎａｍｅの各パラメータを含む可能性がある。取込ヘッダ・セクションは、具体的には、たとえば、ｒｅｃｏｒｄ＿ｔｙｐｅ（たとえば、取込ヘッダ・セクションを特定する）、ｔｏｔａｌ ｎｕｍｓ（たとえば、取込項目の合計数）、およびｔｒａｎｓａｃｔｉｏｎ＿ＤＴ（たとえば、取引日）の各パラメータを含む可能性がある。取込項目セクションは、具体的には、たとえば、ｒｅｃｏｒｄ＿ｔｙｐｅ、ａｌｉｐａｙ＿ｔｒａｎｓ＿ＩＤ（たとえば、ユーザのＡｌｉｐａｙ識別子）、ｐａｒｔｎｅｒ＿ｔｒａｎｓ＿ＩＤ、ａｍｏｕｎｔ（たとえば、取込金額）、およびｃｕｒｒｅｎｃｙ（たとえば、取引が支払われる通貨）の各パラメータを含む可能性がある。返品ヘッダ・セクションは、具体的には、たとえば、ｒｅｃｏｒｄ＿ｔｙｐｅ（たとえば、返金ヘッダ・セクションを特定する）およびｔｏｔａｌ＿ｎｕｍｓ（たとえば、返金する項目の総数）の各パラメータを含む可能性がある。返金項目セクションは、具体的には、たとえば、ｒｅｃｏｒｄ＿ｔｙｐｅ（たとえば、返金項目セクションを特定する）、ｐａｒｔｎｅｒ＿ｔｒａｎｓ＿ＩＤ、ａｌｉｐａｙ＿ｔｒａｎｓ＿ＩＤ、ｐａｒｔｎｅｒ＿ｒｅｆｕｎｄ＿ＩＤ、ａｍｏｕｎｔ（たとえば、返金の金額）、ｃｕｒｒｅｎｃｙ（たとえば、返金が行われる通貨）、およびｒｅａｓｏｎ（たとえば、ユーザが述べた返金理由）の各パラメータを含む可能性がある。

図１０は、仮想カード値を用いて取引を実行する処理の実施形態を示すフロー図である。一部の実施形態では、処理１０００は、図１のシステム１００のカード管理サーバ１１０で実装される。

処理１０００は、仮想カード値を用いて取引を実行する例を、カード管理サーバの視点から表す。

ステップ１００２では、取引に関連付けられている要求がカードレス支払サーバから受信される。要求は、仮想カード値と、取引に対応する取引金額とを含む。ユーザのオンライン支払プラットフォーム・アカウントを使用して業者に対して行うよう要求された取引の支払いに対して、オンライン支払プラットフォームに関連付けられているカードレス支払サーバは、取引に対応する仮想カード値を生成する。仮想カード値および取引金額は、ウェブ・サービス呼び出しを介して（たとえば、ＨＴＴＰ ＰＯＳＴ要求をＸＭＬドキュメントと共に送信することにより）、カード管理サーバに送信される。一部の実施形態では、カードレス支払サーバに関連付けられているＨＴＴＰ基本認証用の認証情報も、要求に含まれる場合がある。

ステップ１００４では、仮想カード値および取引金額が格納される。仮想カード値および取引金額は、カード管理サーバで、新規仮想カードに関連付けられている情報として格納される。たとえば、新規仮想カードの限度額は、取引金額に設定することができる。一部の実施形態では、新規仮想カードに関連付けて格納される情報は、ユーザが構成した有効期限（たとえば、取引を開始した日から１年）と、ユーザが構成した残額とをさらに含む。有効期限および残額は、ユーザが構成する代わりに、オンライン支払プラットフォームまたはカード管理サーバにより決定することもできる。

ステップ１００６では、仮想カード値および取引金額が正常に格納された旨の表示がカードレス支払サーバに送信される。表示の受信に応じて、カードレス支払サーバは、業者関連ロケータを生成してクライアント・デバイスに送信するように構成され、業者関連ロケータは、クライアント・デバイスを業者サーバにリダイレクトするために使用されるように構成されている。カード管理サーバからの表示に応じて、カードレス支払サーバは、仮想カード値および取引金額をクライアント・デバイス経由で業者サーバに渡すために使用する業者関連ロケータを生成する。

ステップ１００８では、事前承認要求が業者サーバから受信される。事前承認要求は、仮想カード値と、取引金額とを含む。事前承認要求は、一部の実施形態では、仮想カード値および取引金額がカード管理サーバにより格納された仮想カード情報に一致する場合に、付与することができる。カード管理サーバは、限度額（たとえば、取引金額）の請求が仮想カードで承認された旨のデータを、仮想カード値と関連付けて格納することができる。

ステップ１０１０では、事前承認確認が業者サーバに送信される。事前承認がカード管理サーバにより付与された場合、承認の確認が業者サーバに送信される。

ステップ１０１２では、カードレス支払サーバに関連付けられているユーザ・アカウントから業者サーバに関連付けられている資金アカウントに取引金額を転送する取込要求が業者サーバから受信される。カード管理サーバにより事前承認が付与されてからしばらく経過した後、業者サーバは、カードレス支払サーバに関連付けられているユーザ・アカウントから業者に関連付けられている資金アカウントに取引金額を転送する取込要求を、カード管理サーバに送信することができる。一部の実施形態では、取込要求は仮想カード値を含む。一部の実施形態では、取込要求は、他の取引に対応する複数の他の取込要求と共に、バッチ形式で送信される。カード管理サーバは、取込要求に含まれる仮想カード値が、支払いが承認された取引に関連付けられていることを検証することができる。続いてカード管理サーバは、カードレス支払サーバと通信して資金の転送を完了することができる。

図１１〜図１４は、上述したさまざまな実施形態を適用して、ユーザが仮想カード値を使用して購入を行えるようにする例を示す。

図１１は、電子商取引ウェブサイトの精算処理に関連付けられている支払方法選択を促すユーザ・インターフェイスの例を示す図である。この例では、業者ＡＢＣで製品を購入することを選択したユーザに、ユーザ・インターフェイス１１００を（たとえば、クライアント・デバイスで実行されているウェブ・ブラウザにより）提示することができる。この例では、購入される製品は、ショッピング・カード領域１１０２で、＄５００のＣａｎｎｏｎ Ｍｏｄｅｌ Ｘ４３カメラとして表されている。この例では、業者ＡＢＣのサーバが、少なくともいくつかのカード管理サービス（たとえば、Ｖｉｓａ（登録商標）、Ｍａｓｔｅｒｃａｒｄ（登録商標）、Ｄｉｓｃｏｖｅｒ（登録商標）、およびＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標））のサーバと、業者ＡＢＣのサーバがそれらのカード管理サービスから物理的なクレジット・カードおよび／またはデビット・カードの発行を受けたユーザから支払いを直接受け取ることができる態様で統合されている可能性がある。一方、業者ＡＢＣのサーバはオンライン支払プラットフォーム（たとえば、Ａｌｉｐａｙ（登録商標））に関連付けられているカードレス支払サーバと統合されていないが、オンライン支払プラットフォームに関連付けられているカードレス支払サーバと、少なくとも１つのカード管理サービスに関連付けられているカード管理サーバとの間の調整された協調により、一部の実施形態では、ユーザはオンライン支払プラットフォームでの自らのアカウントを使用して、取引の支払いを行うことができる。たとえば、カードレス支払サーバは、業者ＡＢＣのサーバと伝統的に統合されると共にカードレス支払サーバと協調するように構成されている、１つまたは複数のカード管理サーバと協調することができる。取引に含まれるユーザは、カードレス支払サーバとカード管理サーバとの間の協調に気付かない可能性があるが、いずれにせよ、複数のカード管理サーバが業者ＡＢＣのサーバと統合されている場合に、取引を進めるカード管理サーバを選択するオプションを保持している必要はない。むしろ、複数のカード管理サーバが業者ＡＢＣのサーバと統合されている場合、取引の完了に使用される１つまたは複数のカード管理サーバは、どのカードレス支払サーバがオンライン支払プラットフォーム／カードレス支払サーバとの調整を確立しているかに応じて決定される。

この例では、ユーザは、この取引に対して業者ＡＢＣにより受け入れられる所望の支払方法に関連付けられているボタンを選択することができる。考えられる支払方法には、Ｖｉｓａ（登録商標）、Ｍａｓｔｅｒｃａｒｄ（登録商標）、Ｄｉｓｃｏｖｅｒ（登録商標）、およびＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）の各カード管理サービスがあり、それぞれボタン１１１０、１１０６、１１１２、および１１０８に対応している。考えられる支払方法には、オンライン支払プラットフォームＡｌｉｐａｙ（登録商標）もあり、ボタン１１１４に対応している。この例では、ユーザは以前にＡｌｉｐａｙ（登録商標）でアカウントを作成しており、ボタン１１１４を選択してから「次へ」ボタン１１０４を選択することで、この取引の支払いをＡｌｉｐａｙ（登録商標）で行うことを選択する。すると、図４の処理４００がカードレス支払サーバにより実行され、たとえば図１２のようなユーザ・インターフェイスがウェブ・ブラウザに表示される。

図１２は、取引を完了するために使用するものとして選択されたオンライン支払プラットフォームに関連付けられているユーザ認証情報を促すユーザ・インターフェイスの例を示す図である。この例では、ユーザが図１１のユーザ・インターフェイス１１００で取引をユーザのＡｌｉｐａｙ（登録商標）で完了することを選択したことに応じて、ユーザ・インターフェイス１２００をユーザに提示することができる。ユーザ・インターフェイス１２００は、ユーザに対して、以前に作成したＡｌｉｐａｙ（登録商標）アカウントの認証情報であるログイン名およびパスワードを、それぞれの入力フィールド１２０２および１２０４に入力するよう促す。自らの認証情報を入力した後、ユーザは「認証情報を提出」ボタン１２０６を選択することができる。これに応じて、図５の処理５００がカードレス支払サーバにより実行される。

図１３は、取引に適用されるユーザ資金源の選択を促すユーザ・インターフェイスの例を示す図である。この例で、ユーザ・インターフェイス１３００は、ユーザが図１２のユーザ・インターフェイス１２００で自らのＡｌｉｐａｙ（登録商標）アカウントの認証情報を提出したことに応じて、ユーザに（オプションで）提示することができる。この例では、ユーザ認証情報が認証されたため、ユーザ・インターフェイス１３００が提示されている。ユーザ・インターフェイス１３００は、ユーザに対して、ユーザのＡｌｉｐａｙ（登録商標）アカウントに以前に結び付けられた複数の資金源から、取引に適用する所望の資金源を選択するよう促す。たとえば、ユーザは、そのような資金源の１つ（たとえば、「銀行普通口座」または「Ａｌｉｐａｙ保証金」）を、プル・ダウン・メニュー１３０２から選択することができる。取引に適用する所望の資金源を選択した後、ユーザは「選択を提出」ボタン１３０４を選択することができる。たとえば、取引に適用する資金源のユーザ選択は、カードレス支払サーバにより実行される図５の処理５００の前または最中に受信され得る。

Ａｌｉｐａｙ（登録商標）アカウントでの支払いにより業者ＡＢＣとの取引を完了することを選択したことにより、Ａｌｉｐａｙ（登録商標）に関連付けられているカードレス支払サーバは、カードレス支払サーバと協調するように構成されているカード管理サーバと協調して、この取引に対応する仮想カード値を生成する。カード管理サーバは、仮想カード値を、＄５００の取引金額が限度額である新規仮想カードに関連付けられているものとして扱い、取引に＄５００を請求するという業者ＡＢＣのサーバの要求を承認して、取引を完了する。取引が完了した（たとえば、取引金額が仮想カードに正常に請求された）と判断した後、業者ＡＢＣのサーバは、後述する図１４に示されているように、取引完了情報に関連付けられているデータをユーザのウェブ・ブラウザに送信することができる。

図１４は、取引完了情報を提示するユーザ・インターフェイスの例を示す図である。この例で、ユーザ・インターフェイス１４００は、ユーザが自らのＡｌｉｐａｙ（登録商標）アカウントでＣａｎｎｏｎ Ｍｏｄｅｌ Ｘ４３カメラの購入の支払いを完了したことに応じて、ユーザに提示することができる。

図１１〜図１４の例に示されているように、ユーザは、取引の支払いを自らのオンライン支払プラットフォーム・アカウントで行うことを選択することができる。すると、オンライン支払プラットフォームに関連付けられているカードレス支払サーバは、業者のサーバと伝統的に統合されているカード管理サーバと自動的に協調して、仮想カード値を使用することにより取引を完了する。これらすべては、図５の処理５００により説明されるように、ユーザに透過的であり得る態様で行われる。

以上の実施形態について、明確な理解を目的として多少詳しく説明したが、本発明は提供された詳細に限定されない。本発明を実装する代替方法は多数存在する。開示された実施形態は例示的なものであり、限定的なものではない。

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