またまた、興味を持ってくれる読者がいないんじゃないかと思われるような、ニーズの乏しい話を書きます。

先日、某ECサイトの3Dセキュア決済システムのテストをしていました。

ステージング（テスト）環境では、テストのためにパスワードを登録していないが正常なカードや、3Dセキュアに対応しているカード、限度額をオーバーしているカード、登録はできるが利用時にエラーの出るカードほか、さまざまなテスト用のクレジットカードが用意されています。

当然、そういったカードを使ってイヤになるほどカード決済、変更、キャンセルを繰り返したテストを行い、かつ意図的にもエラーも出しまくるわけです。

そしてそのテストをクリアしたのち、本番環境で決済代行会社の本番につなぎ、実決済を試みることになります。

特に3Dセキュアの場合、加盟店側のステージング環境と決済代行会社のステージング環境、さらにその先のクレジットカード発行会社（イシュア）が用意するステージングのパスワード認証画面に飛びたいところですが、最後のそれ（カード発行会社が用意するステージングのパスワード認証画面）がありません。

その代わりに決済代行会社が用意したダミー（クレジットカード発行会社の画面として）のパスワード認証画面に飛ぶことになります。

しかし、まずそこに落とし穴があります。

決済代行会社が用意したダミーのパスワード認証画面はおおむねチェックが甘く接続上のアプリの不備をスルーしてしまいがちで、クレジットカード会社が用意する本物のパスワード認証画面では通らないケースが多いのです。

そこで、ステージング環境でのテストの総仕上げとして、本物のカードを使って本番の決済をすることになります。

ECサイトはステージング環境から、または新規サイトであれば本番環境から決済代行会社の本番環境へ接続し、クレジットカード会社が用意する本物のパスワード認証画面へ遷移して決済し、それを最終テストとするのです。

そうすると、本番でしかわからないエラーが出たりします。

また現実では、クレジットカード会社が用意するパスワード認証画面で、ユーザーがカードにパスワードを登録しているにもかかわらず、「パスワード？なにそれ？」となる場合が想像できます。

実際はカード発行会社のWEBサイトで使うパスワードがそれに該当しているのですが、本人は「暗唱番号じゃなくて？」と思ったりすることもあるでしょう。

下記がそのパスワードを求める画面の一例です。

そういったことを想定して、テストする側ではパスワードをわざと間違えたり、その画面で認証をキャンセルしたりするのですが、実は本物のカードであるが故に、各カード発行会社のセキュリティ基準が厳しいと、あっという間にロックされてしまいます。

私の経験で言えば、三井住友VISAカードが厳しかったです。

１回パスワード画面でキャンセル離脱すると、その後、すぐに再試行しても弾かれます。

弾かれるというのは、もう1度決済しようとしても、パスワード画面すら表示に至らず、「認証エラー」が戻されます。

少し待って（10分なのか30分なのか覚えていませんが）試行すると、やっとパスワード画面を出してくれたりしますが、数回パスワード画面でキャンセル離脱するとロックされて自動的には解除されません。

それがテスト者の被る落とし穴というか、ECサイトのアプリの問題なのか否かの判断に迷うわけです。

結果として私の場合は、本当にカード会社にロックされていて、1個人としてカスタマーセンターに電話して、セキュリティ関係部署の人から折り返し電話をもらい、ロックを手動で外してもらいましたが、何分間に何度間違えるとロックされるとか、そういったことは質問しても教えてくれませんでしたし、カード発行会社によっても仕様は違うようです。

やはりカード発行会社の認証の仕様やリスク判定基準は厳秘でしょうけど、開発側からするとそのブラックボックスなところが結構面倒です。

私の場合、テストなので同じ商品を何度も購入しては繰り返し取引をキャンセルしたり、短時間に認証キャンセルを繰り返す必要もあって、たぶんVISAカードのAIが「怪しい」と思ったのでしょう。

そりゃテストですから怪しい動作ですよ。AIも当然の判断かと思います。

そのAIってNTTデータの下記の記事のことですかね。

「3-D Secure本人認証サービス」にリスクベース認証機能を導入
リスクベース認証について
リスクベース認証では、ACS（CAFIS BlueGateユーザー認証サービス）にて、クレジットカード会員が使用するデバイスの設定情報を取得し、取引情報とあわせて不正リスクを判定し認証を行います。不正リスク判定の処理結果において危険な取引（リスク高）と判定された場合には、決済に入らないよう、3-D Secureの認証失敗の結果を加盟店に返却します。クレジットカード会社では、不正使用取引の実態（ネガティブ/ポジティブデータ）をリスク判定エンジンに登録することにより、運用においてリスク判定スコアリングモデルのチューニングを行います。

また、某社発行のMASTERCARDのほうは、住友VISAと違って1度認証キャンセルしてすぐに再試行しても弾かず決済してくれました。

正常に機能して良かったと安心していたのですが、翌日再テストすると、システムになにも変更を加えていないのに、パスワードを求める画面が表示されないまま、決済が完結しました。

そのカード会社のQ&Aで3Dセキュアのパスワード入力画面が表示されません、という問いに対し、回答は「加盟店が本人認証サービス（３Dセキュア）を採用していない」か「3Dセキュアがシステムメンテナンス中でサービスを停止している」というものでした。

いやいや、昨日はきちんとパスワードを求める画面を出してくれてたじゃないか！

こっちはなにもシステムを変えてないし別のブランドのカードでは今日もパスワード画面を表示してくれてるよ！

・・ということで、１個人ユーザーとしてこのMASTERCARDを発行しているカード会社のカスタマーセンターに電話して、質問しました。

もちろん、ECサイトがメンテでも3Dセキュア非導入でもなく、昨日はきちんとパスワード画面が出たのに今日は出ない旨を、伝えました。

この3Dセキュア関係の込みいった質問に関しては、その場では答えが出ず、数時間後に折り返しの電話をもらいました。

結果としては、同じデバイス、同じIPとか同じサイトで3Dセキュア認証で決済が完了した場合、自動的にリスク判定でリスクが低い場合、パスワード画面の表示を省いて3Dセキュア認証を通過、決済する場合があるとのことでした。

いわゆるAIの判定のようですが、カード発行会社のほうの仕様がブラックボックスなだけに・・・テスト泣かせです。

この、3Dセキュアなのにパスワードを求めないという現象もひょっとしたら、上記のNTTデータの記事に

3-D Secure2.0では、今回のサービス提供で用いるリスクベース認証の概念が標準機能として取り入れられ、クレジットカード決済の大多数がパスワードを求めない取引とすることで、カード会員の利便性を向上させることが定義されています。

とあるのでパスワードを求めなかったのかも知れません。

ほかにも、最近の話題としてGoogle Chrome 80問題があります。

詳しくは「Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた」に書かれていますが、2020年2月4日にGoogle Chrome 80がリリースされて以降、業界では阿鼻叫喚というか、ECサイトがGoogle Chrome 80に対応していないと3Dセキュア導入サイトで買い物ができなくなっている問題があります。

GoogleがChrome 80でセキュリティ強化のために行ったCookieの取り扱い仕様変更が、カード業界の不正利用対策である3Dセキュアの既存仕様をダメにしたって感もある事象です。

つまらない話が長くなりました。
現場からは以上です。