カートに商品を入れた人が、住所入力でエラーを出した後に先頭から入力し直す。決済が通らなかった人が、注文できたか分からないままもう一度ボタンを押す。ECサイトでは、このような「途中で止まった」状態が、単なるフォームの見た目の問題に収まりません。入力した情報の保持、エラーの説明、戻る先、注文の成立表示がつながって初めて、利用者は次の行動を選べます。
この記事はEC担当者と制作担当者が、購入途中の失敗を再現して直すための確認票です。決済代行会社ごとに利用できる機能や保存できる情報は異なります。ここでは特定の決済方式の実装を保証せず、住所・配送・支払い・注文確定を通して、どの画面で何を残し、何を再入力させるかを整理します。実際の個人情報の扱い、決済結果、在庫や配送条件は、採用する仕組みと事業者の運用で確認してください。
「買えない」の発生点を画面で分ける
みやあじよのECサイト制作・運用は、商品を見つけ、選び、購入し、必要なら返品へ進む一連の体験を扱います。本稿は、そのうちカートに商品を入れてから注文完了を確認するまでの失敗時に絞ります。公開済みの問い合わせフォーム改善記事は入力前・エラー時・送信後の案内を扱い、EC要件の整理記事はサイト全体の設計を扱います。ここでは住所の不備と決済失敗を別の状態として追い、購入を安全にやり直せるかを検査します。
まず「途中で止まる」を計測画面の一つの数字で終わらせず、利用者が見た現象で分けます。郵便番号と住所の組み合わせが受け付けられない、配送先に指定できない地域だった、必須欄を見落とした、外部決済画面から戻った時にカートが空になった、決済拒否後の次の操作が分からない、注文完了メールは来たが画面は失敗と表示された、という具合です。現象ごとに原因と担当が異なるため、「購入率を上げる」という抽象的な依頼だけでは修正箇所を決められません。
テストの起点は、利用者が最初に入力した値を記録した時点です。住所を誤入力した人と、正しい住所でも配送対象外の人では、同じ赤いエラー表示にしてよいとは限りません。前者には直す欄を知らせ、後者には選べる配送方法や問い合わせ先など、運用上用意できる次の道を示します。配送方法が商品や地域で変わる場合、入力前に確認できる条件を商品ページやカートへ置けないかも点検します。
支払いでは、入力形式のエラー、認証が必要な状態、支払い方法そのものが使えない状態、通信が途切れて結果が未確定な状態を分けます。どれも「決済できませんでした」でまとめると、利用者は新しいカードを入れるべきか、待って確認すべきか判断できません。ただし、決済会社から返った内部コードや審査理由をそのまま公開する必要はありません。表示できる範囲の理由と次の操作を、決済担当と確認して決めます。
入力条件・エラー・復帰先のテスト票
実機で確認する時は、正常に購入できた一件だけで合格にしません。次の表は架空のECサイトを想定したテスト票です。実際の入力規則や利用できる決済方法を決めた表ではなく、確認する欄の例です。
表は左右にスクロールできます。
| 購入段階と条件 | 表示すべき案内 | 保持・復帰を確認するもの | 次に確かめる結果 |
|---|---|---|---|
| 住所の必須欄が空欄 | 項目名と必要な入力を文字で示す | 商品、数量、他の入力済み住所欄 | 該当欄を直して配送選択へ進める |
| 郵便番号と住所が不一致 | どの組み合わせを再確認するか示す | 氏名、連絡先、修正不要な欄 | 修正後も送料が再計算される |
| 配送対象外の地域 | 地域条件と利用できる代替を示す | カート内容と戻る先 | 送料と配送可否を再確認できる |
| 決済認証を中断 | 注文状態と再開方法を区別して示す | 安全に残せる注文情報 | 認証へ戻るか別の方法を選べる |
| 決済拒否または未確定 | 成立の有無を確かめる場所を示す | カート・注文番号の扱い | 二重注文を作らず再試行できる |
この表の「保持」は、すべての値を永久に保存する意味ではありません。同じ購入手順の中で、修正が不要な氏名や配送先を毎回消さないための設計です。カード番号や認証情報など、セキュリティ上もう一度求めるべき値を無理に保持しません。ログイン状態が切れた場合、共有端末を使う場合、別の人の住所が自動で出る場合も考え、どの値をいつ破棄するかを決めます。
W3CのWCAG 2.2「Redundant Entry」解説は、同じ手順内ですでに入力された情報を再び求めるなら、自動入力または選択可能にする考え方を示しています。セキュリティ上必要な再入力や無効になった情報には例外があり、ブラウザの自動入力だけに任せる話でもありません。ECでは、配送先を直すために戻った時、支払いに失敗した時に、何が保たれるかを画面単位で確認します。
図では「入力→検査→失敗内容の説明→修正または再試行→注文状態の確認」を一周として示します。住所の誤りと決済結果未確定を同じ戻り矢印にしないのが要点です。後者は、もう一度購入ボタンを押す前に注文状態を確認する経路が必要です。テスト票には画面名だけでなく、戻った時のカート、配送方法、送料、割引の再計算も記録します。
エラー文は「どこをどう直すか」まで書く
「入力内容に誤りがあります」という画面上部の一文だけでは、長い購入フォームのどこへ戻るか分かりません。W3Cのエラー特定の解説は、検出した入力エラーの項目と内容を文字で示すことを求めています。色だけで囲む表示に頼らず、項目の近くと必要に応じて画面上部の一覧に、例えば「配送先の郵便番号を確認してください」と示します。入力を消してからエラーだけ出すと、修正する手掛かりも失います。
文言を作る時は、サイトが確かめた事実と利用者に依頼する操作を分けます。郵便番号の桁数が足りないなら、その欄を示します。住所を配送対象外と判定したなら、入力を何度変えても解決しない可能性があります。配送エリアを確認できるページや、対応できる受け取り方法への道を用意します。入力内容を勝手に別の住所へ変換する場合は、候補を本人に確認してもらいます。自動補完の便利さが誤配送を招かないようにします。
エラー表示の位置もテストします。スマートフォンで送信ボタンを押すと、エラーが画面外の最上部にだけ現れることがあります。キーボードを使う人、読み上げを使う人がエラーに気づけるか、該当欄へ移動できるかを確認します。エラーを直した後、配送方法や請求金額が変わるなら、確認画面の合計を読み直してもらう必要があります。金額が変わったのに前の同意をそのまま使う設計は避けます。
入力条件を後出しにしないことも大切です。建物名をどこまで入れるか、郵便番号のハイフンは必要か、海外へ送れるか、配送日を選べるか。購入前から分かる条件は、該当欄のそばに短く置きます。長い注意書きを一度に並べるより、商品や地域によって変わる条件をカートと配送選択で適切に見せます。決済方法の利用条件や手数料があるなら、確認画面で初めて発覚しないようにします。
決済失敗後は注文の状態を先に確かめる
決済失敗時の画面は、利用者の再試行を促す前に、注文が作成されたかどうかを確認できる必要があります。「処理に時間がかかっています」と出たまま通信が切れた時、実際には決済が通った可能性も、通っていない可能性もあります。注文履歴、確認メール、決済システムの状態を照合する仕組みを運用担当と設計します。利用者には、確認中なのか、不成立が確認されたのか、成立済みなのかを混ぜずに表示します。自動的に判定できない場合の問い合わせ先と、問い合わせに必要な番号も用意します。
採用する決済サービスの試験環境で、成功、拒否、追加認証、中断を再現します。例えばStripeの公式テスト資料は、実際の送金を伴わない試験値で支払い成功やエラー、認証を試せると説明しています。これはStripeを利用する場合の資料であり、どのECでも同じ画面や値になるわけではありません。本番のカード情報をテストに使わず、自社が採用する決済方式の手順を確認します。失敗した時の注文作成と在庫確保の状態も、画面だけでなく管理側で確かめます。
「もう一度支払う」ボタンを設けるなら、押した時に同じ注文へ再試行するのか、新しい注文を作るのかを明確にします。短時間に連続で押した場合、画面を更新した場合、戻るボタンを押した場合も試します。重複した注文、二度の在庫引当、重複した確認メールが起きないよう、注文と支払いの対応を開発担当と点検します。技術的な一意性の実装は利用するカート・決済サービスに依存するため、記事の文言だけで解決したことにはしません。
代わりの支払い方法へ切り替える時は、配送先や数量が残り、変更後の手数料と合計が確認できるか見ます。カードの失敗理由を必要以上に詳しく表示すると、安全上の問題や誤解が生じることもあります。利用者が取れる行動として、「入力を確認する」「別の方法を選ぶ」「注文履歴で状態を確かめる」「問い合わせる」のどれを示すかを決めます。決済が成立している人へ再試行を勧めないことが、安心して購入を終えるための基本です。
写真は購入手順をテストする作業の補助イメージです。画面はぼかしており、注文番号や個人情報、実際の決済結果を示しません。
修正後は購入者の道を最後まで通す
修正した画面だけを開いて終わらせず、カートから注文完了、確認メール、注文履歴まで通します。住所のエラーを直したら送料やお届け予定が変わるかもしれません。割引コード、ポイント、複数配送先、ゲスト購入など、運用している機能を掛け合わせて確認します。すべての組み合わせを無制限に試すのではなく、実際に多い買い方と、注文金額や配送の誤りにつながる条件を優先します。
テスト票には、画面幅、端末、ログイン状態、カート内容、入力値の種類、発生させたエラー、表示文、保持された値、復帰先、注文と支払いの状態を残します。個人情報や本番カード番号をそのまま票に写しません。再現手順を作れる範囲でダミー値に置き換えます。修正前後の画面を保存しても、見た目だけで「買えるようになった」と判断せず、管理画面側の注文記録と照合します。
公開後は、購入途中の離脱数だけで原因を断定せず、どの段階のエラーが起きたか、問い合わせが何を尋ねているかを見ます。端末や決済手段ごとの差は、十分な件数と条件がある時に読みます。障害が発生した場合は、案内を更新し、既に注文が成立した人への連絡と、未確定の人への確認方法を分けます。改善率を測っていない段階で成果を約束しないことも、運用記録として大切です。
みやあじよへECサイト制作・運用を相談する際は、今の購入手順、住所・配送の条件、採用する決済サービス、実際のエラー画面、注文状態の確認方法を持ち寄れます。カートに入れた後のつまずきを、入力条件・エラー表示・復帰先のテスト票に落とし、担当者が同じ現象を再現できるようにします。
購入途中の失敗を再現できるテスト票へ
ECサイト制作・運用では、住所と決済のエラー時に、入力保持から注文状態の確認までを相談できます。
