Shopify Paymentsで「決済を受け付けられない」を見逃さない｜入金保留と分ける日次監視・切り分け・顧客案内台帳

まず「入金」と「決済受付」を別の監視対象にする

Shopify Paymentsで確認すべきことは、入金予定どおりに資金が動いているかだけではありません。購入者がチェックアウトでカード、Shop Pay、ウォレットなどを選び、決済を完了できる状態かは、別の運用対象です。

たとえば、過去の注文に対する入金予定が表示されていても、新規購入時に決済手段が表示されない、あるいは決済試行が急減する可能性はあります。反対に、入金保留や追加情報の提出依頼があっても、直ちにすべての購入者が決済不能とは限りません。

日次監視では、次の3系統を混ぜずに記録します。

Shopify公式は、［設定］＞［決済］でShopify Paymentsの状態インジケーターを確認できると案内しています。入金保留、ローカル決済方法のオンボーディングエラー、事業情報に関する要件などが対象で、状態は緑・黄・赤で表示されます。色だけを原因名として扱わず、画面上の具体的なメッセージ、表示日時、対応期限を台帳に転記してください。

仕様確認日：2026年7月11日。画面名称や表示内容は、Shopifyの更新やストアの契約・所在国によって変わる場合があります。

日次監視は「表示確認」と「数値確認」を分ける

決済受付の異常は、売上金額だけで監視すると発見が遅れることがあります。売上には流入、在庫、価格、キャンペーン、曜日なども影響するためです。日次の定型作業を、購入画面を直接見る確認と、決済試行の変化を見る確認に分けます。

1. 公開チェックアウトで決済手段の表示を確認する

担当者は、実購入を行わず、通常の購入導線で商品をカートに入れ、チェックアウトまで進みます。少なくとも次を記録します。

• 確認日時と確認者
• 確認に使った販売チャネル、配送先の国・地域、通貨
• 商品、配送方法、注文金額帯
• 表示された決済手段と、前回確認との差分
• 「This store is currently unable to accept payments」などのエラー表示の有無
• スクリーンショットまたは画面録画の保管先

配送先や通貨、商品構成で表示される決済手段が変わる場合があるため、「1回見えた」だけで全条件を代表させない設計が必要です。海外向け販売、複数通貨、地域別の配送制限があるストアは、売上影響が大きい条件を優先して確認対象にします。

実際の決済まで試す運用は、事前承認なしに定例化しないほうが安全です。注文、在庫、返金処理、会計記録などに影響し得るためです。必要な場合は、対象商品、実施権限、注文の扱い、取消・返金の担当、記録方法を事前に決めます。表示確認と実決済テストを同じ作業として扱わないことが重要です。

2. 決済試行を決済手段別に見る

Shopifyのpayment_attemptsスキーマは、チェックアウトにおける決済承認試行を分析対象とし、決済手段別の承認率、再試行、カードブランド、ウォレット、カード発行国別の失敗内訳を分析する例を示しています。AnalyticsまたはShopifyQLを利用できる環境では、売上だけでなく決済試行の構成を確認します。

日次で比較しやすい最小項目は次のとおりです。

• 決済試行数
• 承認数、失敗数、承認率
• 決済手段別の試行数・承認率
• ウォレット別の試行数・承認率
• カードブランド別、発行国別の失敗の偏り
• 再試行の件数
• 比較対象期間と抽出条件

比較は「前日だけ」と固定せず、同じ曜日を含む期間や、キャンペーン実施の有無が近い期間も併記します。試行数が少ない区分では、1件の否認で率が大きく振れるため、率だけでなく件数も同時に見ます。

「決済できない」の切り分け順序

異常を見つけたときは、原因の推測から始めず、販売停止の範囲を確定する順番にします。次の順序なら、広告停止やCS告知を早まって実施するリスクを抑えられます。

1. ストア全体で主要決済プロバイダが有効か確認する

チェックアウトに「This store is currently unable to accept payments」と表示される場合、Shopify公式は、アクティブな主要決済プロバイダがない可能性を案内しています。まず［設定］＞［決済］で、主要決済プロバイダの設定状態を確認します。

Shopify Paymentsを無効化すると、オンラインストアからカード、ウォレット、Shop Payを含む決済手段が削除されます。したがって、複数のカードブランドとShop Payが同時に表示されなくなった場合は、個別カードの否認として処理せず、Shopify Paymentsの有効・無効、直近の設定変更、権限を持つ担当者の操作履歴を先に確認します。

2. Shopify Paymentsの状態メッセージを確認する

［設定］＞［決済］の状態インジケーターとメッセージを確認します。加えて、Shopify Paymentsのアカウントが保留されている場合は、管理画面ホームのバナーとストアオーナーのメールを確認するよう、Shopify公式は案内しています。

この段階で記録する項目は以下です。

• 状態色ではなく、表示されたメッセージ全文
• 表示日時、対応期限、提出・確認が必要な項目
• ストアオーナーの受信メールの有無
• 最終更新・対応日時と実施者
• 直近の事業情報、銀行口座、決済設定、アプリ設定の変更

