鈴木淳也のPay Attention

第187回

PayPay、ついにオフライン決済に対応 キャッシュレスの課題を(少し)解消

新機能のPayPayのオフライン決済のデモンストレーションを行なう同社Payment Product本部のTanneru Dhruva氏

PayPayがついにオフラインでの決済機能に対応した。本連載では過去にも「キャッシュレスは災害に弱い? 『オフライン決済』導入の課題」で、“キャッシュレス”と“オフライン”にまつわる課題に触れてきたが、この問題は実はそれほどシンプルではなく、国のインフラ事情やそのときどきのシチュエーションなどによって発生する障害や求められるソリューションが異なっているのが実際だ。

以前の記事では、ドイツでの決済端末のソフトウェアの不具合にまつわる障害で長期間にわたってカード決済が行なえない加盟店が複数発生した事例のほか、日本での自然災害にまつわるクレジットカードや電子マネーの決済停止の話題に触れている。

主にインフラ側の障害によりキャッシュレス決済が行なえなかった事例となるが、携帯電話の回線事情の厳しいケースではスマートフォンを使った決済、例えばコード決済は利用が難しい。Apple PayやGoogle Payにおいても、しばらくデータ通信が行なえないオフライン状態が続くと一時的に決済できなくなる現象がある。

このように現状のキャッシュレス決済は、支払いを受ける加盟店などのインフラ側と、キャッシュレス決済を行なう利用者側がともに“回線状態が良好である”などの条件が整った場合にのみ成り立っているのが現状だ。だが、比較的インフラが安定していると考えられていた日本においても自然災害にまつわる電力供給の不安や通信回線の遮断の懸念がクローズアップされるようになってきており、最近の例でいえばKDDIの数日間にわたる通信障害や、ドコモ回線での都市部を中心としたデータが流れにくい現象を鑑みるに、キャッシュレス決済の“前提”を見直す時期が到来しつつあるのかもしれない。

その意味で、PayPayの新サービスがこのタイミングで登場したことは非常に興味深い。

難しいオフライン決済の実装

機能の詳細についてはすでに解説されているので割愛したい。仕組みとしてはシンプルに、PayPayアプリを利用しているスマートフォンが携帯電話のネットワークやWi-Fi回線につながっていない“オフライン”状態であっても、条件付きでPayPay決済が行なえるというものだ。

注意点としては、前項でも触れた「自然災害や携帯キャリアの大規模障害で長時間にわたってネットワークが利用できない」といった状況ではなく、あくまで「“一時的に”通信状態の悪い場所でPayPay決済を行なう」ための緊急回避を前提としていることだ。

PayPay側の説明によれば「コンサート会場や地下の店舗など通信回線の利用が厳しい状況でもPayPayを使いたい」といった声に応えたものだという。そのため、例えば自然災害などで店舗側のPOSや決済端末が電気供給を受けられずに動作しなかったり、ネットワークが不通になっていた場合には、現状でこの仕組みは利用できない。

このようにPayPayのオフライン決済はある意味で画期的であるものの、「決済は1日2回まで」「1回あたりの金額上限は5,000円まで(残高払いの場合はその金額に依存)」「オフライン時間の最大期間は14日間」「店舗スキャン(CPM)方式のみ対応」「店舗側の機器が正常に動作していることが前提」といった制限の数々は、前述のような一時回避策としては使えるものの、コード決済全体を完全にオフライン処理できるわけではない。

この理由は、“オフライン”という状態での決済そのものの難易度が高いことに他ならない。

「店舗スキャン(CPM)方式」にのみ対応する

まず前提として、Suicaや楽天Edyなどの電子マネーがICチップ(セキュアエレメント)内に残高情報を記録してオフライン処理を可能としているのに対し、クレジットカードやデビットカード、そして今回のコード決済では与信や残高情報を手元の端末では直接保持しておらず、決済を処理するセンターサーバー側に情報を集約している。

決済リクエストがあると、当該のアカウント情報(カード番号)を元に決済の可否を判定し、その結果を返すことで決済が成り立つ。これをオフライン状態などのネットワークが不通の状況を想定したとき、まず決済リクエストがセンターサーバー側に中継されないため、処理を進めることができない。そのため、オフライン処理とはいっても「経路の一部がオフラインになっていた場合のみ」「決済回数など利用制限あり」といった条件付きでの処理となってしまう。

