タグアーカイブ 注文管理

WooCommerce 11.1で注文撤回機能が登場、14日以内の自己対応を実現

WooCommerce 11.1で注文撤回機能が登場、14日以内の自己対応を実現

WooCommerce 11.1に注文撤回(Order Withdrawal)機能が追加された。EU域内の消費者が持つ14日間の契約撤回権に対応するための仕組みで、顧客が店舗にメールや電話で問い合わせることなく、注文から14日以内であれば自分で撤回リクエストを送信できるようになる。

この機能は既定では無効化されている。すべてのストアに必要な機能ではないため、事業者が設定画面から明示的に有効化する方式だ。顧客向けのリクエストフォーム、自動確認メール、店舗側の通知まで一連のフローが組み込まれている。

本記事では注文撤回機能の概要、有効化の手順、顧客と店舗それぞれの画面で何が起きるのかを解説する。EU向けに販売するストア運営者は特に確認しておきたい内容だ。

注文撤回機能とは何か

注文撤回機能とは何か

注文撤回機能は、EUの消費者保護規則で定められた「注文撤回権」に対応するための機能だ。EU域内の消費者は、商品やサービスを注文した日から14日以内であれば、理由を説明せずに契約を撤回する権利を持つ。従来はこの手続きをメールや電話で行う必要があり、店舗側も個別に対応する必要があった。

EUの14日間撤回権とは

14日間の撤回権はEU消費者権利指令に基づく制度で、オンライン購入を含む通信販売に適用される。消費者は商品を受け取った日から14日以内に撤回を申し出ることができ、事業者は返金に応じる義務を負う。この規則はEU域内の消費者との取引に適用されるため、日本からEU向けに販売するストアも対象になりうる。

重要なのは、注文撤回機能は法的手続きの自動化ツールであって、コンプライアンスを保証するものではないという点だ。WooCommerce Developer Blogの記事でも、事業の内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。

従来の対応との違い

従来のフローでは、顧客がメールや電話で撤回の意思を伝え、店舗担当者が手動で注文を確認し、返金処理を行っていた。この方式には対応漏れや記録不足のリスクが伴う。注文撤回機能は、顧客が自己対応フォームからリクエストを送信し、システムが自動で記録と通知を行う。

従来の対応(Before)
顧客がメールや電話で個別に問い合わせる
顧客 メール送信 → 店舗担当者 手動で確認と返金
対応漏れや記録不足のリスクがある
↓
注文撤回機能(After)
顧客が自己対応フォームからリクエストを送信
顧客 フォーム送信 → 自動処理 記録と通知
確認メールが顧客に届き、店舗にも通知される

このデモで示した違いは大きい。顧客からの撤回リクエストがシステムに記録され、確認メールが自動送信されることで、店舗と顧客の双方に証跡が残る。対応の属人化を防ぎ、処理の一貫性を保てる。

有効化の手順

有効化の手順

注文撤回機能は既定では無効化されている。EU向け販売を行っていないストアでは不要な機能のため、必要な事業者だけが有効化する設計だ。設定はWooCommerceの管理画面から数ステップで完了する。

設定画面での操作

WooCommerceの設定画面を開き、詳細設定タブから機能セクションに移動する。そこに注文撤回のオプションが表示されるので、有効化して変更を保存するだけだ。設定完了後、顧客向けのリクエストフォームが /my-account/withdraw-order というURLで公開される。

エンドポイントのカスタマイズ

リクエストフォームのURLは変更できる。詳細設定のページ設定セクションでエンドポイントを編集すれば、自社の導線に合わせたURLに調整できる。標準のURLは /my-account/withdraw-order だ。

もう1つの重要な特徴として、このページはログイン状態に関わらず動作する。ゲスト購入した顧客でもフォームにアクセスしてリクエストを送信できる。EUの撤回権はゲスト購入者にも適用されるため、この設計は実務上欠かせない。

顧客から見た注文撤回フロー

顧客から見た注文撤回フロー

顧客が注文撤回ページにアクセスすると、短いリクエストフォームが表示される。必要な情報を入力し、送信前に内容を確認する画面を経てから送信する。送信後は確認画面が表示され、入力した内容を含む確認メールが自動的に届く。

STEP 1 注文撤回ページにアクセス
ログイン状態でもゲストでも利用できる
↓
STEP 2 リクエストフォームを入力
注文番号と請求先メールアドレスなどを入力する
↓
STEP 3 入力内容を確認
送信前に詳細をレビューする画面が表示される
↓
STEP 4 送信して確認メールを受信
確認画面が表示され、入力内容を含む確認メールが届く

