普段お店などで決済する時に使用しているQR決済が、 どういう仕組みで動いているのか気になり今回調べてみることにしました。 CPMやMPMといった方式の違い、サーバーとの通信、オフラインの仕組みなど、色々と発見がありました。
また同じ決済でも、Suicaは改札で一瞬で処理が終わっていて、 こんなに処理速度が違うのはなぜなのかというのも気になり 今回は両方の仕組みを比較して、どのような設計の違いがあるのかをまとめてみました。
1. QR決済の仕組み
基本構造
QRコード決済は、インターネット経由でサーバーと通信する ことを前提とした決済方式です。 残高情報や決済履歴はすべてサーバー側で管理されていて、決済時はオンラインでやり取りが発生します。
CPM と MPM について
QR決済には、2つの決済方式があります。
CPM(Consumer-Presented Mode / 利用者提示型)
利用者がスマートフォンにQRコード(バーコード)を表示し、店舗側の端末がそれを読み取る 方式です。 コンビニやスーパー、チェーン店などではこの方式で支払っているかと思います。
取引ごとにQRコードが動的に生成されるのが特徴です。
処理フロー:
利用者のスマホ → QRコード表示
↓
店舗の端末がスキャン
↓
店舗端末 → 決済サーバーに認証リクエスト(インターネット経由)
↓
決済サーバー → 残高確認・認証・引き落とし処理
↓
決済サーバー → 店舗端末に結果を返却
↓
利用者のスマホに決済完了通知
MPM(Merchant-Presented Mode / 店舗提示型)
店舗側が印刷されたQRコードを設置し、利用者がスマホでそれを読み取る 方式。 CPM方式に対応していない店舗で使用されています。
処理フロー:
店舗のQRコード
↓
利用者のスマホでスキャン
↓
利用者が金額を入力
↓
スマホアプリ → 決済サーバーに認証リクエスト(インターネット経由)
↓
決済サーバー → 残高確認・認証・引き落とし処理
↓
利用者のスマホに決済完了画面を表示
↓
店舗側に決済完了通知
MPMのメリットは、店舗側に専用の読み取り端末が不要 なことです。 QRコードを印刷した紙を置くだけで決済を受け付けられるため、導入コストが低い。 ただ、利用者が金額を手入力する必要があるため、入力ミスのリスクは発生します。
補足
MPMには「静的」と「動的」があるようです。
- 静的QR — 一度印刷したコードをずっと使い回す。店舗IDのみが埋め込まれており、金額は利用者が入力
- 動的QR — 取引ごとにコードを生成。金額や注文番号を含められるため、より安全で正確(あまり見たことないですが)
QR決済のまとめ
CPMでもMPMでも、結局はインターネット経由でサーバーに問い合わせている。 QRコード自体はただの入り口で、処理の本体は「サーバー側」にあります。
2. ICカード決済の仕組み
FeliCa とは
通勤などで使用するSuicaやPasmoなどのICカードは、ソニーが開発した FeliCa(フェリカ) という技術を使用しています。 名前は「Felicity(至福)」と「Card」を組み合わせた造語で、日本の多くのICカード決済でこの技術が採用されています。
通信の仕組み
FeliCaは NFC(Near Field Communication / 近距離無線通信) の一種です。
| 項目 | FeliCa(Type-F) |
|---|---|
| 周波数 | 13.56 MHz |
| 通信速度 | 212 kbps / 424 kbps(理論最大 847 kbps)※ |
| 通信距離 | 約10cm以内 |
| 処理時間 | 約0.1秒以内(暗号処理含む) |
リーダー/ライターから発信される「電磁波」によって、ICカード内のアンテナが電力を受け取り、通信が行われます。 カード自体にバッテリーは不要で、電磁誘導で給電しながら通信する 仕組みです。
FeliCaが高速処理を実現できる理由は、 カードとリーダー間のローカル通信で処理が完結する点にあります。
残高情報はICカード内のメモリに直接書き込まれる仕組みです。 認証や残高更新はカードとリーダー/ライターの間で完結し、サーバーとの連携はその後にバックグラウンドで行われます。 決済処理自体がローカルで完結するので、ネットワーク遅延の影響を受けないです。
改札の場合0.1秒の間に、カードの検出・相互認証・データ読み出し・書き込みという一連の処理を暗号処理含めて完了しています。 調べてみるとJR東日本の東京近郊区間だけでも約460駅あり、定期券の乗り越し精算では約10万通りの運賃パターンから正しい金額を計算する必要があります。 運賃計算は改札機側のCPUが担当していて、カード側の高速な読み書きと、リーダー側の高速な演算処理が組み合わさることで、全体で0.1秒以内の処理が実現されています。
参考: 現代日本人に「時」は重要―0.1秒で乗客を捌くSuicaはどのように生まれた?(Yahoo!ニュース オリジナル THE PAGE)
NFCのType-A/Bについて
NFCにはFeliCa以外にも規格があります。
| 規格 | 開発元 | 最大通信速度 | 主な用途(日本) |
|---|---|---|---|
| Type-A | NXP Semiconductors(蘭) | 424 kbps | taspo |
| Type-B | Motorola(米) | 424 kbps | マイナンバーカード、運転免許証 |
| Type-F(FeliCa) | Sony(日) | 847 kbps(実運用は主に212 kbps) | 交通系IC |
FeliCaは日本独自に発展した規格のため、海外ではほぼ使えない というデメリットがあります。 国際的にはType-A/Bが主流で、クレジットカードのタッチ決済(Visaタッチなど)もType-A/Bベースです。
3. 速度差について
QR決済とICカード決済の技術的な違いは以下になります。
| 比較項目 | QR決済 | ICカード決済(FeliCa) |
|---|---|---|
| 通信経路 | スマホ → インターネット → 決済サーバー | カード ↔ リーダー(近距離無線) |
| 認証・処理の場所 | クラウド上のサーバー | カードとリーダー間(ローカル) |
| ネットワーク依存 | 必須(オフラインは限定的) | 決済時点では不要(後段でセンター連携あり) |
| 処理時間 | 数秒〜(通信環境に依存) | 約0.1秒以内 |
| ボトルネック | ネットワーク遅延、サーバー応答 | 物理的な通信距離(約10cm) |
| 残高管理 | サーバー側 | カード内メモリ(チャージはオンライン) |
| オフライン対応 | 利用回数や金額に制限があり | 決済処理はオフライン(チャージ・利用履歴同期等は別途通信が必要) |
速度差の理由
速度差は、処理がどこで行われるか で決まります。
- ICカード → カードとリーダーの間で ローカルに完結 する。ネットワークの通信が不要なので、物理的な通信速度(0.1秒以下)だけ
- QR決済 → インターネットを経由してサーバーと通信 する。ネットワーク遅延、サーバーの処理時間、レスポンスの返却の合計時間
我々が作っているアプリケーションでも同じで、ローカルのデータ参照か サーバーへの問い合わせを含むかで処理時間は変わるので同じことになりますね。
QR決済のオフラインモード
QR決済のネットワーク依存という課題に対して、オフライン決済の機能も開始されています。 利用回数や金額に制限があり、あくまでサーバー中心の設計を維持したまま、例外としてオフラインを許容する仕組みになります。
4. 利用シーンごとの比較
| シーン | 最重要要件 | 最適な方式 |
|---|---|---|
| 交通改札 | 処理速度(0.1秒以内) | ICカード(FeliCa) |
| コンビニ | 多決済対応 | QR + IC 併用 |
| 飲食店 | 導入コストの低さ | QR決済(CPM / MPM) |
改札ではFelicaの速度を求めないと、駅が混雑すること間違い無いですね。 それ以外のシーンではQR決済で1-2秒掛かったとしても、困ることはほぼなさそうですね。
まとめ
QR決済はサーバーに問い合わせる設計、FeliCaはカードとリーダーの間で完結する設計と、 同じ「決済」でもアーキテクチャが根本的に違うことが分かり 普段気にせず使用していた決済の裏側を知れる良い機会になりました。 決済技術の進歩に感謝ですね。
ここまで読んでくださってありがとうございます!
弊社ではエンジニアを募集しております!少しでもご興味がありましたら、カジュアル面談でお話ししましょう!
参考文献
ソニー株式会社 | FeliCa | FeliCaとは | FeliCaのしくみ
「センターサーバ方式Suica」に関する疑問をJR東日本に聞いた【鈴木淳也のPay Attention】-Impress Watch
【書き起こし】共通QRコード決済システムの裏側 – 青木 太郎 【Merpay Tech Fest 2021】 | メルカリエンジニアリング
※ 記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。