JP7419441B2 - 決済システム、決済方法、及びプログラム - Google Patents

Description

本開示は、決済システム、決済方法、及びプログラムに関する。

従来、決済サービスを利用するユーザの利便性を高めるための技術が検討されている。例えば、特許文献１には、店舗に配置されたクライアント装置でユーザが生体認証を実行した場合に、ユーザの取引情報に基づいて、ユーザの信頼性を確認する商取引システムが記載されている。特許文献１の商取引システムでは、ユーザが信頼できる場合に、商品の購入代金の後払いが許可されたり、購入代金の値引き額が大きくなったりする。

特開２０１０－１２２９５０号公報

しかしながら、特許文献１の商取引システムを導入しようとすると、生体認証に対応できるように、種々の店舗のクライアント装置を改修する必要があるので、非常にコストがかかる。この点は、特許文献１の商取引システムに限られず、決済サービス全般的に同様である。従来の技術では、決済サービスを導入するために、多数の装置に対して改修が発生するので、非常にコストがかかっていた。

本開示の目的の１つは、決済サービスを導入するためのコストを低減することである。

本開示に係る決済システムは、ユーザに対し、クレジットカード番号と同じ形式の決済番号を付与する付与部と、過去における前記ユーザの取引に関する取引情報に基づいて、前記ユーザの信頼性に関するスコアを計算する計算部と、前記決済番号に関する決済要求が受け付けられた場合に、前記スコアに基づいて、前記決済番号に関する番号決済を許可するか否かを判定する番号決済判定部と、前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記番号決済を実行する番号決済実行部と、を含む。

本開示によれば、決済サービスを導入するためのコストを低減できる。

決済システムの全体構成の一例を示す図である。 ユーザがＥＣサービスで商品を購入する流れの一例を示す図である。 ユーザがＥＣサービスで商品を購入する流れの一例を示す図である。 決済システムで実現される機能の一例を示す図である。 第１ユーザデータベースの一例を示す図である。 第２ユーザデータベースの一例を示す図である。 決済システムで実行される処理の一例を示す図である。 変形例３における機能ブロックの一例を示す図である。 変形例３の注文確認画面の一例を示す図である。 変形例６の決済システムの全体構成の一例を示す図である。

［１．決済システムの全体構成］
本開示に係る決済システムの実施形態の一例を説明する。本実施形態では、決済サービスと、ＥＣ（Electronic Commerce）サービスと、が連携する場合を例に挙げる。決済サービスは、ＥＣサービス以外の他のサービスと連携してもよいし、他のサービスとは特に連携せずに決済サービス内で全ての処理が完結してもよい。これらの一例は、後述の変形例で説明する。

図１は、決済システムの全体構成の一例を示す図である。例えば、決済システム１は、決済サーバ１０、ＥＣサーバ２０、及びユーザ端末３０を含む。決済サーバ１０、ＥＣサーバ２０、及びユーザ端末３０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続可能である。

決済サーバ１０は、決済サービスのサーバコンピュータである。例えば、決済サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

ＥＣサーバ２０は、ＥＣサービスのサーバコンピュータである。例えば、ＥＣサーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、パーソナルコンピュータ、タブレット端末、又はウェアラブル端末である。例えば、ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５を含む。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、タッチパネル又はマウス等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。

なお、記憶部１２，２２，３２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、コンピュータ読み取り可能な情報記憶媒体に記憶されたプログラムが、情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

また、決済システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、決済システム１は、ＥＣサーバ２０及びユーザ端末３０を含まずに、決済サーバ１０だけを含んでもよい。この場合、ＥＣサーバ２０及びユーザ端末３０は、決済システム１の外部に存在する。決済システム１は、決済サーバ１０と、ＥＣサーバ２０及びユーザ端末３０以外の他のコンピュータと、を含んでもよい。

［２．決済システムの概要］
本実施形態では、ユーザは、ＥＣサービスで利用可能な複数の決済方法（決済手段）のうちの何れかを利用して、ＥＣサービスで商品を購入する。決済方法は、支払方法（支払手段）ということもできる。決済方法自体は、種々の方法を利用可能であり、例えば、クレジットカード決済、銀行振込決済、銀行自動引き落とし決済、銀行口座以外の他の口座を利用した決済、暗号資産決済、電子マネー決済、ポイント決済、払込票決済（コンビニ決済）、又はウォレット決済であってもよい。

図２及び図３は、ユーザがＥＣサービスで商品を購入する流れの一例を示す図である。本実施形態では、ユーザがＥＣサービスに会員登録済みであるものとする。図２のように、ユーザがユーザ端末３０を操作してＥＣサーバ２０にアクセスすると、ＥＣサービスのログイン画面ＳＣ１が表示部３５に表示される。本実施形態では、各画面がブラウザ上で表示される場合を説明するが、各画面は、専用のアプリ上で表示されてもよい。

例えば、ユーザが、入力フォームＦ１０，Ｆ１１にユーザＩＤ及びパスワードを入力してボタンＢ１２を選択すると、ＥＣサービスへのログイン処理が実行される。ログイン処理が成功すると、ＥＣサービスのトップ画面ＳＣ２が表示部３５に表示される。ユーザは、トップ画面ＳＣ２から所望の商品を検索して買い物かごに入れる。ユーザが、買い物かごに入れられた商品を注文するための手続を進めると、注文確認画面ＳＣ３が表示部３５に表示される。

例えば、注文確認画面ＳＣ３には、ユーザが利用可能な決済方法の一覧が表示される。図２の例では、ユーザは、「クレジットカードＢ」及び「クレジットカードＤ」といった２枚のクレジットカードを、ＥＣサービスに登録している。これら２枚のクレジットカードは、物理的なカードである。注文確認画面ＳＣ３には、クレジットカードの名前、クレジットカードのブランドを示すアイコンＩ３０、及びクレジットカードのカード番号の一部が表示される。ユーザは、任意の決済方法のボタンＢ３１を選択して商品を注文する。

本実施形態では、ユーザは、決済サービスの１つである後払いサービスを利用できる。後払いサービスは、商品を注文した後に支払をするサービスである。以降、後払いサービスにおける決済を、後払い決済という。本実施形態では、後払い決済が払込票決済の一種である場合を説明するが、後払い決済は、払込票決済に限られない。例えば、後払い決済は、払込票ではなく、はがき等の他の媒体を利用した決済であってもよいし、電子メール等で通知される払込票番号を利用した決済であってもよい。

例えば、ユーザは、決済方法として後払い決済を選択するためには、後払いサービスの会員登録が必要であるものとする。ユーザがボタンＢ３２を選択すると、後払いサービスの会員登録をするための会員登録画面ＳＣ４が表示部３５に表示される。本実施形態では、決済サービスの事業者と、ＥＣサービスの事業者と、が同じであり、共通のユーザＩＤ及びパスワードが利用されるものとする。例えば、ユーザは、入力フォームＦ４０，Ｆ４１にユーザＩＤ及びパスワードを入力してボタンＢ４２を選択すると、当該入力されたユーザＩＤ及びパスワードの正当性が確認される。

例えば、ユーザＩＤ及びパスワードの正当性が確認されると、図３に移り、後払いサービスの会員登録が完了したことを示す登録完了画面ＳＣ５が表示部３５に表示される。例えば、ユーザがボタンＢ５０を選択すると、注文確認画面ＳＣ３に戻る。図３の注文確認画面ＳＣ３のように、後払いサービスの会員登録が完了すると、ユーザは、後払い決済を選択できるようになる。

図３の例では、後払い決済の表示と、クレジットカード決済の表示と、における基本的な項目は同じである。ただし、クレジットカード決済は、カード番号の一部が表示されるのに対し、後払い決済は、カード番号に相当する後払い番号が一切表示されない。また、クレジットカード決済は、クレジットカードのブランドを示すアイコンＩ３０が表示されるのに対し、後払い決済は、ブランドではなく、後払い決済であることを示すアイコンＩ３４が表示される。図３の例では、アイコンＩ３０，Ｉ３４は、文字列が示されているが、ブランド又は後払い決済であることを視覚的に理解できる図形等の他の情報が示されてもよい。

例えば、ユーザが後払い決済のボタンＢ３１を選択した後に、注文確定のボタンＢ３３を選択すると、後払い決済を実行するためのＳＭＳ（Short Message Service）認証が実行される。ユーザは、ユーザ端末３０に届いたメッセージをＳＭＳ画面ＳＣ６で確認する。ユーザは、ユーザ端末３０を操作して決済サーバ１０又はＥＣサーバ２０にアクセスし、メッセージに記載された確認コードを入力する。ＳＭＳ認証が成功すると、注文が完了したことを示す注文完了画面ＳＣ７が表示部３５に表示される。後払い決済では、クレジットカード決済と同様の分割払いが可能であってもよいし、クレジットカード決済と同様のショッピング枠が設定されてもよい。ショッピング枠は、ＥＣサービスにおけるユーザの利用状況に応じて変化してもよい。

本実施形態では、クレジットカード決済がＥＣサービスに導入された後に、後払い決済がＥＣサービスに導入されたものとする。更に、後払い決済の導入の際には、その時点で導入済みのクレジットカード決済の仕組みが流用されるものとする。このため、後払い決済の基本的な仕組みは、クレジットカード決済の基本的な仕組みと同じである。例えば、クレジットカード決済は、所定の形式を有するカード番号が利用される。ここでの形式とは、番号の体系である。例えば、番号の桁数や各桁が持つ意味は、形式に相当する。

後払い番号の形式自体は、一般的なクレジットカードのカード番号の形式であってよい。例えば、一般的なクレジットカードは、１４～１６桁の数字で構成される。最初の６桁の数字は、カード会社を識別可能な発行者識別番号（銀行識別番号）である。７桁目から最後の１つ手前の数字は、ユーザを識別可能な会員口座番号である。最後の数字は、チェックデジットである。後払い番号の形式も、この形式と同じである。

本実施形態では、後払い番号が発行されたからといって、物理的なクレジットカードが発行されるわけではないものとする。このため、後払い番号は、仮想的なクレジットカードのカード番号ということもできる。後払い番号の発行者識別番号は、カード会社の発行者識別番号と重複しないような番号帯が利用される。例えば、物理的なクレジットカードを発行するカード会社で、最初の６桁が「９９９９－９９」の番号帯を利用していなかったとすると、後払い番号は、最初の６桁が「９９９９－９９」になる。

なお、他の決済サービスで同様の後払いサービスが提供されている場合には、他の決済サービスとは重複しないような番号帯が利用されてもよい。例えば、他の事業者が提供する後払いサービスで、最初の６桁が「９９９９－９９」の番号帯が既に利用されていたとすると、決済システム１で発行される後払い番号は、最初の６桁が「８８８８－８８」になってもよい。他の事業者の後払いサービスと混同するおそれがない場合（例えば、ユーザＩＤ等の他の情報によって、本実施形態の後払いサービスと識別できる場合）には、後払い番号は、最初の６桁が「９９９９－９９」になってもよい。

本実施形態では、後払い番号がＥＣサービスだけで利用可能である場合を説明するが、後払い番号は、ＥＣサービス以外の他のサービスで利用可能であってもよい。後払い番号が他のサービスで利用可能である場合は、後述の変形例で説明する。なお、後払い番号は、ユーザに通知されないものとする。図３の例では、登録完了画面ＳＣ５には、後払いサービスの会員登録が完了したことは表示されるが、後払い番号は、全て伏せ字になっておりユーザに通知されない。

以上のように、本実施形態では、ＥＣサービスで導入済みのクレジットカード決済の仕組みを利用して、後払いサービスが導入されている。後払い番号は、クレジットカード番号と同じ形式の番号である。後払い決済の流れも、クレジットカード決済の流れと同様である。これにより、後払いサービス専用のシステムを新たに構築する必要がなくなるので、後払いサービスを導入するためのコストを低減できる。以降、決済システム１の詳細を説明する。

