どうやら、$response に格納する処理が意図しない動作をしていそうですね。
その処理を見直すか、$response[0] から explode で再セットするかで対応できそうな気はします。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

ありがとうございます。

substrで「OK」「NG」を切り出し、条件分岐には成功しましたが
払い込みに必要な支払番号や取引番号などが空の注文メールとなってしまいます。
DBのdtb_order_temp（注文一時テーブル）を確認したところ
memo01/memo02/memo03/memo07/memo08/memo09の６フィールドともに見事に「NULL」でインサートされておりました。


var_dumpすると
$response[1]
$response[2]
ともにNULLでした。


--------以下はソース抜粋になります--------
var_dump($response[0]);
var_dump($response[1]);
var_dump($response[2]);
$aa=substr($response[0],0,2);
var_dump($aa);
// 成功
if ($aa == "OK") {
// 受注一時テーブルに記録
$arrVal['memo01'] = $this->objConfig->module_name; // モジュールコード
$arrVal['memo02'] = $this->setConveniPayment($response, $arrInput); // 支払情報
$arrVal['memo03'] = FREGI_CONVENI; // 支払方法
$arrVal['memo07'] = $response[2]; // 取引番号
$arrVal['memo08'] = $response[1]; // 支払番号
$arrVal['memo09'] = FREGI_CONVENI_ORDER; // F-REGIステータス
$this->objHelperDB->sfRegistTempOrder($arrData['order_temp_id'], $arrVal);
-----------------------

引き続きコードに手を加え解決できるのか
それとも根本的な問題なのか
考えあぐねています。

こちらでの解決が難しければ有料でお願いしたいのですが。。

substr で先頭2文字を切り出して比較すれば応急的には回避できそうです。
http://jp2.php.net/manual/ja/function.substr.php

プロトコルの仕様変更でもあったのですかね。もしくは、EC-CUBE のモジュールが仕様の解釈を誤って実装されてしまったのですかね。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

早速のヘルプありがとうございます。

var_dump($response[0]);
の結果を2種類添付致します。

（１）コンビニ決済時わざとTELを一桁の数字に

string(48) "NG C1-1-73(����ӥ���ʸ�������TEL��û�����ޤ�) "
文字化けしたままですが、EUC-JPで表示すると以下のように読めるようになります。
↓
string(48) "NG C1-1-73(コンビニ注文処理時のTELが短すぎます) "


（２）コンビニ決済時に正しい電話番号を入力

string(106) "OK 7101989406616 00000000000004934138 http://payment.sej.co.jp/od/hi.asp?50100101989406617c2363af7c1ac6a7 "

「OK」「7101989406616」「00000000000004934138」「http://payment.sej.co.jp/od/hi.asp?50100101989406617c2363af7c1ac6a7」は全て1行で半角スペースで区切られています。

引き続きよろしくお願いします。

とりあえず、$response[0] の内容がどうなっているのかが気になるところです。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

エラー文言の文字化けが解決し、
その後決済処理もスムースに行われていたのですが
数日前から突然正常処理の場合にも
以下のエラー表示が出てしまい
決済完了画面へ遷移せず処理がストップしてしまう現象が出ております。
----------------------------
エラーが発生しました。
OK 2202 00000000000004927198
----------------------------

【前回変更したコード】

/data/downloads/module/mdl_fregi/LC_Page_Mdl_Fregi_Payment.php

723行目

$this->tpl_error = "エラーが発生しました。<br/>". $this->message;
↓
$this->tpl_error = "エラーが発生しました。<br/>". mb_convert_encoding($this->message[0],"UTF-8","EUC-JP");

-----------------------------

上記以外は変更しておりません。

前回アドバイスいただいたようにコードの途中でvar_dumpしながら
処理を追いかけてみたところ

437行目

if ($response[0] == "OK") {
　正常の場合の処理
　return true;
} elseif ($response[0] == "NG") {
　エラーの場合の処理
　return false;
} else {
　エラーの場合の処理
　return false;
}

という条件分岐の処理で
OKでもNGでも最後のelse(その他の結果の場合)に振り分けられてしまっているようです。

returnが必ずfalseなので以下の処理で
すべてがfalseになってしまっているようです。

711行目

// 正常
if ($result === true) {
// 正常に登録されたことを記録
　　// 異常
} elseif ($result === false) {
$this->tpl_error = "エラーが発生しました。<br/>". $this->message;
}

一旦解決したはずの投稿ですが
再び別のエラーを引き起こしてしまい
再度投稿させて頂きました。

解決の糸口になるアドバイスをいただけると幸いです。
よろしくお願いします。

チケットを登録しました。
http://svn.ec-cube.net/open_trac/ticket/444

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

アドバイス通り、var_dumpしてみたところ
Array[0]に全ての変数が入っていました。
そこで、以下のコードを書いて試してみたところ
文字コードをコンバートする事が出来ました。

本当にありがとうございます。
お二人のお陰で助かりました。

また、今後同じケースでつまずく方のヘルプになれば幸いです。


$this->message[0]=mb_convert_encoding($this->message[0],"UTF-8","EUC-JP");
$this->tpl_error = "エラーが発生しました。<br/>". $this->message[0];

とりあえず、
$this->message=mb_convert_encoding($this->message,"UTF-8","EUC-JP");
の前後で、当該変数を var_dump して、どうなっているか辺りが気になるところです。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

ご指摘ありがとうございます。

どうしても解決しなければ有償でお願いしたいと思いますので
その際にはお世話になります。

引き続きよろしくお願いします。