この4ステップのフローは、顧客が自分の操作だけで撤回リクエストを完了できることを示している。確認メールには顧客が入力した内容が含まれるため、顧客はリクエストの記録を残せる。店舗側への電話やメールが不要になり、双方の手間を削減する。

確認メールが自動送信される点は法的にも意味がある。撤回権の行使を顧客が証明できる記録が残るため、後日のトラブルを防ぐ効果が期待できる。

店舗運営者から見た通知と管理

店舗運営者から見た通知と管理

顧客がリクエストを送信すると、店舗運営者には2つの経路で通知が届く。1つは撤回リクエストを知らせるメール通知、もう1つはWooCommerceホーム画面のインボックス通知だ。この二重の仕組みにより、リクエストの見落としを防ぐ。

リクエスト内容に含まれる注文番号と請求先メールアドレスが既存の注文と一致する場合、リクエストは自動的にその注文に紐付けられ、注文メモが追加される。これにより、店舗担当者は注文詳細画面からリクエストの存在を確認できる。

一致する注文が見つからない場合でも、リクエスト自体は受け付けられ、顧客には確認メールが送信される。通知には手動確認が必要であることを示すフラグが付けられ、注文へのリンクはスキップされる。この設計により、注文番号の入力ミスやゲスト購入の注文でも、リクエストが拒否されることはない。

STEP 1 リクエストを受信
メール通知とインボックス通知の両方が届く
↓
STEP 2 注文番号とメールアドレスを照合
既存注文と一致するかシステムが自動判定する
↓
分岐 一致する場合と一致しない場合で処理が変わる
注文が一致 注文に自動リンクされ、注文メモが追加される
注文が不一致 手動確認フラグが付き、注文へのリンクはスキップ

重要な点として、撤回リクエストの送信は注文ステータスを変更しない。注文が自動的にキャンセルされたり、返金が実行されたりすることもない。リクエストはあくまで「撤回の申し出」であり、その後の対応(返金の承認、商品返送の依頼、追加情報の確認など)は店舗側の判断に委ねられる。

導入前に確認すべき注意点

導入前に確認すべき注意点

注文撤回機能は店舗運営の効率化に寄与するが、いくつかの注意点がある。まず、この機能がEUの法的要件への準拠を保証するわけではないという点を理解しておく必要がある。WooCommerce Developer Blogの記事でも、事業内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。

リクエスト処理のワークフロー設計

撤回リクエストが届いた後の対応フローは、店舗自身で設計する必要がある。返金を承認するのか、商品の返送を求めるのか、追加情報を確認するのか。これらの判断基準を事前に決めておかないと、リクエストが届いてから担当者が迷うことになる。

特に、注文ステータスが自動変更されない点は運用上のポイントだ。リクエストが届いても注文は「処理中」などの状態のまま残るため、店舗側で明示的に注文をキャンセルする処理が必要になる。この部分を社内で共有しておかないと、注文が放置されるリスクがある。

ゲスト購入への対応

ログインしていない顧客でもリクエストを送信できる設計は、ゲスト購入が多いストアにとって重要な特徴だ。ただし、ゲスト購入の注文は注文番号とメールアドレスの照合が手動になる可能性がある。手動確認フラグが付いたリクエストを担当者が見逃さないよう、通知の確認ルールを決めておく必要がある。

実務的には、EU向け販売を行うストアにとって注文撤回機能は顧客対応の手間を大幅に減らす可能性がある。メールや電話での個別対応から、システム化されたリクエスト処理へ移行することで、対応の一貫性と記録の完全性が向上する。一方で、リクエスト受信後のワークフローが未整備のままでは、かえって対応が遅れるリスクもある。

注文撤回機能は、WooCommerce 11.1の新機能としてEU対応ストアに実用的な選択肢を提供する。導入を検討する場合は、機能の有効化だけでなく、社内の対応フローまで含めて計画することをおすすめする。

この記事のポイント

  • WooCommerce 11.1に注文撤回機能が追加され、顧客が自己対応で撤回リクエストを送信できる
  • EUの14日間撤回権に対応する仕組みで、既定では無効化されている
  • 顧客はフォーム入力から確認メール受信まで自動フローで完了できる
  • 店舗にはメールとインボックスの二重通知が届き、注文への自動リンクも行われる
  • 注文ステータスは自動変更されないため、受信後のワークフロー設計が必要
WooCommerce処理中注文を未払いのまま請求書プラグインに連携する方法

WooCommerce処理中注文を未払いのまま請求書プラグインに連携する方法