［３．決済システムで実現される機能］
図４は、決済システム１で実現される機能の一例を示す図である。

［３－１．決済サーバで実現される機能］
例えば、決済サーバ１０は、データ記憶部１００、付与判定部１０１、付与部１０２、取得部１０３、計算部１０４、後払い決済判定部１０５、パスワード認証部１０６、セキュリティコード認証部１０７、メッセージ認証部１０８、及び後払い決済実行部１０９を含む。データ記憶部１００は、記憶部１２により実現される。付与判定部１０１、付与部１０２、取得部１０３、計算部１０４、後払い決済判定部１０５、パスワード認証部１０６、セキュリティコード認証部１０７、メッセージ認証部１０８、及び後払い決済実行部１０９は、制御部１１により実現される。

［データ記憶部］
データ記憶部１００は、決済サービスを提供するために必要なデータを記憶する。本実施形態では、決済サービスのうち、主に、後払いサービスに必要なデータについて説明する。例えば、データ記憶部１００は、第１ユーザデータベースＤＢ１を記憶する。

図５は、第１ユーザデータベースＤＢ１の一例を示す図である。図５に示すように、第１ユーザデータベースＤＢ１は、後払いサービスのユーザに関する各種情報が格納されたデータベースである。例えば、第１ユーザデータベースＤＢ１には、ユーザＩＤ、パスワード、氏名、住所、電話番号、メールアドレス、後払い番号、有効期限、名義人、後払いサービスにおける取引情報、及びスコアが格納される。ユーザが後払いサービスの会員登録を済ませると、第１ユーザデータベースＤＢ１に新たなレコードが作成され、ユーザに関する各種情報が格納される。

ユーザＩＤは、ユーザを識別可能なユーザ識別情報の一例である。ユーザ識別情報は、ユーザＩＤに限られず、何らかの形でユーザを識別可能な情報であればよい。例えば、ユーザ識別情報は、電話番号又はメールアドレスといった他の情報であってもよい。本実施形態では、ＥＣサービス及び後払いサービスで互いに同じユーザＩＤ及びパスワードが利用される場合を説明するが、ＥＣサービス及び後払いサービスで互いに異なるユーザＩＤ及びパスワードが利用されてもよい。

後払い番号は、決済番号の一例である。このため、後払い番号について説明している箇所は、決済番号と読み替えることができる。決済番号は、クレジットカード決済の仕組みを利用して、番号決済を利用するための番号である。番号決済は、決済番号に関する決済である。番号決済は、クレジットカード決済以外の他の決済である。後払い決済は、番号決済の一例である。このため、後払い決済について説明している箇所は、番号決済と読み替えることができる。番号決済は、後払い決済以外の他の決済であってもよい。他の決済の一例は、後述の変形例で説明する。

本実施形態では、後払い番号には、仮想的なクレジットカードの有効期限及び名義人が関連付けられる。このため、決済番号は、仮想的なクレジットカードのカード番号ということもできる。仮想的なクレジットカードの有効期限及び名義人は、物理的なクレジットカードの有効期限及び名義人と同じ形式である。例えば、仮想的なクレジットカードの有効期限は、年と月の組み合わせである。仮想的なクレジットカードの名義人は、アルファベットの文字列である。

取引情報は、過去におけるユーザの取引に関する情報である。本実施形態では、ＥＣサービスにおける商品の購入が取引に相当する。更に、ＥＣサービスにおける全ての取引情報のうち、過去に実行された後払い決済に関する取引情報について説明するが、取引情報は、後述の変形例のように、後払い決済以外の他の決済に関する情報であってもよい。例えば、取引情報は、後払い決済が実行された日時、後払い決済の相手方の情報、及び後払い決済の金額を含む。取引情報は、後払い決済が実行されるたびに更新される。

なお、データ記憶部１００に記憶されるデータは、上記の例に限られない。データ記憶部１００は、決済サービスに必要なデータを記憶すればよい。例えば、データ記憶部１００は、後述のパスワード認証、セキュリティコード認証、及びメッセージ認証の各々で正解となるパスワード、セキュリティコード、及び確認コードの各々を記憶してもよい。正解となるパスワード、セキュリティコード、及び確認コードの各々は、決済サーバ１０以外の他のコンピュータで管理されてもよい。

［付与判定部］
付与判定部１０１は、予め定められた付与条件に基づいて、ユーザに対する後払い番号の付与を許可するか否かを判定する。付与条件は、後払い番号の付与を許可するか否かの判定基準となる条件である。付与条件は、ユーザに関する何らかの情報に関する条件であればよく、任意の条件を設定可能である。後払い番号の付与とは、後払い番号を発行すること、又は、発行済みの後払い番号を有効化することである。後払い番号の付与は、後述の付与部１０２により実行される。

本実施形態では、付与判定部１０１は、ユーザに関する情報であって、取引情報とは異なる他の情報に基づいて、ユーザに対する後払い番号の付与を許可するか否かを判定する。他の情報は、取引情報以外の任意の情報を利用可能である。他の情報の一例として、外部の信用情報機関から取得されるユーザの信用情報を説明するが、他の情報は、ユーザの信用情報に限られない。例えば、他の情報は、ＥＣサービスにおけるユーザの取引情報であってもよい。例えば、他の情報は、ＥＣサービス以外の他のサービスにおけるユーザの取引情報であってもよい。

例えば、付与判定部１０１は、外部の信用情報機関のシステムに対し、ユーザの信用情報を送信するように要求する。付与判定部１０１は、信用情報機関のシステムから取得されたユーザの信用情報に基づいて、後払い番号の付与を許可するか否かを判定する。付与判定部１０１は、ユーザの信用情報が基準以上の信頼性を示さない場合には、後払い番号の付与を許可しないと判定し、ユーザの信用情報が基準以上の信頼性を示す場合に、後払い番号の付与を許可すると判定する。

なお、付与判定部１０１による判定方法は、上記の例に限られない。付与判定部１０１は、ユーザに関する何らかの情報に基づいて、付与条件が満たされるか否かを判定すればよい。この情報は、ＥＣサービスにおける取引情報であってもよいし、ユーザの氏名、住所、職業、年収、ＳＮＳアカウント、又は何らかのサービスの利用実績であってもよい。付与判定部１０１は、付与条件が満たされないと判定された場合には、後払い番号の付与を許可せず、付与条件が満たされたと判定された場合に、後払い番号の付与を許可すればよい。

［付与部］
付与部１０２は、ユーザに対し、後払い番号を付与する。本実施形態では、ユーザが後払いサービスの会員登録を完了すると、付与部１０２が新たな後払い番号を発行する場合を説明するが、後払い番号は、会員登録時に発行されるのではなく、会員登録前に予め発行されていてもよい。例えば、付与部１０２は、ユーザＩＤと、後払い番号と、を予め関連付けておいてもよい。この場合、後払い番号を有効化するための有効化フラグをオンにすることが、後払い番号を付与することに相当してもよい。

本実施形態では、付与部１０２は、付与判定部１０１により後払い番号の付与を許可すると判定された場合に、ユーザに対し、後払い番号を付与する。付与部１０２は、付与判定部１０１により後払い番号の付与を許可すると判定されない場合には、ユーザに対し、後払い番号を付与しない。例えば、この場合、付与部１０２は、新たな後払い番号を発行しない。先述した有効化フラグが利用される場合には、付与部１０２は、有効化フラグをオンにしない。

なお、付与判定部１０１による判定が実行されなくてもよく、この場合には、決済サーバ１０は、付与判定部１０１を含まない。この場合、付与部１０２は、会員登録をしたユーザに対し、特段の審査を要することなく、無条件で後払い番号を付与する。例えば、ユーザが後払いサービスの会員登録を完了すると、付与部１０２は、無条件で即時に後払い番号を発行したり、無条件で即時に有効化フラグをオンにしたりする。更に、付与部１０２は、後払いサービスに会員登録することなく、無条件で即時に後払い番号を発行したり、無条件で即時に有効化フラグをオンにしたりしてもよい。即ち、ＥＣサービスに会員登録した時点で、後払い番号が付与されてもよい。

本実施形態では、付与部１０２は、ユーザＩＤと、後払い番号と、を関連付けることによって、ユーザに対し、後払い番号を付与する。ここでの関連付けるとは、２つの情報のうちの一方をキーにして他方を検索可能な状態にすることである。例えば、付与部１０２は、第１ユーザデータベースＤＢ１のうち、ユーザＩＤが格納されたレコードに後払い番号を格納することによって、ユーザＩＤと、後払い番号と、を関連付ける。付与部１０２は、このレコードに後払い番号を追加したり、このレコードに格納された有効化フラグをオンにしたりする。

例えば、付与部１０２は、ユーザＩＤと、物理的なクレジットカードには関連付けられない後払い番号と、を関連付けることによって、ユーザに対し、後払い番号を付与する。本実施形態では、後払い番号が、実在しない仮想的なクレジットカードのカード番号である場合を説明するが、後払い番号は、物理的なクレジットカードに関連付けられたカード番号であってもよい。この場合、物理的なクレジットカードには、通常のカード番号と、後払い番号と、の２つが関連付けられる。後払い番号は、物理的なクレジットカードに形成されてもよい。更に、現実の店舗では利用できないカードに後払い番号が形成されてもよい。このカードには、通常のカード番号は形成されないものとする。

本実施形態では、付与部１０２は、ユーザに対し、後払い番号のうちの少なくとも一部を通知することなく、後払い番号を付与する。ここでの通知とは、電子的な手段を利用して、後払い番号を出力することである。後払い番号は、一切通知されなくてもよいし、一部だけが通知されてもよい。例えば、後払い番号が１６桁だったとすると、１６桁のうちの１桁もユーザに通知されないようにしてもよいし、１桁～４桁程度の一部だけがユーザに通知されて、残りの部分がユーザに通知されないようにしてもよい。

図２の例では、ユーザが、後払いサービスの会員登録の手続を開始してから、後払いサービスの会員登録が完了するまでの間に、付与部１０２は、ユーザに対し、後払い番号を一切通知することなく、後払い番号を付与する。このため、図２の登録完了画面ＳＣ５を含む各画面では、後払い番号が表示されない。後払いサービスの会員登録の完了時に電子メール等のメッセージが送信される場合にも、このメッセージには、後払い番号が通知されないものとする。

なお、決済システム１では、後払い番号がユーザに通知されてもよい。本実施形態では、ユーザが後払い番号を入力する機会がないが、他のサービスで後払い番号を利用可能とする場合には、他のサービスで後払い番号を入力できるように、後払い番号がユーザに通知されてもよい。他にも例えば、原則として後払い番号がユーザに通知されないが、ユーザから特段の開示要求が受け付けられた場合に、後払い番号がユーザに通知されるようにしてもよい。

［取得部］
取得部１０３は、ユーザの取引情報を取得する。取得部１０３は、決済サービスを利用する多数のユーザのうち、後述の計算部１０４がスコアを計算するユーザの取引情報を取得する。本実施形態では、取引情報が第１ユーザデータベースＤＢ１に格納されているので、取得部１０３は、第１ユーザデータベースＤＢ１から、ユーザの取引情報を取得する。取引情報は、第１ユーザデータベースＤＢ１以外の他のデータベース、又は、決済サーバ１０以外の他のサーバコンピュータに格納されていてもよい。この場合、取得部１０３は、他のデータベース又は他のサーバコンピュータから、取引情報を取得する。

本実施形態では、定期的にスコアが計算される場合を説明するので、取得部１０３は、定期的に取引情報を取得する。取得部１０３は、スコアが計算されるタイミングで取引情報を取得すればよく、取引情報が取得されるタイミングは、本実施形態の例に限られない。例えば、後払い決済要求が受け付けられた後にスコアが計算される場合には、取得部１０３は、後払い決済要求が受け付けられた後に、取引情報を取得してもよい。

