こんにちは、編集長の白石です。
この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。
今回お話を伺ったのは、Googleのえーじさんです。
えーじさんのセッションは「ウェブのための次世代決済法」でした。
スライド資料はこちらで公開されています。
Web Paymentsは（モバイル）Webの決済体験を変える
白石: 本日は、Web Paymentsについてお聞かせください。 Web Paymentsというのは、その名の通りWeb上での支払い体験を改善するものだと思いますが、そもそもなぜWeb Paymentsが重要なのでしょうか？
えーじ: それについては面白いデータがあります。
モバイルデバイス上で買い物が行われるのはもう一般的ですが、その3分の2はアプリじゃなくて（モバイル）Webサイトで行われているんですよ。
白石: へえ！スマートフォンだと、Webよりもアプリのほうが長い時間使われていそうですが、意外です。
えーじ: それだけじゃありません。今度はデスクトップWebとモバイルWebで支払いのコンバージョン率を比較すると、デスクトップのほうが2倍も高いんです。
これはつまり、モバイルWebサイトにユーザーはたくさんアクセスしているけど、買い物はデスクトップのほうがしやすいということです。
白石: 逆に言えば、モバイルWebサイトだと決済がしにくいってことですね。
えーじ: そうです。Amazonとか日頃から自分が使っているサイトであれば、クレジットカードの決済情報をあらかじめサービスが記憶しているので、決済はしやすい。
しかし、初めて訪れるサイトで買い物するとなると大変です。 クレジットカード番号や期限、3桁のセキュリティコードまで入力しなくてはならない。さらに、配送が必要な商品となると住所まで入力する必要が出てくる。
これだとめんどくさくて、途中で諦めてしまいますよね。個人的にも、モバイルで見つけた商品はとりあえずブックマークしておいて、デスクトップで決済するようなこともよくあります。
白石: 確かに。ではWeb Paymentsは、そういう決済に関する体験を改善するものだということですね。
えーじ: とりあえずはそうです。ただ、Web Paymentsが目指す世界はさらに先なんですよ。
クレジットカードは近い将来使われなくなるかもしれない
白石: というのは？
えーじ: そもそも、クレジットカードっていうシステムそのものが非常に脆弱なんですよね。プラスチックのカードそのものに、すべての情報が記載されているわけですよ。情報を盗むのも簡単だし、紛失したらおおごとです。
白石: 確かに…。
えーじ: そこで最近は、Apple PayやAndroid Payなど、スマートフォンにクレジットカード情報を搭載しようという動きが出てきました。
スマートフォンの端末には、指紋認証や顔認証を含めた認証機能があり、情報は端末内で安全に格納されるので、コピーができません。決済を行うには、端末が物理的に手元にある必要がある。しかも保存される番号も、クレジットカード番号そのものではなく、トークンと呼ばれる仮の番号です。仮に盗まれたとしてもリモートで無効化できるし、再発行の必要もないわけです。
このように、クレジットカードに比べてメリットが非常に大きいんです。近い将来物理的なクレジットカードは使われなくなると予想している人もいます。
白石: なるほど、ぼくはまだApple Payなどを使ったことがないんですが、そんなにメリットのある仕組みだったんですね。知りませんでした。
えーじ: 決済方法の進化は、これだけにとどまりません。仮想通貨や銀行間送金など、新しい支払い方法も次々に登場していて、「お金を右から左に移動する」ような取引のすべてで革新が起きようとしています。
Web Paymentsはこうした状況において、様々なプレイヤーをつなぐ「接着剤」のような働きになりつつある仕様なんです。
言ってみれば、新しいペイメントエコシステムを構築する上で欠かせないピースになると考えています。
白石: 現在の決済システムが抱える問題点を解決しようとする、壮大な話なわけですね。聞いていてワクワクします。
えーじ: なので、Web Paymentsはすごくたくさんの仕様から成り立っています。そのうち、現在でも実装が広く進んでいて、Web技術者が簡単に試せるのはPayment Request APIです。
Payment Request APIとは
白石: Payment Request APIとはなんですか？
えーじ: これが、最初に申し上げたWeb上の決済を手軽に行えるようにする仕組みです。
単純に言えば、クレジットカードや住所など、決済に必要な情報の入力をユーザーが簡単に行えるようになります。決済情報はブラウザが記憶してくれていて、ユーザーは事前に入力してある値から選ぶだけで、Webサイトに情報を渡すことができます。
基本的なコードは簡単で、以下のようにPaymentRequestのインスタンスを作ってshow()メソッドを呼び出すだけで、支払い情報を選択できるUIをブラウザが表示します。
var request = new PaymentRequest(methods, details, options);request.show().then(response => { // 支払い処理を行う // PSP（決済代行業者）に送るなどして決済を完了 response.complete('success'); });
ここで、ダイアログの中ほどに「Android Pay」や「Visa」など、支払い方法を選択できる項目があります。これは、PaymentRequestのコンストラクタの第一引数として、支払方法の情報を渡すことで指定できます。
また、ダイアログに表示される情報は、PaymentRequestのコンストラクタの第二引数で指定することができます。購入商品の情報を渡すだけでなく、配送オプションを指定することも可能です。
コンストラクタの最後の引数は支払いに関するオプションです。配送先住所を必要とするかや名前、メールアドレス、電話番号の情報を要求するかどうかなどを指定できます。
これらを指定して表示されたダイアログ上でユーザーが入力を終えると、プログラムにユーザーが入力した情報が渡ってきます。 プログラムはこれらの情報をサーバーに送信するなどして、決済を完了するわけですね。
白石: なるほど、Payment Request APIそのものは、使うのは全然難しくなさそうですね。先ほど、実装が進んでいると仰ってましたが、現在どのブラウザで利用できるんでしょうか？
えーじ: Chromeは、iOSを含む全プラットフォームで利用できます。他にもChromiumをベースに開発されているSamsung Internet BrowserやMicrosoft Edgeでも利用できます。Firefoxでは開発中ですね。あと、Safari上ではApple Pay JSという、Apple Payを利用するためのAPIが存在するのですが、それをPayment Request APIでラップしたライブラリも存在します。嬉しいニュースとしては、Safariも現在Payment Request APIを実装中ということです。
白石: おお、もうかなりのブラウザ上で動作するんですね。
えーじ: あと、Payment Request APIがどういう動作をするかを試してみたかったら、polykart.storeというデモサイトがあるのでアクセスしてみてください。商品を選んで「BUY NOW」を選択すれば、Payment Request APIを使用した支払い用ダイアログが表示されます。もちろん、実際に決済が行われるわけではありませんのでご安心ください。
Web Paymentsが目指す世界——新しいペイメントエコシステム
白石: しかし先ほどのコードでちょっと気になったのは、結局クレジットカード番号とかをプログラムが直接受け取るという点です。 セキュリティコードも含め、決済に必要な情報を全部Webサイトに渡してしまうのは何か怖いというか。まあ、現在でも一般的に行われていることではあるんですが。
えーじ: PaymentRequestに渡すペイメントメソッドに’basic-card’を指定した場合、クレジットカードの情報を生で受け取るように動作するんですよね。
‘basic-card’の仕組みはわかりやすく、どんな決済代行業者でも扱えるという点ではいいのですが、おっしゃるとおりセキュリティ面での懸念があります。ペイメントの未来はそこにはありません。
そこで登場するのが、生のクレジットカード情報ではなく、使い捨てのトークンを利用するという方法、つまり先程お話したApple PayやAndroid Payで利用できるトークンのことです。こちらの方法なら安全性も高まりますし、ECサイト側も、クレジットカード情報に触れる必要がないので助かるんです（※）。
※ ECサイト側も助かる…経済産業省が取りまとめたクレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2017により、ECサイトはクレジットカード情報の非保持化、もしくはカード情報を扱う場合はPCI DSS（※）に対応しなくてはならない。
※ PCI DSS（Payment Card Industry Data Security Standard）…カード会員情報の保護を目的として、国際ペイメントブランド5社（アメリカンエキスプレス、Discover、JCB、マスターカード、VISA）が共同で策定したカード情報セキュリティの国際統一基準
白石: これは素晴らしい。ぼくらWeb技術者がこの仕組みを利用するとしたら、どうしたらいいんですか？
えーじ: PaymentRequestに渡すペイメントメソッドには、URLを渡すというもう一つの方法があるんです。こちらの方法を用いると、支払いを行うにあたって、外部のペイメントアプリケーションを呼び出すことができます。
白石: 先ほどのコード例でも、https://android.com/payというURLを渡して、Android Payが表示されていましたね。
えーじ: こちらの方法を用いると、トークン化の処理を含め、複雑な処理は全て裏で行われ、Webアプリは戻ってきたトークンを使って決済処理を完了させるだけで済みます。
白石: セッションスライドの、ペイメントアプリを通じてトークンをやり取りする図を見て、複雑なので怖気づいてたところでした(笑)。
えーじ: この図の、企業間の提携などについては企業間で行われることですし、Web技術者の手をわずらわせることはありませんのでご安心ください。
ちなみに、ペイメントアプリケーションは技術的には誰でも作ることができます。なので、クレジットカードに限らない支払い方法、例えば仮想通貨やキャリア決済なども将来的にはPayment Request APIから扱えるようになるというわけです。
ペイメントアプリケーションを指定するのには、先ほども申し上げたようにURLを使用するので、基本的にはWebアプリです。ですが、Web Manifestの仕組みに対応していれば、ネイティブのAndroidアプリを呼び出すことも可能です。
BobPayという、ネイティブ、Webどちらにも対応したペイメントアプリのサンプルがありますので、よければ試してみてください。Web版はAndroid版Chrome Dev、ネイティブ版はChrome 60以降がインストールされたAndroidであれば試すことができます。
白石: 支払い方法はよりセキュアに、多様化するということですね。そのために、業界全体が変化しようとしている。まさに新しいペイメントエコシステムですね。
本日は、大変勉強になるお話をありがとうございました！