クレジットカード決済の実装 、一番いいのは

• Amazon Payment
• Paypal

みたいに完全に外部のサービスとして構築されていてそこにリダイレクトして処理が行われるものを使うことだろう。

ただ Amazon アカウントもってないだとか Paypal アカウント持ってないだとかいう人は結構多いし、 B2B 系だとさらにいろいろ面倒は増すと思う。国内だと GMO ペイメントがアカウントなしで GMO 側のドメインで決済できるものを提供していたと思うが使ったことないのでよく知らない。こういうタイプは最も望ましい、と思う。

まあ他にもそういうリンク型みたいのいろいろあるだろ。専門じゃないからよく知らん。

非通過型決済とでもいうのか、クライアントサイドで決済を行なって決済事業者としかクレカ情報をやり取りしないタイプの決済サービスが最近は出てきている。 Stripe がそういうのだと代表的なのかな？国内だと pay.jp とか GMO ペイメントのトークン決済とか。

こういうの実は侵入に対する脆弱性は従来型の決済サービスとそこまで変わらんと思う。 http://anond.hatelabo.jp/20170322160743 にも書いたが結局侵入を受ければ一定期間の間に入力されたクレジットカード番号は抜かれてしまうので。

• 自社のデータベースに保存していたクレジットカード番号 5 万件が流出しました
• 侵入を受けていた 2 週間の間に入力されたクレジットカード番号 350 件が流出しました

という事案を比較したときに、企業イメージなりサービスなりへのダメージはその総量はほとんど変化がないのではないか。

はっきりいって自社ドメインにクレカ番号入力ページを設けるメリットは何一つとしてないと思う。どうしてもやりたいんであれば、決済ページだけ完全にドメイン、サーバー、ネットワークなどを分けるしかないのでは。

例えば kanekure.ssig33.com にクレカ決済を入れたいとしたら kanekure-payment.com みたいなドメインを別途設けてそこに OAuth その他 SSO 手段で安全に認証情報を渡してそこで決済させる、みたいな。その決済ドメインでは決済サービス提供以外の JavaScript などは一切使用しないようする。これは DOM Based XSS の可能性を極限まで下げるため。またサーバーセキュリティなども本体サービスとは別基準で運用する。

ようするに Paypal とかリンク型の決済サービスとかを車輪の再発明するしかないと思うのですよ。もし Stripe や pay.jp みたいのを使う場合でも。

だったら最初から Paypal とかリンク型の決済サービスを使っとけばいいよねという話だし、 JavaScript 型のクレカ決済サービスは本質的にナンセンスなものだと俺は思っている。