アカウント名:
パスワード:
●は1年で自動更新なんですよね。こういうのって、一般的にはどうやっているのでしょうか。
EC構築を生業としてるのでこの業界の一般論でいうと、取引記録を決済代行会社が保持して、その前取引情報を使って再取引するのが一般的です。なので自動延長や継続課金であっても店舗側がセキュリティコードを持つようなシステムは一般的ではありません。自社でシステム部門を持って内製で構築しているようなところは技術レベルやリテラシの低さからかカード情報を暗号化せず丸ごと持つような実装なことが多いので気を付けましょう。
Twitterの外部サービスにID・PWを預ける古典的手法から、OAuthのトークンを使う形式に、みたいなものでしょうか。（1回は生情報を預けるのが違うか。なんなら最初からOAuth的に支払金融機関を挟んで、トークンだけ渡す形になればいいと常々思っている。）
JCB系のJ/Secureってそういうサービスだったような。他もあるのかな？
いわゆる3Dセキュア [wikipedia.org]ってやつですね。日本における主要4ブランド（VISA、Master、JCB、日本信販）は対応してます。
が、利用は強制されないんですよねこれ。例えばAmazonや楽天は対応してない。
これらを間に挟むと購入までのステップが増えます。その間に購入をやめる人が出るからって言うんで、このサービスを採用しないんだそうです。さらに近頃はPCからスマフォに利用環境が移りつつあり、スマフォはPCに較べて入力が面倒ですからその傾向は増しているのだとか。そのため、最近は従来PCでは3Dセキュアによる認証を入れていたサイトも、スマフォからだとカード入れただけで通ってしまうなんてこともざら。そしてガラケー時代と違い、スマフォからのアクセスかどうかはUA以外に検知する方法が乏しいから事実上PCからでもやりたい放題という。いい加減カード会社は横並びで強制してもいいと思うんですがねえ。
手間で言うと、カード情報込みで、カード会社のログインを維持するとかできれば、むしろ入力の手間は減りそうなんですけどね。
カード会社のログインを維持するリスクとしては、店舗にカード情報を保存して、1クリック購入でき、店舗のログインを維持しているのと大して変わらないように思います。追加的セキュリティとしては、初めての店舗や一定額以上では再認証するとか。一定額以上という場合、一定期間の全ての店舗での購入の合計額を基準にすれば、店舗側では制御できないものなので、店舗単独の1クリック購入よりはセキュリティが高いとも言えます。
カード情報と、カード会社のログイン情報との比較だと、クラックリスクはどうだろう。
直接カード会社に投げるんではなく、決済代行会社（GMP-PG とか Paygent とか）を通すなら、決済代行会社のプロトコルはどこもだいたいそういうふうになってます。
カード会社が1st、会員が2nd、店舗が3rdとして、3rdには機密情報を預けない方法ないものかと思ったら、4thの代行会社を挟むとな。
本人認証サービス「J/Secure（TM）」｜クレジットカードなら、JCBカード [jcb.co.jp]を見ると、最初にカード情報に店舗に渡すんですね。カード情報は単なる識別子であって、別途認証が要るという方式が全面的に確立しているならそれでもいいのでしょうが、現状そうではないので、認証情報たるカード情報の拡散リスクが残ると。
そういえば、キャップパスやトリップキーが漏れたのは、POSTデータを掲示板用に変換する前の、生に近い状態でログを取っていたからのような雰囲気を感じますが、セキュリティコードを含む●データもそんな感じのログであって、実際に使う顧客データとして保存していたものではない、という説はどうですかね。
そういえば、自動更新に使ってたカードを解約したのに、銀行から引落しがあったという話をどっかで聞いたことがある。一体どういう仕組みなんだろう。解約してもカード会社にデータが残ってる上にそれが機能するってこと？
単にタイミングの問題でしょう。解約の手続きが完了する前に、クレジットでの支払いがされていただけかと。
まず元々の話が本当かどうかってところから考えなよ
継続課金の場合、必ずしも毎回オーソリにかけるわけではなく、オーソリなしで売上データをカード会社に送ります。そのため、カードを解約してもサービスを解約するなり決済手段を変えるなりしていないと、どこかのタイミングでオーソリ弾かれるまでは解約済みカードの請求が発生し得ます。
●でそのような決済方法が取られているとして、そこからセキュリティコード保持の要・不要を考察できないでしょうか。
セキュリティコードの保持は不要なはずです。カード情報を登録する際にホルダーであることを確認するために入れさせているわけで、あとは定期的にオーソリなしで売上データをカード会社に送るわけですから。
ありがとうございます。そうすると、セキュリティコードが保存されていた理由は、継続課金のためではなく、別の理由であろうと。
単に何にも考えずに入力された情報を全部保存していただけではないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
継続課金はセキュリティコードが必要？ (スコア:1)
●は1年で自動更新なんですよね。
こういうのって、一般的にはどうやっているのでしょうか。
Re:継続課金はセキュリティコードが必要？ (スコア:5, 参考になる)
EC構築を生業としてるのでこの業界の一般論でいうと、
取引記録を決済代行会社が保持して、その前取引情報を使って再取引するのが一般的です。
なので自動延長や継続課金であっても店舗側がセキュリティコードを持つようなシステムは一般的ではありません。
自社でシステム部門を持って内製で構築しているようなところは技術レベルやリテラシの低さからか
カード情報を暗号化せず丸ごと持つような実装なことが多いので気を付けましょう。
Re:継続課金はセキュリティコードが必要？ (スコア:5, 参考になる)
そのクレジット顧客IDとクレジットトラッキングナンバーだけ自サーバーに保有しています。
で、継続課金はそのクレジット顧客IDとクレジットトラッキングナンバーを使うわけです。
そのクレジット顧客IDとクレジットトラッキングナンバーが漏れても他所で再利用はできないようになっています。
Re: (スコア:0)
Twitterの外部サービスにID・PWを預ける古典的手法から、OAuthのトークンを使う形式に、みたいなものでしょうか。
（1回は生情報を預けるのが違うか。なんなら最初からOAuth的に支払金融機関を挟んで、トークンだけ渡す形になればいいと常々思っている。）
Re: (スコア:0)
JCB系のJ/Secureってそういうサービスだったような。
他もあるのかな？
Re:継続課金はセキュリティコードが必要？ (スコア:2, 興味深い)
いわゆる3Dセキュア [wikipedia.org]ってやつですね。日本における主要4ブランド（VISA、Master、JCB、日本信販）は対応してます。
が、利用は強制されないんですよねこれ。例えばAmazonや楽天は対応してない。
これらを間に挟むと購入までのステップが増えます。その間に購入をやめる人が出るからって言うんで、このサービスを採用しないんだそうです。
さらに近頃はPCからスマフォに利用環境が移りつつあり、スマフォはPCに較べて入力が面倒ですからその傾向は増しているのだとか。
そのため、最近は従来PCでは3Dセキュアによる認証を入れていたサイトも、スマフォからだとカード入れただけで通ってしまうなんてこともざら。そしてガラケー時代と違い、スマフォからのアクセスかどうかはUA以外に検知する方法が乏しいから事実上PCからでもやりたい放題という。いい加減カード会社は横並びで強制してもいいと思うんですがねえ。
Re: (スコア:0)
手間で言うと、カード情報込みで、カード会社のログインを維持するとかできれば、むしろ入力の手間は減りそうなんですけどね。
カード会社のログインを維持するリスクとしては、店舗にカード情報を保存して、1クリック購入でき、店舗のログインを維持しているのと大して変わらないように思います。
追加的セキュリティとしては、初めての店舗や一定額以上では再認証するとか。
一定額以上という場合、一定期間の全ての店舗での購入の合計額を基準にすれば、店舗側では制御できないものなので、店舗単独の1クリック購入よりはセキュリティが高いとも言えます。
カード情報と、カード会社のログイン情報との比較だと、クラックリスクはどうだろう。
Re:継続課金はセキュリティコードが必要？ (スコア:1)
直接カード会社に投げるんではなく、決済代行会社（GMP-PG とか Paygent とか）を通すなら、
決済代行会社のプロトコルはどこもだいたいそういうふうになってます。
Re: (スコア:0)
カード会社が1st、会員が2nd、店舗が3rdとして、3rdには機密情報を預けない方法ないものかと思ったら、4thの代行会社を挟むとな。
Re: (スコア:0)
本人認証サービス「J/Secure（TM）」｜クレジットカードなら、JCBカード [jcb.co.jp]
を見ると、最初にカード情報に店舗に渡すんですね。
カード情報は単なる識別子であって、別途認証が要るという方式が全面的に確立しているならそれでもいいのでしょうが、現状そうではないので、認証情報たるカード情報の拡散リスクが残ると。
Re: (スコア:0)
そういえば、キャップパスやトリップキーが漏れたのは、POSTデータを掲示板用に変換する前の、生に近い状態でログを取っていたからのような雰囲気を感じますが、セキュリティコードを含む●データもそんな感じのログであって、実際に使う顧客データとして保存していたものではない、という説はどうですかね。
Re: (スコア:0)
そういえば、自動更新に使ってたカードを解約したのに、銀行から引落しがあったという話をどっかで聞いたことがある。
一体どういう仕組みなんだろう。解約してもカード会社にデータが残ってる上にそれが機能するってこと？
Re: (スコア:0)
単にタイミングの問題でしょう。
解約の手続きが完了する前に、クレジットでの支払いがされていただけかと。
Re: (スコア:0)
まず元々の話が本当かどうかってところから考えなよ
Re: (スコア:0)
継続課金の場合、必ずしも毎回オーソリにかけるわけではなく、オーソリなしで売上データをカード会社に送ります。そのため、カードを解約してもサービスを解約するなり決済手段を変えるなりしていないと、どこかのタイミングでオーソリ弾かれるまでは解約済みカードの請求が発生し得ます。
Re: (スコア:0)
●でそのような決済方法が取られているとして、そこからセキュリティコード保持の要・不要を考察できないでしょうか。
Re: (スコア:0)
セキュリティコードの保持は不要なはずです。カード情報を登録する際にホルダーであることを確認するために入れさせているわけで、あとは定期的にオーソリなしで売上データをカード会社に送るわけですから。
Re: (スコア:0)
ありがとうございます。
そうすると、セキュリティコードが保存されていた理由は、継続課金のためではなく、別の理由であろうと。
Re: (スコア:0)
単に何にも考えずに入力された情報を全部保存していただけではないかと。