GMOのMakeshopやEストアーのショップサーブを始めとして、今は信頼出来るASPカートがたくさんありますね。
ちょっと前までASPカートで定期販売と言えばたまごカート1択の状況だったのに、他のサービスも定期課金や発送リマインダー等がオプションで追加出来るようになっています。
安価なカラーミーでも基本的な事なら出来るし、stores.jpの様なおしゃれな無料サイトも注目です。
基本的なカートの性能はほぼ横並びになり、後は決済代行やフルフィルメント（佐川E飛伝やヤマトB2等の帳票関連とのつなぎ等）部分の簡略化、効果測定（CPO、メディアレーション等がカート内でどれだけ把握出来るか？）のようなオペレーション部分が、各社差別化のポイントのひとつだと思います。
ところで、今まで様々なショッピングカートの公式サイトの「機能紹介」ページに記載されていない項目があります。
それは、あたりまえですが、将来的な他社カートへの引越し方法、その際に引き継げるデータ。
ここは、契約前に担当者に質問しておくと良いです。
下記、一般的な例を紹介します。
会員数従量課金であったり、自社基幹システムの一新に伴う繋ぎの問題であったり、ちょっとした機能の違いや決済手数料のち外等でショッピングカートの乗り換えを検討することがありますが（と言うより、ひとつのサービスを永遠に使う前提で通販構築はしない方が良いですよね）、その時に少し悩ましい問題があります。
それは、「会員パスワード」です。
商品マスタや会員ID等はCSVでダーッとダウンロードして、新しいサービスにアップしてしまえば良いのですが、「会員パスワード」だけはどうしようも無い事が多いのです。
ショッピングカート会社からの回答は「セキュリティの為」です。
詳細は省きますが、パスワードは暗号化された不可逆性の英数字になってデータ化されています。
「1234abcd」と言うパスワードがあったとして、これにある式を使い、「0dn3eufy73hfdahefr47qyfh…….」の様な形に変換しています。
「1234abcd」は常に「0dn3eufy73hfdahefr47qyfh…….」になりますが、
「0dn3eufy73hfdahefr47qyfh…….」から「1234abcd」を導き出す方法はありません。（数兆年かけた総当り戦云々は別として）
と言う事は、データベースには「0dn3eufy73hfdahefr47qyfh…….」だけ入れおいて、会員が「1234abcd」と入れた時にサーバー上で変換、一致すればログイン、と言う事にすれば、ショッピングカートの会社も通販運用サイトも、「万が一の情報漏えい」の時のリスクを少しは低減できる訳です。
たしかにそのとおりで、スタッフの入れ替わりも激しい小さい通販会社なんかのPCの中の会員リストCSVにパスワードがそのまま入っていたら危なくてしょうがないですね。
と言うわけで、ショッピングカートの会社が「簡単には他社に引越しさせませんよ」と言ってるわけでは無い？事がわかった所で、次回は、じゃあ引越しの場合はどうしたら良いか、に移ります。
