【メモ】EMV SRC
概要
EMV SRC(EMV Secure Remote Commerce)は、EMVCoが策定するリモート(主にeコマース)決済向けのチェックアウト仕様群です。オンラインの支払い手続を「一貫性があり、便利で、安全」な体験にすることを狙いとしており、Click to Pay系ソリューションの共通ベースライン(API仕様・JavaScript SDK仕様など)を提供します。1
Click to Payは、EMV SRC仕様に基づく消費者向けeコマース決済で、カードブランドやチャネル、デバイスが異なっても共通の統合と体験を目指します。1
用語(最低限)
- SRC System:SRCの基盤(プロファイルやカード候補、チェックアウト等を提供)
- SRC Initiator(SRCI):加盟店(またはPSP)側でSRC Systemを呼び出す役割
- Digital Payment Application(DPA):加盟店側の決済アプリ(チェックアウト画面/支払い処理を含む)
- Digital Terminal:Visa文脈で、DPAのフロント(チェックアウト体験)を実装し、Click to Payに対して各APIを呼ぶ主体
※ EMVCoのUse Casesでは、DPA・SRCI・(必要に応じ)Digital Card Facilitator等の機能が、まとめて「merchant / client」として表現されます。2
典型フロー(EMVCo Use Casesに基づく、加盟店オーケストレーション例)
EMV SRCのフローは、ざっくり言うと「認識(recognition)→プロファイル準備→候補提示→カード選択→チェックアウト」です。認識の具体的方法(どのように端末や消費者を認識するか)はスコープ外とされています。3
1) 消費者が認識済み(Consumer Recognised)
- 消費者がチェックアウトを開始
- 加盟店は、消費者アカウントから得たメール/電話番号(Consumer Identity)を用いて、各SRC SystemへPrepare SRC Profileを呼び出す
- SRC SystemがSRC Profile(群)を返す
- 加盟店がSRC Candidate List(利用可能なカード候補)を提示
- 以降は共通フローへ
2) 消費者が未認識だがフリクションレス(端末などで認識できる)
- 消費者がチェックアウトを開始
- 加盟店は各SRC SystemにIs Recognizedを呼び出す
- 認識できたSRC SystemがFederated ID Tokenを返す
- 加盟店はFederated ID Tokenを用いてPrepare SRC Profileを呼び出す
- SRC Candidate Listを提示
- 以降は共通フローへ
3) 消費者が未認識で、Consumer Identity入力と追加検証が必要
- 加盟店は、消費者にメール/電話番号(Consumer Identity)の入力を促す
- 各SRC SystemにIdentity Lookupを呼び出す
- SRC Systemが、当該Identityの検証方法(オプション)を返す
- 加盟店がInitiate Identity Validationを呼び出し、表示メッセージ等を受領
- 消費者がValidation Data(例:ワンタイムコード等)を入力
- 加盟店がComplete Identity Validationを呼び出す
- SRC SystemがFederated ID Tokenを返す
- 加盟店はFederated ID TokenでPrepare SRC Profileを呼び出し、候補提示
- 以降は共通フローへ
4) 共通フロー(カード選択後)
- 消費者がSRC Candidate Listからカードを選択
- 加盟店が選択カードに紐づくSRC SystemへCheckoutを呼び出す
- SRC Systemがpayload等のチェックアウト関連データを返す
- 加盟店が支払い確定画面を提示し、消費者が確定
- 加盟店(またはPSP)がオーソリ等の決済処理を実行
- 完了後に加盟店がConfirmationを呼び出す
なお、選択されたカードが当該加盟店で初回利用である等の場合、同意確認等の追加ステップアップが必要になり得る旨が示されています。7
Visa Click to Payの認証フロー(代表的なシーケンス)
VisaのClick to Pay(およびUnified Click to Pay)では、チェックアウト時に「認証の希望(authentication preference)」を指定でき、Visa側がリスク評価や指定に基づいてカード保有者検証(CVM)が必要かを判断し、3DSやPasskey、Issuer OTP等の方式を用いて認証済みpayload(支払いに必要なクレデンシャル)を返す、という整理が提示されています。8
0) 前提(登場人物)
- Consumer:購入者
- Digital Terminal:チェックアウト体験を実装し、Click to PayへAPIを呼び出す主体
- Visa Click to Pay:Click to Pay基盤
- Issuer:発行会社(CVMに関与)
- DPA:加盟店側の決済アプリ(最終的に決済処理へ進む)
1) 骨格(方式共通の流れ)
- Digital Terminalが、Click to Payからマスクされたカード候補(card list)を受領
- Consumerがカードを選択し、注文を確定
- Digital Terminalがcheckoutリクエストを送信(必要に応じてauthentication preferenceを含める)
- Visa Click to Payがリスク評価等により、カード保有者検証が必要か判断し、方式を選択(例:3DS、Passkeys、Issuer Online Banking、Issuer SMS/Email OTP、CVV2)
- 成功すると、checkoutレスポンスとして支払いクレデンシャル(例:ECIやdynamic data等)を返す
- 失敗/拒否の場合、そのカードでは続行できず、取引の再開始と別カード選択が必要になり得る
- Digital TerminalがpayloadをDPAに渡し、加盟店側の決済処理へ
2) 方式別の差分(要点)
- 3DS:Digital Terminalが3DSを希望する設定(challenge indicator等)を渡せる。成功時、ECI valueとdynamic data等を含むクレデンシャルがcheckout応答で返る。9
- Passkeys:3DS検証の後にPasskey登録(Enrollment)を促すケース、または既存Passkeyで認証(Authentication)するケースが示されている。10
- Issuer Online Banking:Issuerが提供するURLへ誘導し、Visa側が結果をポーリングしてpayload/クレデンシャルを返す流れが示されている。11
- Issuer OTP:Email/SMSのワンタイムコードで認証し、成功時にECIとverification data等を返す。Digital Terminal起点でauthenticate APIを用いるパターンにも言及がある。12
また、Unified Click to Pay側の説明では、Click to Pay内で3DSを利用するには加盟店がVisaの3DS設定済みである必要がある旨が明記されています。13