EC-CUBEにクレジットカード決済を導入する方法の一つとして、クロネコwebコレクトがあります。今回API方式で導入し、クロネコテスト環境でテストしてみたところ、通知エラーが発生しました。（EC-CUBE → クロネコテスト環境への通知はOK（〇） クロネコテスト環境 → EC-CUBEへの通知がNG（×））
試行錯誤の上解決いたしましたので忘備録として残します。
前提事項
設置環境は以下の通りです。
- EC-CUBE (2.13.5)
- SSL：グローバルサイン（企業認証型）
- サーバー：さくらサーバー
- クロネコｗｅｂコレクト：API方式
API方式の場合、SSLが必須ですが、セキュリティレベルの高いSSLでないと動作しません。
クロネコwebコレクトのサポートに連絡し、「グローバルサインの企業認証型を推奨します」という回答であったため、グローバルサインの企業認証型のSSLをサーバーに設置しました。
発生しているエラー
クロネコwebコレクトテスト環境設定で、クレジットでテスト購入を行いました。
クロネコテスト環境管理画面に、クレジット情報の通知が表示されたことを確認し、クロネコテスト管理画面から、EC-CUBEへ決済情報の通知テストを行ってみました。
そうすると、以下の画像のような「決済依頼データ通知異常終了」というエラーが発生しました。
当然EC-CUBE側には通知されていませんでした。
ググったうえでクロネコサポートに問い合わせ
わからないことはGoogleで調べる。
ということで、エラーメッセージでの調査、クロネコwebコレクト側の事例検索、EC-CUBE側の事例検索など、あらゆる角度から探してみました。
しかし、探せた情報は「決済依頼データ通知異常終了」はクロネコ推奨のSSLでない場合に発生します。というものでした。
ここで、クロネコwebコレクトのサポートに電話してみました。
サポートに、文頭の環境を伝え、「決済依頼データ通知異常終了」が発生する旨を伝えたところ、SSLには問題がないが、所見では原因が特定できないため、EC-CUBEのログを送付してほしいということでしたので、ログをすべて取り、エラー等のプリントスクリーンも添付し回答を待つことにしました。
※本部ブログを書いている現時点ではまだ回答待ちです。
追記：翌日（2018/7/26）サポートより回答がありました。
ここで気になった現象を掘り下げて調べてみました。
回答を待つ間、別の角度から考えてみることにしました。
クロネコwebコレクトからEC-CUBEへ何らかの情報を通知する場合、EC-CUBE側に受信する部分があります。
EC-CUBEの受信部に問題があれば、当然通知が失敗します。
そこで何の気なしに、ブラウザで受信部にダイレクトアクセスしてみました。
そうしたところ、「Internal Server Error」が発生しました。
ただ、エラーになるのは、受信部のフォルダだけで、他のフォルダではInternal Server Errorが発生しませんでした。
フォルダのパーミッション等調べましたが、特に問題がありませんでした。
ということは、.htaccessの設定の問題が疑われました。
そこでAPI方式の受信部に設置される.htaccessを見てみました。
なるほど原因はこれでした。
php_flag mbstring.encoding_translation 0
php_value output_handler null
php_value variables_order EGPS
php_flag session.auto_start 0
php_flag session.use_trans_sid 1order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx※IPアドレスは伏せた表現にしています。
受信部の.htaccessファイルを見てみると、上記の内容が記載されていました。
本来ならば、どうということのない記述ですが、さくらサーバーの場合は致命的です。
さくらサーバーで苦労された方ならピンと来られるかと思いますが、さくらサーバーでは、.htaccessにPHPの設定をすることができません。もし.htaccessにPHPの設定を記述すると、「Internal Server Error」が発生します。
つまり、クロネコシステム側からアクセスしてもInternal Server Errorが発生するため、クロネコwebコレクトテスト管理画面からの通知が異常終了していたのです。
このようにして解決しました。
.htaccessに記述されていたPHP設定は必要な項目ですが、.htaccessには記述できないため、php.iniファイルに記述しました。
さくらサーバーでは、フォルダ単位でphp.iniの記述ができます。
.htaccessファイルは、以下のように記述しました。
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx※IPアドレスは伏せた表現にしています。
PHPの設定部分を.htaccessから削除しました。
php.iniファイルには、以下のように記述し、受信部のフォルダにアップロードしました。
mbstring.encoding_translation=0
output_handler=null
variables_order=”EGPS”
session.auto_start=0
session.use_trans_sid=1
phoinfo();を記述したphpファイルを作り、設定値が反映されていることを確認し、再度クロネコwebコレクトテスト環境管理画面より、通知テストを行ってみたところ、EC-CUBEの管理画面に通知ができました。
その後本番設定に切り替え、EC-CUBEとクロネコwebコレクト間で相互通信ができることを確認しました。
今回は、サーバーの.htaccesに関する仕様が原因でした。
問題のないSSLを導入していても、EC-CUBEの受信部がInternal Server Errorを起こしていたら、その要因を取り除かなければならないことがわかりました。
さらに要注意
クロネコテスト環境から、本番環境に切り替える際に、EC-CUBEでAPIのモジュール設定変更を行ったのですが、設定保存を実行した段階で、強制的に受信部の.htaccessが上書きされていました。
設定を保存するたびに受信部の.htaccessがデフォルト設定に上書きされるため、その度php設定部分を削除した.htaccessをアップロードしなおす必要があります。
最初これがわからず、本番環境に設定したとたん、通知エラーが発生したため慌てました。
修正版の.htaccessファイルの再アップロードで直りました。
この現象は、特定サーバーでのみ発生する要因ではありますが、解決策をググっても見つけられませんでした。本記事が少しでもお役に立てれば幸いです。