Merpay Tech Fest 2022 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2022年8月23日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「Credit Card Payment Security: adding 3D Secure SDK for Merpay iOS」の書き起こしです。
Credit Card Payment Security: adding 3D Secure SDK for Merpay iOSのセッションに、ようこそお越しくださいました。
自己紹介
メルペイでiOSエンジニアをしています、Mikael LE GOFFです。最初はiOSの開発で・Objective-Cに携わりました。そして、いまはフィンテックとチームワークに情熱を注いで持っています。
2019年にメルペイに入社し、現在はメルカリ/メルペイiOSを利用しているお客さまのユーザーが最高の体験ができるようにすべてのエネルギーを費やしています。プロジェクトの管理も大好きでスクラムマスターでもあります。スキルを利用してチームの力になり、最高の結果に貢献していきたいです。
What is 3D Secure
最初に、技術の紹介をします。
3D Secureとはprotocolのことで、ブラウザベースとモバイルベースの両方のアプリを使ったオンラインでの支払いにおける認証セキュリティの確保を目的としています。クレジットカードで支払いをする際の取引でのセキュリティを確保しています。
3Dとは、Issuer・Interoperability・Acquirerの3つのドメインを示しています。
Issuerドメインは基本的にカードの発行者、Interoperabilityドメインは3Dセキュリティのprotocolを深く管理する中間のインフラストラクチャです。Acquirerドメインはサービス利用者が誰かによりますが、支払い先の加盟店や銀行が該当します。我々メルカリ/メルペイはAcquirerドメインサイドに含まれます。
続いて、protocolの歴史を振り返ります。1999年にCelo Communications ABにより作成されました。現在はThales Groupとなっています。
かつてこの技術はp42と呼ばれていましたが、2001年、Arcot SystemsとVisaによってVisa Secureという名称になりました。
2016年にはEMVCoによりprotocolのバージョン2がリリースされました。そして欧州連合の新規認証要件が満たされました。これが、現在使用されている最新版です。
では3D Secureはどう動作するのでしょうか。
まずお客さまがクレジットカードで物を買おうとします。すると、3D Secureのシステムが取引のリスクを予測します。購入を続けていくためにワンタイムパスワードの入力を要求される場合もありますし、何も要求されないこともあります。本スライドの場合は、摩擦のないフリクションレストランザクションです。
グローバルのデータをご紹介します。3D Secureの使用者数・フリクションレスの支払い数は世界でどのくらいでしょうか。
北米ではカード支払いの90%が3D Secureとなっています。欧州では65%、グローバルでは65%です。フリクションレスの支払いについては、北米では20%しかありませんが、欧州およびグローバルの数字は41%です。今後さらにフリクションレスの支払いを増やす、つまりお客さまが何もしなくて済むようにするのが目標です。
Problem we needed to solve
我々が解決しなければならない問題点は、クレジットカードの盗難です。盗まれたクレジットカードは、我々のサービスの中で使われるべきではありません。
オンライン・オフラインともに、クレジットカードを盗む方法はたくさんあります。オフラインの例としてはクレジットカードの写真を撮られる、店舗の支払い端末で情報が盗まれることがあげられます。オンラインでは、インターネットショッピングでクレジットカードの情報を入力した際、ハッカーに情報を引き出される可能性があります。
我々のプロダクトにおいて、盗難されたクレジットカードが使われることを避けなければなりません。3D Secureがなかったらどうなるかというシナリオを考えてみましょう。
例えば、お客さまAのクレジットカードが盗まれたとします。そのカードを使ってお客さまBがメルカリで商品を買おうとしたとき、3D Secureがないとメルカリは盗難されたカードであると把握できません。そうしますと選択肢は一つしかなく、購買プロセスの処理に入らざるを得ないのです。支払いに問題があれば最終的にお客さまへ返金されます。ちなみに、現在メルカリでの取引は3D Secureが100%使われています。
How to identify security risks？
では、セキュリティのリスクをどう判別するのでしょうか。支払い上の問題をフィルタリングする上で、これが一番重要な問題です。
メルカリでの購入で我々がチェックするのは、このアイテムは不正ユーザーが購入するリスクが高いか、クレジットカードは盗難されたものであるというリスクはどのくらいか、です。
不正購入については、AML（Anti Money Laundering / マネー・ローンダリング防止対策）システムによって不正の確率を推定します。また、支払いに使われるクレジットカードが本人のものであることも確認します。
また、クレジットカード取引のリスク審査に3D Secureを使っています。掲載されているスクリーンショットは、メルカリのチェックアウト画面です。クレジットカードで購入するときはこの画面に遷移し、「リスクあり」と判断されると何らかの反応、いわゆるチャレンジが発生します。3D Secureはカード取引の判定を行い、リスクレベルを返します。
ここで、リスクレベルとは何かを簡単に説明します。
一番左の列は上からリスクが低・中・高となっています。当然、リスクが低い方を私たちは望んでいます。リスクが低ければお客さまもパスワード入力など面倒な作業がなくシンプルに取引を済ませられるからです。よって、基本的には低リスクのトランザクションが望まれます。
リスクが中程度と判断されると、システム側で個人情報やワンタイムパスワードが要求されます。お客さまは要求された情報を入力し、正しければ支払いができるのです。
リスクが高すぎる場合、トランザクション拒否となります。選択した品をそのクレジットカードで購入することはできません。
Security and trust using 3DS SDK for iOS
メルカリでは、セキュリティの向上に努めています。また iOS の3D Secure SDK の信頼性の向上にも努めています。クライアントアプリケーションに3D Secure SDKが追加されました。ちなみに、Androidアプリやフロントエンドウェブのコンテンツもあります。
メルカリ上では3D Secure SDKの追加によってお客さまの信頼性を高め、クレジットカードの本当の所有者のみがカードを使えるようにしています。購入者が盗んだクレジットカードを使って商品を購入しようとしても、システムから停止がかかります。
3D Secureからリスク確認につながるパスワードのお話をしましたが3D Secureが要求するパスワードとは 何でしょうか。
パスワードはワンタイムパスワードであることが多いです。ワンタイムパスワードはOTPとも呼ばれており、クレジットカードのIssuerから提供されます。取引に中程度のリスクがある場合は、常に新規のパスワードが要求されるのです。
通常、クレジットカードのIssuerはSMSでOTPをお客さま個人の携帯番号に送付します。OTP送付には他の方法もありますが、SMSの使用が多くの方にとって簡単な方法でしょう。
Implementation details
ここで、実装について紹介します。
左側のスクリーンショットは、メルカリのチェックアウト画面です。中程度のリスクの取引と判断された場合、3Dパスワードの入力画面（中央のスクリーンショット）が表示されます。
ここはクレジットカードの発行会社のポータルで、OTPが要求されます。そこでパスワードを入力し、それが正しいものであれば購入できるようになります。
つまり、クレジットカードの決済要求が確認された後の画面では3D Secureモデルを表示できます。ここでモデルを使っているのは、3D Secure SDKの仕様上、こうなることが想定されているからです。
購入手続きを進めるために、クレジットカードのOTPを要求されます。他にもフリクションレスフローのように、モデル画面が表示されず直接取引成功の画面が表示されるフローもあります。リスクが非常に高い場合は画面にエラーメッセージが表示され、取引が拒否されます。
セキュリティ上の理由から、内部アーキテクチャは常にシンプルにする必要があります。こちらにあるように、メルカリ/メルペイのiOSのアプリがあり、3D Secure SDKが統合されています。3D Secure SDKはさまざまなクレジットカードやプロバイダー、パートナーやそのサーバーとやりとりをします。
一方、アプリ側はバックエンドとやり取りをする必要があります。バックエンドはパートナーに特定の情報を送信・要求します。取引の安全性を確保するために、その場でセキュリティとある種の個人情報を交換しているのです。
既存のコードに新しいSDKを追加すると、どうなるでしょうか。
メルカリのiOSアプリは、かなり大きなiOSのソフトウェアです。3D Secure SDKなど外部のフレームワークを追加する場合、パフォーマンスやセキュリティバイナリーサイズに影響がないことを確認しなければなりません。
パフォーマンスに関してはSDKの不具合によって、アプリの動作が遅くなったり落ちたりといったことを避けたいと思います。
セキュリティについてSDKプロバイダーと協力し、SDK側と私たちで多くのセキュリティの側面をチェックいたします。
アプリのバイナリサイズについては。リリース版のバイナリに何らかの最適化を行っています。例えばApp Storeに大きなソフトウェアを載せると、お客さまがスマホにアプリをインストールする際、長時間待たされる可能性があるからです。
また、SDKはxcframeworkである必要があります。これはXcode 12から必須で、M1 arm 64 architectureへの移行をサポートするためです。SDKは今年もしくは来年に更新される可能性があります。SDK側もしくは私たちの改善次第です。
したがってこの場合、以前のメルカリバージョンに影響を与えないようにする必要があります。SDKを追加して抽象化レイヤーを確保する必要があります。例えばクライアント側でswift protocolsを使うなどしてSDKをバージョンアップした際、コンパイル時にコンフリクトや問題が起きないようにします。
今回の開発で苦労した点についてです。
まずはバグの修正です。まったく新しいプロジェクトでしたのでバグが出るということは想定内でした。このような複雑なシステムの統合には時間がかかりますので、その過程でバグが発生する可能性もあります。SDKのログを元にデバッグを行い、パートナーとともに問題の原因を特定する必要がありました（問題が私たちにあるのか3D Secure SDK側にあるのか）。
そのためSDKや仕様を深く理解し、効率よく打ち合わせをするためのデータを毎回用意する必要がありました。SDKからはたくさんのログが出ることは想像できますが、パートナー側の問題を見つけられるよう、パートナーにとって有意義な情報をフィルタリングする必要もあります。
また、話を理解しやすくするためにシンプルな英語を使い、よりインクルーシブに説明するようにしました。ほとんどの人は英語が話せますが、それは当たり前のことではありません。そのため、多くの人と会議をするときは言語にも配慮しなければならないのです。
レガシーサポートに関しては、古いアプリがまだ動作しているか、アプリは3D Secure SDKをサポートしているか、新しい3D Secureの移行が成功するかを確認する必要があります。
メルペイでは、新機能を提供してABテストを行うためにFeature Flagsを使用しています。これにより、新機能を段階的にリリースできます。
たとえば3D Secureの場合、当初は新機能をお客さまの10%にしかリリースしない予定でした。Feature Flagsを使うとコードが複雑になり、QAによるリグレッションテストが必要になります。お客さまの10%だけが新しい3D Secure SDKを使っている場合、残り9割のお客さまはそれを使用していないので、全体的にしっかりと動作することを確認する必要があります。
QAはQuality Assurance（品質保証）の略です。特に何らかのシステムを開発する場合、障害対策のために優れたQAチームを持つことは必須です。特にフロントエンドではそれが顕著です。
私たちiOSの場合、QAチームはどのような問題でもフォローアップしてくれるので本当に必要な存在でした。
またQAチームはエンジニアでもありますので、問題のデバッグを支援してくれるかもしれ ません。こちらが想像もしていなかったようなユースケースを思いつく可能性もあります。
この場合システムは複雑で3D Secure SDKを通じて多くのクレジットカード会社に依存しています。そのためソフトウェアのイテレーションごとにカード発行会社のシナリオを含め、従来のフローと新しいフローをQAチームがチェックしなければなりませんでした。
最後に、パートナーとのUXの向上です。UXとは基本的にお客さまとのインタラクションを意味します。UXはとても重要です。メルカリのUXを向上させるために、私たちはパートナー企業とともに取り組んできました。
まず、エラーのフィードバックに説明文を追加しました。3D Secure SDKにはデフォルトでエラーのフィードバックが含まれています。それは、私たち自身が書いたコードではありません。私たちはお客さまに表示するものすべてをコントロールできるようにしたいと考えました。
そこで3D Secure SDKから送られてくるすべてのエラーメッセージをカスタマイズする必要がありました。またエラーが発生した場合の支払フロー・決済フローも更新しました。エラーにはさまざまな種類があるため、ときに異なる方法で対処する必要がありました。
この新機能はAndroidにも実装されているためOS固有のユーザーインタラクションについても議論しました。例えばAndroidではパスワードを入力するチャレンジ画面は画面上に表示される新しいアクティビティになります。しかしiOSの場合、ページシートが表示されることになります。
Credits to the team.
それでは、ここでチームを讃えたいと思います。非常に重要なことです。
大規模なプロジェクトでしたので、達成するためにこれだけの人数が必要でした。一緒に何か月も仕事をしたプロジェクトマネージャ、Androidエンジニア、UXデザイナー、バックエンドエンジニア、そして素晴らしいパートナーの皆様のおかげで、このプロジェクトを実現できました。ありがとうございました。
Links
3D Secureの使用についてより深く知りたい方、世界の3D Secureの使用状況について詳しく知りたい方はぜひこれらのリンクをご参照ください。
参考資料
The latest 3D Secure specification is made by EMVCo, LLC.：
https://www.emvco.com/terms-of-use/?u=wp-content/uploads/documents/EMVCo_3DS_SdkSpec_210_1017-1.pdf
Data related 3DS usage in the world：
https://www.ravelin.com/global-payment-regulation-map
ご清聴いただきありがとうございました。
