前シーズン、クライアントから、
ECCUBEにて「PAYPAY決済が使えないか？」との要望を受けたが、
決済モジュールをあーだーこうだするのが、嫌だったので、
「個別開発になるので、開発費かかるんで・・・」
と逃げていたのだけど、
2022年4月、DGFT（デジタルガレージ・ファイナンシャル・テクノロジー）より、
2系統用のPAYPAY決済モジュールが用意されており、
問い合わせたところ、結構な大事になり、
思ってもみない特単を頂ける運びとなった。

そして、9月よりDGFTに切り替えての準備を、この間際に行っている。
「事前にテストしとけよ！」は、その通りなんだけど、
決済までのシステムの統合を図っていたので、
どうせ決済だけなら、と、高をくくっていたが、
ちょっと、まあ間に合いそうなんだけど、すったもんだした記録↓

***

ダミーモード

テスト決済用で、本物のカード情報をいれるも、
「NH02000000000000/取引が無効です」
と、表示される。

8/26～使えるとのことだったので、
結果、テクニカルサポートに問い合わせ、専用の番号でないと、通らないと教わる。
どっか？書いてましたっけ？（汗

入金済みのステータス更新

モジュールの設定「お客様の入金通知URL」
(https://xxxx.net/sbivt3g/res.php）を、MAPの本人認証

https://www.ec-cube.net/upload/manual_file/04141415_6257add4793c7.pdf
【P17】

に登録し、コールバックを受け取り、受注状況を更新します。（成功・失敗etc）

クレジットカード決済の場合、
「ダウンロード販売時のステータス更新機能」にチェックを入れると、
Status:入金済みにしてくれるようですが、
PAYPAYなど、他の決済では、新規受注（ORDER_NEW）のままで、
都度、人海戦術でチェックして、変更する必要があるようです。

魔改造するしか、ありません・・・

ということで、ソース解析をしたところ、

res.phpで受け取って、
LC_Page_SBIVT3G_Receive.phpで、成功・失敗の判別処理しており、
こっちをさわると、アップデート時に泥沼になりそうなので、
res.phpのLC_Page_SBIVT3G_Receiveの処理の前後に、追加処理を追加します。

キャンセルや値段変更があった場合にも、
このres.phpがコールバックされるので、
LC_Page_SBIVT3G_Receive読み出し前に、

該当データが、ORDER_PENDINGであることを、控えます。

foreach($_REQUEST as $key => $val) {
	if (preg_match('/\[orderId\d+\]/', $key) {
		$order_id	= $val;

		$objQuery		=& SC_Query_Ex::getSingletonInstance();
		$arrOldOrder	= $objQuery->select('status, deliv_id', 'dtb_order', 'del_flg = 0 and order_id	= ?', [$order_id]);
	}
	break;
}

で、処理に問題なかった場合、
どの決済でも、ORDER_NEWとなるので、

ORDER_PENDING >> ORDER_NEW

の変化を条件に、最終処理を追加します。

if ($arrOldOrder[0]['status'] == ORDER_PENDING) {
	$arrOrder	= $objQuery->select('status, deliv_id', 'dtb_order', 'del_flg = 0 and order_id	= ?', [$order_id]);	
	if ($arrOrder[0]['status']	== ORDER_NEW) {
		if (in_array([2, 5, 12], $arrOrder[0]['deliv_id'])) {
			$Order['status']	= ORDER_DELIV; // 発送済み

			// QRコード送信
			send_shippingmail_qr($order_id);
			break;
		default
			$Order['status']	= ORDER_PRE_END; // 入金済み
		}

		// update
		$objQuery->update('dtb_order', $Order, 'order_id = ?', $order_id);
	}
}

配達方法(deliv_id）ごとに、取り扱う商品が異なる＝システム分岐しているので、
２，５，１２の場合だけ、QRコードを送信し、

statusを更新している。

なんで、入金済みを自動にしないのだろうね？
よくわからない。