Eccube

ECCUBE 2.17 & ベリトランス決済モジュール(DGFT)

前シーズン、クライアントから、
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)ごとに、取り扱う商品が異なる=システム分岐しているので、
2,5,12の場合だけ、QRコードを送信し、

statusを更新している。

 

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

 

-

【重大事案】2022年10月 3Dセキュア 1.0廃止

今回は、ECCUBE前提の話となりますが、

それ以外のシステムにおいても、
3Dセキュア 2.0の対応は必須で、回避不可の事案です!

 

1年前から、3Dセキュアを2.0に切り替えるようアナウンスがあったようですが、
どれほどの方が、この移行に際して、準備していたでしょうか?

私も、完全に軽視しておりましたが、
クライアントからの問い合わせに、調べてみたところ、
重大な事案であることが、判明致しました!!

 

結論だけ先にいうと、

3Dセキュア1.0廃止後、未対応のシステムは、
2.0が1.0を補完してくれるわけではなく、
カード情報入力後、VISAなどの画面に移行もせず、決済出来るようで、

つまり、カード番号と有効年月、裏面のコードがわかれば、
3Dセキュアをスキップして、決済できるわけです。

セキュリティー・ガバガバの、悪用し放題の暗黒時代が到来!
その上で、チャージバックが多発することは、間違いないでしょう!

 

エンジニアでさえ、廃止の2ヶ月前に知った事案で、
一般エンドユーザーが管理する環境下では、おそらく未対応のまま、10月を迎えることになるでしょう!

***

【私記】

日本では、ECサイトの構築において、
ECCUBEが多く採用されており、デザインの変更が容易なこと、
多様なプラグインで、カスタマイズが可能なこと
などが、挙げられると思いますが、

2系、3系、4系へと、進化してきました。

 

3系からは、Symfonyというフレームワークが採用され、
開発環境が置き換わり、2系とは中身は別物になりました。
※私個人的に、3系移行は嫌いです。

近頃、2系は、有志によりカスタマイズされ、
PHP7(2.17)、PHP8(2.18)での動作が可能になり、
カスタマイズのしやすさから、弊社は愛用しておりますが、

(書きかけ)

 

【結論】

結論は先に書いていますが、

この事実は、決済代行業者の詳しい人でさえ、知らなかった事案でした!

当然、案内にこのような記載はなく、
(担当者が知らないのですから)
エンジニアも当然知る余地もなく、
末端のエンジニアの手がかかっていないECサイトは、

3Dセキュア2.0には、移行しないでしょう!

 

そして、更に恐ろしいことに、
ECサイトが3Dセキュア2.0に対応していても、
カード発行会社が2.0に対応していない場合、
チャージバックが発生するという、怪奇が起こります!

現状、楽天カードでさえ、2.0に未対応だそうです・・・

 

わかりますか?、楽天でさえ、です!

もっと小さな規模会社名義のVISAやJCBなりのカード、たくさんありますよね?

それらが、すべて2.0に対応しない限り、
自店がいくら対応していようと、暗黒時代は終わらないのです!

 

2022年10月移行、決済が完全に停止するわけではありません。

3Dセキュアのない状態で、決済され、
チャージバックが発生した場合は、店舗責任とななるのかな?

 

2.0で、1.0を下位互換し、旧画面を表示してあげれば済むのですが、
これだと、1.0を永遠に使う輩が出てくるので、
今回完全に打ち切りとなるわけですが、

同時に、裸の状態(カード、有効期限、裏面のコードだけ)で決済出来てしまうのは、
とても、危険なんですよね~~

 

10月にならないと、事件は表面化しないと思いますが、
その時は、1.0完全廃止は、延期になるんでしょうね・・・
どうも、このシナリオが強そうです。

-