なお、後払い決済要求が受け付けられるタイミングも、本実施形態の例に限られず、任意のタイミングであってよい。例えば、ＥＣサービスにおける注文を確定するための確定要求がユーザ端末３０から受け付けられた後ではなく、その前に、後払い決済要求が受け付けられてもよい。他にも例えば、ユーザが注文を確定させた後に、決済方法を選択する場合には、確定要求が受け付けられてユーザが決済方法を選択した後に、後払い決済要求が受け付けられてもよい。

［計算部］
計算部１０４は、取得部１０３により取得された取引情報に基づいて、ユーザの信頼性に関するスコアを計算する。本実施形態では、スコアが数値で表現される場合を説明するが、スコアは、文字又は記号で表現されてもよい。また、本実施形態では、スコアの数値が高いほど信頼性が高い場合を説明するが、スコアと信頼性の間に相関関係があればよく、スコアの数値が低いほど信頼性が高くてもよい。

なお、取引情報と、スコアと、の関係を示すデータは、データ記憶部１００に記憶されているものとする。本実施形態では、このデータが数式形式である場合を説明するが、このデータは、テーブル形式であってもよいし、プログラムコードであってもよい。このデータは、取引情報とスコアの関係が学習された機械学習モデルであってもよい。計算部１０４は、取引情報と、上記データと、に基づいて、スコアを計算する。

例えば、計算部１０４は、予め定められたルールに基づいて、取引情報を数値化してスコアを計算する。このルールは、任意のルールを設定可能であり、例えば、個々の取引金額、取引金額の合計額、未払い金額、未払いの合計額、取引回数、取引頻度、未払い回数、未払い頻度、取引場所、又は利用中心地からの距離といったルールであってもよい。計算部１０４は、ルールに基づいて、これらの数値を計算してスコアを計算する。例えば、計算部１０４は、取引金額又はどの合計額が多く、かつ、未払い金額又はどの合計額が少ないほど、ユーザの信頼性が高くなるように、スコアを計算する。計算部１０４は、ユーザのスコアを、このユーザのユーザＩＤに関連付けて第１ユーザデータベースＤＢ１に格納する。

本実施形態では、計算部１０４は、定期的に、最新の取引情報に基づいて、スコアを計算する。例えば、計算部１０４は、１日に１回、スコアを計算する。スコアが計算される周期は、１日ごとではなく、任意の周期であってよい。例えば、計算部１０４は、半日ごと、数日ごと、１週間ごと、又は１ヶ月ごとに、スコアを計算してもよい。定期的にスコアが計算されることによって、ユーザがＥＣサービスで注文をする時点では、スコアの計算が完了されているものとする。

なお、計算部１０４は、不定期的にスコアを計算してもよい。例えば、計算部１０４は、ユーザがＥＣサービスにログインするたびにスコアを計算してもよい。例えば、計算部１０４は、ユーザがＥＣサービスで商品を注文する時に（即ち、後払い決済要求が受け付けられた時に）、その場でスコアを計算してもよい。計算部１０４は、後払い決済判定部１０５による判定が実行される時点でスコアの計算を完了すればよく、その他の任意のタイミングでスコアを計算可能である。

［後払い決済判定部］
後払い決済判定部１０５は、後払い番号に関する後払い決済要求が受け付けられた場合に、スコアに基づいて、後払い決済を許可するか否かを判定する。後払い決済要求は、後払い番号を実行するための要求である。後払い決済要求は、クレジットカード決済と同じ形式の要求である。後払い決済要求の形式は、クレジットカード決済のＡＰＩに準じた形式であればよい。本実施形態では、後払い決済要求は、ＥＣサーバ２０から送信される場合を説明するが、後払い決済要求は、ユーザ端末３０又は店舗の端末といった他のコンピュータから送信されてもよい。

本実施形態では、クレジットカード決済の決済要求と、後払い決済の決済要求と、を例に挙げる。以降、これらを、それぞれクレジットカード決済要求及び後払い決済要求という。先述したように、クレジットカード決済要求及び後払い決済要求は、互いに同じ形式である。この形式自体は、公知のクレジットカード決済のＡＰＩで定められた形式であってよい。即ち、クレジットカード決済要求及び後払い決済要求の各々に含まれるヘッダや実データ部分のデータ構造自体は、公知のデータ構造であってよい。

例えば、クレジットカード決済要求及び後払い決済要求は、１４桁～１６桁の数値、有効期限、及び名義人を含む。クレジットカード決済要求の場合、１４桁～１６桁の数値は、物理的なクレジットカードのカード番号を意味する。後払い決済要求の場合、１４桁～１６桁の数値は、後払い番号を意味する。データ構造としては、クレジットカード決済要求及び後払い決済要求は、互いに同じ形式であるが、１４桁～１６桁の数値の番号帯が異なるので、この番号帯によって、何れの決済要求であるかを区別できる。クレジットカード決済要求及び後払い決済要求には、決済額等の他の情報も含まれているものとする。

例えば、後払い決済判定部１０５は、クレジットカード決済要求及び後払い決済要求の各々に含まれる１４桁～１６桁の数値の番号帯に基づいて、何れの決済要求であるかを特定する。本実施形態では、後払い番号の番号帯が「９９９９－９９」であるものとする。後払い決済判定部１０５は、「９９９９－９９」の番号帯の決済要求であれば、後払い決済要求であると判定する。後払い決済判定部１０５は、後払い決済要求であると判定された場合に、後払い決済を許可するか否かを判定する。後払い決済判定部１０５は、他の番号帯の決済要求であれば、クレジットカード決済要求であると判定する。後払い決済判定部１０５は、クレジットカード決済要求であると判定された場合には、後払い決済を許可するか否かを判定しない。

例えば、後払い決済判定部１０５は、スコアが閾値以上であるか否かを判定し、当該判定結果に基づいて、後払い決済を許可するか否かを判定する。本実施形態では、スコアが示す数値が高いほど信頼性が高いので、後払い決済判定部１０５は、スコアが閾値未満であると判定された場合には、後払い決済を許可しないと判定し、スコアが閾値以上であると判定された場合には、後払い決済を許可すると判定する。閾値は、全ユーザで共通の固定値であってもよいし、ユーザの応じて定められていてもよい。

なお、スコアと信頼性の関係が逆の場合（スコアが示す数値が低いほど信頼性が高い場合）、後払い決済判定部１０５は、スコアが閾値以上であると判定された場合には、後払い決済を許可しないと判定し、スコアが閾値未満であると判定された場合には、後払い決済を許可すると判定すればよい。スコアが文字又は他の記号で表現される場合には、後払い決済判定部１０５は、スコアが、信頼性が相対的に低いことを示す文字又は記号であると判定された場合には、後払い決済を許可しないと判定し、信頼性が相対的に高いことを示す文字又は記号であると判定された場合には、後払い決済を許可すると判定すればよい。

本実施形態では、後払い決済判定部１０５は、注文確認画面ＳＣ３に対するユーザの操作によって後払い決済要求が受け付けられた場合に、後払い決済を許可するか否かを判定する。注文確認画面ＳＣ３は、決済画面の一例である。このため、注文確認画面ＳＣ３を記載した箇所は、決済画面と読み替えることができる。決済画面は、後払い決済を一例とする番号決済に関する場面である。決済画面は、後払い決済要求をするための画面、又は、決済方法を選択するための画面である。

例えば、後払い決済判定部１０５は、注文確認画面ＳＣ３において後払い決済が選択されて後払い決済要求が受け付けられた場合に、後払い決済を許可するか否かを判定する。ユーザの決済方法が後払い決済で固定されている場合には、後払い決済判定部１０５は、注文確認画面ＳＣ３に対するユーザの操作がなくても、後払い決済を許可するか否かを判定してもよい。他にも例えば、店舗のコンピュータから後払い決済要求が送信される場合には、後払い決済判定部１０５は、注文確認画面ＳＣ３に対するユーザの操作がなくても、後払い決済を許可するか否かを判定してもよい。

なお、クレジットカード決済要求が受け付けられた場合には、クレジットカード決済をするための処理が実行される。この処理自体は、公知の処理であってよい。例えば、データ記憶部１００には、カード番号における冒頭の６桁の発行者識別番号と、カード会社のサーバの識別情報（例えば、ＩＰアドレス）と、の関係を示すデータが記憶されている。決済サーバ１０は、クレジットカード決済要求に含まれるカード番号のうち、冒頭の６桁の発行者識別番号に関連付けられたカード会社のサーバに対し、与信等の一連の処理を要求する。決済サーバ１０は、カード会社のサーバから処理結果を受信すると、ＥＣサーバ２０に処理結果を転送する。

［パスワード認証部］
パスワード認証部１０６は、後払い決済に関する後払い決済要求が受け付けられた場合には、パスワード認証を省略し、クレジットカード決済に関するクレジットカード決済要求が受け付けられた場合には、パスワード認証を実行する。後払い決済要求は、第１決済要求の一例である。クレジットカード決済要求は、第２決済要求の一例である。このため、後払い決済要求について説明している箇所は、第１決済要求と読み替えることができる。クレジットカード決済要求について説明している箇所は、第２決済要求と読み替えることができる。

第１決済要求は、後払い決済を一例とする番号決済を実行するための要求である。第１決済要求は、第２決済要求と同じ形式の要求である。第１決済要求及び第２決済要求の形式は、クレジットカード決済のＡＰＩに準じた形式であればよい。第１決済要求及び第２決済要求は、原則として、同じデータ構造のデータが送信されることによって行われる。第１決済要求及び第２決済要求の違いは、原則として、カード番号又は後払い番号に相当する数値の番号帯である。本実施形態では、第１決済要求及び第２決済要求は、ＥＣサーバ２０から送信される場合を説明するが、第１決済要求及び第２決済要求は、ユーザ端末３０又は店舗の端末といった他のコンピュータから送信されてもよい。

パスワード認証は、ユーザが予め登録したパスワードを利用した認証である。予め登録されたパスワードと、ユーザが入力したパスワードと、が一致しない場合には、パスワード認証が成功せず、これらが一致する場合に、パスワード認証が成功する。本実施形態では、物理的なクレジットカードに関連付けられたパスワードを利用した３Ｄセキュアと呼ばれるパスワード認証を例に挙げるが、パスワード認証は、他の名前で呼ばれてもよい。例えば、パスワード認証は、決済サービスにログインするためのパスワード、又は、その他のパスワードが利用されてもよい。

［セキュリティコード認証部］
セキュリティコード認証部１０７は、後払い決済要求が受け付けられた場合には、セキュリティコード認証を省略し、クレジットカード決済要求が受け付けられた場合には、ユーザに対し、セキュリティコード認証を実行する。セキュリティコード認証は、物理的なクレジットカードに形成されたセキュリティコード（例えば、裏面に印刷された２桁又は３桁のコード）を利用した認証である。物理的なクレジットカードに形成されたセキュリティコードと、ユーザが入力したセキュリティコードと、が一致しない場合には、セキュリティコード認証が成功せず、これらが一致する場合に、セキュリティコード認証が成功する。

［メッセージ認証部］
メッセージ認証部１０８は、メッセージ認証部１０８は、後払い決済要求が受け付けられた場合に、ユーザ端末との間でメッセージ認証を実行する。メッセージ認証は、認証情報を含むメッセージを利用した認証である。メッセージに含まれる認証情報と、ユーザが入力した認証情報と、が一致しない場合には、メッセージ認証が成功せず、これらが一致する場合に、メッセージ認証が成功する。

本実施形態では、ＳＭＳ認証がメッセージ認証に相当する場合を説明するが、メッセージ認証は、他の種類であってよく、例えば、電子メール、メッセージアプリ、又はＳＮＳを利用した認証であってもよい。また、メッセージ認証で利用される認証情報は、図３で説明した確認コードに限られない。例えば、メッセージに含まれるリンクの引数の中に認証情報が埋め込まれていてもよい。この場合、ユーザがリンクを選択すれば、確認コード等の情報を手入力することなく、メッセージ認証が完了する。

