ECサイトでレンタルサーバーを使う前に確認すべきこと

ECサイトでは、商品ページが表示できても取引が成功したとは限りません。注文受付・在庫確保・決済・確認メールが別々のサービスで動くことがあります。一つだけ失敗すると、支払い済みなのに注文がない状態や、在庫の二重販売が起こります。

レンタルサーバーを選ぶ前に、一件の注文が通る経路と各サービスの責任を図にします。カード情報をどこで扱うか、注文データをどこへ保存するか、障害時にどの時点へ戻せるかを決めます。容量や月額より先に、取引状態を追跡できる構成かを判断します。

自社運用する範囲を先に決める

WordPressとECプラグインを自社サーバーで運用する方法は、機能を調整しやすい一方で更新責任が増えます。外部ECサービスは基盤管理を任せられますが、契約条件と機能制約があります。社内の技術体制と販売要件から選びます。

商品点数だけで難易度を判断しません。会員・定期購入・クーポン・配送連携などが増えると処理とデータが複雑になります。独自開発が必要な理由と、保守を続ける担当者を明確にします。

レンタルサーバーの利用規約でEC利用や負荷の条件を確認します。障害時のサポート範囲も見ます。プラグイン内部の注文不具合は、サーバー会社の調査対象外になる場合があります。

カード情報を自社ページへ入力させるのか、決済事業者へ移動させるのかを確認します。リダイレクト、埋め込み画面、自社入力では管理範囲が異なります。決済事業者の実装手順と現在の契約条件に従います。

PCI Security Standards CouncilのFAQでは、PCI DSS v4.0.1のSAQ Aでも、埋め込み決済ページを使う事業者にはスクリプト攻撃への対策確認があると説明されています。決済を委託すれば、自社ECページの改ざん対策が不要になるわけではありません。

カード番号をログ・メール・バックアップへ残さない構成を確認します。管理者権限を分け、多要素認証を使います。適用されるPCI DSS要件は決済方式と契約で変わるため、決済事業者や専門家へ現在の範囲を確認します。

注文には一意の番号を付けます。受付時刻・決済状態・在庫処理・通知結果を別々に記録します。画面上の「完了」だけでなく、決済事業者と受注管理の件数を照合します。

WebhookやAPIは通信失敗することがあります。再送されたときに二重注文や二重売上にならない処理が必要です。失敗中の注文を一覧にし、担当者が再確認できるようにします。

在庫連携が遅れた場合の販売停止条件も決めます。注文を受け続けて後から謝る運用にしません。決済成功後に在庫を確保できなかった場合の返金と顧客連絡を、業務担当者と確認します。

ECサイトのデータベースは更新頻度が高いため、一般的な会社サイトより短い損失時間を求める場合があります。何分または何件まで失えるかを業務側で決めます。その条件に合うバックアップ頻度と複製方法を選びます。

WordPress公式のバックアップ解説が示すように、一般的な復元にはデータベースとファイルの両方が必要です。ただし古いデータベースへ戻すと、取得後の注文や会員情報を失います。復元前に書き込みを止め、差分を保全します。

復元テストでは画面表示だけでなく、注文と決済照合を確認します。外部の決済・在庫・配送サービスは同じ時点へ戻らないためです。復元後に差分を処理する担当者と手順を決めます。

セールやメール配信では短時間に注文が集中します。商品ページのキャッシュだけでは、カートと決済の負荷を減らせません。本番に近い環境で、許可された範囲の負荷試験を行います。

外部APIの時間切れや遅延も試します。購入者が戻る操作や再送をしたとき、注文状態が壊れないかを確認します。上限を超えた場合に販売を一時停止し、利用者へ案内できる状態を作ります。

公開後は応答時間、エラー、注文と決済の不一致を監視します。売上件数だけでは障害を判断できません。技術担当者と受注担当者が同じ受付番号を使って状況を共有します。

WordPress・ECプラグイン・PHPを更新するときは、商品閲覧から決済完了までを検証します。営業時間や出荷締めを考え、切り戻し条件を決めます。自動更新の対象と、事前検証する対象を分けます。

障害時には新規注文を止める判断者が必要です。サーバー会社、制作会社、決済事業者への連絡順を用意します。顧客への案内と返金判断は、技術復旧とは別の責任です。

ECサイト向けの条件は、高性能という言葉だけでは比較できません。決済範囲を限定し、注文状態を照合し、復元後の差分を処理できることが必要です。その運用を継続できない場合は、自社サーバーより管理範囲の小さい外部ECサービスも含めて再検討します。