|
前回まででテストも完了して，いよいよサイトのオープンという段階まで進んだのですが，ここで話は少し戻ります。サイトによっては決済システムを導入しなければならなかったり，メールマガジンの発行，Web2.0的発想からブログやBBS，SNSといったコミュニティ系システムとの連携を図りたいという場合もあるかもしれません。
こうしたシステムはサイトの本筋とは別の物で，いわば付加機能だと考えられます。どういった付加機能があり，それは内製すべきなのか，はたまたツールやサービスを購入したほうがいいのか。今回は付加機能の勉強です。
決済機能を付加する
ここまでのお話は，Web+DBという公約数で，どんな業種のサイトにもあてはまる物を選んで説明してきました。今回のお話は業種によっては必要のない話かもしれません。ただいくつかのお話は，今後のサイト拡張などにもかかわってくると思いますので，今は関係がないという方も暇つぶし程度の気持ちで読んでいただければと思います。
淡々と機能だけ説明してもイメージが沸きにくいので，雑貨ショップのサイトということにしましょう。このサイトには，いくつかの商品カテゴリがあって，カテゴリのリンクをたどったり，検索フォームからの自由入力で商品が検索できます。検索した結果から，閲覧者は欲しい物をカートに入れて購入できます。
このサイトのシステム開発では，検索機能，カート，表から見えない部分で商品の登録，編集といった機能を作成します。「あれ？支払いは？」と思われるかもしれません。実はシステムの開発で，支払いシステムは作らないということがよくあります。ではどうやって支払い機能を実装するのでしょうか。
一般的な小売店であれば，支払い方法というのは対面での商品と代金の交換しかありません。しかし対面商売ができないネットでは事情が異なってきます。ネットで物を買う場合の支払いにはいくつかの方法があります。システムとしての開発で，実装が最も簡単なのは「料金着払い/代引き」システムです。これは注文があった商品を発送し，到着時に宅配業者が玄関先で支払いを受け取る方法，あるいは商品の箱の中に振込用紙が入っていて，顧客が銀行やコンビニエンスストア，郵便局などから支払うという方法です。
さらに簡単な支払い方法として「料金前払い」というのもありますね。これは振込などで払ってもらったことを確認できたら商品を発送するという方法で，オークションなどではよく使われています。しかしネットの販売サイトで前払い方式というのは，ネット詐欺の感じが強いため，顧客にはあまり好かれません。
着払いや代引きについてはクレジット・カードをネットで使いたくないという顧客が多いため，結構な需要があります。実際私の周りでも「カード決済ができるサイトでも着払いができるなら着払いのほうで買う」という友人知人がたくさんいます。売る側としては，到着時に支払いを受け取れる代引きはいいとしても，商品先送り代金後払いというのは不払いや踏み倒しが怖いので，開発時にもあまり提案されなくなってきています。買う側も売る側も先に渡したほうが不利という意識があるわけです。
買い物における心情論は置いておくとして，システム開発の面から言うと，先払いにしろ後払いにしろ，顧客から預かる情報は氏名と住所程度ですみます。その正当性などを判断する必要もありません。実はメールで住所や氏名と欲しい商品名を送ってもらえばシステムの流れとしてはできてしまうため，サーバー側に情報を残す必要性も薄いですし，顧客情報のセキュリティも保ちやすくなります。ブラウザ上のフォームから氏名と住所と商品名をメールで送信するだけであればPHPやデータベースを使用することなく，単純なHTMLだけでも作成できます。そのためか数年前までの小さなPCパーツショップや農家の直販サイトなどでは，こうした形式でのECサイトがたくさんありました。
しかしECサイトとしてのステータスを考えた場合，仮に顧客の大半が代引きを選択するとしても，販売店側としてはクレジットカード決済機能は搭載したくなります。「カード払いができる会社＝信用のある会社」 という印象があることは否めません。
さてそのカード決済ですが，これは単純にカード番号だけを預かればいいというものではありません。入力されたカード番号のクレジット・カードが実在し，そのカードが決済に使用できるのかを確認し(停止していたり限度額を超えていることがあります)，それからやっと請求ができるわけです。そのカードが利用できるのかどうかは買い物をしたその場で判断が必要です。
ではどうすればいいのでしょうか。結論から申し上げると，カード決済のシステムは案件ごとに開発するようなものではありません。ほとんどの場合，決済外部サービスを利用します。
まずカード決済では1社限定というのは非現実的で，メジャーな4～5社のカードが使用できなくてはなりません。そのカードが使用できるかどうか(これをオーソリといいます)を確認するには，各カード会社のデータベースに問い合わせをする必要があります。当然ながら各カード会社が，ある任意のカード番号がショッピングに利用できるのかを誰でも彼でも確認できるようにオープンにしているということはありません。あるカード番号が存在するのかどうかですら確認する仕組みを公にはしていません。
カード決済をシステムとして導入するには，カード会社各社に直接問い合わせる何らかの方法--これはカード会社のデータベースへのアクセスを意味します--を実装する必要があるというわけです。しかし現実的には直接カード会社のデータベースへ接続するための方法は提供されていません。つまりカード決済システムを内製する方法というものがもともと存在していないというわけです。
ではどうやって決済を行うのかということですが，カード会社あるいは別の決済専門会社が提供している外部サービスを利用することになります。決済外部サービスに対して，こちらのサーバーから必要な情報を送信し，そのカード番号が利用できるのであれば，請求金額を送信するという仕組みです。決済システムはブラウザ上に画面としては出ず，閲覧者には決済システムに制御推移したことはわかりにくいように配慮されている場合がほとんどです（図1）。
図1●決済関係の流れ（決済画面は決済サービスにより提供される）
ネット決済はクレジット・カードだけではなく，プリペイド・システムを使ったサービスもあります。WebMoneyやBitCashなどが該当します。Edyのような携帯電話チャージ型電子マネーの一部もネット決済で利用できます。
プリペイド型はコンビニエンスストアなどで金銭と交換で支払い用のIDを受け取り，そのIDをブラウザから入力することで支払いに代えるというシステムです。クレジット・カードで買い物をするのは怖いけど，仕事の都合で帰宅が遅くて代引きが面倒，近くに銀行や郵便局がなく到着後の振込も面倒という人たちが主に利用しています。カードが使用できない未成年者も利用層に入ります。プリペイド型の決済システムはクレジット・カードと比べれば必要性は高くありませんが，前述のように未成年者もターゲットとしているようなサイトでは導入検討の余地があります。こうしたプリペイド型の決済も支払い部分は外部サービスを利用することになります。
つまり決済部分の処理エンジンそのものは内製できるものではなく，カード会社やプリペイド会社が提供している外部サービスを利用しなくてはならないというわけですね。カード決済もプリペイド決済も，システムを利用するためにはそれぞれ各社との契約が必要です。契約前の審査などで若干日数を要する可能性もあるので，決済型サイトを構築する場合には早めに契約処理を進めておく必要があります。
それぞれが外部サービスですが，カード会社で数社，プリペイドも数社ということになると個別にこちらのシステムも合わせていかなくてはならないという手間ができます。そこでカード/プリペイドの決済を一手にまとめて引き受けるという外部決済サービスを提供している企業も存在します。サイバーソースやゼロといった企業です。開発側の視点から見ると，こうしたワンストップ型の外部サービスは開発工数を短縮することができるため非常に重宝です。PCだけでなく携帯サイトも併設する場合にも対応してくれます。
閲覧者には決済そのものが外部サービスになっているかどうかといったことはわかりません。同様に決済のテストを行っているときに，あなたの目にもわからないと思います。外部とやり取りしているんだということを明確に把握しているのは，おそらく開発を直接担当しているプログラマだけです。技術的な問題が発生した際には，プログラマが直接外部サービス側の技術担当と質疑応答ができる環境を作ってあげてください。
外部サービス側とプログラマの連絡がスムーズに行われず，質問と回答の往復に数日を要するようだとシステムの安定性が損なわれます。金銭にかかわるトラブルはサイトにも運営する会社にも大きなダメージを与えかねません。「決済システムは内製していたんじゃないのか？」とトンチンカンなことを言い出さないように，ここはしっかりと理解しておきたいところです。
ここで念を押しておきます。実際にカードが使えるかどうか，支払いが成立したかどうかを判断している部分はプログラマが作ったものではなく外部サービスです。何らかのトラブルが発生した場合，外部サービスに対して通信しているこちらに問題があるのか，はたまた外部サービス側に問題があるのかということも考えておかなくてはならないでしょう。外部サービスの中身そのものはブラックボックスで，いったいどういう仕組みでオーソリや決済を行っているのかはわかりません。その中身に問題があった場合，こちら側のプログラマは手の施しようがありません。
カード決済の結果や指定日間の売り上げ統計は外部サービス側で提供されている場合がほとんどです。一方，何がいくつ売れたのかという商品側の情報は，こちら側の管理画面になります。決済外部サービスは決済に特化しているため，カード番号のほかにはいくら買ったかという情報しかありません。誰がいつどんな商品を買ったのかという部分はこちらのサーバーでまとめる必要があります。
管理画面が分かれているのが一瞬面倒に思えます。外部サービスを利用する際のポイントですが，統計などはそれを専門でやっている側で確認するほうが確実です。また必要な情報は分散しないで一カ所に集中しておかないとセキュリティ上の問題が広がりかねません。こちら側のサイトは決済外部サービスに対してカード番号などを送信しているので，実はカード番号を知り得るし，保存しておこうと思えば保存しておくこともできます。
しかし，こちらのサーバーにもカード番号を持ち，外部サービス側にもカード番号を持っている(これは当然持っていないとオーソリも決済もできません)という二元管理は危険です。何かの障害によってサイト利用者のカード番号が流出したといった場合を考えてみてください。こちらのサーバーにも外部サービスにもカード番号があれば，どちらから番号が流出したのかの判断ができなくなります。もし外部サービスにのみカード番号が保存されているのであれば，流出先は特定できます。しかるべき対策を取るにあたっても迅速に動くことができますね。
少しだけセキュリティ意識のお話を。本来データというものは，特定の一カ所にまとめておくほうが便利で管理もしやすくなります。しかしこの決済のケースのように分散せざるを得ない場合には，分散先の一カ所だけに限定して，そのコピーをあちらにもこちらにもという持ち方はしないほうが安全です。決済に限らずあらゆる統計をExcelに落として管理したいという要望はよく聞かれます。しかし本当ならばExcelに落としたらサーバーからは情報を消すなどして，情報の多元管理は避けるのが賢明です。
プログラマの立場から言えば，Excelに落とすほうがずっと危険です。ファイルをコピーされるかもしれません。プリントアウトして確認後に丸めて捨てたゴミを持ち帰られるかもしれません。Winnyやウイルスの影響でそれが流出しても責任はとれません。PCごと盗まれることもあります。またExcelに貼り付けた物はいくらでも修正できてしまうので，本当のデータとは完全に一致しなくなっていく可能性もでてきます。何が正であるのかもわからなくなった上に，コピーの過程で流出の危険性も増加していくという大変怖い状態です。
流出の発覚で株価が落ちるくらいはかわいいものです。小さい会社だとコロっといきます。流出データでの企業恐喝もあります。軽々しく考えず，十分安全と思われる運用ポリシーを決めてください。情報流出事件のほとんどはシステムを作ったプログラマの責任範囲ではなく，前出のようなローカル・コピーの扱いが原因です。
発注者「あなたのところのプログラムは情報漏洩とか心配ないだろうね」
開発元「ええ，お客さんが管理画面をコピーしてExcelで保存しなければね」
現実にはあり得ない会話ですが，もし本音で営業担当が語ればこういう話になることでしょう。ちゃんと管理者にしか見えなくした管理画面から，ひょっとしたら誰でもが触れるPCにデータを持ってきてしまうんですから，そこからの流出は開発側では誰も責任はとれないわけです。課金関係があるサイトでは特に注意が必要です。
