トークン決済に移行したら決済エラーが頻発した件。


企業のWeb担当者やWeb制作、Web系のシステム業界の話です。

ECサイトや特定の予約サービスなどで、決済代行会社を利用している小・中規模のサイトでは、その決済代行会社より「トークン決済方式」への切り替えを要求されたご担当者も多いと思います。

これは経済産業省が指針「「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」によるもので、2018年6月までにクレジットカード情報を非保持化する方式(トークン決済方式)へ切り替える必要があってのことと認識しています。

そもそも、大手ECはともかく、中小のECサイトや決済が必要なサイトは数年前まで決済を決済代行会社の画面で行う「リンク方式」と、ECサイト側の画面に導入する「モジュール方式」が主流でした。

前者(リンク方式)は決済がECサイト側ではないのでデータ送信時のリスクは考えなくてもいいですが、画面のデザインが変わってしまい、カッコ悪いという理由で、後者(モジュール方式)を導入している場合が多いように思います。

ただ、そのモジュール方式でも、数年前は「カード情報はECサイト側で保存しなくていいからら安心」と決済代行会社は言っていました。

しかし、今になって「カード情報はサーバを通過するんですよ、だからダメ」と言い直してきたため、「保存しないから安心って言ってたのに、今度はサーバを通過するからダメって、なんだよ!」と思うわけです。

まあ、上げ足を取っても仕方ないというか、それだけカード情報の送信を暗号化(トークン化)しなくてはならない時代になったということですね。

私も複数の決済のあるサイトに関与しているので、ここ数か月でECサイトのCMSの決済モジュールを更新(変更)したり、某サイトではプログラマさんに改修いただいたりしました。

ここからが本題ですけど。

先日も某サイトの改修をプログラマさんにやってもらったのですが、その後、決済エラーのクレームが頻発しました。

もちろんテスト環境でのテストを終えてから本番環境にリリースし、直後にPCやスマホで複数注文を入れて無事決済ができたことも確認いたのですが、なにが悪いのかわかりません。

クライアントもユーザーのデバイスの種類やOS、ブラウザの種類やバージョンなどをユーザーから詳しく聞いていない状態で「エラーを調べてほしい」と来るのですが、正直、なにが原因かはわかりませんでした。

決済代行会社のほうも、それだけの情報では調べようがなく、無事決済出来た人のほうが多いし、端末側の問題ではないのか?とも言っていたようです。

その後、大多数のユーザーさんは決済できているのですが、エラーとなるユーザーのクレームはポツポツと発生し続けます。

それでも決済代行会社のほうは、エラー記録はない、もっと詳しいユーザー側の環境情報がないとわからないということで、本腰をいれてくれません。

結局、こちらのエンジニアから憶測で、「決済代行会社のトークンサイトのポート番号が問題ではないか?」ということになり、決済代行会社に確認すると、もらっていた接続仕様書に書かれているポートは2443ポートだけが解放されている状態で、仕様書には無い別の443ポートだけが解放されたURLがメールで案内されました。

「おいっ!」

仕様書で接続先を変更していたのなら、最初にエラーの相談をした際に、決済代行会社のほうから「自社が渡した接続仕様書が古いのでではないか?」と怪しんで言ってきてほしかったです。

弊社が直接契約している決済代行会社(S社)ではないし、どこの決済代行会社とも書きませんが、さすが●●●グループ会社品質。
エラーに振り回された側としてはちょっといい加減すぎないか?と思った次第です。


コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください