決済画面のUIデザイン：入力・確認・失敗時の導線を設計する

決済画面では、何にいくら支払うのか、次に何をすればよいのか、支払いが完了したのかを明確に伝える必要があります。本記事では、QRコード決済の仕組み、入力フォームの設計、PayPayと楽天ペイの事例を通して、画面づくりのポイントを整理します。

チームで画面を確認する場合は、UXデザインをチームで検討する方法と合わせて、変更理由と確認条件を共有しておくと判断がぶれません。

最後に、無料で利用を開始できるPixsoで、支払い前から完了までの画面を試作する方法を紹介します。ツールを使うだけで費用や工数が必ず減るわけではないため、必要な機能と共同作業の範囲も確認しましょう。

1. 決済画面の仕組みとは？

決済画面を設計する際は、利用者が行う操作と、決済サービスが支払いを確認する処理を分けて理解しておきましょう。コードや入力フォームが表示されたことと、支払いが完了したことは同じではありません。

まずQRコード決済を例に説明します。後半の入力欄や確認画面の考え方は、カード決済などにも関わりますが、実際に必要な操作は支払い方法によって異なります。

QRコード決済

一般的な一次元バーコードが横方向に情報を表すのに対し、QRコードは縦と横の二次元で情報を表します。

QRコードの情報量は、コードのバージョンやデータの種類、誤り訂正レベルなどによって変わります。「バーコードの350倍」と一律には言えません。デンソーウェーブのQRコード解説（英語）では、3隅の位置検出パターンにより向きを識別できることも説明されています。主な構成要素は次のとおりです。

1. セル（情報を表す小さな区画）
2. 位置検出パターン（切り出しシンボル）
3. タイミングパターン
4. アライメントパターン
5. フォーマット情報

画面設計では、利用者がコードを提示して店舗に読み取ってもらうのか、店舗のコードを読み取るのかを区別します。読み取り後に金額入力や確認が必要な方式もあるため、コード表示だけを決済完了として扱わないでください。

2. 決済画面のUIデザインに必要な3つの要素

決済画面では、進行状況、操作を説明する情報、利用できる支払い方法の表示を整理します。

次の3つは、利用者が状況を理解するための要素です。表示を整えるだけで決済の安全性が保証されるわけではなく、実際の処理やセキュリティ対策と一致している必要があります。

2.1 手続きの進捗と支払い状態

複数の入力画面がある場合は、フォームの上部などに「入力」「確認」「完了」といった手順を示します。利用者が今どの段階にいるか、あと何が必要かを把握できるようにしましょう。

手順の進捗と、決済処理の状態は区別します。確認画面へ進んでも支払い済みとは限りません。選んだ商品や金額を見直せるようにし、送信後は処理中、完了、失敗など、確認できた状態を表示します。

2.2 アイコンや説明文を入れる

アイコンや商品画像は、支払い方法や購入対象を見分ける手がかりになります。装飾性だけでなく、何を表しているかが伝わることを優先します。

商品名、数量、金額などを読みやすい文字で示し、必要に応じて画像やアイコンを添えます。アイコンだけで操作を判断させず、「カードで支払う」のような説明を組み合わせると、選択肢を区別しやすくなります。

2.3 支払いマークとセキュリティロゴの記載

決済ページには、実際に利用できる支払い方法を明示します。ブランドの支払いマークやセキュリティ関連のロゴを使う場合は、契約や表示条件を満たしていることが前提です。

支払いオプションのそばに対応ブランドを表示すると、その方法を使えるか判断しやすくなります。ただし、ロゴがあること自体は取引の安全性の証明にはなりません。実際の対応状況と異なる表示は避けましょう。

以下は、セキュリティ関連ロゴの参考画像です。自分のサービスでそのまま使用できるロゴの一覧ではありません。

画像出典：掲載元の記事。ロゴの利用許諾や現行の表示条件を示す資料ではありません。

