以下に添付図面を参照しながら、本開示の実施形態について説明する。なお、本明細書及び図面において実質的に同一の機能を有する要素については、同一の符号を付することにより重複説明を省略する場合がある。
<1.第1実施形態>
本発明に係る第1実施形態について説明する。第1実施形態は、加盟店のカード決済機能を有するカード決済システムに関し、特に、カード決済システム側と何ら契約を結んでいない非加盟店でもカード払いが利用できるようになる仕組みに関する。
以下、第1実施形態に係るシステムの構成例、支払代行方法、そのシステムに含まれる各要素のハードウェア構成例及び機能、そのシステムにおける処理の流れについて順に説明する。
[1−1.システム構成例]
まず、図1を参照しながら、第1実施形態に係るシステムの構成例について説明する。図1は、第1実施形態に係るカード決済システム、利用者端末、非加盟店端末、及び銀行システムを含むシステム構成の一例を示した説明図である。
図1に示すように、第1実施形態に係るシステムは、カード決済システム101、利用者端末102、非加盟店端末103、及び銀行システム104を含む。
図1の例では、説明の都合上、カード決済システム101と、利用者端末102と、非加盟店端末103とがネットワーク50を介して接続されている。但し、第1実施形態においては、カード決済システム101と非加盟店端末103とは接続されていなくてもよい。ネットワーク50は、例えば、LAN(Local Area Network)やWAN(Wide Area Network)などの有線及び/又は無線の通信網である。
カード決済システム101は、例えば、サーバ装置、ワークステーション、メインフレームなどのコンピュータを1台又は複数台有するコンピュータシステムである。カード決済システム101は、銀行システム104と接続されている。カード決済システム101と銀行システム104とは、例えば、専用の通信回線、或いは、ネットワーク50のような通信網を利用して接続される。
カード決済システム101は、クレジットカードのブランドとの加盟店契約がある加盟店としての機能(以下、加盟店機能)を有する。加盟店に設置される決済端末は、利用金額、及びクレジットカード番号などのカード情報をクレジットカード会社の決済システムに送信してカード決済を依頼する。加盟店機能は、このような決済端末の機能を含む。但し、ここでは、カード決済システム101がクレジットカード会社の決済システムとしての機能をさらに含み、カード決済を実行できる場合について説明する。
また、カード決済システム101は、カード会員が利用するアプリケーションプログラム(以下、アプリ)を制御する。例えば、カード決済システム101は、アプリを利用してアクセスを試みるカード会員に対し、会員認証の結果に応じてアクセスを制限する。また、カード決済システム101は、ログインしたカード会員がアプリを介して利用できるサービスの制限やアプリの表示を制御する。
なお、以下では、説明の都合上、アプリを介してカード決済システム101にアクセスする例を示すが、Webブラウザなどの他のアクセス手段を利用してカード決済システム101にアクセスできるようにしてもよい。この場合、アプリを介して提供される機能は、他のアクセス手段を介して提供される。また、アプリ及び他のアクセス手段の両方でカード決済システム101にアクセスできるようにしてもよい。
利用者端末102は、例えば、スマートフォン、携帯電話、PC(Personal Computer)、タブレット端末などのコンピュータである。図1の例では、説明の都合上、利用者端末102をカード会員が利用する場合について説明する。利用者端末102には、カード決済システム101にアクセスするためのアプリがインストールされている。但し、他のアクセス手段を利用してカード決済システム101にアクセスする場合には、利用者端末102にアプリがインストールされなくてもよい。
非加盟店端末103は、例えば、スマートフォン、携帯電話、PC(Personal Computer)、タブレット端末、サーバ装置、POS(Point Of Sales)システムなどのコンピュータである。図1の例では、説明の都合上、非加盟店端末103を非加盟店(スタッフや経営者など)が利用する場合について説明する。非加盟店端末103には、例えば、ディスプレイDSP及びプリンタPRTの少なくとも一方が接続される。
銀行システム104は、銀行が管理するシステムである。銀行システム104は、例えば、振込や振替(引き落としを含む)などの機能を提供する。以下では、説明の都合上、カード決済システム101からの依頼手続に応じて、銀行システム104が振込などの処理を実行できることを前提とする。
以上、システム構成例について説明した。図1に示したシステム構成例はあくまでも一例であり、実施の態様に応じて様々に変形することができる。例えば、カード決済システム101を主要な機能に応じて複数のシステムに分ける変形や、利用者端末102の機能をATM(Automated Teller Machine)などに搭載する変形などが可能である。
[1−2.支払代行方法]
次に、図2を参照しながら、第1実施形態に係る支払代行方法について説明する。図2は、第1実施形態に係る支払代行方法について説明するための説明図である。
図2に示すように、第1実施形態に係る支払代行方法では、例えば、カード会員が非加盟店との間で売買契約/役務提供契約61を締結した場合(S1)に発生するカード会員から非加盟店への支払をカード決済システム101が代行する。カード決済システム101による支払の代行を利用する場合、カード会員は、カード決済システム101側とサービス利用契約62を締結する。
サービス利用契約62がある場合、カード決済システム101は、カード会員からの依頼に応じて、非加盟店の銀行口座に代金を振り込み(S2a)、カード会員のクレジットカードによるカード決済により代金の支払を受ける(S2b)。このとき、カード決済システム101は、代金と共に所定の手数料をカード会員に請求する。非加盟店は、振り込み(S2a)及びカード決済(S2b)の手続が完了した旨の通知を受けてカード会員に商品/役務を提供する(S3)。
第1実施形態に係る支払代行方法を適用すれば、カード決済システム101がカード決済を実行するため、カード会員は、非加盟店に対する代金を実質的にクレジットカードで支払うことができる。非加盟店は、カード決済システム101側と特別な契約を結ぶことなく、銀行口座さえあれば代金の支払を受けることができる。さらに、カード決済時に課される手数料を含む所定の手数料はカード会員に対して請求される。そのため、余計な負担なく非加盟店でカード決済を利用できるようになる。
以上、第1実施形態に係る支払代行方法について説明した。以下では、図2に例示した支払代行方法を実現しうるカード決済システム101、利用者端末102、及び非加盟店端末103について、さらに説明する。
[1−3.ハードウェア構成例]
図3を参照しながら、カード決済システム101、利用者端末102、及び非加盟店端末103の機能を実現可能なハードウェアについて説明する。
図3は、第1実施形態に係るカード決済システム、非加盟店端末、及び利用者端末の機能を実現可能な情報処理装置のハードウェア構成例を示したブロック図である。なお、図3に示した情報処理装置70は、カード決済システム101、利用者端末102、及び非加盟店端末103の機能を実現可能なハードウェアの一例である。
図3に示すように、情報処理装置70は、プロセッサ71、メモリ72、表示IF(Interface)73、通信IF74、及び接続IF75を有する。
プロセッサ71は、例えば、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)などである。メモリ72は、例えば、ROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリなどの記憶装置である。
表示IF73は、LCD(Liquid Crystal Display)、ELD(Electro-Luminescence Display)などのディスプレイデバイス(非図示)を接続するためのインターフェースである。例えば、表示IF73は、プロセッサ71や表示IF73に搭載されたGPU(Graphic Processing Unit)により表示制御を実施する。
通信IF74は、有線及び/又は無線のネットワークに接続するためのインターフェースである。通信IF74は、例えば、有線LAN、無線LAN、光通信ネットワーク、携帯電話ネットワーク、専用回線などに接続される。
接続IF75は、外部デバイスを接続するためのインターフェースである。接続IF75は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)などである。
接続IF75には、例えば、キーボード、マウス、タッチパネル、タッチパッドなどの入力インターフェース(非図示)が接続されうる。また、接続IF75には、プリンタやカメラなどの外部機器(非図示)が接続されうる。また、接続IF75には、可搬性の記録媒体76が接続されうる。記録媒体76は、例えば、磁気記録媒体、光ディスク、光磁気ディスク、半導体メモリなどである。
プロセッサ71は、記録媒体76に格納されたコンピュータプログラムを読み出してメモリ72に格納し、メモリ72から読み出したコンピュータプログラムに従って情報処理装置70の動作を制御する。情報処理装置70で実現される機能は、コンピュータプログラムを用いて実装されうる。コンピュータプログラムは、メモリ72に予め格納されていてもよいし、通信IF74を介してネットワークからダウンロードされてもよい。
以上、情報処理装置70のハードウェアについて説明した。
[1−4.カード決済システムの機能]
次に、図4を参照しながら、カード決済システム101の機能について説明する。図4は、第1実施形態に係るカード決済システムが有する機能の一例を示したブロック図である。なお、図4に示したカード決済システム101は、第1実施形態に係るカード決済システムの一例である。
図4に示すように、カード決済システム101は、支払代行手段111、カード決済手段112、及び記憶手段113を有する。なお、支払代行手段111及びカード決済手段112の機能は、上述したプロセッサ71により実現されうる。記憶手段113の機能は、上述したメモリ72により実現されうる。
支払代行手段111は、銀行振込機能111a、加盟店機能111b、及び確証チェック機能111cを有する。
銀行振込機能111aは、銀行システム104にアクセスして、非加盟店の銀行口座に代金を振り込むための処理(以下、振込処理;例えば、図2のS2aを参照)を実行する。加盟店機能111bは、加盟店の決済システム(以下、加盟店システム)として動作し、カード会員のクレジットカードで代金及び手数料をカード決済するための処理(以下、カード決済処理;例えば、図2のS2bを参照)を実行する。
確証チェック機能111cは、売買契約/役務提供契約61の確証を与える情報(例えば、後述する確証情報113b)をチェックする。確証チェック機能111cによりチェックOKと判定されたとき、上記の振込処理及びカード決済処理が実行される。
カード決済手段112は、会員認証機能112a、アプリ制御機能112b、及びカード決済機能112cを有する。
会員認証機能112aは、利用者端末102からのアクセス要求を受け付けたとき、アクセス要求に含まれるログイン情報に基づいてカード会員の会員認証を実施する。ログイン情報には、例えば、カード会員のログインID、クレジットカード番号(以下、カード番号)、パスワードなどの情報が含まれる。会員認証機能112aは、会員認証に成功したとき、カード会員によるアクセスであるとして、利用者端末102からのアクセスを許可する。
アプリ制御機能112bは、利用者端末102にインストールされ、カード会員がアクセスに利用するアプリの制御(表示制御、入力制限など)を実施する。例えば、アプリ制御機能112bは、アプリの画面上に表示する選択項目をカード会員の契約内容などに応じて制御する。なお、Webブラウザなどの他のアクセス手段によるアクセスを受け付ける場合、アプリ制御機能112bは、アプリの場合と同様に他のアクセス手段に対する制御を実施する。
カード決済機能112cは、クレジットカード会社の決済システム(以下、カード会社システム)として動作し、加盟店システム又は支払代行手段111からのカード決済要求に応じて、カード決済要求に含まれるクレジットカードの情報に基づくカード決済を実行する。なお、クレジットカードの情報には、カード番号や有効期限などが含まれる。
記憶手段113には、会員情報113a、確証情報113b、支払先情報113c、及び請求先情報113dが格納される。
会員情報113aは、カード会員についての情報を含む。例えば、会員情報113aには、図5に示すような情報が含まれる。図5は、第1実施形態に係る会員情報の一例を示した図である。なお、図5の例では、説明の都合上、会員情報113aを2つのデータベース(A)(B)に分けているが、会員情報113aを格納するデータベースの構造はこれに限定されない。
図5(データベース(A)を参照)に示すように、会員情報113aには、例えば、クレジットカード名義人、カード番号、及び有効期限の情報が含まれる。また、会員情報113aには、支払代行サービスの利用契約(サービス利用契約62)についての情報が含まれる。図2の例のようにサービス利用契約62があるカード会員については、会員情報113aに「契約あり」と記載される。
また、会員情報113aには、クレジットカード利用金額の引き落としに利用する銀行口座(以下、引落口座)の情報(データベース(B)を参照)が含まれる。引落口座の情報には、例えば、口座名義人、銀行名、支店名、及び口座番号の情報が含まれる。図5の例では、データベース(A)(B)が引落口座IDで紐付けられている。なお、図5に示した会員情報113aは一例であり、一部の情報が省略されてもよいし、他の情報が追加されてもよい。
再び図4を参照する。確証情報113bは、売買契約/役務提供契約61の確証を与える情報である。確証情報113bとしては、例えば、カード会員が非加盟店で買い物をした際に非加盟店が発行する請求書などがある。後述するように、確証情報113bは、非加盟店が生成する情報であるが、カード会員の利用者端末102からカード決済システム101に提供される情報である。
なお、カード決済システム101側で提供するフォーマットに従って非加盟店が情報を記入した書類なども確証情報113bになりうる。例えば、カード決済システム101が書類のフォーマットをインターネット上に公開し、非加盟店が非加盟店端末103で書類のフォーマットをダウンロードして必要事項を記入する仕組みを適用できる。
請求書の発行や書類の記入は、手作業又は非加盟店端末103を利用して容易に行える。そのため、上記の仕組みを適用するに際し非加盟店に大きな負担は生じない。
支払先情報113cは、支払代行サービスによる代金の振込先(図2の例では非加盟店)についての情報である。請求先情報113dは、支払代行サービスによる代金及び手数料の請求先(図2の例ではカード会員)についての情報である。
確証情報113b、請求先情報113d、及び支払先情報113cは、図6に示すように、互いに関連付けて記憶手段113に格納される。図6は、第1実施形態に係る確証情報、請求先情報、及び支払先情報の一例を示した図である。
図6には、確証情報113bが請求書のイメージデータ(以下、請求書画像)である場合が例示されている。図6(A)に示すように、確証情報113b、請求先情報113d、及び支払先情報113cは、例えば、支払代行IDで紐付けられる。支払代行IDは、支払代行サービスの利用毎に付与される識別情報である。
図6の例において、支払先情報113cは、代金の振込先となる非加盟店の口座名義人及び銀行口座についての情報を含んでいる。請求先情報113dは、代金の請求先となるカード会員のクレジットカード名義人及びカード番号についての情報を含んでいる。後述するように、これら支払先情報113c及び請求先情報113dは、カード会員の利用者端末102からカード決済システム101に提供される。
図6(B)に示した請求書画像は、確証情報113bの一例であり、非加盟店についての情報(例えば、会社名、屋号、代表者名など)、請求金額、支払期限、支払内容(品目別の明細など)、振込先の口座情報などを含む。後述するように、請求書画像は、例えば、非加盟店が発行した請求書をカード会員が利用者端末102で撮像して生成され、カード決済システム101に送信される。
以上、カード決済システム101の機能について説明した。
[1−5.利用者端末の機能]
次に、図7を参照しながら、利用者端末102の機能について説明する。図7は、第1実施形態に係る利用者端末が有する機能の一例を示したブロック図である。なお、図7に示した利用者端末102は、第1実施形態に係る利用者端末の一例である。
図7に示すように、利用者端末102は、記憶手段121、撮像手段122、制御手段123、表示手段124、及び入力手段125を有する。
なお、記憶手段121の機能は、例えば、上述したメモリ72により実現されうる。撮像手段122の機能は、上述した接続IF75に接続されるカメラ及びプロセッサ71により実現されうる。制御手段123の機能は、上述したプロセッサ71により実現されうる。表示手段124の機能は、上述したプロセッサ71及び表示IF73により実現されうる。入力手段125の機能は、上述した接続IF75に接続される入力インターフェースにより実現されうる。
記憶手段121には、アプリ121a及び会員情報121bが格納される。アプリ121aは、カード決済システム101へのアクセスに利用されるアプリケーションプログラムである。会員情報121bは、利用者端末102を利用するカード会員のログインIDやカード番号などの情報である。会員情報121bは、記憶手段121に予め格納されてもよいし、アプリ121aへの入力時に記憶手段121へ格納されてもよい。
撮像手段122は、制御手段123による制御に応じて被写体を撮像し、被写体のイメージデータを生成する。例えば、撮像手段122は、非加盟店が発行した請求書を被写体とする請求書画像を撮像する。また、撮像手段122は、請求書や非加盟店端末103のディスプレイDSPに表示されているQRコードを撮像して、QRコードに含まれる情報を読み取る。なお、振込先についての情報を含むQRコードを非加盟店の店頭に掲示し、そのQRコードを利用者端末102で読み込む仕組みを採用してもよい。
制御手段123は、記憶手段121からアプリ121aを読み出し、読み出したアプリ121aを実行する。例えば、制御手段123は、アプリ121aのログイン画面を表示手段124に表示させ、カード会員にパスワードなどの入力を促す。このとき、制御手段123は、記憶手段121から会員情報121bを読み出し、ログイン画面の入力欄にログインIDなどの情報を自動的に表示してもよい。
入力手段125を介してログインの操作が実行されたとき、制御手段123は、ログイン画面に入力されたパスワードやログインIDなどのログイン情報を含むアクセス要求をカード決済システム101に送信する。会員認証に成功したとき、制御手段123は、アプリ121aのポータル画面を表示する。ポータル画面には、例えば、アプリ121aを介して利用可能なサービスの項目などが表示される。
入力手段125を介して支払代行サービスの項目が選択されたとき、制御手段123は、図7(A)に示すような支払代行サービス用の入力画面を表示し、カード会員に入力を促す。なお、図7(A)の入力画面は一例であり、表示される項目の種類や入力欄の配置などは様々に変形可能である。
図7(A)の例では、クレジットカードの名義人及び利用限度額(現在のご利用限度額)と共に、支払代行サービスで支払う代金(ご利用金額)、カード決済の方法(支払回数、リボ払、継続払)の入力欄が表示されている。
リボルビング払いを利用する場合、カード会員は、「リボ払」の下にあるチェックボックスにチェックを入れる。毎月定期的に一定額の支払いを行う継続払いを利用する場合、カード会員は、「継続払」の下にあるチェックボックスにチェックを入れ、毎月の支払日を入力欄に入力する。例えば、家賃や月謝などの支払いに支払代行サービスを利用する場合、カード会員は「継続払」の欄に入力する。
図7(A)の入力画面には、振込先の情報を入力する欄が表示されている。この例では、振込先についての入力欄として、銀行名、支店名、口座の種類(当座、普通)、口座番号、名義人の欄が表示されている。また、支払代行サービスによる振込の実行日(振込日)を指定する入力欄が表示されている。
なお、振込先の入力については、非加盟店が発行した請求書画像から自動的に読み込まれるようにしてもよいし、QRコードなどを利用して少なくとも一部の情報(例えば、名義人や口座番号など)が自動的に読み込まれるようにしてもよい。例えば、図6(B)に例示した請求書のように、振込先の情報を含むQRコードが請求書に印字されていれば、カード会員は楽に振込先の情報を入力できるようになる。なお、QRコードをカード会員に提示する方法としては、例えば、非加盟店の店頭に掲示する方法を適用しうる。
図7(A)の入力画面には、さらに、カード決済金額が表示されている。このカード決済金額は、支払代行サービスにより非加盟店に支払われる代金に所定の手数料を加えた金額であり、カード決済によりカード会員から徴収される金額である。制御手段123は、代金に応じた手数料(例えば、代金の2〜5%)を計算し、計算した手数料と代金との合計額をカード決済金額として表示する。
図7(A)に示した入力画面の中で、「送信」と記載されたオブジェクトは、入力画面の内容をカード決済システム101に送信するためのボタンオブジェクトである。「撮影」と記載されたオブジェクトは、請求書を撮像して請求書画像を生成するために、利用者端末102の撮像機能(撮像手段122)を呼び出すためのボタンオブジェクトである。「読取」と記載されたオブジェクトは、QRコードを読み取るために、利用者端末102の撮像機能(撮像手段122)を呼び出すためのボタンオブジェクトである。
例えば、カード会員は、「撮影」ボタンを押下して撮像機能を呼び出し、請求書を撮像して請求書画像を生成する。請求書画像の生成が終わると、請求書画像のファイル名(図7(A)の例では「BL1000101.jpg」)が入力画面に表示される。なお、請求書画像のファイル形式は任意である。例えば、BMP形式やGIF形式などでもよい。「送信」ボタンが押下されると、制御手段123は、入力情報及び請求書画像をカード決済システム101に送信する。
以上、利用者端末102の機能について説明した。
[1−6.非加盟店端末の機能]
次に、図8を参照しながら、非加盟店端末103の機能について説明する。図8は、第1実施形態に係る非加盟店端末が有する機能の一例を示したブロック図である。なお、図8に示した非加盟店端末103は、第1実施形態に係る非加盟店端末の一例である。
図8に示すように、非加盟店端末103は、記憶手段131、入力手段132、及び出力手段133を有する。なお、記憶手段131の機能は、上述したメモリ72により実現されうる。入力手段132の機能は、上述した接続IF75に接続される入力インターフェースにより実現されうる。出力手段133の機能は、上述した接続IF75及びプロセッサ71により実現されうる。
記憶手段131には、定型情報131a及び店舗情報131bが格納される。定型情報131aは、請求書などの書類のフォーマットについての情報である。例えば、上述した確証情報113bの元となる書類のフォーマットがカード決済システム101により公開されている場合、非加盟店は、非加盟店端末103を利用してフォーマットをダウンロードし、定型情報131aとして記憶手段131に格納しておいてもよい。
店舗情報131bは、非加盟店についての情報である。例えば、店舗情報131bは、支払代行サービスによる振込先として利用可能な銀行口座についての情報や、請求書に記載する非加盟店についての情報(例えば、会社名、屋号、代表者名など)を含む。また、店舗情報131bは、QRコードの情報を含んでいてもよい。
入力手段132は、非加盟店端末103の操作や情報の入力に利用される。出力手段133は、ディスプレイDSPやプリンタPRTに情報を出力するための制御を実施する。例えば、出力手段133は、定型情報131aに基づいて請求書などの書類データをディスプレイDSPに表示する。また、出力手段133は、プリンタPRTを制御して、振込先などの情報が入力された書類を印刷する。
上記のように、非加盟店端末103は、上述した確証情報113bの元となる請求書などの書類を発行するために非加盟店が利用する端末である。但し、請求書などの書類は手作業で作成することもできる。そのため、上記の非加盟店端末103を利用せずとも非加盟店は第1実施形態の支払代行サービスを利用できる。
以上、非加盟店端末103の機能について説明した。
[1−7.処理の流れ]
次に、カード決済システム101及び利用者端末102が主に実行する処理の流れについて説明する。なお、ここでは、説明の都合上、非加盟店端末103を利用して非加盟店が請求書を発行することを前提に説明を進める。
(全体的な処理シーケンス)
まず、図9を参照しながら、カード決済システム101及び利用者端末102を含むシステムの全体的な処理シーケンスについて説明する。図9は、第1実施形態に係る支払代行方法を実現する際に、カード決済システム、非加盟店端末、及び利用者端末が実行する処理の流れを示したシーケンス図である。
なお、図9の例では、利用者端末102でアプリ121aが既に起動し、カード決済システム101でカード会員の会員認証が成功していることを前提に説明を進める。
(S101)カード会員と非加盟店との間で売買契約/役務提供契約61が結ばれると、非加盟店は、非加盟店端末103を利用して請求書を発行する。
例えば、非加盟店端末103は、定型情報131aが示す請求書のフォーマットに、店舗情報131bが示す非加盟店についての情報(会社名など)やQRコードなどを記入した請求書をプリンタPRTで印刷する。ここでは、非加盟店の銀行口座についての口座情報を含むQRコードが請求書に印刷されることを前提に説明を進める。なお、QRコードは、例えば、非加盟店の店頭に掲示されていてもよい。
(S102)カード会員がアプリ121aのポータル画面から支払代行サービスの項目を選択したとき、利用者端末102は、アプリ121aを介して、サービス利用契約62の有無を確認するための確認要求をカード決済システム101に送信する。
(S103)カード決済システム101は、確認要求に応じて、ログイン時に特定したカード会員の情報(カード番号など)から、そのカード会員に対応する会員情報113aのレコードを特定する。そして、カード決済システム101は、特定したレコードの内容を基にサービス利用契約62の有無を確認する。この例では、サービス利用契約62があるため、カード決済システム101は、利用者端末102に対して「契約あり」と応答する。
(S104)利用者端末102は、「契約あり」の応答に応じて、アプリ121aの表示画面を支払代行サービス用の入力画面(図7(A)を参照)に遷移する。そして、利用者端末102は、その入力画面に対する入力を受け付ける。ここで、カード会員により代金やカード決済の方法についての情報が入力される。
(S105)「撮影」ボタンオブジェクトが押下されたとき、利用者端末102は、撮像機能(撮像手段122)を起動させ、売買契約/役務提供契約61の確証となる請求書の撮影を促すメッセージを表示する。カード会員による撮影操作の後、利用者端末102は、請求書画像を生成し、請求書画像のファイル名を入力画面に表示する。
(S106)「読取」ボタンオブジェクトが押下されたとき、利用者端末102は、撮像機能(撮像手段122)を起動させ、QRコードの撮影を促すメッセージを表示する。カード会員による撮影操作の後、利用者端末102は、QRコードから非加盟店の口座情報などを読み取り、読み取った口座情報などを入力画面の入力欄に表示する。
なお、口座情報などの振込先についての情報をカード会員が手入力する場合にはS106の処理を省略することができる。
(S107)「送信」ボタンオブジェクトが押下されたとき、利用者端末102は、入力画面の入力欄に入力された情報及び請求書画像を含む支払要求をカード決済システム101に送信する。なお、クレジットカードの利用限度額を超える金額が入力されている場合や入力漏れがある場合、利用者端末102は、再入力を促すメッセージを表示してもよい。
(S108)カード決済システム101は、利用者端末102から送信された支払要求を受け付け、支払要求から、支払代行サービスを利用してカード会員が支払う代金(以下、支払金額)、カード決済の方法、振込先についての情報、及び請求書画像などを抽出する。
(S109)カード決済システム101は、支払金額がクレジットカードの利用限度額を超えていないかをチェックする。このとき、カード決済システム101は、振込先となる銀行口座の存在などを確認してもよい。カード決済システム101は、チェックOKの場合にS110以降の処理の開始を許可する。一方、チェックNGの場合、カード決済システム101は、エラーが生じた旨を利用者端末102に通知する。
(S110)カード決済システム101は、支払要求に含まれる請求書画像に基づいて、売買契約/役務提供契約61の確証となる請求書のチェックを実行する。請求書のチェックは、例えば、カード決済システム101側の検証者が目視により行うか、カード決済システム101により自動的に行うか、或いは、両者を組み合わせて行う。
例えば、カード決済システム101は、請求書画像から請求書に記載された支払金額及び振込先についての情報(口座番号など)を読み取り、支払要求に含まれる支払金額及び振込先についての情報と一致するかを判定する。
両者が一致するとき、カード決済システム101は、チェックOKと判定する。両者が不一致の場合、カード決済システム101は、検証者が利用する端末の表示装置に請求書画像を表示し、目視によるチェックを促す。この場合、検証者からチェックOKである旨の入力があったとき、カード決済システム101は、チェックOKと判定する。
カード決済システム101は、チェックOKの場合にS111以降の処理の開始を許可する。一方、チェックNGの場合、カード決済システム101は、エラーが生じた旨を利用者端末102に通知する。
(S111)カード決済システム101は、支払金額に応じた手数料を計算し、計算した手数料と支払金額との合計額を計算する。手数料は、例えば、支払金額の所定割合(例えば、2〜5%)に相当する金額に設定される。カード決済システム101は、カード会員のクレジットカードによるカード決済により合計額を徴収するための処理(カード決済処理)を実施する。なお、支払金額の引落は、指定の引落日に実行される。
(S112)カード決済システム101は、支払要求に含まれる振込先についての情報に基づいて、支払金額を非加盟店の銀行口座に振り込むための処理(振込処理)を実行する。なお、振込日の指定がある場合、指定の振込日に支払金額が振り込まれる。一方、振込日の指定がない場合には、例えば、振込を実行可能な直近の日に支払金額が振り込まれる。
なお、S111、S112の処理は順序を逆にしてもよい。上記のカード決済処理及び振込処理が完了すると、カード決済システム101は、今回の支払代行サービスの利用に対して支払代行IDを発行する。支払代行IDは、個々の売買契約/役務提供契約61を特定できるように支払代行サービスの利用毎に発行される。
カード決済システム101は、今回発行した支払代行IDを含む完了通知を利用者端末102に送信し、非加盟店への支払が完了した旨を通知する。
(S113)利用者端末102は、カード決済システム101から完了通知を受信すると、アプリ121aの表示画面に支払が完了した旨を表示する。また、利用者端末102は、完了通知に含まれる支払代行IDを表示画面に表示すると共に、支払代行IDを非加盟店に提示するように促すメッセージを表示する。
カード会員は、利用者端末102の表示を非加盟店に提示し、支払が完了した旨及び支払代行IDを非加盟店に通知する。支払代行IDは、カード決済システム101で管理される。例えば、カード決済システム101は、支払代行IDを提示して情報の開示要求を受けたとき、カード決済処理及び振込処理の状況、及び、請求書画像を参照できるようにする。
上記のように、第1実施形態の仕組みを適用する場合、非加盟店は請求書を発行するだけで実質的にカード決済を利用した支払を受けることができる。また、支払代行IDを利用して請求書画像を参照できるため、非加盟店及びカード会員の両者が、処理の対象が意図した売買契約/役務提供契約61であるかを確かめられる。また、カード決済システム101でも売買契約/役務提供契約61の確証を残せるため、支払代行サービスの不正利用を事前及び/又は事後にチェックすることができる。
(利用者端末の処理フロー)
ここで、図10及び図11を参照しながら、上記の処理シーケンスのうち、利用者端末102が実行する処理の流れについて、より詳細に説明する。図10は、第1実施形態に係る利用者端末が実行する処理の流れを示した第1のフロー図である。図11は、第1実施形態に係る利用者端末が実行する処理の流れを示した第2のフロー図である。
(S121)カード会員は、入力手段125を利用してアプリ121aを起動させる。アプリ121aの起動操作が行われると、制御手段123は、記憶手段121から読み出したアプリ121aを実行し、カード決済システム101にログインするためのログイン画面を表示手段124に表示する。
ログインIDやパスワードなどのログイン情報が入力されると、制御手段123は、ログイン情報を含むアクセス要求をカード決済システム101に送信して、会員認証の実施を要求する。なお、制御手段123は、ログイン情報の少なくとも一部を記憶手段121にある会員情報121bから取得してもよい。
制御手段123は、会員認証の結果をカード決済システム101から受信する。この例では、会員認証が成功したことを前提に説明を進める。会員認証に成功した場合、制御手段123は、会員認証の結果と共に、カード決済システム101からクレジットカードの利用限度額についての情報を受信してもよい。
(S122)制御手段123は、アプリ121aのポータル画面を表示する。ポータル画面には、支払代行サービスを含む各種サービスの機能を選択するための項目が表示される。例えば、各種サービスの項目はボタンオブジェクトやプルダウンメニューなどの形式で表示される。支払代行サービスを利用する場合、カード会員は、支払代行サービスの項目を選択する。制御手段123は、カード会員による選択を受け付ける。
(S123)制御手段123は、支払代行サービスの利用契約(サービス利用契約62)をカード会員が締結しているか否かを確認するための確認要求をカード決済システム101に送信する。
(S124)制御手段123は、確認要求に応じてカード決済システム101から送信される確認結果の通知を受信する。制御手段123は、この通知に基づいて有効なサービス利用契約62があるか否かを判定する。
例えば、サービス利用契約62がない場合、或いは、契約期間が既に終了している場合、制御手段123は、「契約なし」である旨の通知を受信する。この場合、制御手段123は、有効な利用契約がないと判定する。一方、「契約あり」である旨の通知を受信した場合、制御手段123は、有効な利用契約があると判定する。
有効な利用契約がある場合、処理はS128へと進む。一方、有効な利用契約がない場合、処理はS125へと進む。
(S125)制御手段123は、サービス利用契約62の手続(以下、契約手続)を行うための契約手続用の画面を表示手段124に表示する。なお、契約手続用の画面を直接表示せず、契約手続を促すメッセージと共に、契約手続用の画面を表示するためのボタンオブジェクトをアプリ121aの画面に表示する方法や、契約手続用のサイトへアクセスするためのリンクを表示する方法も適用できる。
(S126)制御手段123は、カード会員による契約手続の状況を確認し、契約手続が完了したか否かを判定する。例えば、契約手続は、契約手続用の画面からアプリ121aを介してカード決済システム101にアクセスし、契約条項やサービス利用料などの同意事項にカード会員が同意した場合に完了する。
制御手段123は、カード決済システム101から契約手続が完了した旨の通知を受信した場合に、契約手続が完了したと判定する。一方、契約手続に失敗した旨の通知をカード決済システム101から受信した場合や、カード会員が契約手続用の画面からアプリ121aのポータル画面に遷移した場合、制御手段123は、契約手続が未了のまま終了したと判定する。
契約手続が完了した場合、処理はS128へと進む。一方、契約手続が未了のまま終了した場合、処理はS127へと進む。
(S127)制御手段123は、支払代行サービスを利用できない旨のメッセージをアプリ121aの画面に表示し、支払代行サービスの利用不可をカード会員に通知する。S127の処理が完了すると、処理はS139へと進む。
(S128)制御手段123は、支払金額や決済方法の入力を指示するメッセージをアプリ121aの画面に表示し、カード会員による入力を受け付ける。
(S129)「撮影」ボタンオブジェクトが押下されたとき、制御手段123は、利用者端末102の撮像機能(撮像手段122)を起動し、請求書の撮影操作を指示するメッセージをアプリ121aの画面に表示する。撮像手段122は、カード会員による撮影操作に応じて被写体(請求書)のイメージデータを生成する。
(S130)制御手段123は、支払先情報の入力又はQRコードの撮影(QRコードの読取)を指示するメッセージをアプリ121aの画面に表示する。
「読取」ボタンオブジェクトが押下されたとき、制御手段123は、利用者端末102の撮像機能(撮像手段122)を起動し、QRコードの撮影を指示するメッセージを表示する。撮像手段122は、カード会員による撮影操作に応じてQRコードを撮像し、QRコードの情報(この例では支払先情報)を読み取る。
(S131)「送信」ボタンオブジェクトを押下する送信操作に応じて、制御手段123は、入力漏れを確認する。未入力の情報がある場合、制御手段123は、未入力情報の入力を指示するメッセージをアプリ121aの画面に表示する。このとき、制御手段123は、支払金額がカード利用限度額を超えていないかを確認してもよい。
(S132)制御手段123は、請求書画像、支払金額、決済方法(支払回数、リボ払、継続払など)、支払先情報を含む支払要求をカード決済システム101に送信する。S132の処理が完了すると、処理はS133へと進む。
(S133)制御手段123は、カード決済システム101から送信される完了通知又は拒否通知を受信する。完了通知は、支払代行サービスによる支払の処理が完了した旨を示す通知であり、支払代行IDが含まれる。一方、拒否通知は、支払代行サービスによる支払の処理に失敗した旨を示すエラー通知である。
(S134)制御手段123は、カード決済システム101から受信した通知が完了通知か否かを判定する。受信した通知が完了通知である場合、処理はS136へと進む。一方、受信した通知が完了通知でない場合(拒否通知である場合)、処理はS135へと進む。
(S135)制御手段123は、拒否通知から拒否理由を取得する。拒否理由としては、例えば、支払金額がカード利用限度額を超えていること、請求書についての確証チェックに失敗したこと、支払先情報から振込先を特定できないことなどがある。制御手段123は、支払代行サービスについての手続の失敗と拒否理由とをアプリ121aの画面に表示する。S135の処理が完了すると、処理はS139へと進む。
(S136)制御手段123は、完了通知から支払代行IDを取得する。
(S137)制御手段123は、支払代行サービスによる支払の手続が完了した旨と支払代行IDとをアプリ121aの画面に表示し、表示内容を非加盟店に提示するよう促すメッセージを併せて表示する。
(S138)制御手段123は、支払代行IDを入力することで請求書画像や手続状況(カード決済処理及び振込処理の状況)を確認できる手続状況確認用サイトの情報(URL(Uniform Resource Locator)など)を含むQRコードを表示する。なお、制御手段123は、手続状況確認用サイトを特定できる検索キーワードやURL自体をアプリ121aの画面に表示してもよい。
(S139)制御手段123は、アプリ121aのポータル画面を表示する。S139の処理が完了すると、図10及び図11に示した一連の処理は終了する。
上記のように、売買契約/役務提供契約61の確証となる請求書画像は利用者端末102の撮像機能(撮像手段122)を利用して生成され、カード決済システム101に送信される。そのため、非加盟店は、カード決済システム101に確証を提供するための特別な機器を要しない。
また、QRコードを利用して情報を入力できるため、入力にかかる負担や入力ミスを低減しうる。図10の例では、有効なサービス利用契約62がない場合でも、カード会員であればアプリ121aですぐに契約手続を行えるため、手続負担を低減しうる。
(カード決済システムの処理フロー)
次に、図12を参照しながら、上記の処理シーケンスのうち、カード決済システム101が実行する処理の流れについて、より詳細に説明する。図12は、第1実施形態に係るカード決済システムが実行する処理の流れを示したフロー図である。
(S141)カード決済手段112は、利用者端末102から送信されるログイン情報を受信する。そして、カード決済手段112は、ログイン情報及び会員情報113aに基づいて会員認証を実施し、会員認証の結果を利用者端末102に送信する。この例では、会員認証が成功したことを前提に説明を進める。
(S142)支払代行手段111は、利用者端末102から支払代行サービスに関する利用契約(サービス利用契約62)の確認要求を受信する。そして、支払代行手段111は、会員情報113aの中から該当するカード会員のレコードを特定し、特定したレコードの「サービス利用契約」欄を参照する。
(S143)支払代行手段111は、サービス利用契約62があるか否かを判定する。
S142で特定したレコードに「契約あり」と記載されている場合、支払代行手段111は、サービス利用契約62があると判定する。一方、S142で特定したレコードに「契約なし」と記載されている場合、支払代行手段111は、サービス利用契約62がないと判定する。サービス利用契約62がある場合、処理はS145へと進む。一方、サービス利用契約62がない場合、処理はS144へと進む。
(S144)支払代行手段111は、確認要求に対する応答として、サービス利用契約62がない旨を利用者端末102に通知する。S144の処理が完了すると、図12に示した一連の処理は終了する。
(S145)支払代行手段111は、確認要求に対する応答として、サービス利用契約62がある旨を利用者端末102に通知する。そして、支払代行手段111は、利用者端末102からの支払要求を待ち受ける。このとき、支払代行手段111は、確認要求に対する応答の後、予め設定された一定期間だけ支払要求を待ち受ける。
(S146)支払代行手段111は、利用者端末102から支払要求を受信したか否かを判定する。支払要求を受信した場合、処理はS147へと進む。一方、一定期間が経過しても支払要求を受信しない場合、処理はS153へと進む。
(S147)支払代行手段111は、支払要求に含まれる支払金額の情報を取得し、支払金額がクレジットカードの利用限度額より少ないか否かを判定する。支払金額が利用限度額より少ない場合、処理はS148へと進む。一方、支払金額が利用限度額より少なくない場合、処理はS153へと進む。なお、支払金額が利用限度額と同額の場合に処理がS148へ進むように変更してもよい。
(S148)支払代行手段111は、支払要求に含まれる請求書画像に基づいて、売買契約/役務提供契約61の確証を与える請求書のチェック(確証チェック)を実施する。なお、確証チェックの例については後述する。支払代行手段111は、確証チェックが成功した(チェックOK)か否かを判定する。チェックOKの場合、処理はS149へと進む。一方、チェックOKでない場合、処理はS153へと進む。
(S149)支払代行手段111は、今回の売買契約/役務提供契約61における支払代行サービスの利用を識別するための支払代行IDを発行する。
(S150)支払代行手段111は、支払要求に含まれる支払先情報に基づいて、非加盟店の銀行口座に支払金額を振り込むための振込処理を実行する。このとき、支払代行手段111は、銀行システム104にアクセスし、指定振込日にカード会員の名義で支払金額を非加盟店の銀行口座に振り込むための手続処理を実行する。
(S151)支払代行手段111は、支払金額に応じた手数料を計算し、計算した手数料と支払金額との合計額を計算する。また、支払代行手段111は、カード決済手段112と連携して、支払要求に含まれる決済方法に基づいて、計算した合計額をカード決済するためのカード決済処理を実行する。
(S152)支払代行手段111は、支払代行IDを含む完了通知を利用者端末102に送信する。S152の処理が完了すると、図12に示した一連の処理は終了する。
(S153)支払代行手段111は、拒否理由を含む拒否通知を利用者端末102に送信する。
例えば、S146で支払要求が受信されない場合、拒否通知には、タイムアウトを示す拒否理由が含まれる。S147で支払金額が利用限度額より小さくない場合、拒否通知には、支払金額が超過している旨を示す拒否理由が含まれる。S148で確証チェックが成功しなかった場合、拒否理由には、確証チェックが失敗した旨を示す拒否理由が含まれる。
S153の処理が完了すると、図12に示した一連の処理は終了する。
上記のように、第1実施形態の仕組みを適用する場合、アプリ121aを介して利用者端末102から送信される情報を基にカード決済システム101で売買契約/役務提供契約61についての確証チェックを含む各種のチェックが行われ、チェック結果に応じてカード決済を含む支払の処理が実行される。また、カード決済に伴う手数料が、支払代行サービスの利便性を享受するカード会員から徴収されるため、非加盟店の負担軽減に寄与する。
ここで、図13を参照しながら、上述した確証チェックの処理について、より詳細に説明する。図13は、第1実施形態に係るカード決済システムが実行する処理のうち確証チェックに関する処理の流れを示したフロー図である。なお、図13に示した処理の内容は一例であり、一部の処理を省略したり、他のチェック処理を追加する変形も可能である。
(S161)支払代行手段111は、請求書画像から請求金額を読み取る。例えば、支払代行手段111は、OCR(Optical Character Recognition/Reader)などの技術を利用して請求金額を読み取る。非加盟店が予め設定されたフォーマットを利用している場合、請求金額の記載位置などは既知である。
(S162)支払代行手段111は、読み取った請求金額が、支払要求に含まれる支払金額に一致するか否かを判定する。請求金額と支払金額とが一致する場合、処理はS163へと進む。一方、請求金額と支払金額とが一致しない場合や、請求書画像から請求金額が正しく読み取れない場合、処理はS166へと進む。
(S163)支払代行手段111は、請求書画像から支払先情報を読み取る。例えば、支払代行手段111は、OCRなどの技術を利用して支払先情報を読み取る。なお、請求書に支払先情報のQRコードが記載されている場合、支払代行手段111は、QRコードから支払先情報を読み取ってもよい。支払代行手段111により読み取る情報は、支払先情報の一部(例えば、口座番号)だけでもよい。
(S164)支払代行手段111は、支払要求に含まれる支払先情報の口座番号と、請求書画像から読み取った口座番号とが一致するか否かを判定する。これら2つの口座番号が一致する場合、処理はS165へと進む。一方、これら2つの口座番号が一致しない場合、処理はS166へと進む。
なお、この例では支払先情報のうち口座番号をチェックに利用しているが、支払先情報に含まれる他の情報をチェックに利用してもよい。また、支払代行手段111は、この時点で銀行システム104にアクセスし、支払先情報に含まれる口座番号が実際に存在するか、その口座番号に対応する口座名義人が支払先情報の口座名義人と一致するかを確認してもよい。
(S165)支払代行手段111は、確証チェックについてチェックOKと判定する。S165の処理が完了すると、図13に示した一連の処理は終了する。
(S166)支払代行手段111は、検証者による確認を促すメッセージを請求書画像と共に検証者の端末に表示させ、検証者による確認結果の入力を待ち受ける。なお、支払代行手段111は、メッセージ及び請求書画像を電子メールなどの手段で検証者に送信してもよい。
(S167)支払代行手段111は、検証者による入力内容に応じて、検証者がチェックOKと判断したか否かを判定する。検証者がチェックOKと判断した場合、処理はS168へと進む。一方、検証者がチェックOKと判断しなかった場合、処理はS169へと進む。
(S168)支払代行手段111は、確証チェックについてチェックOKと判定する。S168の処理が完了すると、図13に示した一連の処理は終了する。
(S169)支払代行手段111は、確証チェックについてチェックNG(チェックの失敗)と判定する。S169の処理が完了すると、図13に示した一連の処理は終了する。
上記のように、請求書画像から読み取った情報に基づいて確証チェックを実施することで、確証チェックにかかる負担を軽減することができる。また、請求書画像の読み取り不良などで確証チェックに失敗した場合でも検証者によるチェックで救済できるため、確証チェックのエラーによってカード会員及び非加盟店が最初から手続をやり直すことが少なくなり、カード会員及び非加盟店の負担軽減に寄与する。
以上、本発明に係る第1実施形態について説明した。
<2.第2実施形態>
次に、本発明に係る第2実施形態について説明する。第2実施形態は、加盟店のカード決済機能を有するカード決済システムに関し、特に、非加盟店がカード会員である場合に、非加盟店が発行する請求書を利用せずに、上記の支払代行サービスを実現できるようにする仕組みに関する。
以下の説明では、既に説明した第1実施形態に係る構成要素については、同一の符号を付して重複説明を省略し、第2実施形態に係る構成要素との間の相違点についてのみ説明する場合がある。
例えば、第2実施形態に係る仕組みは、図1に例示したシステム構成に適用できるため、システム構成例についての説明を省略する。同様に、カード決済システム101、利用者端末102、非加盟店端末103のハードウェア構成例についても説明を省略する。但し、第2実施形態では、非加盟店端末103がネットワーク50に接続され、カード決済システム101にアクセスできる状態にある。
[2−1.支払代行方法]
まず、図14を参照しながら、第2実施形態に係る支払代行方法について説明する。図14は、第2実施形態に係る支払代行方法について説明するための説明図である。
図14に示すように、図2に示した第1実施形態に係る支払代行方法と、第2実施形態に係る支払代行方法との主な相違点は、非加盟店がカード会員である点にある。第2実施形態では、非加盟店との間で売買契約/役務提供契約61を結び、支払代行サービスを利用するカード会員を単に「利用者」と呼ぶことにする。
非加盟店がカード会員であるため、カード決済システム101は、非加盟店のクレジットカードに関する情報を保持している。また、非加盟店も、利用者端末102のアプリ121aと同じアプリ(後述するアプリ131c)を利用でき、アプリ131cを介してカード決済システム101にアクセスできる。第2実施形態では、この環境を活用し、売買契約/役務提供契約61の確証として、請求書画像とは異なる情報を利用する。
また、非加盟店がカード会員であるため、カード決済システム101から非加盟店への支払を銀行振込以外の方法で実施することが可能になる。
例えば、一方のカード会員から他方のカード会員へと送金するカード送金を支払代行サービスに利用できる。また、非加盟店が利用したカード利用額の引落時に、支払代行サービスの支払金額を引落金額から減額するか、引き落とした金額の一部(支払金額に相当する額)を引落口座に戻すことで実質的な支払とする仕組みも適用できる。
上記のように、第2実施形態では、請求書画像とは異なる情報を売買契約/役務提供契約61の確証として利用する点、及び、非加盟店に対する支払を口座振込以外の方法で実行できる点が第1実施形態とは異なる。なお、非加盟店に対する支払を口座振込で実施することもでき、さらに、第1及び第2実施形態の仕組みを組み合わせることもできる。
ここで、図15を参照しながら、第2実施形態に係るシステムの全体的な処理シーケンスについて説明する。図15は、第2実施形態に係る支払代行方法を実現する際に、カード決済システム、非加盟店端末、及び利用者端末が実行する処理の流れを示したシーケンス図である。
なお、図15の例では、利用者端末102でアプリ121aが既に起動し、非加盟店端末103でアプリ131cが既に起動し、カード決済システム101で利用者及び非加盟店の会員認証が成功していることを前提に説明を進める。
(S201)非加盟店がアプリ131cのポータル画面から、請求側として、支払代行サービスの項目を選択したとき、非加盟店端末103は、アプリ131cの画面に請求金額及び支払方法を入力するための入力画面を表示する。支払方法としては、例えば、銀行振込やカード送金などがある。なお、カード送金については後述する。
(S202)非加盟店が請求金額及び支払方法を入力すると、非加盟店端末103は、請求金額及び支払方法を含む支払要求Aを生成する。
(S203)非加盟店端末103は、支払要求Aをカード決済システム101に送信し、売買契約/役務提供契約61の確証となるキー情報の生成に用いるキーの発行を要求すると共に請求金額の支払いを要求する。
(S204)カード決済システム101は、非加盟店端末103から支払要求Aを受信すると、今回の支払要求Aを識別するための支払IDを発行する。また、カード決済システム101は、支払ID、非加盟店のカード番号、及び支払IDの発行日時に基づいて、キー情報の生成に用いるキーを生成する。この例では、キーとして、支払ID、カード番号、発行日時から生成されるハッシュ値を利用する。カード決済システム101は、生成したキー(ハッシュ値)を非加盟店端末103に送信する。
(S205)非加盟店端末103は、カード決済システム101から受信したキー(ハッシュ値)及び非加盟店のカード番号を含むキー情報を生成する。そして、非加盟店端末103は、生成したキー情報を利用者に提供する。
例えば、非加盟店端末103は、キー情報からQRコードを生成し、生成したQRコードをディスプレイDSPに表示するか、プリンタPRTでQRコードを印刷して利用者に提示する。利用者は、利用者端末102の撮像機能(撮像手段122)を利用してQRコードを読み取ることによりキー情報を容易に取得できる。
なお、非加盟店端末103から利用者端末102にキー情報を提供する方法としては、QRコードの他、例えば、ネットワーク50を利用する方法、非接触通信を利用する方法、記録媒体を利用する方法などが適用できる。この例では、非加盟店端末103がキー情報からQRコードを生成しているが、カード決済システム101がQRコードを生成し、QRコードのイメージデータを非加盟店端末103に送信する仕組みに変形してもよい。
(S206、S207)利用者がアプリ121aのポータル画面から、支払側として、支払代行サービスの項目を選択したとき、利用者端末102は、アプリ121aを介して、サービス利用契約62の有無を確認するための確認要求をカード決済システム101に送信する。第1実施形態の場合と同様に、カード決済システム101は、確認要求に応じて確認結果を利用者端末102に送信する。この例では、カード決済システム101が「契約あり」と応答する。
(S208)利用者端末102は、カード決済システム101からの応答を受け、アプリ121aの画面を支払代行サービス用の入力画面に遷移し、その入力画面に対する入力を受け付ける。ここで、利用者により支払金額及び決済方法(支払回数、リボ払、継続払など)が入力される。
(S209)利用者は、非加盟店端末103から提供されるキー情報を利用者端末102に入力する。キー情報がQRコードで提供される場合、利用者は、利用者端末102の撮像機能(撮像手段122)を利用してQRコードを読み取る。そして、利用者端末102は、利用者が入力した支払金額及び決済方法と、キー情報とを含む支払要求Bを生成する。
(S210)利用者端末102は、支払要求Bをカード決済システム101に送信し、支払代行サービスによる支払を要求する。
(S211)カード決済システム101は、非加盟店端末103から送信された支払要求Aと、利用者端末102から送信された支払要求Bとを受け付ける。なお、カード決済システム101は、支払要求Aの受信から一定期間(例えば、30分)が経過しても支払要求Bが受信できない場合には受け付けを拒否してもよい。
(S212)カード決済システム101は、2つの支払要求A、Bに基づいて支払の許否を判定する。例えば、カード決済システム101は、非加盟店端末103にキーとして送信したハッシュ値と、支払要求Bに含まれるハッシュ値とが一致するか否かを判定する。2つのハッシュ値が一致する場合、カード決済システム101は、支払代行サービスによる支払の処理を許可する。不一致の場合、カード決済システム101は、支払代行サービスによる支払の処理を許否する。
(S213、S214、S215)第1実施形態と同様に、カード決済システム101は、利用者のクレジットカードの利用限度額と支払金額とを比較し、支払金額が利用限度額より少ないことをチェック(金額チェック)する。そして、カード決済システム101は、非加盟店への支払のための処理(以下、支払処理)及び利用者のクレジットカードによるカード決済処理を実行する。なお、支払処理については後述する。
(S216、S217)カード決済システム101は、支払処理及びカード決済処理が完了した旨を示す完了通知を非加盟店端末103及び利用者端末102に送信する。なお、何らかのエラーが生じた場合には、第1実施形態の場合と同様の拒否通知が非加盟店端末103及び利用者端末102に送信される。
(S218、S219)非加盟店端末103は、支払の手続が完了した旨のメッセージ及び支払代行IDをアプリ131cの画面に表示する。同様に、利用者端末102は、支払の手続が完了した旨のメッセージ及び支払代行IDをアプリ121aの画面に表示する。
上記のように、第2実施形態では、売買契約/役務提供契約61の確証として請求書画像を利用するのではなく、カード決済システム101が発行する支払IDに基づくキーを利用する。なお、図15の例ではカード決済システム101がキーを生成しているが、非加盟店端末103がキーを生成してカード決済システム101に提供してもよい。
第2実施形態の仕組みを適用する場合、第1実施形態と同様、非加盟店はクレジットカードのブランドと加盟店契約を締結せずに、実質的にカード決済を行うことが可能になる。また、非加盟店は、アプリ131cが動作する市販のコンピュータがあれば支払代行サービスを利用でき、少ない導入コストで支払代行サービスを利用できる。
[2−2.カード決済システムの機能]
ここで、図16を参照しながら、カード決済システム101の機能について、図4に示したカード決済システム101との相違点を中心に説明する。図16は、第2実施形態に係るカード決済システムが有する機能の一例を示したブロック図である。
図16に示すように、第2実施形態において、カード決済システム101は、支払代行手段111、カード決済手段112、記憶手段113に加え、カード送金手段114を有する。なお、カード送金手段114の機能は、上述したプロセッサ71により実現されうる。
記憶手段113には、会員情報113a、支払先情報113c、請求先情報113dに加え、ストック情報113e及び履歴情報113fが格納される。
ストック情報113e及び履歴情報113fは、支払代行サービスにおいて非加盟店への支払(出金)及びカード決済による支払金額の徴収(入金)を管理するための入出金管理情報の一例である。
ストック情報113e及び履歴情報113fは、例えば、図17に示すような内容を有する。図17は、第2実施形態に係る入出金管理情報(ストック情報、履歴情報)の一例を示した図である。
図17の例において、ストック情報113eには、クレジットカード名義人、カード番号、事前入金額、及び不足分カード決済予定額の情報が含まれる。
事前入金額は、例えば、カード送金により受領した金額、及びカード送金用にカード会員が事前に入金した金額の総額である。不足分カード決済予定額は、カード送金の送金額が事前入金額より多い場合に、カード決済により精算される予定の不足金額である。不足金額の精算もカード決済であるため、支払回数を複数回にすることや、リボ払を利用することができる。
履歴情報113fには、支払ID、送金元カード番号、送金先カード番号、送金額、送金日時、入金、出金の情報が含まれる。
支払IDの欄には、支払要求Aに応じて発行した支払IDが記録される。この支払IDに紐付けて、送金元カード番号の欄に利用者のカード番号が記録され、送金先カード番号の欄に非加盟店のカード番号が記録される。送金額の欄には支払金額が記録され、送金日時の欄には、送金が完了した日時が記録される。
利用者から非加盟店への送金は、利用者のクレジットカードによるカード決済処理(入金)と、非加盟店の事前入金額への増額処理(出金)とが済んだときに完了する。入金が済むと入金の欄に「済」と記録される。出金が済むと出金の欄に「済」と記録される。
非加盟店への支払にカード送金が選択された場合、カード決済処理(入金)及び増額処理(出金)の完了日時が、送金日時の欄に記録される。非加盟店への支払に口座振替が選択された場合には、カード決済処理(入金)及び振込処理(出金)の完了日時が、送金日時の欄に記録される。
再び図17を参照する。支払代行手段111及びカード決済手段112が有する主な機能は、図4に示したカード決済システム101と同様である。但し、支払代行手段111には、支払IDの発行、キーとなるハッシュ値の生成、及びハッシュ値のチェックを実施する機能が追加される。
カード送金手段114は、支払方法としてカード送金が選択されたときに、上記の入出金管理情報を利用して送金を実施する。カード送金の場合、振込手数料が発生しないため、利用者が負担する手数料を抑えることができる。
例えば、所定の期日にまとめて事前入金額を口座に振り込む仕組みの場合、支払代行サービスによる支払がある度に振込手数料を支払って振込を行う場合に比べ、振込手数料の総額を少なくすることができる。また、非加盟店が利用したカード利用額を口座から引き落とす際に、引落金額から事前入金額を減算して、実質的な事前入金額の支払を行うことで、さらなる振込手数料の減額に繋がる。
以上、第2実施形態におけるカード決済システム101の機能について説明した。
[2−3.非加盟店端末の機能]
次に、図18を参照しながら、非加盟店端末103が有する機能について、図8に示した非加盟店端末103との相違点を中心に説明する。図18は、第2実施形態に係る非加盟店端末が有する機能の一例を示したブロック図である。
図18に示すように、第2実施形態において、非加盟店端末103は、記憶手段131、入力手段132、出力手段133に加え、制御手段134が明示的に記載されている。制御手段134の機能は、上述したプロセッサ71により実現されうる。
記憶手段131には、定型情報131a、店舗情報131bの他、アプリ131c及び会員情報131dが格納される。
アプリ131cは、利用者端末102で実行されるアプリ121aと同じ、カード決済システム101へのアクセスに利用されるアプリケーションプログラムである。会員情報131dは、非加盟店端末103を利用する非加盟店のログインIDやカード番号などの情報である。会員情報131dは、記憶手段131に予め格納されてもよいし、アプリ131cへの入力時に記憶手段131へ格納されてもよい。
制御手段134は、記憶手段131からアプリ131cを読み出し、読み出したアプリ131cを実行する。例えば、制御手段131は、アプリ131cのログイン画面をディスプレイDSPに表示させ、非加盟店にパスワードなどの入力を促す。このとき、制御手段134は、記憶手段131から会員情報131dを読み出し、ログイン画面の入力欄にログインIDなどの情報を自動的に表示してもよい。
制御手段134は、利用者端末102の制御手段123と同様に、会員認証やアプリ131cの画面表示などを実施する。アプリ131cのポータル画面から支払代行サービスの項目が選択された場合、制御手段134は、請求側か支払側かを選択させる選択オブジェクトを表示する。非加盟店は請求側になるため、請求側が選択される。
請求側が選択されると、制御手段134は、請求金額や支払方法(口座振込の利用又はカード送金)などの情報を入力するための入力画面を表示する。また、制御手段134は、支払要求Aの生成、キーの発行要求、キー情報の提供を実施し、完了通知の受信に応じて手続完了の表示及び支払代行IDの表示を実施する。
なお、キー情報の提供方法としては、例えば、キー情報を含むQRコードをディスプレイDSPに表示する方法や、そのQRコードをプリンタPRTで印刷して利用者に渡す方法、非接触通信などの通信手段を用いてキー情報そのものを利用者端末102に送信する方法などが適用できる。
以上、第2実施形態における非加盟店端末103の機能について説明した。
(利用者端末102について)
利用者端末102の主な機能は第1実施形態と同じである。但し、アプリ121aのポータル画面から支払代行サービスの項目が選択された場合、利用者端末102の制御手段123は、請求側か支払側かを選択させる選択オブジェクトを表示する。利用者は支払側になるため、支払側が選択される。支払側が選択されると、制御手段123は、第1実施形態と同様に、支払金額や決済方法などを入力するための入力画面(図7を参照)を表示する。
[2−4.処理の流れ]
次に、第2実施形態における非加盟店端末103、利用者端末102、カード決済システム101が実行する処理の流れについて、さらに説明する。
(非加盟店端末の処理フロー)
まず、図19を参照しながら、非加盟店端末103が実行する処理の流れについて説明する。図19は、第2実施形態に係る非加盟店端末が実行する処理の流れを示したフロー図である。
(S221)非加盟店は、入力手段132を利用してアプリ131cを起動させる。アプリ131cの起動操作が行われると、制御手段134は、記憶手段131から読み出したアプリ131cを実行し、カード決済システム101にログインするためのログイン画面をディスプレイDSPに表示する。
ログインIDやパスワードなどのログイン情報が入力されると、制御手段134は、ログイン情報を含むアクセス要求をカード決済システム101に送信して、会員認証の実施を要求する。なお、制御手段134は、ログイン情報の少なくとも一部を記憶手段131にある会員情報131dから取得してもよい。制御手段134は、会員認証の結果をカード決済システム101から受信する。この例では、会員認証が成功したことを前提に説明を進める。
(S222)制御手段134は、アプリ131cのポータル画面を表示する。ポータル画面には、支払代行サービスを含む各種サービスの機能を選択するための項目が表示される。支払代行サービスを利用する場合、非加盟店は、支払代行サービスの項目を選択する。支払代行サービスの項目が選択されると、制御手段134は、請求側又は支払側を選択するための選択オブジェクトを表示する。非加盟店は、選択オブジェクトから請求側を選択する。
(S223)制御手段134は、請求金額、支払方法を入力するための入力画面を表示する。この例では、支払方法として、口座振込及びカード送金を選択することができる。なお、口座振込及びカード送金は一例であり、他の支払方法を選択できるようにしてもよい。
(S224)制御手段134は、請求金額及び支払方法を含む支払要求Aを生成し、キーとなる支払IDの発行要求として、支払要求Aをカード決済システム101に送信する。なお、この例では支払IDを含む情報(例えば、支払ID、カード番号、支払IDの発行日時)に基づいて生成されるハッシュ値がキーとして利用される。制御手段134は、支払要求Aに対する応答としてカード決済システム101から送信されるハッシュ値を取得する。
(S225)制御手段134は、非加盟店のカード番号、及びカード決済システム101から取得したハッシュ値を含むキー情報を生成する。また、制御手段134は、キー情報のQRコードをディスプレイDSPに表示するか、プリンタPRTで印刷する。なお、制御手段134は、非接触通信などの通信手段を利用してキー情報を利用者端末102に送信してもよい。また、カード決済システム101が生成したキー情報のQRコードを、制御手段134が取得して表示又は印刷してもよい。
(S226)制御手段134は、支払要求Aの送信から一定の時間内に完了通知を受信できたか否かを判定する。例えば、支払要求Aから一定の時間が経過しても完了通知を受信しない場合(タイムアウト)や拒否通知を受信した場合、制御手段134は、完了通知を受信できなかったと判定する。
一定の時間内に完了通知を受信できた場合、処理はS227へと進む。一方、一定の時間内に完了通知を受信できなかった場合、制御手段134は、手続の失敗を示すエラー通知を表示し、処理をS228へと進める。
(S227)制御手段134は、支払代行サービスの手続が完了した旨と、完了通知に含まれる支払代行IDとをディスプレイDSPに表示する。また、制御手段134は、支払代行IDを記憶手段131に格納する。
(S228)制御手段134は、アプリ131cのポータル画面をディスプレイDSPに表示する。S228の処理が完了すると、図19に示した一連の処理は終了する。
上記のように、第2実施形態における非加盟店端末103は、売買契約/役務提供契約61の確証として請求書を発行せず、キーとなる情報(この例ではハッシュ値)を確証として利用する。そのため、非加盟店は、アプリ131cにより手続を進めることができ、さらに手続の手間が軽減されうる。
(利用者端末の処理フロー)
次に、図20を参照しながら、利用者端末102が実行する処理の流れについて説明する。図20は、第2実施形態に係る利用者端末が実行する処理の流れを示したフロー図である。
(S231、S232、S233)S231、S232の処理は、図10のS121、S122の処理(第1実施形態)とほぼ同じであるため、詳細な説明を省略する。異なる点は、利用者がアプリ121aのポータル画面から支払代行サービスの項目を選択した際に、請求側か支払側かを選択する選択オブジェクトが表示され、利用者が支払側を選択する点である。
支払代行サービスに関する利用者の利用契約の確認(S233)についても、処理の内容が第1実施形態(図10のS123−S127)と同じであるため、利用契約があることを前提として、確認の処理に関する詳細な説明を省略する。
(S234)制御手段123は、支払金額や決済方法(支払回数、リボ払、継続払など)の入力を指示するメッセージと共に、入力画面をアプリ121aの表示領域に表示し、利用者による入力を受け付ける。
(S235)制御手段123は、利用者端末102の撮像機能(撮像手段122)を起動し、非加盟店から提供されるQRコードの撮影を指示するメッセージを表示する。撮像手段122は、利用者による撮影操作に応じてQRコードを撮像し、QRコードに含まれるキー情報を読み取る。
(S236)制御手段123は、入力画面から入力された支払金額、決済方法、キー情報を含む支払要求Bを生成し、支払要求Bをカード決済システム101に送信する。また、制御手段123は、キー情報を記憶手段121に格納する。
この例では、キー情報にハッシュ値及び非加盟店のカード番号が含まれている。ハッシュ値は、例えば、支払ID、非加盟店のカード番号、及び支払IDの発行日時に基づいて生成される。この場合、制御手段123は、カード決済システム101から支払ID及び支払IDの発行日時を取得し、キー情報のカード番号を用いてハッシュ値を計算し、キー情報に含まれるハッシュ値との一致を確かめることで、支払先(非加盟店)の正当性を確認できる。
そこで、制御手段123は、支払要求Bを送信する前に、ハッシュ値の一致を確かめる上記の処理を実行し、一致を確認してから支払要求Bを送信してもよい。このような確認の仕組みを含めることで安全性を高めることができる。
(S237)制御手段123は、支払要求Bの送信から一定の時間内に完了通知を受信できたか否かを判定する。例えば、支払要求Bから一定の時間が経過しても完了通知を受信しない場合(タイムアウト)や拒否通知を受信した場合、制御手段123は、完了通知を受信できなかったと判定する。
一定の時間内に完了通知を受信できた場合、処理はS238へと進む。一方、一定の時間内に完了通知を受信できなかった場合、制御手段123は、手続の失敗を示すエラー通知を表示し、処理をS239へと進める。なお、制御手段123がタイムアウトを判断するための一定の時間は、非加盟店端末103がタイムアウトを判断するための一定の時間に比べて十分に長い時間に設定される。
(S238)制御手段123は、支払代行サービスの手続が完了した旨と、完了通知に含まれる支払代行IDとを表示手段124に表示する。また、制御手段123は、支払代行IDを記憶手段121に格納する。
(S239)制御手段123は、アプリ121aのポータル画面を表示手段124に表示する。S239の処理が完了すると、図20に示した一連の処理は終了する。
上記のように、第2実施形態における利用者端末102は、QRコードを利用して非加盟店端末103からハッシュ値を含むキー情報を取得する。ハッシュ値は、例えば、売買契約/役務提供契約61に基づく支払を特定するための支払ID及び支払先である非加盟店のカード番号を含む情報から生成される。
なお、上記の例ではハッシュ値を利用しているが、支払IDやカード番号などの情報を組にした情報セットを利用してもよい。つまり、支払IDを利用して非加盟店、利用者、売買契約/役務提供契約61を紐付けることができれば、第2実施形態の仕組みを実現することができる。
第2実施形態の仕組みによれば、支払ID又は支払IDに基づく情報をキーに利用者と非加盟店との間の売買契約/役務提供契約61について確証が得られるため、利用者、非加盟店の双方がアプリで手続を完結でき、手続の手間が軽減されうる。
(カード決済システムの処理フロー)
次に、図21及び図22を参照しながら、カード決済システム101が実行する処理の流れについて説明する。図21は、第2実施形態に係るカード決済システムが実行する処理の流れを示した第1のフロー図である。図22は、第2実施形態に係るカード決済システムが実行する処理の流れを示した第2のフロー図である。
(S251、S252)カード決済手段112は、利用者及び非加盟店の両方について会員認証を実施する。会員認証の処理は、第1実施形態(図12のS141)と同じであるため、詳細な説明は省略する。この例では、会員認証が成功したことを前提に説明を進める。また、支払代行サービスに関する利用者の利用契約を確認する処理についても第1実施形態(図12のS142−S145)と同じであるため、詳細な説明を省略する。この例では、利用契約があることを前提に説明を進める。
(S253)支払代行手段111は、非加盟店端末103からの支払要求Aを待ち受ける。支払要求Aを受信した場合、支払代行手段111は、受信した支払要求Aに対応付けるユニークな支払IDを発行し、処理をS254へと進める。
(S254)支払代行手段111は、発行した支払ID、非加盟店のカード番号、及び支払IDの発行日時をもとにハッシュ値を生成する。但し、アプリ131cによるログイン時に非加盟店のカード番号は特定される。ハッシュ値の生成には、所定のハッシュ関数が用いられる。なお、利用可能なハッシュ関数の種類は任意である。
(S255)支払代行手段111は、支払要求Aに対する応答として、非加盟店端末103にハッシュ値を送信する。
(S256)支払代行手段111は、利用者端末102からの支払要求Bを待ち受ける。支払要求Bを受信した場合、支払代行手段111は、支払要求Bに含まれるカード番号に基づいて支払要求A、Bを対応付け、処理をS257へと進める。
(S257)支払代行手段111は、支払要求Aに対する応答として非加盟店端末103に送信したハッシュ値と、支払要求Bに含まれるハッシュ値とが一致するか否かを判定する。
ハッシュ値が一致する場合、処理はS258へと進む。一方、ハッシュ値が一致しない場合、支払代行手段111は、非加盟店端末103及び利用者端末102にエラーを示す拒否通知を送信して、図21及び図22に示した一連の処理を終了する。
(S258)支払代行手段111は、支払要求Bが示す支払金額が、利用者の利用限度額の範囲内であるか否かを判定する。支払金額が利用限度額の範囲内である場合、処理はS259へと進む。一方、支払金額が利用限度額の範囲外である場合、支払代行手段111は、非加盟店端末103及び利用者端末102にエラーを示す拒否通知を送信して、図21及び図22に示した一連の処理を終了する。
(S259)支払代行手段111は、支払要求Aが示す請求金額と、支払要求Bが示す支払金額とが一致するか否かを判定する。請求金額と支払金額とが一致する場合、処理はS260へと進む。一方、請求金額と支払金額とが一致しない場合、支払代行手段111は、非加盟店端末103及び利用者端末102にエラーを示す拒否通知を送信して、図21及び図22に示した一連の処理を終了する。
(S260)支払代行手段111は、履歴情報113fに新たなレコードを追加し、支払ID、送金元カード番号(利用者のカード番号)、送金先カード番号(非加盟店のカード番号)、送金額(支払金額)を登録する。
(S261)支払代行手段111は、支払金額に応じた手数料を計算し、計算した手数料と支払金額との合計額を計算する。また、支払代行手段111は、カード決済手段112と連携して、支払要求に含まれる決済方法に基づいて、計算した合計額をカード決済するためのカード決済処理を実行する。
(S262)支払代行手段111は、S260で新たに追加した履歴情報113fのレコードに対する入金済登録(「入金」欄を「済」に設定)を実施する。
(S263)支払代行手段111は、支払要求Aが示す支払方法がカード送金であるか否かを判定する。支払方法がカード送金である場合、処理はS264へと進む。一方、支払方法がカード送金でない場合(口座振込である場合)、処理はS266へと進む。
(S264)カード送金手段114は、非加盟店のカード番号に対応するストック情報113eのレコードを特定し、特定したレコードにある事前入金額を支払金額の分だけ増加させる。また、カード送金手段114は、事前入金額の更新に応じて必要が生じた場合に不足分カード決済予定額を更新する。
(S265)支払代行手段111は、S260で新たに追加した履歴情報113fのレコードに対する出金済登録(「出金」欄を「済」に設定)を実施する。S265の処理が完了すると、処理はS268へと進む。
(S266)支払代行手段111は、銀行システム104にアクセスし、利用者名義で非加盟店の口座に支払金額を振り込むための振込処理を実行する。なお、振込先口座としては、例えば、非加盟店のカード利用額を引き落とすための引落口座が利用される。振込日が指定されている場合、支払代行手段111は、指定された振込日に支払金額が振り込まれるように振込処理を実行する。
但し、予め非加盟店が支払代行サービス用に振込先口座を登録してある場合、支払代行手段111は、登録してある振込先口座に対して上記の振込処理を実行する。
(S267)支払代行手段111は、S260で新たに追加した履歴情報113fのレコードに対する出金済登録(「出金」欄を「済」に設定)を実施する。また、支払代行手段111は、入金済登録及び出金済登録の両方が完了した日時を送金日時として履歴情報113fに記録する。
(S268)支払代行手段111は、上記のような入金及び出金についての処理が完了した手続を特定するためのユニークな支払代行IDを発行する。また、支払代行手段111は、支払代行IDを支払先情報113c及び請求先情報113dに紐付けて管理する。
(S269)支払代行手段111は、支払代行IDを含む完了通知を利用者端末102及び非加盟店端末103に送信する。S269の処理が完了すると、図21及び図22に示した一連の処理は終了する。
上記のように、第2実施形態では、非加盟店による要求に応じて非加盟店端末103にキーとなるハッシュ値が提供され、提供したハッシュ値と利用者端末102から取得されるハッシュ値との一致が確認される。また、ハッシュ値は、売買契約/役務提供契約61により生じた支払に対して発行される支払IDに基づいて生成される。そのため、ハッシュ値により、非加盟店、利用者、売買契約/役務提供契約61が紐付けられる。
また、非加盟店がカード会員であるため、クレジットカードに対応付けて管理される事前入金額を利用して送金するカード送金の仕組みを利用できる。また、カード利用額を引き落とすための引落口座の情報を利用できるため、口座振込を利用する場合でも、振込先口座についての情報を利用者が入力するなどの手間を省略できる。
また、一変形例として、支払金額の分を非加盟店の引落金額から差し引くことで実質的に支払を実行した形にする仕組みが考えられる。また、他の変形例として、支払の度に口座振込を実行するのではなく、一定期間の支払金額を蓄積し、毎月決まった日に総額を振り込む仕組みが考えられる。このような仕組みを適用することで、支払代行サービスの利用時にかかる手数料を低減しうる。
[2−5.システム構成の変形例]
これまで、カード決済システム101に支払代行手段111及びカード決済手段112が含まれることを前提に説明を進めてきた。しかし、支払代行サービスについての処理を主に実行する支払代行手段111と、カード決済についての処理を主に実行するカード決済手段112とを分けてもよい。
例えば、クレジットカード会社がカード決済手段112に相当するシステムを運営し、支払代行サービスを提供するサービス提供会社が支払代行手段111に相当するシステムを運営する運営形態などが考えられる。
上記のような運営形態に対応する場合、カード決済システム101は、例えば、図23に示すようなカード決済システム201と支払代行システム202とに分けられる。図23は、第2実施形態の一変形例に係るカード決済システム及び支払代行システムの一例を示したブロック図である。
図23に示すように、カード決済システム201は、記憶手段211、カード決済手段212、及びカード送金手段213を有する。ここで、記憶手段211には、会員情報211a及びストック情報211bが格納される。
カード決済手段212は、上述したカード決済手段112に対応する。カード送金手段213は、上述したカード送金手段114に対応する。会員情報211aは、上述した会員情報113aに対応する。ストック情報211bは、上述したストック情報113eに対応する。
支払代行システム202は、記憶手段221、及び支払代行手段222を有する。ここで、記憶手段221には、支払先情報221a、請求先情報221b、及び履歴情報221cが格納される。
支払代行手段222は、上述した支払代行手段111に対応する。支払先情報221aは、上述した支払先情報113cに対応する。請求先情報221bは、上述した請求先情報113dに対応する。履歴情報221cは、上述した履歴情報113fに対応する。
上記のように、カード決済システム201と支払代行システム202とに機能を分散し、両システムが連携して動作することで上述したカード決済システム101と同様の仕組みを実現できる。この変形例によれば、両システムを異なる運営者又は組織で運営することが可能になる。このような変形についても第2実施形態の技術的範囲に属する。
以上、本発明に係る第2実施形態について説明した。
<3.組合せについて>
上述した第1及び第2実施形態の仕組みは組合せ可能である。例えば、アプリ121aのポータル画面に、いずれの仕組みを利用するかを選択させる選択オブジェクトを表示し、利用者又は非加盟店が選択できるようにしてもよい。また、第2実施形態の仕組みに、非加盟店が発行した請求書画像をカード決済システム101に送信させ、カード決済システム101で確証チェックを実施する第1実施形態の仕組みを追加してもよい。このような組合せは、例えば、不正利用の抑制に寄与する。
なお、不正利用対策としては、例えば、3Dセキュアと呼ばれる認証技術を組み合わせる方法などを適用できる。また、サービス利用契約の締結時にカード会員の審査を行うなどの対策も不正利用の抑制に寄与しうる。また、支払代行サービスによる支払の限度額をクレジットカードの利用限度額より低く設定することで不正利用による損害を低減しうる。このように、上述した第1及び第2実施形態の技術に新たな仕組みを追加してもよい。こうした変形例についても本発明に係る実施形態の技術的範囲に属する。
以上、添付図面を参照しながら本発明に係る好適な実施形態について説明したが、本発明はここで開示した例に限定されない。当業者であれば、特許請求の範囲に記載された範疇において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと解される。