本実施形態では、メッセージ認証部１０８が、後払い決済要求が受け付けられた後であり、かつ、後払い決済が実行される前に、メッセージ認証を実行する場合を説明するが、メッセージ認証部１０８は、後払い決済の実行後に、メッセージ認証を実行してもよい。この場合、所定の期間までにメッセージ認証が完了しなければ、後払い決済がキャンセルされてもよい。

［後払い決済実行部］
後払い決済実行部１０９は、後払い決済判定部１０５により後払い決済を許可すると判定された場合に、後払い決済を実行する。後払い決済実行部１０９は、後払い決済判定部１０５により後払い決済を許可しないと判定された場合には、後払い決済を実行しない。後払い決済を実行するとは、後払い決済に必要な少なくとも一部の処理を実行することである。

後払い決済自体は、種々の処理によって実行可能である。例えば、本実施形態のように、後払い決済が払込票決済の一種である場合には、後払い決済実行部１０９は、払込票に相当する収納情報を生成する処理、収納代行会社に収納情報を送信する処理、払込票のデータを生成する処理、払込票を印刷する処理、払込票を郵送するための情報を出力する処理、又はこれらの組み合わせを実行することによって、後払い決済を実行する。

本実施形態では、後払い決済実行部１０９は、後払い決済判定部１０５により後払い決済を許可すると判定され、かつ、メッセージ認証が成功した場合に、後払い決済を実行する。後払い決済実行部１０９は、後払い決済判定部１０５により後払い決済を許可しないと判定された場合、又は、メッセージ認証が成功しなかった場合には、後払い決済を実行しない。

［３－２．ＥＣサーバで実現される機能］
例えば、ＥＣサーバ２０は、データ記憶部２００、サービス提供部２０１、及び表示制御部２０２を含む。データ記憶部２００は、記憶部２２により実現される。サービス提供部２０１及び表示制御部２０２は、制御部２１により実現される。

[データ記憶部]
データ記憶部２００は、ＥＣサービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、第２ユーザデータベースＤＢ２を記憶する。

図６は、第２ユーザデータベースＤＢ２の一例を示す図である。第２ユーザデータベースＤＢ２は、ＥＣサービスのユーザに関する各種情報が格納されたデータベースである。例えば、第２ユーザデータベースＤＢ２には、ユーザＩＤ、パスワード、氏名、住所、電話番号、メールアドレス、決済方法情報、及びＥＣサービスにおける取引情報が格納される。ユーザがＥＣサービスの会員登録を済ませると、第２ユーザデータベースＤＢ２に新たなレコードが作成され、ユーザに関する各種情報が格納される。

決済方法情報は、ユーザがＥＣサービスに登録した決済方法に関する情報である。例えば、ユーザがＥＣサービスにクレジットカードを登録した場合には、決済方法情報は、クレジットカードのカード番号、有効期限、及び名義人を示す。本実施形態では、ユーザは、複数のクレジットカードをＥＣサービスに登録できるものとする。このため、ユーザが後払いサービスの会員登録を完了して後払い番号が発行されたとしても、クレジットカードを追加する流れと同じ流れで、クレジットカード番号の１つであるかのように、後払い番号を追加できる。

例えば、ユーザが後払いサービスに会員登録をした場合には、決済方法情報は、後払い番号、有効期限、及び名義人を示す。これらの情報は、後払いサービスの会員登録後に、決済サーバ１０からＥＣサーバ２０に対して送信されるものとする。決済サービス及びＥＣサービスでユーザＩＤが共通なので、ＥＣサーバ２０は、どのユーザの後払い番号等であるかを特定できる。ＥＣサーバ２０は、当該特定されたユーザのユーザＩＤに可憐付けて、後払い番号等の情報を、第２ユーザデータベースＤＢ２に格納する。

例えば、ユーザがＥＣサービスに銀行口座を登録した場合には、決済方法情報は、銀行口座の金融機関コード、支店名、及び口座番号を示す。後払いサービスを利用するユーザの決済方法情報は、後払い番号、有効期限、及び名義人を示す。ＥＣサービスで他の決済方法を利用可能である場合には、他の決済方法に関する情報が格納される。取引情報は、ＥＣサービスで購入された商品、利用金額、及び利用日時といった情報を含む。ユーザがＥＣサービスを利用するたびに、取引情報が更新される。

［サービス提供部］
サービス提供部２０１は、ＥＣサービスを提供する。ＥＣサービスの提供方法自体は、公知の種々の方法を利用可能である。例えば、サービス提供部２０１は、ユーザ端末３０から、商品を注文するための注文要求を受け付ける。サービス提供部２０１は、ユーザが選択した決済に必要なデータを、決済サーバ１０に送信する。サービス提供部２０１は、決済サーバ１０から、決済が完了したことを示す通知を受信した場合に、取引情報を生成して第２ユーザデータベースＤＢ２に格納する。

例えば、サービス提供部２０１は、ユーザがクレジットカード決済を選択した場合には、決済サーバ１０に対し、クレジットカード決済要求を送信する。クレジットカード決済要求には、第２ユーザデータベースに格納されたユーザのクレジットカードのカード番号、有効期限、及び名義人が含まれる。サービス提供部２０１は、ユーザが後払い決済を選択した場合には、決済サーバ１０に対し、後払い決済要求を送信する。後払い決済要求には、第２ユーザデータベースに格納されたユーザの後払い番号、有効期限、及び名義人が含まれる。

例えば、クレジットカード決済及び後払い決済以外の他の決済方法に決済サービスが対応している場合、例えば、サービス提供部２０１は、ユーザが他の決済方法を選択すると、他の決済方法の決済方法情報に基づいて、決済サーバ１０に対し、他の決済方法を実行するための決済要求を送信する。

［表示制御部］
表示制御部２０２は、ＥＣサービスに関する各種画面を、ユーザ端末３０に表示させる。例えば、表示制御部２０２は、ユーザに対し、後払い番号のうちの少なくとも一部を通知することなく、後払い決済要求をするための注文確認画面ＳＣ３を表示させる。本実施形態では、表示制御部２０２は、後払い番号が一切通知されない注文確認画面ＳＣ３を表示させる。

例えば、表示制御部２０２は、ユーザ端末３０に対し、注文確認画面ＳＣ３の表示データを送信することによって、注文確認画面ＳＣ３を表示させる。表示データは、何らかの画面を表示させるためのデータであればよく、例えば、ＨＴＭＬデータである。ブラウザではなく、ＥＣサービス専用のアプリ上で注文確認画面ＳＣ３を表示させる場合には、表示制御部２０２は、アプリで表示可能な形式の表示データを送信すればよい。

例えば、表示制御部２０２は、後払い決済と、他の決済方法と、の中からユーザによる選択を受け付けるための注文確認画面ＳＣ３に、後払い決済と、他の決済方法と、の各々を区別して表示させる。ここでの区別とは、後払い決済であることを示す第１情報と、他の決済方法であることを示す第２情報と、を注文確認画面ＳＣ３で表示させることである。図３の例では、表示制御部２０２は、アイコンＩ３０，Ｉ３４によって、これらを区別するので、アイコンＩ３４が第１情報に相当し、アイコンＩ３０が第２情報に相当する。

なお、後払い決済と、他の決済方法と、を区別する方法は、アイコンＩ３０，Ｉ３４を利用した方法に限られない。表示制御部２０２は、後払い決済に関する情報と、他の決済方法に関する情報と、を視覚的に何らかの形で異ならせるようにすればよい。例えば、表示制御部２０２は、後払い決済であることを示す第１文字列と、他の決済方法であることを示す第２文字列と、を表示させることによって、これらを区別してもよい。他にも例えば、後払い決済を選択するためのボタンＢ３１と、クレジットカード決済を選択するためのボタンＢ３１と、の色によって、これらを区別してもよい。

［３－３．ユーザ端末で実現される機能］
例えば、ユーザ端末３０は、データ記憶部３００、表示制御部３０１、及び操作受付部３０２を含む。データ記憶部３００は、記憶部３２により実現される。表示制御部３０１及び操作受付部３０２は、制御部３１により実現される。

[データ記憶部]
データ記憶部３００は、決済サービス及び定期支払サービスの各々を利用するために必要なデータを記憶する。例えば、データ記憶部３００は、決済サービス及び定期支払サービスの各々のアプリケーションを記憶する。

［表示制御部］
表示制御部３０１は、図２及び図３で説明した各画面を表示部３５に表示させる。

［操作受付部］
操作受付部３０２は、図２及び図３で説明した各画面における操作を受け付ける。

［４．決済システムで実行される処理］
図７は、決済システム１で実行される処理の一例を示す図である。この処理は、制御部１１，２１，３１がそれぞれ記憶部１２，２２，３２に記憶されたプログラムに従って動作することによって実行される。図７では、ユーザが、ＥＣサービスにログインし、買い物かごに入れた商品を注文する手続を進めた後に、注文確認画面ＳＣ３からボタンＢ３２が選択された場合の処理が示されている。

図７のように、ユーザ端末３０は、決済サーバ１０との間で、会員登録画面ＳＣ４を表示させるための処理を実行する（Ｓ１）。会員登録画面ＳＣ４は、注文確認画面ＳＣ３ではなく、トップ画面ＳＣ２等の他の画面から表示されるようにしてもよい。会員登録画面ＳＣ４は、ＥＣサービスのドメイン上で表示されてもよいが、本実施形態では、決済サービスのドメイン上で表示されるものとする。ユーザ端末３０は、決済サーバ１０との間で、ユーザＩＤ及びパスワードの正当性を確認するための処理を実行する（Ｓ２）。

Ｓ２では、ユーザ端末３０は、決済サーバ１０に対し、入力フォームＦ４０，Ｆ４１に入力されたユーザＩＤ及びパスワードを送信する。決済サーバ１０は、ユーザＩＤ及びパスワードを受信すると、これらの正当性を確認する。この時点では、第１ユーザデータベースＤＢ１にユーザＩＤ及びパスワードが格納されていないので、決済サーバ１０は、ＥＣサービス及び決済サービスの事業者が管理する他のデータベースを利用して、ユーザＩＤ及びパスワードの正当性を確認する。他のデータベースには、正解となるユーザＩＤ及びパスワードが格納されているものとする。

決済サーバ１０は、ユーザＩＤ及びパスワードの正当性を確認すると、外部の信用情報機関のシステムに対し、ユーザの信用情報を問い合わせる（Ｓ３）。Ｓ３では、決済サーバ１０は、外部の信用情報機関のシステムに対し、氏名、住所、及び電話番号といったユーザを識別可能な情報を送信する。これらの情報は、先述した他のデータベースに格納されているものとする。外部の信用情報機関のシステムは、決済サーバ１０から受信した情報に基づいて、ユーザを特定して信用情報を決済サーバ１０に送信する。信用情報自体は、種々の情報を利用可能である。

決済サーバ１０は、ユーザの信用情報に基づいて、後払い番号を付与するか否かを判定する（Ｓ４）。Ｓ４では、決済サーバ１０は、信用情報が示すユーザの信頼性が所定の基準未満である場合には、後払い番号を付与しないと判定し、この信頼性が基準以上である場合に、後払い番号を付与すると判定する。後払い番号を付与しないと判定された場合（Ｓ４：Ｎ）、本処理は終了する。この場合、ユーザ端末３０にはエラーメッセージが表示され、後払いサービスの会員登録は完了しない。ユーザは、後払い決済以外の他の決済方法を利用して、商品を注文する。

Ｓ４において、後払い番号を付与すると判定された場合（Ｓ４：Ｙ）、決済サーバ１０は、クレジットカード番号と同じ形式の後払い番号を発行し、ユーザに対し、当該新たに発行された後払い番号を付与する（Ｓ５）。Ｓ５では、決済サーバ１０は、発行済みの後払い番号と重複しないように、最初の６桁が「９９９９－９９」の後払い番号を発行する。決済サーバ１０は、第１ユーザデータベースＤＢ１に新たなレコードを作成し、当該レコードに、ユーザＩＤや後払い番号等の情報を格納する。決済サーバ１０は、後払い番号等の情報を、ＥＣサーバ２０に送信する。ＥＣサーバ２０は、後払い番号等の情報を、第２ユーザデータベースＤＢ２に格納する。

