【文献】
“NTTデータ 「CAFIS」が外貨建てのカード決済に対応 ECサイト上での多通貨決済がスタート”,CardWave,日本,iResearch Japan株式会社,2012年 5月25日,第25巻, 第3号,pp.36〜37
【文献】
本田元,“外貨預金口座連動型決済カードの可能性 新しい外貨預金商品としての決済カード”,月刊金融ジャーナル,日本,金融ジャーナル社,2010年 6月29日,第51巻, 第7号,pp.76〜79
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0015】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
【0016】
図10は、従来の越境ECにおける決済の例について概要を示した図である。図の左側には日本の消費者およびマーチャント、右側には米国のマーチャントおよび消費者がそれぞれ示されている。日本国内での消費者とマーチャントとの間、および米国内での消費者とマーチャントとの間の購買取引は、越境ECではなく、当然、決済はそれぞれの国の通貨によって行われる。すなわち、日本の消費者は日本円(図中では「¥」として表示)によって支払い、日本のマーチャントはそのまま日本円によって受け取る。また、米国の消費者は米国ドル(図中では「$」として表示)によって支払い、米国のマーチャントはそのまま米国ドルによって受け取る。
【0017】
一方で、日本の消費者が米国のマーチャントのWebサイトを介して商品等を購入する越境ECの場合、例えば、クレジットカードによって決済を行うと、日本の消費者は日本円によって支払うことになるが、米国のマーチャントに対しては米国ドルによって支払われる。このとき、日本の消費者の支払う金額は、クレジットカード会社等が用いる独自の為替レートによって米国ドルから変換された金額が用いられる。この為替レートには、通常、クレジットカード会社等によってスプレッドが上乗せされており、市場での為替レートと比較して割高となってしまう。米国の消費者が日本のマーチャントから商品等を購入する場合も同様である。
【0018】
図11は、従来の越境ECにおける決済の具体例について概要を示した図である。ここでは、
図10の例における日本と米国との間での越境ECにおける具体的な決済状況の例を示している。例えば、上段の図では、日本の消費者「aさん」、「bさん」、「cさん」が、それぞれ、米国のマーチャントの「Shop A」、「Shop B」、「Shop C」で販売している$9、$5、$2の商品を購入した場合を示している。市場における為替レートが1$=¥100であったとすると、日本円での支払額は、本来、それぞれ¥900、¥500、¥200となるべきところ、図中の例では、¥4のスプレッドが乗せられた為替レート(1$=¥104)が適用されており、日本の消費者の支払額は、それぞれ、¥936、¥520、¥208となって割高となっている。
【0019】
同様に、下段の図では、米国の消費者「dさん」、「eさん」、「fさん」が、それぞれ、日本のマーチャントの「店D」、「店E」、「店F」で販売している¥100、¥500、¥300の商品を購入した場合を示している。この場合、米国ドルでの支払額は、本来、それぞれ$1、$5、$3となるべきところ、図中の例では、$0.04のスプレッドが乗せられた為替レート(1.04$=¥100)が適用されており、米国の消費者の支払額は、それぞれ、$1.04、$5.2、$3.1となって割高となっている。
【0020】
越境ECでの決済におけるこのような為替スプレッドの影響を可能な限り回避するため、本発明の一実施の形態である決済システムでは、消費者と海外のマーチャントとの間に、消費者からの入金を受け付け、マーチャントに対して入金を行う決済用のゲートウェイを設ける。そして、取引毎に直接為替交換を行って決済するのではなく、ゲートウェイ内でいったん仮想通貨に変換し、仮想通貨による通貨種別間の両替注文を板情報として管理し、相対する注文をマッチングさせる。これにより、スプレッドが乗らない交換レートを用いることができ、消費者は、当該交換レートによって決定された金額を支払えばよく、商品購入時の費用負担を低減させることができる。
【0021】
図2は、本実施の形態の越境ECにおける決済の例について概要を示した図である。
図10の従来の例と同様のケースにおいて、本実施の形態では、越境ECの場合に、例えば、日本の消費者による米国のマーチャントへの支払いに係る両替(日本円→米国ドル)と、米国の消費者による日本のマーチャントへの支払いに係る両替(米国ドル→日本円)とを、中間のEC決済ゲートウェイ10において仮想通貨を用いることでマッチングさせる。これにより、日本の消費者による日本円での支払いを、日本のマーチャントへの支払いに充当し、また、米国の消費者による米国ドルでの支払いを、米国のマーチャントへの支払いに充当することができ、外国為替による通貨の実際の両替を行わずに為替スプレッドの影響を排除することが可能となる。
【0022】
図3は、本実施の形態の越境ECにおける決済の具体例について概要を示した図である。
図11の従来の例と同様のケースにおいて、例えば、上段の図における日本の消費者「aさん」は、米国のマーチャントの「Shop A」から$9の商品を購入した場合、為替スプレッドが上乗せされない¥900を支払うことになる。なお、ここでは説明の便宜上、為替スプレッドはゼロとしているが、両替のマッチングの結果次第では実際には少額のスプレッドが乗る場合も生じ得る。この¥900の支払いは、下段の図における日本のマーチャントの「店D」、「店E」、「店F」での米国の消費者「dさん」、「eさん」、「fさん」に対する販売額の合計が¥100+¥500+¥300=¥900であることから、EC決済ゲートウェイ10においてマッチングの対象とされ、これらのマーチャントへの支払いに充当される。
【0023】
同様に、下段の図における米国の消費者「dさん」、「eさん」、「fさん」は、それぞれ、日本のマーチャントの「店D」、「店E」、「店F」から¥100、¥500、¥300の商品を購入した場合、為替スプレッドが上乗せされない$1、$5、$3を支払うことになる。これらを合計した$9の支払いは、上段の図における米国のマーチャントの「Shop A」での米国の消費者「aさん」に対する販売額が$9であることから、EC決済ゲートウェイ10においてマッチングの対象とされ、当該マーチャントへの支払いに充当される。
【0024】
本実施の形態では、
図3の例のように、通貨種別間の両替を伴う決済を1対1でのみマッチングさせるのではなく、販売額と支払額の合計が合致する限り、m対nの数でマッチングさせることができるものとする。相対する両替をマッチングさせる際の手法としては、特に限定されないが、株式市場などにおけるいわゆる「板寄せ方式」などを適宜用いることができる。
【0025】
<システム構成>
図1は、本発明の一実施の形態である決済システムの構成例について概要を示した図である。決済システム1は、越境EC環境と、越境ECでの取引に係る決済処理を行うEC決済ゲートウェイ10からなる。越境EC環境は一般的なものであってよく、例えば、インターネット等のネットワーク50を介して接続された、消費者30が利用する情報処理端末である消費者端末31と、消費者30とは通貨圏が異なるマーチャント40のEC用Webサイトを実装するWebサーバ41を有する。
【0026】
また、決済に用いる実際の銀行口座として、各マーチャント40が支払いを受け取る個別の銀行口座42に加え、EC決済ゲートウェイ10が決済処理を行うために保有する通貨種別毎の入出金用銀行口座20を有する。
図1の例では、入出金用銀行口座20として、日本円、米国ドル、および中国元での入出金をそれぞれ受け付ける銀行口座(入出金用銀行口座20a〜20c)を有している。これらの口座は、それぞれの通貨圏の国の銀行等に個別に設けられていてもよい。
【0027】
EC決済ゲートウェイ10は、例えば、サーバ機器や、クラウドコンピューティング環境上に構築された仮想サーバなどにより実装されるサーバシステムであり、図示しないOS(Operating System)やDBMS(DataBase Management System)、Webサーバプログラムなどのミドルウェア上で動作するソフトウェアとして実装された、銀行入出金管理部11、仮想通貨交換エンジン12、ゲートウェイ(GW)口座管理部13、マーチャント口座管理部14、プライスコンバータ15、およびマーケットメーカー16などの各部を有する。また、データベース等により実装されたマーチャント管理マスタ17などのデータストアを有する。
【0028】
銀行入出金管理部11は、各入出金用銀行口座20に対して、入金の監視や、各マーチャント40の銀行口座42への振込・送金等の出金指示を行う機能を有する。具体的には、入出金用銀行口座20が設けられている銀行のオンラインバンキングやネットバンキング等のインタフェースを介してコマンド等を発行することで処理を行う。
【0029】
仮想通貨交換エンジン12は、ネットワーク上で流通・交換が可能な仮想暗号通貨を実現するための処理エンジンとしての機能を有する。外部の仮想通貨交換エンジンや仮想通貨交換サービスに対するインタフェース機能として実装されたものであってもよい。仮想通貨交換エンジン12としては、公知の技術を適宜用いることができる。本実施の形態では、エンタープライズ向けの通貨交換ネットワークとして、通貨交換に必要な機能群がOSS(Open Source Software)として提供されており自由に利用可能であるRipple(登録商標)(https://ripple.com/)を用いるものとして説明する場合がある。
【0030】
GW口座管理部13は、Rippleなどの仮想通貨交換エンジン12上に設けられたEC決済ゲートウェイ10用の仮想通貨(Rippleでは「IOU」に相当)の口座であるGW口座13aを管理する機能を有する。GW口座管理部13は、GW口座13aに対して所定の通貨種別(
図1の例では、日本円(¥)、米国ドル($)、中国元(元))の仮想通貨の発行を行う。また、後述するマーチャント口座からGW口座13aへの仮想通貨の入金(RippleではIOUの償還に相当)を検知した場合に、銀行入出金管理部11に対して、入出金用銀行口座20から対象のマーチャント40の銀行口座42への出金指示を出力する。
【0031】
マーチャント口座管理部14は、各マーチャント40と関連付けられた仮想通貨の口座であるマーチャント口座を管理する機能を有する。
図1の例では、日本、米国および中国の各マーチャント40に対応するマーチャント口座として、日本口座14a、米国口座14bおよび中国口座14cがそれぞれ1つ以上設けられている。
【0032】
各マーチャントには、受け取りを許可する仮想通貨の通貨種別が設定されている。通常は、対象の国で流通する通貨種別のみが許可されるが、例えば、日本のマーチャント40が中国元での受け取りを許可する場合など、他の通貨種別を許可するようにしてもよい。なお、このような設定情報は、マーチャント管理マスタ17などに予め登録される。受け取りを許可する通貨種別以外の種別によって仮想通貨の入金があった場合は、後述するマーケットメーカー16に対して、受け取りを許可する通貨種別への両替注文を行い、両替された結果の仮想通貨を入金処理する。
【0033】
プライスコンバータ15は、後述するマーケットメーカー16が保有するオーダーブック16aの情報に基づいて、マーチャント40のWebサーバ41が提供するEC用のWebサイトにおいて販売する商品等の価格を、消費者の現地通貨における価格に変換して提示する機能を有する。
【0034】
マーケットメーカー16は、通貨種別間の両替の組み合わせ毎に保有するオーダーブック16aの情報を管理し、両替処理を行う機能を有する。オーダーブック16aは、マーチャント口座管理部14から出される両替注文の情報を注文板情報として保持している。マーケットメーカー16は、オーダーブック16aにおける売り/買いの両替注文に対して、上述の
図3に示したようなマッチングを行って両替注文を成立させる。なお、具体的なマッチングの手法については特に限定されず、Rippleなどの仮想通貨交換エンジン12が備えるマッチング機能を用いてもよいし、独自にマッチング処理を構築してもよい。マーケットメーカー16は、また、プライスコンバータ15等からの指示に応じて、現在の板情報に基づいて両替における平均取得レートを算出して出力する。
【0035】
マーチャント管理マスタ17は、本実施の形態の決済システム1を利用して決済を行うマーチャント40についてのマスタ情報を保持するテーブルである。上述したマーチャント40が入金を許可する通貨種別の情報や、銀行口座42の情報などを管理する。
【0036】
図1の例では、EC決済ゲートウェイ10を1つのサーバシステムとして構成しているが、構成は適宜柔軟に変更することが可能であり、例えば、銀行入出金管理部11やGW口座管理部13、マーチャント口座管理部14などを各国に分散して配置して各国用のゲートウェイシステムとして構成し、プライスコンバータ15やマーケットメーカー16を1ヶ所に集約して設けるというような構成とすることも可能である。
【0037】
また、本実施の形態では、GW口座管理部13やマーチャント口座管理部14などについて、口座の情報を管理する機能を有するソフトウェアとして構成しているが、口座の情報とこれにアクセスする機能とを一体とした「口座オブジェクト」として実装することも可能である。同様に、マーケットメーカー16についても、オーダーブック16aの情報とこれにアクセスする機能とを一体とした「オーダーブックオブジェクト」として実装することも可能である。
【0038】
<処理の流れ(全体)>
図4は、本実施の形態における決済処理の流れの例について概要を示したフローチャートである。消費者30が越境ECによって海外のマーチャント40から商品等を購入する際の決済処理において、まず、決済に先立ち、マーチャント40のEC用のWebサイトは、EC決済ゲートウェイ10のプライスコンバータ15にアクセスして、商品等の販売価格に対する、消費者30の現地通貨での支払価格を取得して、消費者30に提示する(S01)。このとき、プライスコンバータ15は、マーケットメーカー16におけるオーダーブック16aの板状況を参照し、マーチャント40が属する国の通貨単位での販売額を、消費者30が属する国の通貨単位での支払額に変換して出力する。
【0039】
支払額が決定して商品等の購入契約が締結されると、その後、EC決済ゲートウェイ10の銀行入出金管理部11は、入出金用銀行口座20に消費者30から上記の支払額が入金されたかどうかを監視する(S02)。消費者30が入金する先の入出金用銀行口座20は、通貨種別に応じてEC決済ゲートウェイ10が指定する。例えば、
図1の例において、日本円での支払いの場合には、日本円での入出金を受け付ける入出金用銀行口座20aを指定する。銀行入出金管理部11は、各入出金用銀行口座20への入金の有無を定期的に確認する。新たな入金があった場合は、その通貨種別と金額、および支払先のマーチャント40に係る情報をGW口座管理部13に通知する。
【0040】
なお、支払先のマーチャント40に係る情報は、例えば、消費者30が入出金用銀行口座20に振込等により入金する際に入力する振込情報に、マーチャント40を特定するID等の情報や、対象の取引の注文番号などを入力させることで把握することができる。例えば、マーチャント40を特定するID等の情報が指定された場合は、EC決済ゲートウェイ10においてマーチャント管理マスタ17を参照することでマーチャント40を特定することができる。また、注文番号が措定された場合は、例えば、マーチャント40において購買契約が締結された際に、その注文番号とマーチャント40の情報を予めWebサーバ41がネットワーク50などを介してEC決済ゲートウェイ10に送信しておくことで、マーチャント40を特定することができる。
【0041】
消費者30からの入金が把握できた場合、その通知を受領したGW口座管理部13は、当該入金に係る通貨種別および入金額に対応する(すなわち、等価値の)仮想通貨(RippleではIOU)を発行し、さらに、発行した仮想通貨を、対象のマーチャント40と関連付けられたマーチャント口座へ送金する(S03)。
【0042】
マーチャント口座管理部14は、各マーチャント口座への入金を監視しており、対象のマーチャント口座に仮想通貨の入金があったことを検知した場合に、その通貨種別が、当該マーチャント40が受け取りを許可する通貨種別と一致しない場合、マーケットメーカー16に対して、入金された仮想通貨の通貨種別を当該マーチャント40が受け取りを許可する通貨種別へ交換する両替注文を出す(S04)。例えば、¥1,000を$10に交換するために「売り:¥1,000/買い:$10」の両替注文を出す。なお、各マーチャント40が受け取りを許可する通貨種別の情報は、上述したように、マーチャント管理マスタ17などに予め登録されている。
【0043】
一方で、マーチャント口座に入金された仮想通貨の通貨種別が、当該マーチャント40が受け取りを許可する通貨種別と一致する場合、もしくは、上記の両替注文が約定して受け取りを許可する通貨種別の仮想通貨がマーチャント口座に入金された場合、マーチャント口座管理部14は、対象のマーチャント口座に入金された仮想通貨を全額GW口座13aに送金(RippleではIOUの償還)する(S05)。
【0044】
GW口座管理部13は、GW口座13aへの仮想通貨の入金を監視しており、マーチャント口座からの仮想通貨の入金を検知した場合に、その通貨種別および入金額に対応する(すなわち、等価値の)現実通貨での金額、および入金元のマーチャント口座に対応するマーチャント40の銀行口座42の情報を銀行入出金管理部11へ送信して出金の依頼を行う(S06)。対象のマーチャント40の銀行口座42の情報は、上述したように、マーチャント管理マスタ17などに予め登録されている。
【0045】
銀行入出金管理部11は、GW口座管理部13から受け取った通貨種別と金額、および銀行口座42の情報に基づいて、対象の通貨種別を取り扱う入出金用銀行口座20(
図1の例では米国ドルでの入出金を受け付ける入出金用銀行口座20b)から、対象のマーチャント40の銀行口座42に対して振込や送金などの実際の出金処理を行う(S07)。以上の一連の処理により越境ECでの決済が完了する。
【0046】
<処理の流れ(現地通貨での価格決定)>
図5は、
図4のステップS01の現地通貨での価格決定処理の流れの例について示したシーケンス図である。現地通貨での支払価格の取得要求を受けたEC決済ゲートウェイ10のプライスコンバータ15は、まず、マーケットメーカー16に対して、注文板情報に基づく平均取得レートの計算指示を行う。指示を受けたマーケットメーカー16では、まず、仮想通貨交換エンジン12に対してコマンド等を発行し、対象の通貨種別間の両替注文の板情報、すなわちオーダーブック16aの情報を取得する。そして、オーダーブック16aの情報に基づいて、後述する手法などにより平均取得レートを計算し、プライスコンバータ15に応答する。プライスコンバータ15では、平均取得レートと商品等の販売額とに基づいて、消費者30の現地通貨での支払額を計算する。
【0047】
図6は、
図5の例における平均取得レートの計算処理の流れの例について示したフローチャートである。まず、両替注文の一覧について処理を繰り返すループ処理を開始する(S11)。ループ処理では、まず、対象の両替注文に基づいて両替済の金額を更新するための準備処理として、対象の両替注文に係る交換後の価格(以下では「α」と記載する)を計算し、これまでの両替済金額の合計(以下では「A」と記載する)に「α」を加算した両替済金額「A+α」を計算する。なお、両替注文の情報は、例えば、「1$=¥100のレートで、¥5,000分交換する」というように、交換レートと交換対象金額の情報を含むものとする。
【0048】
次に、両替済金額「A+α」が、販売国の通貨での販売額以上となっているか否かを判定する(S13)。「A+α」が販売額に満たない場合は、これまでの両替済金額を更新する(S14)。すなわち、「A+α」を新たな「A」として、次の両替注文の処理に移る(S15、S11)。
【0049】
一方で、ステップS13において「A+α」が販売額以上となっている場合は、両替済金額の「A+α」が販売額と同額になるよう平均取得レートを調整する(S16)。例えば、「α」を追加する前の「A」の額が販売額に満たない場合は、以下の式により平均取得レートを計算する。
【0050】
平均取得レート=平均取得レート+
対象の両替注文における交換レート×(販売額−A)/A
その後、ループ処理を終了し、ステップS16で算出した平均取得レートを返却して(S17)、処理を終了する。以上の一連の処理により、オーダーブック16aにおける両替注文の板情報に基づいて、対象の通貨種別間での仮想通貨における交換レートの平均を取得することができる。
【0051】
<処理の流れ(入金監視、仮想通貨発行)>
図7は、
図4のステップS02の入金監視処理およびステップS03の仮想通貨発行処理の流れの例について示したシーケンス図である。まず、消費者30が、EC決済ゲートウェイ10が指定する入出金用銀行口座20に対して実際の入金を行う。銀行入出金管理部11は、定期的に当該口座に対する入金の有無を確認することにより、入金を検知し、必要に応じて消費者30に対して入金を確認した旨の通知を行う。例えば、消費者30に対して電子メールを送付する等により入金確認の通知を行うことができる。
【0052】
入金を検知した銀行入出金管理部11は、GW口座管理部13に対して、入金された通貨種別と金額に対応する(すなわち、等価値の)仮想通貨(RippleではIOU)の発行指示を行う。発行指示を受けたGW口座管理部13は、仮想通貨発行および送金のためのコマンド等からなるトランザクションを作成して、これを仮想通貨交換エンジン12に対して実行する。これにより、仮想通貨交換エンジン12によって仮想通貨が発行されるとともに、発行された仮想通貨が対象のマーチャント40に関連付けられたマーチャント口座に対して送金される。
【0053】
<処理の流れ(両替注文指示、償還指示)>
図8は、
図4のステップS04の両替注文指示処理およびステップS05の償還指示処理の流れの例について示したシーケンス図である。まず、マーチャント口座管理部14は、各マーチャント40に関連付けられたマーチャント口座に対して仮想通貨の入金トランザクションが存在しないかを、仮想通貨交換エンジン12に対して定期的に確認する。仮想通貨交換エンジン12からのレスポンスによって入金があったことを検知すると、次に通貨種別の判定を行う。具体的には、仮想通貨交換エンジン12からのレスポンスの内容から入金に係る通貨種別の情報を取得する。また、マーチャント管理マスタ17を参照して、対象のマーチャント口座(もしくはこれに関連付けられたマーチャント40)が受け取りを許可している通貨種別の情報を取得する。そして、これらの通貨種別が一致するか否かを判定する。
【0054】
通貨種別が一致しない場合は、受け取りを許可する通貨種別へ交換するための両替指示の処理を行う。具体的には、まず、マーチャント口座管理部14は、仮想通貨を両替するためのコマンド等からなるトランザクションを作成して、このトランザクションメッセージを含む両替指示をマーケットメーカー16に対して送信する。マーケットメーカー16は、受け取ったトランザクションメッセージを仮想通貨交換エンジン12に対して送信することにより、仮想通貨交換エンジン12が両替用のトランザクションを実行して通貨種別間での仮想通貨の両替を行う。
【0055】
一方、入金された通貨種別と、対象のマーチャント40が受け取りを許可する通貨種別とが一致する場合は、入金された仮想通貨をGW口座13aへ送金するための償還指示の処理を行う。具体的には、まず、マーチャント口座管理部14は、仮想通貨をGW口座13aへ送金するためのコマンド等からなるトランザクションを作成して、これを仮想通貨交換エンジン12に対して実行する。これにより、仮想通貨交換エンジン12によって対象のマーチャント口座内の仮想通貨がGW口座13aに送金される。その後、GW口座管理部13は、銀行入出金管理部11に対して対象のマーチャント40の銀行口座42への出金依頼を行うが、この処理の詳細については後述する。
【0056】
<処理の流れ(出金依頼、出金処理)>
図9は、
図4のステップS06の出金依頼処理およびステップS07の出金処理の流れの例について示したシーケンス図である。まず、GW口座管理部13は、GW口座13aに対して仮想通貨の入金トランザクションが存在しないかを、仮想通貨交換エンジン12に対して定期的に確認する。仮想通貨交換エンジン12からのレスポンスによって入金があったことを検知すると、次に、出金依頼の内容を作成する。具体的には、仮想通貨交換エンジン12からのレスポンスの内容から入金に係る通貨種別と金額の情報、および入金元のマーチャント口座の情報を取得する。そして、マーチャント管理マスタ17を参照し、マーチャント口座に関連付けられたマーチャント40および銀行口座42の情報を取得し、仮想通貨の通貨種別と入金額に対応する(すなわち、等価値の)現実通貨での金額の情報、および銀行口座42の情報を出金依頼の内容として作成する。
【0057】
その後、出金依頼の内容を銀行入出金管理部11へ送信して出金依頼を行う。銀行入出金管理部11は、受け取った出金依頼の内容に基づいて、対象の通貨種別を取り扱う入出金用銀行口座20から対象の銀行口座42への実際の送金を、銀行等が提供する振込サービスや送金サービスに対して指示する。銀行等が提供する振込サービス等は、指示された内容に従って、入出金用銀行口座20から対象のマーチャント40の銀行口座42に対して実際の送金を行う。以上の一連の処理により越境ECでの決済処理を行うことができる。
【0058】
以上に説明したように、本発明の一実施の形態である決済システム1によれば、消費者30と海外のマーチャント40との間にEC決済ゲートウェイ10を設け、取引毎に直接為替交換を行って決済するのではなく、EC決済ゲートウェイ10内でいったん仮想通貨に変換し、仮想通貨による通貨種別間の両替注文をオーダーブック16aにおける板情報として管理し、相対する注文をマッチングさせる。これにより、仮想通貨交換ネットワークにおける市場の為替レートを用いることができ、消費者は、当該為替レートによって決定された金額を支払えばよく、スプレッドの影響を回避して、商品購入時の費用負担を低減させることができる。
【0059】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。