前回の記事で解説したように、Payment Request API によってウェブでの支払いにおけるユーザーエクスペリエンスは大きく変わる可能性があります。しかし、これが本当にメインストリームになるのか、将来的に自分のサイトを対応させる必要性は出てくるのか？そんな疑問を持つ方は少なくないと思います。

僕はかなり高い確率で、今後ウェブ上でのほとんどの支払いが Web Payments を経由したものに変わっていくと予想しています。この記事では、その理由を説明していきます。

クレジットカードのセキュリティ問題 #

あなたはクレジットカードを紛失して再発行した経験はありますか？

クレジットカードは紛失や盗難で番号が漏れて他人に知られてしまった可能性がある場合、カード番号を変更しなければなりません。番号が変わるということは、設定してある自動引落などが全てやり直しになってしまいます。その手続きの大変さを考えただけでも、クレジットカードを紛失するのは、金銭的な損失に加えて、それに対する処置という意味でも、大きな損失を伴います。

そもそもクレジットカードの仕組みというものは脆弱です。実店舗などの対面での支払いであれば、物理的カードの提示に加え、署名や PIN 番号の入力、監視カメラがあるなどの理由から、ある程度の安全性は担保されてきました。しかしオンラインの支払いが中心と なってきた現在はどうでしょう？

多くのオンラインサービスでは、カード番号と持ち主の名前、有効期限が正しければ決済可能です。これは相手が誰であろうと、それらの情報が正しければ決済できてしまうということを意味しています。そしてそれらの情報は、カードが手に入れば一発でわかりますし、カード番号を預けているサービスがクラックされ、情報が盗まれるだけでも悪用することができてしまいます。そして実際にそういったケースはあとを絶ちません。

もちろん、カード会社も手をこまねいて見ているわけではありません。クレジットカードのセキュリティ対策としていくつかの方法があります。

まず、カード情報を受け取る側に課される制約として、PCI DSS と呼ばれるクレジットカード情報を守るためのセキュリティ基準が用意されています。米国では PCI DSS 対応は EC ビジネスを行う上で実質的に必須になっています。

日本でも「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」として、2018 年 3 月までにオンラインでの支払いに PCI DSS を導入する要件を含む取り組みが 進められています。

CVC 番号の利用もかなり広まってきました。CVC 番号はカードの裏に書いてある 3 桁程度の数字で、これをマーチャントでカード番号と合わせて入力することで、本人確認が行われます。もちろんマーチャントの脆弱性で漏洩されては意味がありませんので、データベースに保存しない前提になっています。とはいえカードに明記されているものですし、ブラウザなどのクライアントからネットワークを介して渡される以上、どこかに脆弱性が存在する可能性はありますし、絶対的に安全なものとは言い切れません。

他には、3D セキュアと呼ばれる決済時にクレジットカード会社のサイトで認証を行う方式もあります。ただ、お金の支払いの度に id とパスワードによる認証が求められるため、ここでユーザーが脱落してしまうことは容易に想像できます。マーチャントがシステムを実装する手間も考えれば、喜んで導入される類のものではありませんし、あまり普及率は高くないようです。3D セキュアの新バージョンではリスクベース認証を取り入れることで、最小限の認証で済ませることになるようですが、実装の手間が減るわけではありません。

いずれにしろ重要なのは、クレジットカードの情報が漏洩する可能性をできるだけ減らすことです。

そこで PCI DSS は、2015 年に発表されたバージョン 3.2 において、明確に生のクレジットカード情報をブラウザ上で扱うことに関して、従来よりも強い制約を設けました。日本の 「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」においても同様です。

今後オンラインマーチャントは、クレジットカード情報を全く扱わない「クレジットカード情報の非保持化」を進めるか、もしくは PCI DSS に対応するか、の選択を迫られます。

Payment Request API + ペイメントアプリ + トークナイゼーション #

クレジットカード情報の漏洩は効率的に防ぎつつ、ユーザーがカードを利用するために必要とされる手間を増やさない、そんなことは実際に可能でしょうか？

そこで切り札になるのが「トークナイゼーション」と呼ばれる方法です。

トークナイゼーションが画期的なのは、それが渡されたカード情報を守る方法ではなく、そもそもカード情報を渡さないというアプローチを取っている点です。「トークン」と呼ばれる一時的に利用できる文字列をクレジットカード会社に発行してもらい、それをマーチャントに渡すことで、決済を行います。

このトークンはトランザクションに特化して発行されるため他の用途には使えないことに加え、トークン自体から元のカード番号を逆引きできないことから、漏洩したところで被害は最小限に食い止められる、という特徴があります (厳密には様々なバリエーションがあるようですが、ここでは触れません)。

つまり、これを使えば間接的に「クレジットカード情報の非保持化」を実現することができます。

では、どうやってこのトークンを取得して、ブラウザを介してマーチャントに渡すのでしょうか？そこで登場するのが Payment Request API です。

Payment Request API + ペイメントアプリ + トークナイゼーション

Payment Request API では、前回紹介した basic card と呼ばれる生のカード情報を扱う支払い方法に加えて、ペイメントアプリと呼ばれる支払い方法を提供することができます。このアプリがユーザーに代わってクレジットカード会社からトークンを提供してくれるため、マーチャントは一切生のクレジットカードに触れることなく、従来よりもセキュアにサーバーやペイメントゲートウェイに支払情報を渡すことができるようになります。

実際のデモを見てみましょう。

BobPay という支払い方法がデモ用のペイメントアプリです。"PAY" を押すとアプリが立ち上がり、"CONTINUE" で決済を承認する流れになっていますが、この部分はアプリによっては PIN を入力したり、指紋認証をすることで承認する流れになるはずです。

そしてポイントは、これらが Web Payments というオープンな仕様、オープンなエコシステム上で成り立っているため、誰でも独自のペイメントアプリを提供できる、という点です。

ペイメントアプリは Android 版 Chrome 60 (現在ステーブル) から利用可能になっています。既に Alipay, Samsung pay などが対応を表明しており、そのうち実際に利用できるマーチャントも出てくるものと思われます。ご自分で試されたいという方は、このデモサイトで実際に支払いを試してみて下さい (実際にお金が取られることはありません)。ここからデモ用の BobPay アプリをインストールすることができます。Android 版ペイメント アプリの仕様もここに掲載されています。

まとめ #

ポイントは下記の通りです。

  • 「クレジットカード情報の非保持化」はオンラインコマースの急務。
  • トークナイゼーションとペイメントアプリの登場で、オンラインの支払いは従来よりも安全に。
  • Payment Request API により、このエコシステムがウェブでも利用可能に。

残りの問題はブラウザの対応状況ですが、むしろこれは楽観的に捉えて間違いない状況です。

Windows にデフォルトでインストールされている Edge ブラウザでは (少なくとも基本的な機能は) 既に利用可能ですし、Firefox でも実装が進められています。

また本日、Safari も Payment Request API の実装を開始したというニュースがありました。これの意味するところは、これまでプロプライエタリな Apple Pay JS を介して Apple Pay というペイメントアプリしか利用できなかった Safari というプラットフォームに、オープンな Web Payments が加わることで、他のペイメントアプリも利用できるようになる可能性が出てきた、ということです。

AppStore の制約が厳しい Apple がペイメントアプリを許可してくれるかは興味深いところですが、Service Worker の実装が進んでいることも考えると、ウェブ版のペイメントアプリだけ利用可能になるという可能性もあります。いずれにせよ、興味は尽きません。

オープンなウェブというプラットフォームの上で、オープンな支払いのエコシステムが誕生し、広く利用されるようになる日は、思ったほど遠くなさそうです。