以上の処理により、後払いサービスへの会員登録が完了し、ユーザは、ＥＣサービスで後払い決済を選択できるようになる。決済サーバ１０は、第１ユーザデータベースＤＢ１に格納された取引情報に基づいて、スコアを計算する（Ｓ６）。Ｓ６では、決済サーバ１０は、ユーザごとに、当該ユーザの取引情報と、スコアの計算式と、に基づいて、このユーザのスコアを計算する。決済サーバ１０は、Ｓ６の処理を定期的に実行し、第１ユーザデータベースＤＢ１に格納されたスコアを更新する。

ユーザ端末３０は、ＥＣサーバ２０との間で、注文確認画面ＳＣ３を表示させるための処理を実行する（Ｓ７）。Ｓ７では、ＥＣサーバ２０は、第２ユーザデータベースＤＢ２に格納された決済方法情報に基づいて、カード番号の最初の１桁でブランドを特定し、当該特定されたブランドに応じたアイコンＩ３０を選択する。ＥＣサーバ２０は、カード番号の最初の６桁が「９９９９－９９」であれば、後払い決済を示すアイコンＩ３４を選択する。ＥＣサーバ２０は、これらのアイコンＩ３０，Ｉ３４を含む注文確認画面ＳＣ３の表示データを生成してユーザ端末３０に送信する。

ユーザ端末３０は、ユーザがボタンＢ３３を選択すると、ＥＣサーバ２０に対し、注文要求を送信する（Ｓ８）。ＥＣサーバ２０は、ユーザ端末３０から注文要求を受信すると（Ｓ９）、ＥＣサーバ２０は、決済サーバ１０に対し、ユーザが選択した決済方法に応じた決済要求を送信する（Ｓ１０）。Ｓ１０では、ＥＣサーバ２０は、第２ユーザデータベースＤＢ２に格納された決済方法情報を含む決済要求を送信する。

決済サーバ１０は、決済要求を受信すると（Ｓ１１）、ユーザが選択した決済方法を特定する（Ｓ１２）。Ｓ１２では、決済サーバ１０は、決済要求に含まれる情報に基づいて、クレジットカード決済、後払い決済、又はその他の決済が特定される。クレジットカード決済及び後払い決済は、基本的な形式は同じなので、決済サーバ１０は、上６桁の番号帯によって何れが選択されたかを特定する。その他の決済は、クレジットカード決済及び後払い決済とは異なる形式なので、決済サーバ１０は、Ｓ１１で受信した決済要求の形式に基づいて、その他の決済を特定する。

Ｓ１２において、クレジットカード決済が特定された場合（Ｓ１２：クレジットカード決済）、決済サーバ１０は、必要に応じてパスワード認証及びセキュリティコード認証を実行して、クレジットカード決済を実行し（Ｓ１３）、本処理は終了する。パスワード認証、セキュリティコード認証、及びクレジットカード決済が実行される流れは、先述した通りである。

Ｓ１２において、後払い決済が特定された場合（Ｓ１２：後払い決済）、決済サーバ１０は、第１ユーザデータベースＤＢ１に格納されたユーザのスコアに基づいて、後払い決済を実行するか否かを判定する（Ｓ１４）。後払い決済を実行しないと判定された場合（Ｓ１４：Ｎ）、本処理は終了する。この場合、ユーザ端末３０にはエラーメッセージが表示され、後払い決済は完了しない。ユーザは、後払い決済以外の他の決済方法を利用して、商品を注文する。

Ｓ１４において、後払い決済を実行すると判定された場合（Ｓ１４：Ｙ）、決済サーバ１０は、ユーザ端末３０との間で、ＳＭＳ認証を実行する（Ｓ１５）。Ｓ１５におけるＳＭＳ認証の流れは、先述した通りである。決済サーバ１０は、ＳＭＳ認証が成功すると、後払い決済を実行し（Ｓ１６）、本処理は終了する。Ｓ１６では、決済サーバ１０は、ユーザ宛てに払込票を郵送するための処理を実行することによって、後払い決済を実行する。決済サーバ１０は、Ｓ１６の処理の完了をＥＣサーバ２０に送信すると、ＥＣサーバ２０は、注文を確定するための処理を実行する。

Ｓ１２において、その他の決済が特定された場合（Ｓ１２：その他）、決済サーバ１０は、その他の決済を実行し（Ｓ１７）、本処理は終了する。

本実施形態の決済システム１は、クレジットカード番号と同じ形式の後払い番号の後払い決済要求が受け付けられた場合に、ユーザのスコアに基づいて、後払い番号に関する後払い決済を許可するか否かを判定する。決済システム１は、後払い決済を許可すると判定された場合に、後払い決済を実行する。これにより、クレジットカード決済の仕組みを流用して後払いサービスを導入できるので、後払いサービスを導入するコストを低減できる。例えば、ＥＣサービスでは、複数枚のクレジットカードを登録できるようになっているので、その１つとして、後払い番号を登録することによって、既存の仕組みを流用できる。更に、後払い決済が実行される前に、ユーザのスコアに基づいて後払い決済を許可するか否かが判定されるので、商品の代金を支払わない悪意のあるユーザに対して後払い決済が許可されることを防止できる。後払い番号の付与時にユーザの信頼性を確認することも考えられるが、悪意のあるユーザが、その時点では信頼性のあるユーザのふりをして、信頼性のチェックをすり抜ける可能性がある。決済システム１は、後払い決済の実行時に、ユーザの信頼性をチェックするので、悪意のあるユーザによる後払い決済の利用を確実に防止できる。

また、決済システム１は、ユーザに関する情報であって、取引情報とは異なる他の情報に基づいて、ユーザに対する後払い番号の付与を許可するか否かを判定する。これにより、悪意のあるユーザに対し、後払い番号が付与されることを防止できる。例えば、無条件で即時に後払い番号を付与することも考えられるが、悪意のあるユーザの取引情報がある程度蓄積されるまでは、不正行為を防止できない可能性がある。この点、実施形態のように、外部の信用情報業者のシステムから取得した信用情報等の他の情報に基づいて、後払い番号の付与を許可するか否かを判定することによって、悪意のあるユーザによる不正行為を確実に防止できる。

また、決済システム１は、ユーザＩＤと、物理的なクレジットカードには関連付けられない後払い番号と、を関連付けることによって、ユーザに対し、後払い番号を付与する。これにより、後払い決済のために物理的なクレジットカードを発行する手間を省くことができる。

また、決済システム１は、ユーザに対し、後払い番号のうちの少なくとも一部を通知することなく、後払い番号を付与して注文確認画面ＳＣ３を表示させ、後払い決済における一連の処理を実行する。これにより、悪意のある第三者に対し、後払い番号が漏洩することを防止できる。例えば、後払い番号がＥＣサービスだけで利用できる専用の番号である場合、ユーザが後払い番号を知らなくても、ＥＣサービス又は決済サービス側で後払い番号を管理していれば、後払い決済を実行できる。このため、正当なユーザの利便性を低下させることなく、後払い決済を実行できる。

また、決済システム１では、取引情報は、過去に実行された後払い決済に関する情報である。これにより、過去に実行された後払い決済に応じたスコアを計算できるので、ユーザの信頼性を正確に評価し、悪意のあるユーザによる後払い決済の利用を確実に防止できる。例えば、後払い決済以外の他の取引に関する取引情報に基づいてスコアを計算することも可能であるが、悪意のあるユーザが、他の取引では正当なユーザのふりをしている場合には、悪意のあるユーザによる後払い決済を防止できない可能性があるが、実際に発生した後払い決済に応じたスコアを計算することによって、実際に発生した後払い決済に応じた信頼性を評価できる。

また、決済システム１は、後払い決済要求が受け付けられた場合には、パスワード認証を省略し、クレジットカード決済要求が受け付けられた場合には、パスワード認証を実行する。これにより、クレジットカード決済ほどには後払い決済のセキュリティ性を要求しない場合に、不要な認証を省略できるので、ユーザの利便性が高まる。例えば、後払い決済は、高額決済には対応せずに、クレジットカード決済は、高額決済に対応可能だったとする。この場合、後払い決済で不正が起きたとしても、被害額が低額で済むので、パスワード認証を省略することによって、セキュリティ性よりもユーザの利便性を重視できる。後払い決済用のパスワードを管理する手間を軽減することもできる。

また、決済システム１は、後払い決済要求が受け付けられた場合には、セキュリティコード認証を省略し、クレジットカード決済要求が受け付けられた場合には、セキュリティコード認証を実行する。これにより、クレジットカード決済ほどには後払い決済のセキュリティ性を要求しない場合に、不要な認証を省略できるので、ユーザの利便性が高まる。例えば、後払い決済は、高額決済には対応せずに、クレジットカード決済は、高額決済に対応可能だったとする。この場合、後払い決済で不正が起きたとしても、被害額が低額で済むので、セキュリティコード認証を省略することによって、セキュリティ性よりもユーザの利便性を重視できる。後払い決済用のセキュリティコードを管理する手間を軽減することもできる。

また、決済システム１は、注文確認画面ＳＣ３に、後払い決済と、他の決済方法と、の各々を区別して表示させる。これにより、ユーザが、注文確認画面ＳＣ３上で後払い決済と他の決済方法を確認しやすくなるので、ユーザの利便性が高まる。例えば、クレジットカード決済の仕組みを利用して後払い決済を導入すると、ユーザインタフェース上も、クレジットカード決済と後払い決済が似てしまう可能性があるが、アイコンＩ３０，Ｉ３４によって後払い決済とクレジットカード決済を区別できるので、ユーザが後払い決済を利用しようとして、誤ってクレジットカード決済を選択することを防止できる。逆に、ユーザがクレジットカード決済を利用しようとして、誤って後払い決済を選択することも防止できる。

また、決済システム１は、後払い決済要求が受け付けられた場合に、ユーザ端末３０との間でメッセージ認証を実行する。これにより、ユーザになりすましてログインした第三者が後払い決済を利用するといったことを防止できるので、セキュリティが高まる。

［５．変形例］
なお、本開示は、以上に説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

［５－１．変形例１］
例えば、実施形態では、過去に実行された後払い決済の取引情報に基づいて、スコアが計算される場合を説明した。取引情報は、後払いサービス以外の他のサービスの取引情報であってもよい。例えば、決済サービスが提供する一連のサービスのうち、後払いサービス以外の他のサービスの取引情報に基づいて、スコアが計算されてもよい。例えば、決済サービス以外の他のサービスの取引情報に基づいて、スコアが計算されてもよい。

後払いサービスは、第１サービスの一例である。後払いサービス以外の他のサービスは、第２サービスの一例である。このため、後払いサービスについて説明している箇所は、第１サービスと読み替えることができる。他のサービスについて説明している箇所は、第２サービスと読み替えることができる。第１サービス及び第２サービスの組み合わせは、任意の組み合わせであってよい。第１サービスの事業者と、第２サービスの事業者と、は互いに同じであってもよいし、互いに異なってもよい。

変形例１では、第２サービスの一例として、ＥＣサービスを説明する。ユーザは、後払いサービスを開始する前に、クレジットカード決済等を利用して、ＥＣサービスをある程度利用しているものとする。第２ユーザデータベースＤＢ２には、ユーザが後払いサービスを開始する前のＥＣサービスの取引情報も格納されている。変形例１の取得部１０３は、ユーザＩＤに基づいて、後払い決済に関する後払いサービスとは異なるＥＣサービスにおける取引情報を取得する。