アカウント上の対応事項が見つかった場合でも、公開チェックアウトで実際に何が表示されているか、決済試行がどの条件で変化したかは別途確認します。

3. Shopify側の障害情報を確認する

Shopify Payments利用中にゲートウェイの問題が起きた場合、Shopify公式はShopifyステータスページの確認を案内しています。監視台帳には、ステータスページを確認した時刻、対象コンポーネント、表示内容、更新時刻、URLを残します。

ただし、ステータスページに情報がないことだけで、ストア固有の設定・アカウント・購入条件の問題を除外することはできません。逆に、障害情報がある場合でも、自ストアの決済手段表示や試行数への影響を確認してから、広告や顧客案内の範囲を決めます。

4. 特定条件への偏りを確認する

ストア全体の決済手段が表示され、Shopify Paymentsの状態にも直ちに対応すべき表示がなく、ステータスページにも該当情報がない場合は、決済試行データを分解します。

確認軸は、決済手段、ウォレット、カードブランド、カード発行国、配送先、通貨、端末やブラウザの情報を取得できる範囲です。ここでの目的は原因を断定することではなく、「全購入者向けの告知が必要な状態か」「特定条件の購入者への案内・調査に留めるか」を判断することです。

広告・CS・定期購入の初動を事前に決める

決済受付の異常では、技術確認と同時に販売活動をどう扱うかが問題になります。判断者が不在のまま広告を継続すると、購入できないページへ流入を増やす可能性があります。一方、確認不足で全広告を止めると、正常な導線まで止めることになります。

そこで、台帳の状態ごとに暫定判断を定義します。

定期購入を扱う場合は、通常の新規チェックアウトと別に、継続課金の失敗通知、契約更新、在庫引当、会員特典の扱いを担当部署と確認します。本記事で紹介するpayment_attemptsはチェックアウトでの決済承認試行を対象にした分析仕様です。定期購入の請求状態まで同じ指標で把握できるとは限らないため、利用中の定期購入アプリ・契約管理機能の記録と照合してください。

顧客案内は「使えない理由」を推測して伝えない

顧客への連絡では、カード会社、Shopify、購入者の入力内容のいずれが原因かを、確認前に断定しないことが重要です。とくに個別否認では、ストア全体の障害と同じ文面を出す必要はありません。

ストア全体の受付に影響がある場合の案内例

現在、一部または全部の決済手段でご注文を完了しにくい状況を確認しており、原因を確認しています。復旧状況は本ページで更新します。お急ぎの場合は、表示されている利用可能な決済手段をご確認ください。

実際に利用可能と確認していない決済手段を案内しないでください。「別のカードなら必ず使える」「すぐ復旧する」といった約束も避けます。

個別の決済失敗について問い合わせを受けた場合の確認項目

問い合わせフォームやCS台帳では、必要最小限の情報だけを受け取ります。

• 発生日時と注文しようとした商品
• 表示されたエラーメッセージ
• 利用しようとした決済手段の種類
• 配送先の国・地域
• 再試行の有無

カード番号、有効期限、セキュリティコードなど、決済情報そのものをCSが収集・保管する設計にはしません。情報を受けた後は、同時刻の公開チェックアウト表示、決済試行の集計、Shopify Paymentsの状態を照合します。

そのまま使える「決済受付監視台帳」

スプレッドシート、チケット管理ツール、障害管理ツールのどれを使う場合でも、時系列で判断を追える列を作ります。障害時だけでなく、正常時の記録を残すことが比較の基準になります。

監視日時：
確認者：
確認環境（国・通貨・配送先・端末）：
公開チェックアウトの表示決済手段：
表示エラーの有無／画面保存先：
Shopify Payments状態（色・メッセージ全文）：
ホーム画面バナー／オーナーメールの確認結果：
Shopifyステータスページ確認時刻・表示内容：
決済試行数／承認数／失敗数／承認率：
決済手段・ウォレット・カード発行国別の変化：
直近の設定・事業情報・アプリ変更：
影響範囲の仮説（未確定であることを明記）：
広告判断（継続・抑制・停止）／決定者／時刻：
CS案内文／公開先／掲載時刻：
Shopifyへの照会番号・添付資料：
次回確認時刻／担当者：
復旧確認結果とクローズ判断：

Shopifyへ照会する場合は、「決済できない」とだけ伝えるより、再現条件と時系列を添えるほうが切り分けに使いやすくなります。少なくとも、ストアURL、発生開始時刻とタイムゾーン、影響する決済手段、国・通貨、画面キャプチャ、状態メッセージ、ステータスページ確認結果、該当する注文または試行の識別情報を整理します。

決済受付の監視は、異常を必ず未然に防ぐ仕組みではありません。しかし、入金・アカウント状態・チェックアウト・個別否認を同じ事象として処理しないことで、確認漏れと過剰な販売停止の両方を減らせます。まずは日次の表示確認と台帳記録を始め、試行データを見られる環境では決済手段別の比較を追加する順序が現実的です。

参考情報

• Shopify Help Center：Configuring Shopify Payments
• Shopify Help Center：Troubleshooting payment gateways
• Shopify Developer Documentation：payment_attempts