Kyashはなぜ3Dセキュアに“VCAS”を採用したのか　スマホ決済ベンチャーが目指す新しいお金の文化

3Dセキュアにワンタイムパスワードを採用

山口章和氏：私は『Kyashにおける3Dセキュア対応について』と題して話をしたいと思います。2020年11月17日にKyash Cardが3Dセキュアに対応しました。この3Dセキュアは、私が所属しているペイメントチームが対応しました。

今回はその3Dセキュアの対応の話と、3Dセキュアがどういうものなのかという説明、今回利用しているVCASというサービスについて紹介したいと思っています。

まず自己紹介です。私は山口と申します。2020年3月にKyashに入社しました。入社当時からペイメントチームに所属しています。ペイメントチームは、VisaとかQUICPayに関わるシステムの開発などを行っています。私は、VisaやISO8583という電文周りの作業に携わることが多いです。

冒頭でも言ったとおり、2020年11月17日にKyash Cardが3Dセキュアに対応しました。これによって、Kyash Cardがよりセキュアに利用していただけます。3Dセキュア対応カードでないと使えないサービスがあるんですけど、この対応によって使えるようになったので、利用できる機会が増えたのかなと思っています。

今流している動画は、プッシュでOTP（ワンタイムパスワード）が受け取れるというものです。3Dセキュア対応の加盟店で決済するときに、OTPの送信方法が選べます。送信方法を選ぶとOTPが送信されるので、（認証コードを）入力をして決済が完了するという流れです。

OTPを採用することによって、パスワードを事前に登録したり覚えたりが不要なので、利便性の面でもよかったのかなと思っています。

日本で初めて3DセキュアにVCASを利用

3Dセキュアについて説明をしたいと思います。通常は、ECサイトで決済するとイシュアまで、最終的にはオーソリゼーションと言われる与信判定処理が行われます。3Dセキュアは、その前にユーザー認証が行える仕組みになっています。

3Dセキュアの取引の場合、ECサイトでユーザーが決済すると、最終的にイシュアドメインに対して認証の要求が送信されて、アクセスコントロールサーバーと呼んでいる、ACSが3DSの認証処理を行います。今回はこのACSにVisa Consumer Authentication Service（VCAS）を利用しています。

3Dセキュアは1.0、2.0という複数のバージョンがあるんですが、VCASを利用することによって、その差異をほとんど意識することなく3Dセキュアに対応できました。

3Dセキュアの対応でVCASを利用したのは、Kyashが日本で初めてだったようで、Visaさんからもプレスリリースが出ました。

先ほどの図の中でイシュアドメインの部分を拡大したものです。Kyashの内部がどういう構成になっているかですが、オーソリゼーション、電文の処理の部分と、3Dセキュアの処理の部分ではサービスが異なっていて、かつ、やりとりする相手も異なっています。

3Dセキュアのサービスは私たちも作っていて、これはVCASとJSONを介してやりとりをしています。決済電文は、決済電文を処理するサービスがあって、カードブランドのサーバーとISO8583という電文のフォーマットでやりとりをしています。

3Dセキュアの認証の部分の話をしたいと思います。図の中において緑色で示している部分が認証に関わる部分です。3Dセキュア対応の加盟店で利用すると、ACSまで3Dセキュアの認証要求が来て、この情報をもとにカードホルダーに対して認証を行っています。

冒頭でも触れたとおり、Kyashでは3Dセキュアの認証でOTPを採用しているので、このタイミングでユーザーに対してOTPの送付も行なっています。

3Dセキュアは、この2つが主要な画面になるのかなと思っています。VCASを利用することによって、私たちが追加で実装をする必要は特にありませんでした。SMSやPushの選択画面を出していると思うんですけど、このあたりはKyashから送信して表示するようになっています。

ここで選ばれた方法がKyashに送られてくるので、その情報をもとにKyashから利用者に対してOTPを送るようになっています。OTPの生成や入力画面のあとの検証処理はVCASがしてくれるので、これについてもKyashでは特になにもしていません。

OTPなしに決済が完了　フリクションレスフローの仕組み

Kyash Cardを利用されていて、気づいた人もいると思いますが、対応する加盟店で決済をしたときにOTPを入力せずに決済が完了したっていうケースもあります。これはリスクベース認証というもののおかげです。

リスクベース認証というのは、Visaのスコアリングとイシュア側のルールによって、3Dセキュアのユーザー認証の前に、リスク判定を行うことです。このリスク判定の結果、低リスクとなると、ユーザー認証をせずにそのままECサイト側にレスポンスするという仕組みになっています。

図のオレンジ色の部分が低リスクの場合です。ユーザー認証をスキップすることをフリクションレスフロー、ユーザー認証をスキップしないことを「チャレンジフロー」と呼んでいます。

そもそもなぜこういう仕組みがあるのかというと、3Dセキュアバージョン1のときには、都度ユーザー認証が入ることが多いから、というのが理由だと思います。結果としてカゴ落ちというECサイトで商品をカゴに入れて決済画面まで行くけど、購入しないという現象が多く発生していました。

ほかにも、3Dセキュアの全取り引きにおいて、ユーザー認証が必要なケースがそもそも少なかったというのもあって、まずはリスクの判定をしてユーザー認証をするかどうかを決める仕組みができたようです。

次にオーソリゼーションの話をします。オーソリゼーションは緑色で載せているところに関係があります。3Dセキュアの場合は、既存のオーソリゼーションの処理とちょっと異なっています。

関係のある部分をハイライトにしました。3Dセキュアの認証が成功した場合は、ACSからECサイトに向けてトークンが発行されます。ECサイト側はイシュアに対してこのトークンを電文にくっつけて送ります。こうすることによって、イシュア側はその電文が不正な3Dセキュアの電文ではないかと確認ができるようになっています。

Kyashではこの電文処理の部分を内製していて、3Dセキュア対応でフィールドが追加されたので、Parse処理など諸々の変更を行なっています。

この電文処理の変更の部分では、Visaと試験があります。今回のように、ACSが発行したトークンが最終的にイシュアまで送られてくるという一気通貫の試験を設けられていなかったので、この部分に関しては本番前のパイロット期間で自分たちで試してみるしかない感じで、やっぱり開発期間は心配でした。

将来的にはAppleのログインや生体認証の実現を予定

まとめです。まずVisaのドキュメントを読み解く必要があって、開発自体はけっこう大変でした。ただ難しい反面、チームでワイワイしながら読み合わせをして、知見を貯めながら開発できたのはよかったと思っています。

また今回、自分たちで3Dセキュア周りの実装をしたので、自分たちの開発で実際にECサイトで決済時に3Dセキュアの取り引きが行われて、商品が購入できるということはけっこう感慨深かったと思っています。

VCASの話です。今回VCASを採用することによって、他の認証手段の追加ができるようになりました。今のところOTPだけですが、アプリのログインや生体認証によって取り引きを許可することは可能なので、将来的にはこのあたりを実現していきたいなと思っています。

今回はKyashの3Dセキュア対応の話をしました。ありがとうございました。