WooCommerceで銀行振込(BACS)や後払い決済を使う場合、注文を「処理中」にした途端に、外部の請求書発行プラグインがその注文を「支払い済み」と認識してしまうことがある。この原因は、WooCommerceが処理中ステータスに遷移する際に支払い日(_date_paid)を自動で記録し、多くのプラグインがそのメタデータを支払い完了の合図として読み取るからだ。ここではこの仕組みを詳しく解説し、後払い注文を未払いのまま連携させる確実な修正方法を紹介する。

なぜ処理中になった注文が「支払い済み」扱いになるのか

なぜ処理中になった注文が「支払い済み」扱いになるのか

WooCommerceの内部動作として、注文が「処理中(processing)」または「完了(completed)」に切り替わると、maybe_set_date_paid()というメソッドが呼ばれ、現在の日時を_postmetaテーブルの_date_paidに保存する。この動作は、クレジットカード決済など即時払いが完了した瞬間を記録するためにある。ところが銀行振込(BACS)は標準で「保留中(on-hold)」になるが、運用上「処理中」に手動変更したり、コードで処理中に固定すると、実際には入金前でも支払い日が書き込まれてしまう。

請求書発行プラグイン(WooCommerce PDF Invoicesや会計連携プラグインなど)は、通常この_date_paidをもとに「支払い済み」かどうかを判断する。さらに、WC_Orderクラスのis_paid()メソッドは内部的に「処理中」「完了」といったステータスを見てtrueを返す設計のため、_date_paidが空でも「支払い済み」と扱われるケースも多い。結果として、入金前の後払い注文が会計ソフト上で「支払い済み請求書」として取り込まれてしまうのだ。

修正前
注文ステータス:処理中 → WooCommerceが_date_paidを自動記録 → 請求書プラグインが「支払い済み」と判定
↓
修正後
注文ステータス:処理中 → _date_paidは記録されない(未払いのまま) → 請求書プラグインは「未払い」として連携

上図のように、_date_paidの書き込みを止めるか、支払い済み判定のロジック自体を書き換えることで、請求書が正しく「未払い」で連携されるようになる。次に、具体的にどう対処すればよいかを方法別に紹介する。

支払い済み判定のメカニズムを特定する

支払い済み判定のメカニズムを特定する

修正に入る前に、自分が使っている請求書発行プラグインがどのタイミングで「支払い済み」と判断しているかを知っておくと無駄な試行錯誤が減る。大きく分けると以下の3パターンがあり、フィルターの効き方が変わる。

  • _date_paidのメタデータを直接 get_post_meta() や$order->get_meta(‘_date_paid’) で読み取っている
  • WC_Order::get_date_paid() メソッドを呼び出している(フィルターフック posible)
  • WC_Order::is_paid() メソッドで判定している(ステータスベース)

多くのプラグインは最後のis_paid()や、直接メタデータを読む形をとる。get_date_paid()フィルターだけでは直らなかった場合、is_paid()の返り値を書き換えるか、そもそも_date_paid自体を保存させないアプローチが有効だ。

強制的に未払いにする3つの方法

強制的に未払いにする3つの方法

方法1. _date_paidが記録されるのを根本から防ぐ

WooCommerceが処理中ステータスに変わったときに_date_paidをセットするのは、maybe_set_date_paid()の中で「このステータスは支払い完了とみなす」という配列に「processing」が含まれているからだ。この配列はwoocommerce_payment_complete_order_statusフィルターで変更できる。以下のコードをテーマのfunctions.phpまたはCode Snippetsプラグインで追加すれば、BACS(bank transfer)決済の注文でのみ「processing」を支払い完了ステータスから外せる。

add_filter('woocommerce_payment_complete_order_status', function($statuses, $order) {
    if ($order instanceof WC_Order && 'bacs' === $order->get_payment_method()) {
        $statuses = array_filter($statuses, function($s) {
            return $s !== 'processing';
        });
    }
    return $statuses;
}, 10, 2);

これにより、BACSの注文が「処理中」に移行しても、WooCommerceは「これは支払い完了ステータスではない」と認識し、_date_paidを一切書き込まない。注文メモなどに残る変わったログも出ず、動作は非常にクリーンだ。結果として、請求書プラグインが_date_paidを見ている限り、未払いのままとなる。

方法2. is_paid()の返り値を上書きする

もし日付メタデータを消してもなお請求書が「支払い済み」になってしまう場合は、プラグインがWC_Order::is_paid()メソッドを使っている可能性が高い。このメソッドは内部的にwc_get_is_paid_statuses()が返すステータス配列(デフォルトでは’processing’と’completed’)と照合し、trueを返す。こちらもフィルターでBACSだけ処理中を除外できる。

add_filter('woocommerce_order_is_paid_statuses', function($statuses, $order) {
    if ($order instanceof WC_Order && 'bacs' === $order->get_payment_method()) {
        $statuses = array_diff($statuses, array('processing'));
    }
    return $statuses;
}, 10, 2);