例えば、取得部１０３は、ＥＣサーバ２０に対し、スコアの計算対象となるユーザの取引情報を要求する。ＥＣサーバ２０は、第２ユーザデータベースＤＢ２を参照し、決済サーバ１０からの要求に応じて、ＥＣサービスにおけるユーザの取引情報を送信する。取得部１０３は、ＥＣサーバ２０から、ＥＣサービスにおけるユーザの取引情報を取得する。

変形例１では、実施形態と同様に、決済サービスのユーザＩＤと、ＥＣサービスのユーザＩＤと、が同じである場合を説明するが、これらのユーザＩＤが異なる場合には、決済サーバ１０及びＥＣサーバ２０の少なくとも一方に、これらのユーザＩＤの対応関係が保持されているものとする。決済サーバ１０及びＥＣサーバ２０の少なくとも一方は、この対応関係に基づいて、どのユーザの取引情報を取得すればよいかを特定できる。

変形例１の計算部１０４は、ＥＣサービスにおける取引情報に基づいて、スコアを計算する。ＥＣサービスの取引情報がスコアの計算で利用される点で実施形態とは異なるが、スコアの計算方法自体は、実施形態と同様であってよい。例えば、計算部１０４は、ＥＣサービスの取引情報を数値化し、当該数値を計算式に代入することによって、スコアを計算する。例えば、計算部１０４は、ユーザの取引金額が多く、かつ、取引が正常に完了した件数が多いほど、ユーザの信頼性が高くなるように、スコアを計算する。

変形例１の決済システム１は、ＥＣサービスにおける取引情報に基づいて、スコアを計算する。これにより、後払いサービスにおける利用実績が無い又は少ないユーザだったとしても、他のサービスにおける取引を考慮して正確なスコアを計算できる。例えば、後払いサービスを利用し始めたユーザだったとしても、このユーザの信頼性を評価して後払い決済を実行するか否かを判定できる。

［５－２．変形例２］
例えば、変形例１では、ＥＣサービスといった１つの第２サービスの取引情報に基づいて、スコアが計算される場合を説明したが、取得部１０３は、複数の第２サービスの各々における取引情報を取得してもよい。例えば、決済サービスが、ＥＣサービス、旅行予約サービス、金融サービス、通信サービス、及び電子書籍サービスといった５つの第２サービスと連携している場合には、取得部１０３は、これら５つの第２サービスの各々の取引情報を取得してもよい。

変形例２では、上記５つのサービスが、同じ事業者により提供されるものとする。更に、上記５つのサービスで、共通のユーザＩＤが利用されるものとする。後払いサービスにおけるユーザＩＤも共通なので、あるユーザのユーザＩＤによって、上記５つのサービスにおける、このユーザの取引情報を取得できる。

計算部１０４は、複数の第２サービスの各々における取引情報に基づいて、スコアを計算する。複数の第２サービスの各々の取引情報がスコアの計算で利用される点で実施形態とは異なるが、スコアの計算方法自体は、実施形態で説明した通りである。例えば、計算部１０４は、第２サービスごとに、ユーザのスコアを計算し、５つの第２サービスの各々のスコアの合計値又は平均値を、最終的なスコアとして計算してもよい。計算部１０４は、５つの第２サービスの各々の取引情報を数値化して計算式に代入し、１つのスコアを計算してもよい。

変形例２の決済システム１は、複数の第２サービスの各々における取引情報を取得し、計算部１０４は、複数の第２サービスの各々における取引情報に基づいて、スコアを計算する。これにより、複数の第２サービスの各々におけるユーザの取引を総合的に考慮して、正確なスコアを計算できる。

［５－３．変形例３］
例えば、番号決済は、クレジットカード決済以外の他の決済であればよく、後払い決済に限られない。番号決済では、クレジットカード以外の他の決済方法を利用した決済であればよい。変形例３では、後払い決済以外にも、銀行自動引き落とし決済と、暗号資産決済と、が番号決済として利用可能である場合を例に挙げる。即ち、変形例３では、３種類の番号決済が可能であるものとする。

銀行自動引き落とし決済は、銀行口座から利用額が自動的に引き落とされる決済である。即ち、銀行自動引き落とし決済は、決済方法として銀行口座を利用する決済である。銀行自動引き落とし決済は、銀行口座が利用されるという点でクレジットカード決済と似ているが、クレジットカード決済は、自動引き落としまでに１ヶ月～２ヶ月程度要するのに対し、銀行自動引き落とし決済は、原則として、自動引き落としが即時に実行される点で異なる。

暗号資産決済は、暗号資産を利用した決済である。即ち、暗号資産決済は、決済方法として暗号資産を利用する決済である。変形例３では、ＥＣサービス及び決済サービスの事業者が暗号資産サービスも提供するものとする。更に、暗号資産サービスは、ＥＣサービス及び決済サービスと共通のユーザＩＤが利用されるものとする。このため、ＥＣサービス及び決済サービスのユーザＩＤがあれば、ユーザが保有する暗号資産を特定可能である。暗号資産を利用した決済自体は、種々の手法を利用可能である。暗号資産自体も、種々の種類を利用可能である。

なお、銀行自動引き落とし決済及び暗号資産決済についても、別途の会員登録の手続が発生してもよい。この場合、銀行自動引き落とし決済及び暗号資産決済の各々の会員登録の流れは、後払い決済と同様であってよい。他にも例えば、後払い決済、銀行自動引き落とし決済、又は暗号資産決済の何れかの会員登録が完了すれば、他の番号決済についても自動的に利用できるようになってもよい。これら３つの番号決済のうちの何れを利用するかは、ユーザが自由に選択できるようにしてもよいし、何れか１つの番号決済の会員登録が完了すれば、残り２つの番号決済も自動的に利用できるようになってもよい。

変形例３の付与部１０２は、ユーザに対し、複数種類の決済方法の中からユーザにより選択された種類に応じた番号帯の後払い番号を付与する。変形例３では、３種類の番号決済が可能なので、３つの番号帯が存在する。例えば、後払い決済は、冒頭の６桁が「９９９９－９９」である。銀行自動引き落とし決済は、冒頭の６桁が「８８８８－８８」である。暗号資産決済は、冒頭の６桁が「７７７７－７７」であるものとする。個々の番号決済の番号帯は、任意の番号帯であればよく、変形例３の例に限られない。

図８は、変形例３における機能ブロックの一例を示す図である。変形例３の決済システム１は、処理実行部２０３を含む。処理実行部２０３は、制御部２１により実現される。処理実行部２０３は、番号決済の番号帯に応じた種類に基づいて、所定の処理を実行する。所定の処理は、番号決済の種類の応じた処理である。変形例３では、番号決済に応じたアイコンＩ３４を表示させる処理が所定の処理に相当する場合を説明するが、所定の処理は、任意の処理であってよく、変形例３の例に限られない。

例えば、番号決済の種類に応じて、分割払いの可否が異なる場合には、所定の処理は、分割払いの可否を決定する処理であってもよい。例えば、番号決済の種類に応じて、決済要求の送信先が異なる場合には、所定の処理は、決済要求の送信先を特定する処理であってもよい。例えば、番号決済の種類に応じて、決済要求の形式が異なる場合には、所定の処理は、番号決済の種類に応じた形式の決済要求を生成する処理であってもよい。

変形例３では、処理実行部２０３は、実施形態で説明した表示制御部２０２の機能を含む。例えば、処理実行部２０３は、決済要求をするための注文確認画面ＳＣ３に、決済番号の番号帯に応じた種類に関するアイコンＩ３４を表示させる。アイコンＩ３４は、種類画像の一例である。このため、アイコンＩ３４について説明している箇所は、種類画像と読み替えることができる。種類画像は、アイコンＩ３４以外の他の画像であってもよい。例えば、種類画像は、文字列、数字、又はその他の記号であってもよい。

図９は、変形例３の注文確認画面ＳＣ３の一例を示す図である。例えば、処理実行部２０３は、決済番号の番号帯に応じた種類のアイコンＩ３４を、注文確認画面ＳＣ３に表示させる。番号帯とアイコンＩ３４の関係は、データ記憶部２００に記憶されているものとする。処理実行部２０３は、ユーザが利用する決済番号の番号帯に関連付けられた種類のアイコンＩ３４を、注文確認画面ＳＣ３に表示させる。

例えば、処理実行部２０３は、決済番号の冒頭の６桁が「９９９９－９９」である場合、後払い決済を示すアイコンＩ３４を選択する。処理実行部２０３は、決済番号の冒頭の６桁が「８８８８－８８」である場合、銀行自動引き落とし決済を示すアイコンＩ３４を選択する。処理実行部２０３は、決済番号の冒頭の６桁が「７７７７－７７」である場合、暗号資産決済を示すアイコンＩ３４を選択する。処理実行部２０３は、これらの選択されたアイコンＩ３４を含む注文確認画面ＳＣ３を表示させる。

例えば、後払い決済判定部１０５は、注文確認画面ＳＣ３に対するユーザの操作によって決済要求が受け付けられた場合に、番号決済を許可するか否かを判定する。注文確認画面ＳＣ３から任意の番号決済を選択できる点で実施形態とは異なるが、後払い決済判定部１０５の判定方法自体は、実施形態と同様である。

変形例３の決済システム１は、ユーザに対し、複数種類の決済方法の中からユーザにより選択された種類に応じた番号帯の後払い番号を付与する。決済システム１は、番号帯に応じた種類に基づいて、所定の処理を実行する。これにより、ユーザが選択した番号決済の種類に応じた処理を実行できるので、ユーザの利便性が高まる。更に、決済番号の番号帯によって、どの番号決済が選択されたかを簡単に特定できる。

また、決済システム１は、注文確認画面ＳＣ３に、決済番号の番号帯に応じた種類に関するアイコンＩ３４を表示させる。決済システム１は、注文確認画面ＳＣ３に対するユーザの操作によって決済要求が受け付けられた場合に、番号決済を許可するか否かを判定する。これにより、注文確認画面ＳＣ３で番号決済を確認しやすくなるので、ユーザの利便性が高まる。ユーザがある番号決済を実行しようとした時に、誤って他の番号決済を選択するといった誤操作を防止できる。

［５－４．変形例４］
例えば、実施形態では、決済サービスと同じ事業者が提供するＥＣサービスで後払い決済が利用可能である場合を説明したが、決済サービスとは異なる事業者が提供する外部サービスで後払い決済が利用可能であってもよい。変形例４では、後払い番号は、後払い番号の発行者と異なる事業者が提供する外部サービスで利用可能である場合を説明する。更に、外部サービスの一例として、実施形態で説明したＥＣサービスとは異なる事業者が提供する外販サービスを説明する。

変形例４の後払い決済判定部１０５は、外販サービスから後払い決済を利用するための後払い決済要求が受け付けられた場合に、スコアに基づいて、後払い決済を許可するか否かを判定する。変形例４の後払い決済要求は、外販サービスのシステムから受信する。後払い決済要求の形式は、実施形態と同様であってよく、クレジットカード決済要求と同じ形式であるものとする。後払い決済要求を送信する主体が実施形態とは異なるが、後払い決済判定部１０５の判定方法自体は、実施形態で説明した通りである。

変形例４の後払い決済実行部１０９は、後払い決済判定部１０５により後払い決済を許可すると判定された場合に、外販サービスに関する後払い決済を実行する。外販サービスのシステムから受信した後払い決済要求に応じた後払い決済が実行される点で異なるが、後払い決済実行部１０９による後払い決済の実行方法自体は、実施形態で説明した通りである。なお、外部サービスは、外販サービスに限られない。例えば、外部サービスは、外部の事業者により提供される旅行予約サービス、電子書籍サービス、又はオンラインフリーマーケットサービスであってもよい。

変形例４の決済システム１は、後払い番号の発行者と異なる事業者が提供する外販サービスから、後払い決済要求が受け付けられた場合に、スコアに基づいて、後払い決済を許可するか否かを判定する。決済システム１は、後払い決済を許可すると判定された場合に、外販サービスに関する後払い決済を実行する。これにより、後払い決済を利用可能なサービスが増えるので、ユーザの利便性が高まる。

