会員グループごとに支払い方法を制限する支払い方法管理アドオンと、EC-CUBE 4.4 対応で踏んだ型の話

会員グループ管理プラグインの支払い方法管理アドオンです。法人会員だけ請求書払いを使える、一般会員には代金引換を出さない、といった出し分けができます。

EC-CUBE 4.4 対応でこのアドオンだけ厄介な踏み方をしたので、そこも書きます。

判定のルール

制限は支払い方法ごとに設定します。会員グループ側に何を許可するかを列挙するのではなく、「この支払い方法は、どの会員グループが使えるか」を決める形です。

未設定は制限なしです。導入直後は何も割り当てられていないので、これまでどおり全ての支払い方法が選べます。制限したい支払い方法にだけグループを設定してください。複数グループに所属している会員は、いずれか1つが許可していれば選べます。

「法人」「一般」というグループがあって、こう設定した場合。

購入者から見るとこうなります。

設定方法

管理画面の 会員管理 > 会員グループ の編集画面に「支払い方法」の選択欄が増えます。ここでチェックした支払い方法が、そのグループの会員に開放されます。

選択欄に並ぶのは店舗設定の支払方法で登録したものです。非表示にした支払い方法も選択欄には出ますが、購入画面に元々表示されないので割り当てても効果はありません。

2段構えにしている理由

制限は購入画面と購入フローの2箇所で効かせています。片方だけでは守れないためです。

購入画面側は OrderTypeExtension が選択肢からその会員の使えないものを取り除きます。ここで少し面倒なのが、本体の OrderType はフォーム送信時（PRE_SUBMIT）に支払い方法の選択肢を制限なしの状態で作り直すことです。表示時に絞るだけだと送信時に制限が消えてしまうので、本体の処理の後にもう一度絞り込んでいます。

購入フロー側は PaymentValidator が注文確認と注文確定の両方で、受注に載っている支払い方法を検査します。確定側も見ているのは、本体の confirm() が購入フローの後で無条件に flush() するからです。確認画面で差し戻しても受注には保存されているので、確定側で検査しないとそのまま注文が通ってしまいます。

EC-CUBE 4.4 対応で直したところ

共通の対応（属性記法への変換、Symfony 7 の Security 差し替え、SensioFrameworkExtraBundle の削除など）は本体プラグインの記事のとおりです。ここでは固有のものを2つ。

選択肢の型で購入手続きが500になる

4.4 の ShoppingController は Payment の choices を配列前提で array_map に渡すようになりました。こちらは ArrayCollection のまま渡していたので、TypeError で購入手続き画面が500になります。

厄介だったのは症状の出方です。配送方法アドオン側のテストが「配送方法の選択肢が0件」で落ちるという形で表面化しました。落ちているのは配送方法、原因は支払い方法が渡す choices の型。アドオンを個別に見ていたら追えなかったと思います。アドオンを何本も並行して 4.4 に上げていて、たまたま両方のテストを回していたから見つかりました。

選択肢が0件のときの案内文

もう1つ。選択肢が0件になったとき、原因を問わずこちらの文言で上書きしていました。本体は配送方法の組み合わせが原因の場合に「配送方法が異なる場合は同じ配送方法を選んでください。」と対処方法を案内するのですが、これが消えていたわけです。

本体の時点で既に0件なら本体の案内をそのまま使い、こちらの絞り込みで0件になった場合だけ差し替えるようにしました。これは本体の ShoppingControllerTest::testPaymentEmpty を、プラグインを有効にしたまま走らせて見つけています。自分のテストだけ回していると気づけない類なので、本体のテストをプラグイン有効のまま通すのは効きます。

あとは有効化時の外部キーの張り替えを専用接続に変えました。理由は配送方法管理アドオンと同じで、MySQL の DDL 暗黙コミットを DBAL 4 が検知するようになったためです。

動作要件といまの状況

パッケージ名は ec-cube/customergrouppayment44、プラグインコードは CustomerGroupPayment44 です。依存プラグインが有効でないと、有効化時にエラーメッセージを出して中断します。

2026年7月27日時点で CI は通っていますが、EC-CUBE 4.4 本体が未リリースのため配布は本体のリリース後です。