ロゴごとに対象サービスや使用条件が異なります。導入している決済事業者や認証の提供元が定める条件を確認し、対象外の認証まで受けているような表示をしないようにします。

3. 決済画面のUIデザインに必要な3つのポイント

ここからは、入力の見やすさ、番号の表示形式、確定前の確認という3つのポイントを説明します。

進捗や支払い方法の表示と組み合わせ、利用者が内容を理解し、修正し、納得して支払いへ進める流れを作りましょう。

3.1 見やすく直感的な操作性

決済画面の役割は、利用者が購入内容を理解したうえで、意図した支払いを行えるようにすることです。

手続きが複雑だと入力や確認の負担が増えますが、簡略化のために金額や条件を隠すことも避けなければなりません。入力欄は次の点を意識して整理します。

1. 読みやすい文字サイズと十分なコントラスト
2. 入力しても消えないラベルを使う
3. フィールドの区切りが分かる余白を確保する
4. 標準のフォーム要素と自然なDOM順序で、キーボードの移動順を整える

アイコンは入力内容の補助に使い、説明を置き換えるものにはしません。キーボード操作では、正のtabindexで独自の順序を作るより、画面の順序とDOMの順序を合わせることを優先します。MDNのキーボード操作の解説（英語）も参考にしてください。

3.2 カスタムスペーシング

ここでいうカスタムスペーシングとは、クレジットカード番号や電話番号の入力時に、空白やハイフンを補って読み取りやすくする表示上の工夫です。

JavaScriptなどで表示を整えられますが、カードブランドや国・地域によって番号の長さや区切りは異なります。すべてを同じ桁数に固定せず、採用する入力形式に合わせて扱いましょう。電話番号や郵便番号にも同じ注意が必要です。

区切りがあると桁を見直しやすくなりますが、それだけで番号が正しいと保証できるわけではありません。貼り付け、途中の削除、カーソル移動が妨げられないかを確認し、表示形式の調整と入力値の検証を分けて設計します。

3.3 全情報確認画面を設ける

支払いを確定する前に、購入内容と請求額を確認できる画面を用意します。商品、数量、手数料を含む合計金額、支払い方法、必要なら配送先を示し、誤りがあれば修正へ戻れるようにします。

確定ボタンは、その操作で何が行われるか分かるラベルにします。送信後は処理中であることを伝え、結果が不明なときに安易な再送を促さないようにしてください。支払いの成否を確認してから、完了表示や再試行の案内へ進みます。

4. 決済画面のUIデザイン参考事例

実際のサービスは、コードを提示する、店舗のコードを読み取る、ポイント利用を設定するなど、複数の操作を扱います。PayPayと楽天ペイの掲載例を使い、主操作と補助操作を分ける考え方を見ていきましょう。

掲載画像は現行バージョンの画面とは異なる可能性があります。実際の操作方法は各サービスの公式ガイドで確認し、画面の見た目と現在の機能を混同しないでください。

4.1 PayPay

画像出典：Mteamの記事。

PayPayでは、支払い用のコードを提示する方法と、店舗のQRコードを読み取る方法があります。PayPay公式の記事では「支払う」からコードを提示する流れなどが説明されています。アプリを起動するだけで支払いが完了するわけではありません。

カードを裏返すような表現で残高を示す場合も、支払元や残高の確認が隠れすぎないかが重要です。PayPayの例を参考に、次の5点を確認してみましょう。

1. 支払いの主操作を見つけやすい、整理されたデザインになっているか
2. アイコンとラベルから、コード提示と読み取りの違いが分かるか
3. バーチャルカードの着せ替え表現を採用しても、支払元を識別できるか
4. グラデーションや立体表現が、文字や金額の読みやすさを損なわないか
5. キャンペーン表示が、支払い操作や状態確認を妨げないか

4.2 楽天ペイ

画像出典：Mteamの記事。

楽天ペイでは、支払い方法に加えてポイントや楽天キャッシュの利用設定も重要になります。公式の支払いガイドとポイント・キャッシュの利用設定ガイドを参考に、支払元と利用するポイントを確認してから操作できるかを検討しましょう。旧画像の配置を、現行アプリに共通する固定ルールとは扱いません。