［５－５．変形例５］
例えば、変形例３で説明したように、番号決済は、銀行自動引き落とし決済又は暗号資産決済であってもよい。変形例３では、これら２つの番号決済が利用可能である場合を説明したが、決済システム１では、銀行自動引き落とし決済又は暗号資産決済の何れか一方のみが利用可能であってもよい。

例えば、番号決済が銀行自動引き落とし決済である場合には、第１ユーザデータベースＤＢ１には、決済番号と、銀行口座に関する情報と、が関連付けられているものとする。銀行自動引き落とし決済は、番号決済を選択したユーザの銀行口座に関する情報に基づいて実行される。銀行自動引き落とし自体は、公知の処理により実行可能である。例えば、番号決済が暗号資産決済である場合には、第１ユーザデータベースＤＢ１には、決済番号と、暗号資産に関する情報と、が関連付けられているものとする。暗号決済は、番号決済を選択したユーザの暗号視線に関する情報に基づいて実行される。暗号資産決済自体は、公知の処理により実行可能である。

変形例５の決済システム１は、番号決済は、銀行自動引き落とし決済、又は暗号資産決済である。これにより、実施形態と同様の理由で、銀行自動引き落とし決済又は暗号資産決済を導入するためのコストを低減できる。

［５－６．変形例６］
例えば、決済システム１の全体構成は、実施形態で説明した例に限られない。例えば、決済システム１は、複数の第２サービスと、外部サービスと、の各々で利用可能であってもよい。変形例６では、決済サービスが、旅行予約サービス、電子書籍サービス、オンラインフリーマーケットサービス、スマホ決済サービス、及び外販サービスといった６つのサービスと連携している場合を説明する。

図１０は、変形例６の決済システム１の全体構成の一例を示す図である。変形例６では、決済システム１は、ＧＷサーバ１０Ａ、他決済サーバ１０Ｂ、及び後払い決済サーバ１０Ｃを含む。決済システム１の外部に、ＥＣサーバ２０Ａ、旅行予約サーバ２０Ｂ、電子書籍サーバ２０Ｃ、オンラインフリーマーケットサーバ２０Ｄ、スマホ決済サーバ２０Ｅ、外販サーバ２０Ｆ、及びユーザ端末３０が存在する。

ＧＷサーバ１０Ａ、他決済サーバ１０Ｂ、後払い決済サーバ１０Ｃ、ＥＣサーバ２０Ａ、旅行予約サーバ２０Ｂ、電子書籍サーバ２０Ｃ、オンラインフリーマーケットサーバ２０Ｄ、スマホ決済サーバ２０Ｅ、及び外販サーバ２０Ｆの各々の物理的構成は、実施形態で説明した決済サーバ１０又はＥＣサーバ２０と同様であってよい。

ＧＷサーバ１０Ａは、ＥＣサーバ２０Ａ、旅行予約サーバ２０Ｂ、電子書籍サーバ２０Ｃ、オンラインフリーマーケットサーバ２０Ｄ、スマホ決済サーバ２０Ｅ、及び外販サーバ２０Ｆの各々からの決済要求を受信する。変形例６では、ＥＣサービス、オンラインフリーマーケットサービス、及び外販サービスの３つで後払い決済を利用可能である場合を説明するが、６つ全てのサービスで後払い決済を利用可能であってもよい。

ＥＣサービスからの後払い決済要求は、実施形態で説明した通りである。オンラインフリーマーケットサービスからの後払い決済要求は、ＥＣサービスと同様の形式及び流れで受け付けられるものとする。外販サービスからの後払い決済要求は、変形例４で説明した通りである。ＧＷサーバ１０Ａは、ＥＣサービス等の各サービスから決済要求を受信すると、決済要求の種類を特定する。決済要求の種類を特定する方法は、実施形態で説明した通りである。

ＧＷサーバ１０Ａは、後払い決済要求が受け付けられた場合には、後払い決済サーバ１０Ｃに対し、後払い決済要求を送信する。後払い決済サーバ１０Ｃは、実施形態及び変形例１～５で説明した決済サーバ１０の機能を有する。後払い決済サーバ１０Ｃの処理は、実施形態及び変形例１～５で説明した決済サーバ１０が後払い決済要求を受け付けた後に実行される処理と同様である。後払い決済サーバ１０Ｃは、後払い番号を付与する処理等も実行するものとする。

ＧＷサーバ１０Ａは、クレジットカード決済要求等の他の決済要求であれば、他決済サーバ１０Ｂに対し、決済要求を送信する。他決済サーバ１０Ｂは、ＧＷサーバ１０Ａから受信した決済要求に基づいて、クレジットカード決済等の他の決済を実行する。

変形例６の決済システム１は、種々のサービスにおける後払い決済に対応できる。例えば、ＧＷサーバ１０Ａが決済の種類を特定し、その後の処理を実行する主体を振り分けることによって、種々の決済方法に対応できるようになる。

［５－７．変形例７］
例えば、実施形態では、計算部１０４によりスコアが計算され、後払い決済判定部１０５により後払い決済を許可するか否かが判定される場合を説明したが、これらの処理が実行されなくても、本開示の「決済サービスを導入するためのコストを低減する」といった課題を解決できる。即ち、後払い番号がクレジットカード番号と同じ形式であれば、クレジットカード決済の仕組みを流用して、後払い決済を実現できるので、計算部１０４及び後払い決済判定部１０５を含まない決済システム１も、本開示の範囲に含まれる。計算部１０４及び後払い決済判定部１０５を含まずに、付与判定部１０１、付与部１０２、取得部１０３、パスワード認証部１０６、セキュリティコード認証部１０７、メッセージ認証部１０８、又は後払い決済実行部１０９を含む決済システム１も、本開示の範囲に含まれる。

例えば、決済システム１が計算部１０４及び後払い決済判定部１０５を含まない場合、後払い決済実行部１０９は、後払い決済要求が受け付けられると、実施形態で説明したスコアには基づかずに、後払い決済を実行する。この場合、後払い決済のための審査が実行されずに無条件で後払い決済が実行されてもよいし、物理的なクレジットカードと同様のショッピング枠を後払い番号に設ける場合には、ショッピング枠を超えないか否かの判定が実行されてもよい。実施形態で説明したスコア以外の何らかの不正検知アルゴリズムによる不正検知が実行されたうえで後払い決済が実行されてもよい。

例えば、実施形態では、クレジットカード番号と同じ形式の後払い番号が付与される場合を説明したが、後払い番号は、クレジットカード決済以外の他の決済方法と同じ形式の番号であってもよい。決済システム１が他の決済方法に対応済みであれば、他の決済方法を利用した決済の仕組みを利用して、後払い決済を導入できるので、本開示の「決済サービスを導入するためのコストを低減する」といった課題を解決できる。このため、クレジットカード以外の他の決済方法と同じ形式の後払い番号を付与する決済システム１も、本開示の範囲に含まれる。

例えば、クレジットカード以外の他の決済方法と同じ形式の後払い番号を付与する決済システム１として、銀行口座と同じ形式の後払い番号を付与するが挙げられる。決済システム１において、銀行口座自動引き落とし決済の仕組みを導入済みだった場合には、銀行口座の番号と同じ形式の後払い番号が付与されてもよい。銀行口座は、金融機関コード、支店番号、及び口座番号により特定される。このため、後払い番号として、どの金融機関も利用していない金融機関コード、支店番号、及び口座番号が付与されてもよい。

なお、他の決済方法は、銀行口座決済に限られず、何らかの番号によって特定可能なものであればよい。例えば、暗号資産の口座、証券口座、又は電子マネーの一種である口座であってもよい。決済システム１は、導入済みの銀行口座自動引き落とし決済の仕組みを流用して、後払い決済を導入できるので、導入時のコストを低減できる。決済システム１は、クレジットカード決済及び銀行口座以外の他の決済方法と同じ形式の後払い番号を付与してもよい。

［５－８．その他の変形例］
例えば、上記説明した変形例１～７のうちの２つ以上を組み合わせてもよい。

例えば、実施形態では、ＥＣサービス及び決済サービスが互いに連携する場合を説明したが、決済サービスは、他のサービスと連携しなくてもよい。この場合、決済サービスという１つのサービスの中で、クレジットカード決済の仕組みを流用して、後払い決済を導入するようにしてもよい。

例えば、決済サーバ１０で実現されるものとして説明した機能は、ＥＣサーバ２０又は他のサーバコンピュータで実現されてもよい。ＥＣサーバ２０で実現されるものとして説明した機能は、決済サーバ１０又は他のサーバコンピュータで実現されてもよい。例えば、決済サーバ１０又はＥＣサーバ２０で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも１つのコンピュータで実現されるようにすればよい。

［６．付記］
例えば、本開示に係る決済システムは、下記のような構成も可能である。
（１）
ユーザに対し、クレジットカード番号と同じ形式の決済番号を付与する付与部と、
過去における前記ユーザの取引に関する取引情報に基づいて、前記ユーザの信頼性に関するスコアを計算する計算部と、
前記決済番号に関する決済要求が受け付けられた場合に、前記スコアに基づいて、前記決済番号に関する番号決済を許可するか否かを判定する番号決済判定部と、
前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記番号決済を実行する番号決済実行部と、
を含む決済システム。
（２）
前記決済システムは、前記ユーザに関する情報であって、前記取引情報とは異なる他の情報に基づいて、前記ユーザに対する前記決済番号の付与を許可するか否かを判定する付与判定部を更に含み、
前記付与部は、前記付与判定部により前記決済番号の付与を許可すると判定された場合に、前記ユーザに対し、前記決済番号を付与する、
（１）に記載の決済システム。
（３）
前記付与部は、前記ユーザを識別可能なユーザ識別情報と、物理的なクレジットカードには関連付けられない前記決済番号と、を関連付けることによって、前記ユーザに対し、前記決済番号を付与する、
（１）又は（２）に記載の決済システム。
（４）
前記付与部は、前記ユーザに対し、前記決済番号のうちの少なくとも一部を通知することなく、前記決済番号を付与し、
前記決済システムは、前記ユーザに対し、前記決済番号のうちの少なくとも一部を通知することなく、前記決済要求をするための決済画面を表示させる表示制御部を更に含み、
前記番号決済判定部は、前記決済画面に対する前記ユーザの操作によって前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
（１）～（３）の何れかに記載の決済システム。
（５）
前記取引情報は、過去に実行された前記番号決済に関する情報である、
（１）～（４）の何れかに記載の決済システム。
（６）
前記付与部は、前記ユーザを識別可能なユーザ識別情報と、前記決済番号と、を関連付けることによって、前記ユーザに対し、前記決済番号を付与し、
前記決済システムは、前記ユーザ識別情報に基づいて、前記番号決済に関する第１サービスとは異なる第２サービスにおける前記取引情報を取得する取得部を更に含み、
前記計算部は、前記第２サービスにおける前記取引情報に基づいて、前記スコアを計算する、
（１）～（５）の何れかに記載の決済システム。
（７）
前記取得部は、複数の前記第２サービスの各々における前記取引情報を取得し、
前記計算部は、前記複数の第２サービスの各々における前記取引情報に基づいて、前記スコアを計算する、
（６）に記載の決済システム。
（８）
前記決済システムは、前記番号決済に関する第１決済要求が受け付けられた場合には、パスワード認証を省略し、クレジットカード決済に関する第２決済要求が受け付けられた場合には、前記パスワード認証を実行するパスワード認証部を更に含む、
（１）～（７）の何れかに記載の決済システム。
（９）
前記決済システムは、前記番号決済に関する第１決済要求が受け付けられた場合には、セキュリティコード認証を省略し、クレジットカード決済に関する第２決済要求が受け付けられた場合には、前記セキュリティコード認証を実行するセキュリティコード認証部を更に含む、
（１）～（８）の何れかに記載の決済システム。
（１０）
前記付与部は、前記ユーザに対し、複数種類の決済方法の中から前記ユーザにより選択された前記種類に応じた番号帯の前記決済番号を付与し、
前記決済システムは、前記決済番号の前記番号帯に応じた前記種類に基づいて、所定の処理を実行する処理実行部を更に含む、
（１）～（９）の何れかに記載の決済システム。
（１１）
前記処理実行部は、前記決済要求をするための決済画面に、前記決済番号の前記番号帯に応じた前記種類に関する種類画像を表示させ、
前記番号決済判定部は、前記決済画面に対する前記ユーザの操作によって前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
（１０）に記載の決済システム。
（１２）
前記決済システムは、前記番号決済と、他の決済方法と、の中から前記ユーザによる選択を受け付けるための決済画面に、前記番号決済と、前記他の決済方法と、の各々を区別して表示させる表示制御部を更に含み、
前記番号決済判定部は、前記決済画面において前記番号決済が選択されて前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
（１）～（１１）の何れかに記載の決済システム。
（１３）
前記決済システムは、前記決済要求が受け付けられた場合に、ユーザのユーザ端末との間でメッセージ認証を実行するメッセージ認証部を更に含み、
前記番号決済実行部は、前記番号決済判定部により前記番号決済を許可すると判定され、かつ、前記メッセージ認証が成功した場合に、前記番号決済を実行する、
（１）～（１２）の何れかに記載の決済システム。
（１４）
前記決済番号は、前記決済番号の発行者と異なる事業者が提供する外部サービスで利用可能であり、
前記番号決済判定部は、前記外部サービスから前記番号決済を利用するための前記決済要求が受け付けられた場合に、前記スコアに基づいて、前記番号決済を許可するか否かを判定し、
前記番号決済実行部は、前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記外部サービスに関する前記番号決済を実行する、
（１）～（１３）の何れかに記載の決済システム。
（１５）
前記番号決済は、銀行自動引き落とし決済又は暗号資産決済である、
（１）～（１４）の何れかに記載の決済システム。

