EC-CUBEをさくらのレンタルサーバで導入してみた(4) / 決済モジュール編

こんにちは、ハイモジモジの松岡です。

連載第3回では思わぬ「meta description問題」に直面し、何とか解決することができましたが、今回はさらに大きな問題が立ちはだかることになりました。

決済モジュールが組み込めない

いよいよ直販サイト「SHOP MOJIMOJI」もリニューアルのメドが立ち、残すは決済モジュールを組み込むのみ、という段階まできました。プラグインとモジュールの違いについては割愛しますが、どちらも「機能を付加する小さなプログラム」という意味では同じ。細かいことは気にしなくても大丈夫です。

なのですが、サイトを構築する上で致命的になりかねない箇所だけは「事前に細かくチェックしておくべき」と、過去の自分に教えてあげたい事案が発生してしまいました。なんと、当の決済モジュールが導入できないことが判明したのです。

決済の仕組みについては同一サーバー内でシームレスに買い物が完結する「埋込型」にするか、外部の決済ページに飛ばす「リンク型」にするかを自由に選択できますが、契約する決済サービスによっては両方対応している場合もあれば、どちらか一方しか対応していない場合もあります。その点、EC-CUBEを導入する前から契約していた決済サービスがあり、その内容に満足していたハイモジモジは、同じ会社の決済モジュールを「埋込型」で導入するつもりでした。

ところが、いざインストールしようとEC-CUBEのモジュール配布ページにアクセスしてみたら、末尾にこんな記述があったのです。

動作環境
クレジットカード決済システム接続方式はデータ伝送型での接続となります。
購入者のカード情報は加盟店様サイト内で入力されるため商品届け先指定ページ以降は必ずSSLの環境下(https)でご用意ください。

SSL環境を用意せよ

えっ、そうなの？　はじめは驚きましたが、考えてもみれば当たり前のこと。以前は「決済専用ページ」に外部リンクさせていたので、そこまで意識していませんでしたが、EC-CUBEで決済モジュールを埋込型で活用するならば、お客様の大事なクレジットカード情報を同一サーバー内で一時的にお預かりすることになる。SSL環境を用意するのはECサイトを運営する上で当然のことです。

埋込型の決済モジュール導入にSSL環境が必須であることは分かりましたが、この時点ではまだ楽観していました。なぜなら今回、契約した「さくらのレンタルサーバ」の「スタンダード」は、確かSSLにも対応していたはずなのです。

両手を組んで、祈るようにサービス説明ページにアクセスしてみたところ、ほらやっぱり、共有SSLに対応していました。ただし、こんな一文が記載されていました。

当社では、独自ドメイン名での共有SSL運用を推奨していません。

えっ、そうなの？　さらに詳しく見てみると、このように書かれていました。

独自ドメイン形式(https://secure***.sakura.ne.jp/******/)【非推奨】
CookieやHTTP認証、プラグインによる通信内容などの機密情報を悪意のある第三者が共有(盗聴)することが可能です。

独自SSLを改めて準備すべきか？

例えばハイモジモジは「www.hi-mojimoji.com」という独自ドメインを運用していますから、「さくらのレンタルサーバ」から提供される初期ドメイン形式での運用は想定していませんでした。すでに独自ドメインでGoogle等の検索エンジンにクロールされてきた実績があるのですから、今さら変更するのは抵抗があります。つまり、EC-CUBEでの独自ドメイン継続運用はマスト。

ところが「スタンダード」では、独自ドメインとSSLの組み合わせ（＝独自SSL）は「非推奨」であることが判明しました。「悪意のある第三者が機密情報を共有（盗聴）できてしまう」のであれば、その可能性を運営者として無視するわけにはいきません。つまり「さくらのレンタルサーバ」でいえば、決済モジュールを埋込型で活用しようとするならば、独自SSLに対応している上位プランの「ビジネスプロ」または「マネージドサーバ」を契約する必要があるのです。

さて、どうするか。すでに「スタンダード」を契約してしまいましたし、EC-CUBEもインストールしてしまった現状で、また一からやり直すのは煩わしい。また、上位プランだと月額固定費が予算オーバーになってしまう。独自SSLの場合、SSL証明書の発行も自前で行わねばならず、こちらもそれなりの費用がかかってしまいます。

正直、頭を抱えてしまいました。ほらね、クリティカルな問題はあらかじめ検討しておかないと。

モジュールを断念して、決済ページに外部リンク

結局は、何を優先させるかです。できることとできないことがあり、何を採用すれば誰のためになるのか。そこのところを突き詰めて考えろ、ということなのかもしれません。

最終的にハイモジモジが下した結論は、サーバーは「スタンダード」のまま、決済モジュール導入を断念し、注文時のデータ（合計金額等）を決済サービスの専用ページに外部リンクさせるというもの。注文データにパラメータを付与して外部に引き渡す、これまで採用してきた方式です。これなら「まずは安価なサーバーで運用してみたかった」という自社の都合と、すでにこの決済方式に慣れているリピーターに安心感を与えるという両面を達成できます。つまりは期待した埋込型の導入は果たせず、元のリンク型に落ち着いたわけですが、これはこれで良かった気もしています。

ただしこの方法は、一般にはお勧めできません。というのも今回、契約している決済代行会社はリンク型ではなく「SSL環境下での埋込型決済モジュール導入」を推奨していますし、注文データを引き渡すリンク型ではEC-CUBEのスクリプトを直接改造しなければならなかったからです。やはり費用はかかっても、必要経費だと思って「独自SSL対応のサーバー」を契約し、素直に埋込型が可能な決済モジュールを導入した方がシンプルだと思われます。もちろん、リンク型を提供している決済サービスであれば何の問題もないのですが、まずは契約したい決済サービスの仕様を事前に確認しておきましょう。

ついにリニューアル達成

まだまだ粗削りながら、ひとまずリニューアルオープンするところまでは漕ぎつけました。一部購入できない商品があり、移行できていないページもありますが、とにかく新生「SHOP MOJIMOJI」をオープンすることができました。

細かいところは、細かく手直ししていけばいいのです。お客様に迷惑がかからない限り、適宜改修していけばいいのです。ショップ運営に正解はないのですから、ああでもない、こうでもないと試行錯誤を続けていけばいいのです。などと「詰めの甘かった自分」を正当化していますが、反面教師として改めて繰り返しておきますね。あらかじめ検討を、と。

本連載も、とうとう次回が最終回。エピローグ的な「こぼれ話」で締めくくりたいと思います。あと1回、お付き合いくださいませ。

>>EC-CUBEをさくらのレンタルサーバで導入してみた(5) / こぼれ話編