クレジットカードの場合、実は店舗側がオフラインでもある程度の決済を受け付けることができる。有名なものは「インプリンタ」と呼ばれるカード券面のエンボスをカーボン紙で転写する仕組みだが、カード決済端末でもオフラインでとりあえず決済を通してしまい、後でセンターと同期させるというケースがある。ダイヤルアップ回線など通信事情が厳しかった時代の名残だが、こうした後請求が可能なのも、「与信」という形でカード自体の安全性をある程度保証しているクレジットの仕組みによるものだ。

これを利用して“タッチ決済”の処理速度を向上させているのが「オープンループでの鉄道乗車」で、改札入場時にはネガチェック(無効なカードの判定)しか行なっておらず、オーソリゼーションや実際の請求などは1日単位で後でまとめて行なわれる。

大阪の南海難波駅で導入されたオープンループ乗車用の改札

PayPayのオフライン決済の仕組み

PayPayでは「店舗スキャン(CPM)方式」「ユーザースキャン(MPM)方式」の2種類の支払い方法があり、今回オフライン処理に対応したのはCPMのみとなる。

CPMは大手チェーンなどを中心に導入されている仕組みで、同社では実数を報告していないものの、店舗数でいえばこちらのCPM方式の割合の方が多いのではないかと筆者は考えている。CPM方式ではシステム利用料ぶんだけ高額になってしまうが、POSレジに直接決済機能を取り込めるためにレジ周りが省スペースで済むこと、ユーザーにQRのスキャンや金額入力操作をさせる必要がないため、レジの流れがスムーズになることもあり、当初はMPMで導入した店舗であっても後にCPMに切り替えるケースがあるからだ。

CPMの場合、店舗側のネットワークが有効であればPayPayのセンターサーバーへの問い合わせが可能なため、とりあえず決済を進めることができる。一方で、ユーザー側のPayPayアプリはバーコードあるいはQRコードを表示させるだけで済むので、この場合には“最悪のケースで”オフラインであっても問題ない。アプリ側にコードを表示させる機能があれば対応できるからだ。ただPayPayによれば、通常のオンライン時には5分間隔のバーコードのリフレッシュが、オフライン時には1分間隔まで縮まるという。その理由について「少しでも安全性を高めるため」(PayPayで開発を担当するTanneru Dhruva氏)と述べている。

CPMでユーザー側端末をオフラインにした場合の問題はいくつか考えられる。1つは「いくらの金額の支払いをどのタイミングで決済されたのか」をユーザーのPayPayアプリ側で把握する術がないことだ。

店舗がバーコードリーダーでアプリ画面に表示されるバーコードを読み取ったとしても、スマートフォン側はそれを認識できない。そのため、アプリで鳴らしている「PayPay!」の音声は鳴らせないし、支払い後に残高がそれに応じて動くこともない。ゆえにオフライン中は残高表示機能も使えない。

問題の2つめは、「オフライン状態を維持されると、バーコードで示されるユーザー情報が有効なものか」どうかの判定が行なえない。残高不足などのケースではセンターサーバー側の処理で弾けるが、例えば盗難などのケースはどうだろうか? クレジットカードもあり得るが、カードを無効化されるまでは不正利用が可能だ。

PayPayの場合はオフライン状態を維持し続ける限り、バーコードを表示し続けることができる。残高不足のようにセンターサーバー側で止めることも可能だが、少しでも無効化までの“ラグ”を解消するため、「1日2回まで」のような制限を設けているのだと推察する。

PayPayのオフライン決済では、端末がオンラインになったタイミングで一気に同期が行なわれる
決済直後の残高表示。実際に決済されたかが分からないため、金額表示も変化がない

PayPayによれば、「MPM方式(ユーザースキャン)でのオフライン決済対応」も検討中だという。こちらはさらに難しく、そもそもセンターサーバーとのやり取りを行なっているのはQRコードを読み取って金額を入力するユーザーのPayPayアプリ側なので、これがオフラインでは何もできない。

だが、MPMでも「店舗側がタブレット端末などに(金額情報を含んだ)動的QRコードを生成し、それをユーザーがPayPayアプリで読み取る」という仕組みであれば多少話は異なる。