このコードを追加すると、is_paid()は見かけ上「処理中」でもfalseを返すため、請求書プラグインは「未払い」と判断する。方法1と併用すれば、_date_paidの直接読み取りもis_paid()経由の判定も両方ブロックできる。

方法3. プラグイン側のエクスポートフィルターを利用する

どうしても上記のフィルターで直らない、あるいは他プラグインとの兼ね合いで処理中ステータスを支払い完了扱いのままにしたい場合は、請求書発行プラグインが用意しているデータ書き換え用のフックを使う。たとえば、WooCommerce PDF Invoices & Packing Slips であれば wpo_wcpdf_document_data や wpo_wcpdf_invoice_data といったフィルターがある。請求書に含める「支払い済み」フラグや日付を、注文の支払い方法がBACSのときだけ空にすることで解決できる。

プラグインのフィルター一覧は開発元のドキュメントで確認する必要があるが、一般に「Paid = 1」や「paid_date」といったキーを書き換えることが多い。次のサンプルは、WooCommerce PDF Invoicesで支払い状況を未払いに戻す例だ。

add_filter('wpo_wcpdf_invoice_data', function($data, $document) {
    if ($document->order instanceof WC_Order && 'bacs' === $document->order->get_payment_method()) {
        $data['paid'] = 0;
        $data['date_paid'] = '';
    }
    return $data;
}, 10, 2);

なお、プラグインが読み取るフィールド名は製品によって異なるため、実際のソースコードや開発元への問い合わせで正確なキー名を調べるのが確実だ。

カスタム注文ステータスで処理中と区別する方法

カスタム注文ステータスで処理中と区別する方法

根本的に「後払い専用の処理中ステータス」をWooCommerceに追加するという手もある。標準の処理中ステータスは、支払い完了後の発送準備として使われる場面が多い。これに対し、後払いは「入金確認前だが、すでに注文を受け付け、請求書を発行したい」という微妙な状態だ。そこで「後払い処理中」のようなカスタムステータスを作れば、WooCommerceの支払いロジックに干渉せず、かつ請求書プラグインも処理中ではないため誤って支払い済み扱いしなくなる。

function register_custom_order_status_invoice_processing() {
    register_post_status('wc-invoice-processing', array(
        'label'                     => '後払い処理中',
        'public'                    => true,
        'show_in_admin_status_list' => true,
        'show_in_admin_all_list'    => true,
        'exclude_from_search'       => false,
        'label_count'               => _n_noop('後払い処理中 (%s)', '後払い処理中 (%s)')
    ));
}
add_action('init', 'register_custom_order_status_invoice_processing');

add_filter('wc_order_statuses', function($order_statuses) {
    $order_statuses['wc-invoice-processing'] = '後払い処理中';
    return $order_statuses;
});

このステータスをBACSの注文に割り当てれば、標準の処理中ルートを通らずに済む。ただし、配送プラグインや在庫連動がこのカスタムステータスを「処理中」同様に扱うよう追加のフックが必要になるケースもある。その場合は、woocommerce_order_is_paid_statusesフィルターなどで「wc-invoice-processing」も支払い完了とみなしたい処理にだけ含めると調整できる。

よくある質問

この修正を適用すると、クレジットカードの処理中注文まで未払いになりませんか

紹介したコードはいずれも if 文で’ bacs ‘決済に限定しているため、クレジットカードや他の即時決済には影響しない。条件を厳密に書けば、安全に導入できる。

後払い注文のステータスをカスタムステータスにしたら、WooCommerceの標準メールは飛びますか

新規ステータスを追加しただけでは自動的にメールは送信されない。woocommerce_order_status_invoice-processing のようなアクションフックを利用して、独自のメールテンプレートをトリガーするか、処理中と同じメールを送るように設定する必要がある。

どの方法を選ぶべきかの判断基準は

まずは方法1と方法2を組み合わせて適用してみるのが最も手軽で汎用性が高い。それで解決しない場合はプラグイン固有のフィルターを探す。長期的に後払いワークフローを整理したいならカスタムステータスがおすすめだ。

この記事のポイント

  • 処理中へのステータス変更で_date_paidが自動保存される仕様が原因
  • woocommerce_payment_complete_order_statusフィルターで_date_paid書き込みをBACSだけ無効化できる
  • is_paid()の返り値を上書きすれば、日付以外の「支払い済み」判定もブロック可能
  • 請求書プラグイン固有のフィルターがあれば、そこからも支払い情報を空にできる
  • 後払い専用のカスタム注文ステータスを導入すれば、処理中と混同せずに管理できる