初回案内と小さなアニメーションについても、次の観点から検討できます。

1. ウォークスルーで、初めての利用者が支払い方法と必要な設定を理解できるか
2. マイクロアニメーションが操作の結果を補助し、文言による説明も残っているか

5. 決済画面のUIデザインに役立つ無料ツールPixso

決済画面の試作では、支払い前、確認、処理中、完了といった状態を並べて検討できるツールが役立ちます。画面を作る機能だけでなく、レビューや共有まで含めて選びましょう。

その選択肢の一つがPixsoです。無料で利用を開始でき、UIデザインとプロトタイプの作成に対応しています。利用人数や必要な機能に応じて料金・プランを確認してください。

5.1 Pixso

Pixsoで決済画面を試作する際には、費用、部品の再利用、既存ファイルの移行、共有の4点から作業を整理できます。

1. 無料範囲で試作し、共同作業に必要な費用を確認する
2. 金額表示や入力欄を共通部品にして修正をそろえる
3. 対応する他社形式のファイルをインポートする
4. 同じファイルを共有し、画面の状態をチームでレビューする

Pixso公式サイトでは、次のツールのファイルをインポートできることが案内されています。これは、すべての表現や機能が完全に再現されることを保証するものではありません。

1. Figma
2. Sketch
3. Axure
4. Adobe XD

インポート後は、フォント、コンポーネント、画面遷移が意図どおりかを確認します。既存の入力フォームを活用する場合も、商品名と金額をそろえた支払い前、処理中、完了のフレームを用意し、つながりを見直しましょう。

5.2 Pixsoの機能

デザインと共同作業の機能を、各社の公式情報に基づいて比較します。同じ種類の機能でも、利用プランや操作方法が異なる点に注意してください。

Pixsoのプロトタイプで確認するのは、支払い前から結果表示までの画面と操作の流れです。実際の課金処理を行う機能ではないため、決済事業者との連携、二重送信への対策、処理結果の確認は実装側で別途検証します。機能の概要は、Pixso公式サイト、Figma Design（英語）、Sketch Design（英語）、Adobe XDヘルプ（英語）を参照しています。各社で対応環境、プラン、編集権限が異なり、同じ行に載る機能でも操作や範囲は同一ではありません。Adobe XDは現在メンテナンスモード（英語）のため、新規導入時は利用条件と今後の運用も確認してください。

決済フローをレビューする観点

決済画面は入力フォームの見た目だけでなく、支払い前後の状態を連続して確認します。請求額、通貨、配送先、選択した支払い方法が確認画面で一致しているかを最初に見てください。

• 入力：カード番号、名義、有効期限、セキュリティコードの形式を分けて示す。
• 確認：小計、手数料、割引、合計を同じ基準で表示する。
• 失敗：承認待ち、拒否、通信失敗を区別し、再試行で二重送信しない状態にする。
• 復帰：戻る操作や再読み込み後も、入力済みの内容と注文状態を誤解させない。

複数の状態をチームで確認する場合は、前段で案内したUXレビューのページと合わせ、各状態の期待結果をコメントに残すと実装前の認識差を減らせます。

6. まとめ

決済画面では、入力を簡潔にすることと、支払い内容や処理結果を正確に伝えることの両方が必要です。設計では次の3点を押さえましょう。

1. 金額、支払い方法、現在の状態を確認し、必要なら修正できる画面にする。

2. 事例は配置や案内の参考にし、現行の操作方法は公式ガイドで確認する。

3. Pixsoで支払い前、処理中、完了の画面をつなぎ、状態ごとの案内を検討する。

まずは一つの購入内容を使い、金額の確認から支払い結果まで通して試作してみてください。コードの表示やボタンの操作を完了と取り違えず、利用者が何を確認し、次に何をすべきかを判断できる画面にしましょう。