１ 決済システム、Ｎ ネットワーク、１０ 決済サーバ、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、２０ ＥＣサーバ、３０ ユーザ端末、３４ 操作部、３５ 表示部、２０Ａ ＥＣサーバ、２０Ｂ 旅行予約サーバ、２０Ｃ 電子書籍サーバ、２０Ｄ オンラインフリーマーケットサーバ、２０Ｅ スマホ決済サーバ、２０Ｆ 外販サーバ、３０ ユーザ端末、１００ データ記憶部、１０１ 付与判定部、１０２ 付与部、１０３ 取得部、１０４ 計算部、１０５ 決済判定部、１０６ パスワード認証部、１０７ セキュリティコード認証部、１０８ メッセージ認証部、１０９ 決済実行部、２００ データ記憶部、２０１ サービス提供部、２０２ 表示制御部、２０３ 処理実行部、３００ データ記憶部、３０１ 表示制御部、３０２ 操作受付部、Ｂ１２，Ｂ３１，Ｂ３２，Ｂ３３，Ｂ４２，Ｂ５０ ボタン、Ｆ１０，Ｆ４０ 入力フォーム、Ｉ３０，Ｉ３４ アイコン、ＳＣ１ ログイン画面、ＳＣ２ トップ画面、ＳＣ３ 注文確認画面、ＳＣ４ 会員登録画面、ＳＣ５ 登録完了画面、ＳＣ６ ＳＭＳ画面、ＳＣ７ 注文完了画面、ＤＢ１ 第１ユーザデータベース、ＤＢ２ 第２ユーザデータベース。

Claims (17)

1. ユーザに電子商取引サービスを提供する電子商取引サーバと通信可能な決済サーバを含む決済システムであって、
   クレジットカード番号と同じ形式の決済番号に関する番号決済を前記ユーザに提供する番号決済サービスに、前記電子商取引サーバにアクセスした前記ユーザが会員登録をしておらず、前記電子商取引サービスで注文する商品を確認するための注文確認画面で、前記ユーザが前記会員登録を希望する操作を行って前記決済サーバにアクセスして前記会員登録を完了させた場合に、前記ユーザに対し、前記決済番号を付与する付与部と、
   過去における前記ユーザの取引に関する取引情報に基づいて、前記ユーザの信頼性に関するスコアを計算する計算部と、
   前記決済番号に関する決済要求が受け付けられた場合に、前記スコアに基づいて、前記決済番号に関する番号決済を許可するか否かを判定する番号決済判定部と、
   前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記商品の前記番号決済を実行する番号決済実行部と、
   を含み、
   前記決済番号は、前記電子商取引サービスで前記ユーザが利用可能な決済方法に関する決済方法情報として、前記電子商取引サーバに登録され、次回から前記ユーザは、前記注文確認画面で前記番号決済を選択可能である、
   決済システム。
2. 前記決済システムは、前記ユーザに関する情報であって、前記取引情報とは異なる他の情報に基づいて、前記ユーザに対する前記決済番号の付与を許可するか否かを判定する付与判定部を更に含み、
   前記付与部は、前記付与判定部により前記決済番号の付与を許可すると判定された場合に、前記ユーザに対し、前記決済番号を付与する、
   請求項１に記載の決済システム。
3. 前記付与部は、前記ユーザを識別可能なユーザ識別情報と、物理的なクレジットカードには関連付けられない前記決済番号と、を関連付けることによって、前記ユーザに対し、前記決済番号を付与する、
   請求項１又は２に記載の決済システム。
4. 前記付与部は、前記ユーザに対し、前記決済番号のうちの少なくとも一部を通知することなく、前記決済番号を付与し、
   前記決済システムは、前記ユーザに対し、前記決済番号のうちの少なくとも一部を通知することなく、前記決済要求をするための決済画面を表示させる表示制御部を更に含み、
   前記番号決済判定部は、前記決済画面に対する前記ユーザの操作によって前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
   請求項１又は２に記載の決済システム。
5. 前記取引情報は、過去に実行された前記番号決済に関する情報である、
   請求項１又は２に記載の決済システム。
6. 前記付与部は、前記ユーザを識別可能なユーザ識別情報と、前記決済番号と、を関連付けることによって、前記ユーザに対し、前記決済番号を付与し、
   前記決済システムは、前記ユーザ識別情報に基づいて、前記番号決済に関する第１サービスとは異なる第２サービスにおける前記取引情報を取得する取得部を更に含み、
   前記計算部は、前記第２サービスにおける前記取引情報に基づいて、前記スコアを計算する、
   請求項１又は２に記載の決済システム。
7. 前記取得部は、複数の前記第２サービスの各々における前記取引情報を取得し、
   前記計算部は、前記複数の第２サービスの各々における前記取引情報に基づいて、前記スコアを計算する、
   請求項６に記載の決済システム。
8. 前記決済システムは、前記番号決済に関する第１決済要求が受け付けられた場合には、パスワード認証を省略し、クレジットカード決済に関する第２決済要求が受け付けられた場合には、前記パスワード認証を実行するパスワード認証部を更に含む、
   請求項１又は２に記載の決済システム。
9. 前記決済システムは、前記番号決済に関する第１決済要求が受け付けられた場合には、セキュリティコード認証を省略し、クレジットカード決済に関する第２決済要求が受け付けられた場合には、前記セキュリティコード認証を実行するセキュリティコード認証部を更に含む、
   請求項１又は２に記載の決済システム。
10. 前記付与部は、前記ユーザに対し、複数種類の決済方法の中から前記ユーザにより選択された前記種類に応じた番号帯の前記決済番号を付与し、
    前記決済システムは、前記決済番号の前記番号帯に応じた前記種類に基づいて、所定の処理を実行する処理実行部を更に含む、
    請求項１又は２に記載の決済システム。
11. 前記処理実行部は、前記決済要求をするための決済画面に、前記決済番号の前記番号帯に応じた前記種類に関する種類画像を表示させ、
    前記番号決済判定部は、前記決済画面に対する前記ユーザの操作によって前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
    請求項１０に記載の決済システム。
12. 前記決済システムは、前記番号決済と、他の決済方法と、の中から前記ユーザによる選択を受け付けるための決済画面に、前記番号決済と、前記他の決済方法と、の各々を区別して表示させる表示制御部を更に含み、
    前記番号決済判定部は、前記決済画面において前記番号決済が選択されて前記決済要求が受け付けられた場合に、前記番号決済を許可するか否かを判定する、
    請求項１又は２に記載の決済システム。
13. 前記決済システムは、前記決済要求が受け付けられた場合に、ユーザのユーザ端末との間でメッセージ認証を実行するメッセージ認証部を更に含み、
    前記番号決済実行部は、前記番号決済判定部により前記番号決済を許可すると判定され、かつ、前記メッセージ認証が成功した場合に、前記番号決済を実行する、
    請求項１又は２に記載の決済システム。
14. 前記決済番号は、前記決済番号の発行者と異なる事業者が提供する外部サービスで利用可能であり、
    前記番号決済判定部は、前記外部サービスから前記番号決済を利用するための前記決済要求が受け付けられた場合に、前記スコアに基づいて、前記番号決済を許可するか否かを判定し、
    前記番号決済実行部は、前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記外部サービスに関する前記番号決済を実行する、
    請求項１又は２に記載の決済システム。
15. 前記番号決済は、銀行自動引き落とし決済又は暗号資産決済である、
    請求項１又は２に記載の決済システム。
16. ユーザに電子商取引サービスを提供する電子商取引サーバと通信可能な決済サーバが、
    クレジットカード番号と同じ形式の決済番号に関する番号決済を前記ユーザに提供する番号決済サービスに、前記電子商取引サーバにアクセスした前記ユーザが会員登録をしておらず、前記電子商取引サービスで注文する商品を確認するための注文確認画面で、前記ユーザが前記会員登録を希望する操作を行って前記決済サーバにアクセスして前記会員登録を完了させた場合に、前記ユーザに対し、前記決済番号を付与する付与ステップと、
    過去における前記ユーザの取引に関する取引情報に基づいて、前記ユーザの信頼性に関するスコアを計算する計算ステップと、
    前記決済番号に関する決済要求が受け付けられた場合に、前記スコアに基づいて、前記決済番号に関する番号決済を許可するか否かを判定する番号決済判定ステップと、
    前記番号決済判定ステップにより前記番号決済を許可すると判定された場合に、前記商品の前記番号決済を実行する番号決済実行ステップと、
    を実行し、
    前記決済番号は、前記電子商取引サービスで前記ユーザが利用可能な決済方法に関する決済方法情報として、前記電子商取引サーバに登録され、次回から前記ユーザは、前記注文確認画面で前記番号決済を選択可能である、
    決済方法。
17. ユーザに電子商取引サービスを提供する電子商取引サーバと通信可能な決済サーバを、
    クレジットカード番号と同じ形式の決済番号に関する番号決済を前記ユーザに提供する番号決済サービスに、前記電子商取引サーバにアクセスした前記ユーザが会員登録をしておらず、前記電子商取引サービスで注文する商品を確認するための注文確認画面で、前記ユーザが前記会員登録を希望する操作を行って前記決済サーバにアクセスして前記会員登録を完了させた場合に、前記ユーザに対し、前記決済番号を付与する付与部、
    過去における前記ユーザの取引に関する取引情報に基づいて、前記ユーザの信頼性に関するスコアを計算する計算部、
    前記決済番号に関する決済要求が受け付けられた場合に、前記スコアに基づいて、前記決済番号に関する番号決済を許可するか否かを判定する番号決済判定部、
    前記番号決済判定部により前記番号決済を許可すると判定された場合に、前記商品の前記番号決済を実行する番号決済実行部、
    として機能させ、
    前記決済番号は、前記電子商取引サービスで前記ユーザが利用可能な決済方法に関する決済方法情報として、前記電子商取引サーバに登録され、次回から前記ユーザは、前記注文確認画面で前記番号決済を選択可能である、
    プログラム。

Images