ただ、肝心の“決済アクション”を起こすユーザーのPayPayアプリがオフラインではセンターサーバーとのやり取りが発生しないため、一工夫が必要だ。具体的には、動的QRコードを表示する店舗側の端末とPayPayアプリが直接“コミュニケーション”を行なって“中継”をしてもらうなどの手順が必要となる。

“オフライン”状態でどう端末同士のコミュニケーションを行なうかだが、例えばBluetoothの仕組みであったり、あるいは“音”を使うなどのアイデアが考えられる。超音波のような可聴域を外れた音を使っての通信はいろいろな応用事例があり、仕組みとしては考慮の余地がありそうだ。

オフライン事例をインドに学ぶ

さて、オフライン決済については先行事例に学べということで、話はインドに飛ぶ。

毎回勘違いされているので何度も説明するが、PayPayのベースとなる技術を開発したのはインドで決済サービスを提供している「Paytm」で、中国のサービスではない。PayPayの開発においてはPaytmを含むインドの技術者が現在もなお多数参加しているが、前出のDhruva氏によれば「今回のPayPayのオフライン機能はPaytmとはリンクしていない」という。つまり日本のニーズに合わせた独自開発の機能となる。

インドのオフライン決済事情については他誌のこちらの記事が詳しい。インドでのインフラ事情は不安定で、停電やネットワークの不通も珍しくない。同国ではスマートフォンを使ったキャッシュレス決済が近年盛り上がっているが、一方でこれら事情を背景にオフライン決済におけるニーズも存在している。

中央銀行にあたるインド準備銀行(RBI)の傘下組織でインターバンクシステムを提供するNPIC(National Payments Corporation of India)が「UPI(Unified Payments Interface)」という個人間送金システムサービスを用意しており、これを店舗決済にも利用している。QRコードを利用するスマートフォンでの決済のほか、フィーチャーフォン上でUSSD(Unstructured Supplementary Service Data)を使ったテキストメニューによる送金も利用できるというのがインドらしいが、これはユーザー端末が回線に接続されていることが前提となる。ただ、インフラ事情から必ずしも万全の状態でサービスが利用できないケースもあり、機能制限付きでオフライン決済を可能にする「UPI Lite」という仕組みが登場した。

PaytmもUPIの仕組みを利用した決済に対応するが、UPI Liteとは別にオフライン決済の仕組みを用意している。まずは店舗側がオフラインのケースを想定したもので、こちらは「Soundbox」という製品だ。QRコードが掲示された“スタンド”にいくつかのシンプルな機能を付与したもので、正確にいうとSIMカードを内蔵しているのでオフラインではないのだが、単純なQRコードを印刷したMPMの仕組みだけでは実現できないいくつかの機能を付与している。

決済タイミングで音を鳴らして店舗スタッフに通知したり、上位版では1日ごとにセールスレポートを音声読み上げしたりと、手元にスマートフォンがなくてもその機能の一部を代替してくれる。同国でのスマートフォン普及率が3割前後といわれているので、こうしたソリューションが必要なのだと考える。

PaytmのSoundbox。同国のインフラ事情を反映した仕組みといえる

ではユーザー側のオフライン対応は? という疑問で調べていたら、その回答はなんと「タッチ決済」だった。Paytmでは「Tap to Pay」の名称で呼んでいるが、NFC機能をサポートするAndroidやiPhoneであればPaytmアプリから支払い用のカードを追加できるので、非接触の“タッチ決済”に対応したPOSや決済端末にスマートフォンを近付けて支払うというもの。

Paytmでは物理カードも提供しているため、最終手段は物理カードというのがおそらく答えだ。結局、店舗側とユーザー側のいずれかのネットワークが使えない状態ではお手上げだが、どちらか片方が有効であれば何らかの決済手段があるという考えなのだと思われる。

PayPayのオフライン状態での表示。あくまで緊急回避手段なので、適時他の決済手段を組み合わせるのも手だ

国内SIerでシステムエンジニアとして勤務後、1997年よりアスキー(現KADOKAWA)で雑誌編集、2000年にプロフェッショナル向けIT情報サイト「@IT」の立ち上げに参画。渡米を機に2002年からフリーランスとしてサンフランシスコからシリコンバレーのIT情報発信を行なう。2011年以降は、取材分野を「NFCとモバイル決済」とし、リテール向けソリューションや公共インフラ、Fintechなどをテーマに取材活動を続けている。Twitter(@j17sf)