Shopify運用設計研究所 > Shopifyの決済手数料はいくら?|利益率と入金照合で見る運用設計
2026年7月3日
•約22分で読めます
Shopifyの決済手数料を、月額プラン料金、Shopify Payments決済処理手数料、外部サービス取引手数料、外部決済手数料、返金、チャージバック、支払い照合レポート、入金差異、粗利率、月次台帳、プラン見直しまで含めて運用設計します。
Shopifyの決済手数料は、料金表を見ればだいたい判断できますか?
入口として料金表の確認は必要です。ただし実務で見るべきなのは、料率そのものより、月次で粗利率が崩れていないか、入金額を説明できるか、返金やチャージバック後に会計まで合うかです。
ShopifyでECを運営すると、決済手数料は毎月必ず効いてきます。
検索すると、Shopify Paymentsの決済処理手数料、外部サービス取引手数料、プラン別の違い、外部決済の注意点などが出てきます。もちろん最新の料金確認は必要です。
ただし、手数料の数字だけを見ても、運用判断には足りません。
この状態では、売上が伸びても利益が残っているのか分かりません。
Shopify公式ヘルプの手数料と費用では、Shopify Paymentsの処理手数料、外部サービスの取引手数料、通貨両替に関する費用などが説明されています。手数料額は、管理画面や契約条件で確認する前提です。
また、支払い照合レポートでは、Shopify Paymentsの取引、手数料、支払いなどの残高アクティビティを確認し、銀行口座への入金と照合できると説明されています。一方で、このレポートは会計目的の収益計算書ではなく、外部決済サービスの情報も含まれない点に注意が必要です。
Shopifyの決済手数料で本当に見るべきなのは、最新料率の暗記ではなく、売上から手数料・返金・チャージバック・入金差異を差し引いた後に、月次の利益率を説明できる状態です。
Shopifyの決済手数料は、次の順番で整理すると実務に落とし込みやすくなります。
| 決めること | 見るポイント |
|---|---|
| 費用の種類を分ける | 月額プラン料金、Shopify Payments決済処理手数料、外部サービス取引手数料、外部決済サービス側の手数料を混ぜない |
| 最新料率の確認元を固定する | 公式料金ページ、Shopify管理画面、契約条件、決済サービス管理画面を確認元にする |
| 入金単位で照合する | 注文売上、返金、チャージバック、手数料、支払い合計、銀行入金額を突合する |
| 粗利率へ反映する | 商品原価、送料、値引き、決済手数料、返品・返金コストを含めて見る |
| 月次台帳を作る | 注文、支払い、返金、手数料、会計確認メモを同じ表で追えるようにする |
| プラン見直しを定例化する | 注文規模、決済方法、外部決済比率、運用負荷、必要機能を月次または四半期で見る |
この記事では、具体的な手数料率や金額は断定しません。料率、金額、適用条件は、国、契約、プラン、決済方法、カード種別、通貨、作成時期、Shopify側の改定によって変わります。最新情報は、Shopifyの公式料金ページ、管理画面、利用規約、契約条件、外部決済サービスの管理画面で確認してください。
この記事の目的は、手数料の数字を暗記することではありません。EC担当、経理、経営者が同じ数字を見て、「なぜこの入金額になったのか」「この粗利率で広告を続けてよいのか」「プランを見直すべきか」を判断できる状態を作ることです。
決済方法そのものの選び方や返金承認の設計は、既存記事のShopifyの決済設定は何を決めてから有効化すべきかでも整理しています。この記事では、その後の費用管理と入金照合に絞ります。
Shopifyの費用は、「Shopifyに払うもの」「決済サービスに払うもの」「運用上の損失」を分けて見ます。
| 費用・影響 | 何に対する費用か | 確認場所 | 月次で見る理由 |
|---|---|---|---|
| 月額プラン料金 | Shopifyの利用プランに対する固定費 | Shopify管理画面、公式料金ページ、請求書 | 売上規模に対して固定費が重すぎないか見る |
| Shopify Payments決済処理手数料 | Shopify Paymentsで決済を処理する費用 | Shopify管理画面、支払い関連レポート、契約条件 | 決済方法・カード種別・通貨で利益率が変わる |
| 外部サービス取引手数料 | 外部決済サービス利用時にShopify側で発生する取引手数料 | Shopify公式ヘルプ、管理画面、請求情報 | 外部決済を増やしたときの追加コストを見る |
| 外部決済手数料 | PayPal、後払い、各決済会社など外部サービス側の手数料 | 外部決済サービス管理画面、明細 | Shopify側の手数料とは別に経理照合が必要 |
| 通貨関連の費用 | 通貨両替や支払い通貨の差異に関する費用 | Shopify管理画面、公式ヘルプ、明細 | 海外販売や複数通貨販売で粗利がずれる |
| 返金の影響 | 売上取消、部分返金、送料返金、手数料調整 | Shopify注文、決済明細、支払い照合レポート | 売上、在庫、会計、粗利を戻す必要がある |
| チャージバックの影響 | 異議申し立て、保留、手数料、損失 | Shopify、決済サービス、証拠提出画面 | 商品代金、送料、手数料、対応工数が損失化する |
| 入金差異 | 支払い合計と銀行入金額のズレ | 支払い照合レポート、銀行明細、会計ソフト | 経理締めで説明できない差異を残さない |
この表を作らずに「Shopifyの手数料はいくらか」とだけ見ると、判断を誤ります。
たとえば外部決済を追加すると、顧客にとっては支払い手段が増えます。一方で、Shopify側の外部サービス取引手数料、外部決済サービス側の手数料、入金サイクル、返金経路、チャージバック対応、会計照合の手間が増える場合があります。
逆に、Shopify Payments中心に寄せれば、Shopify管理画面で支払いや返金を見やすくなる一方、国、通貨、カード種別、利用条件、保留、支払いスケジュールを確認する必要があります。
つまり、決済手数料は「安い決済を選ぶ」話ではありません。顧客の購入体験、入金管理、会計確認、例外対応、利益率を同時に見る話です。
決済手数料の料率や金額は変わります。プランや国、決済方法、契約条件、Shopify Paymentsの提供条件、外部決済サービスの改定によっても変わります。そのため、本文中に固定の数字を置いて運用判断するのは危険です。
| 確認したいこと | 優先する確認元 | 注意点 |
|---|---|---|
| Shopify Paymentsの処理手数料 | Shopify管理画面、利用規約、公式料金ページ | 対象国、カード種別、通貨、契約条件を確認する |
| 外部サービス取引手数料 | Shopify公式ヘルプ、管理画面、請求情報 | Shopify Payments利用有無や決済方法で扱いが変わる |
| 月額プラン料金 | Shopify公式料金ページ、契約情報、請求書 | 年払い、キャンペーン、契約条件を混ぜて比較しない |
| 外部決済サービス側の手数料 | PayPalや後払いなど各サービスの管理画面・契約書 | Shopify側の取引手数料とは別に見る |
| 返金時の手数料調整 | Shopify管理画面、決済サービス明細、契約条件 | 返金対象、手数料の扱い、通貨条件を処理時点で確認する |
| チャージバック関連費用 | Shopify、決済サービス、異議申し立て画面 | 結果、保留、手数料、証拠提出期限を追う |
料金解説記事としては、たとえばTUNAのShopify決済手数料ガイドのように、プラン別・決済別の見方を整理した記事も参考になります。ただし、実際の料率判断では、第三者記事を根拠にせず、Shopify公式ページ、管理画面、契約条件、外部決済サービスの最新情報を確認してください。
運用上は、月次台帳に「料率の根拠URL」「確認日」「確認者」を残します。記事や社内メモの古い数字をコピーし続けるのではなく、月次締めのタイミングで最新の確認元へ戻る運用にします。
決済方法ごとの比較では、手数料率だけでなく、入金サイクル、返金経路、チャージバック対応、会計照合のしやすさを見ます。
| 決済方法 | 見るポイント | 照合で注意すること |
|---|---|---|
| Shopify Payments | 処理手数料、支払いスケジュール、支払い照合レポート、保留、通貨 | Shopify Paymentsの範囲で入金・手数料・返金を確認する |
| Shop Pay | Shopify Paymentsとの関係、購入体験、顧客情報、返金 | 通常のカード決済と同じ台帳で追えるか確認する |
| PayPal | PayPal側の手数料、入金、返金、異議申し立て | Shopify注文とPayPal明細を別キーで突合する |
| 後払い・外部決済 | 与信、入金サイクル、外部決済手数料、外部サービス取引手数料 | Shopify側と決済会社側の両方の費用を分ける |
| 銀行振込・手動決済 | 入金確認、振込名義、期限、未払いキャンセル | 決済手数料より消込漏れ・入金前出荷のリスクを見る |
| 代引き | 配送会社精算、受取拒否、返品、手数料負担 | 銀行入金ではなく配送会社の精算明細と照合する |
| 複数通貨決済 | 支払い通貨、表示通貨、両替、国際販売 | 売上通貨と入金通貨を混ぜない |
単純に「顧客が使いたいから追加する」ではなく、「追加した場合、どの台帳で、誰が、どの明細と照合するか」まで決めます。
PayPalを追加するなら、PayPal側の入金明細、返金、異議申し立てを誰が見るのかを決めます。後払いを追加するなら、与信結果、出荷条件、入金サイクル、未払い時の扱いを決めます。銀行振込を残すなら、入金確認前出荷を防ぐ注文フィルタや担当者が必要です。
決済方法の有効化は、Shopifyの決済設定は何を決めてから有効化すべきかで扱ったように、出荷条件や返金承認とセットで考えます。
Shopify Paymentsを使っている場合、支払い照合レポートは月次確認の重要な入口になります。
ただし、支払い照合レポートだけで会計処理が完結するわけではありません。注文・売上のレポート、返金、銀行明細、会計ソフト、外部決済サービス明細と組み合わせて使います。
| レポート上の見る場所 | 何を確認するか | 会計・運用での使い方 |
|---|---|---|
| 開始残高・終了残高 | 対象期間のShopify Payments残高の動き | 月またぎの残高や保留を確認する |
| 手数料差し引き前のアクティビティ | 決済・返金などの総額 | 注文売上や返金集計と比較する |
| 手数料 | 対象期間に差し引かれた手数料 | 決済コストとして台帳へ転記・確認する |
| 純額 | 手数料差し引き後の残高変動 | 粗利率や入金見込みの確認に使う |
| 支払い合計 | 銀行口座へ支払われた合計 | 銀行明細の入金額と突合する |
| 請求額 | Shopify Paymentsで行われた決済 | 注文売上と照合する |
| 返金 | 返金と関連する調整 | 返金理由、在庫戻し、会計処理とつなぐ |
| 異議申し立て | チャージバックや関連調整 | 証拠提出、損失、再発防止を台帳化する |
| 調整・保留 | 手動またはシステム調整、保留金 | 入金差異の原因として確認する |
注文日、決済確定日、返金日、支払い日、銀行入金日、会計計上日は同じとは限りません。月末月初に返金やチャージバックがあると、注文レポートの売上、支払い照合レポートの残高、銀行入金、会計ソフトの数字がずれます。
入金差異をゼロに見せることより、差異の理由を「日付、決済方法、返金、チャージバック、保留、外部決済」のどれかに分類できることが重要です。
APIや会計ソフト連携で自動化する場合も、この考え方は変わりません。注文、返金、支払い、会計をどうつなぐかは、Shopify API連携の設計方法でも扱っている通り、正本と同期イベントを先に決めます。
返金やチャージバックは、売上を取り消すだけではありません。商品原価、送料、決済手数料、返品送料、倉庫作業、CS対応、証拠提出、再販売可否まで影響します。
| 事象 | 売上への影響 | 手数料・入金への影響 | 運用で確認すること |
|---|---|---|---|
| 発送前キャンセル | 売上取消または返金 | 手数料調整の扱いを確認 | 在庫戻し、会計取消、顧客通知 |
| 発送後返品 | 売上減少、一部返金または全額返金 | 決済手数料、返金日、送料負担を確認 | 検品、再販売可否、返品理由 |
| 部分返金 | 商品代、送料、値引きの一部調整 | 返金額と手数料調整を明細で確認 | どの明細を返したか、税・会計の扱い |
| チャージバック | 売上が保留・取消・損失化する可能性 | 異議申し立て関連の費用や保留を確認 | 証拠提出、配送証跡、顧客対応 |
| 外部決済側返金 | Shopifyと外部決済で状態がずれる可能性 | Shopify側と外部決済側の明細を両方確認 | 返金経路、二重返金、会計反映 |
返金時の手数料の戻り方や調整方法は、決済方法、国、契約条件、通貨、処理時点の規約で変わります。ここは一般論で処理せず、管理画面と契約条件を確認してください。
会計処理も同じです。売上取消、返金、手数料、チャージバック、消費税、勘定科目、税区分は、会社の会計方針や税務判断に関わります。この記事では一般的な運用設計として整理していますが、最終判断は税理士または会計担当者に確認してください。
返金・チャージバックを台帳に入れるなら、注文番号、決済方法、返金・異議申し立てID、発生日、理由、商品影響、金額影響、会計確認メモ、再発防止メモを残します。ここまで残しておくと、「どの商品・決済方法・販売施策で利益が削られているか」を見られるようになります。
Shopifyの売上レポートだけを見ていると、利益率を高く見積もりがちです。粗利率を見たいなら、少なくとも次の要素を分けます。
| 要素 | 見る理由 |
|---|---|
| 商品売上 | 売上の起点。ただし値引き・返金前後を分ける |
| 値引き | クーポン、キャンペーン、手動割引で粗利が変わる |
| 送料収入・配送費 | 顧客から受け取る送料と実配送費が一致しない |
| 税 | 税込・税抜、税区分、会計方針で見え方が変わる |
| 商品原価 | 商品別・SKU別の粗利を見るために必要 |
| Shopify Payments手数料 | 決済方法や通貨によって差が出る |
| 外部サービス取引手数料 | 外部決済を使う場合に追加で見る |
| 外部決済手数料 | 外部決済サービス側の明細で確認する |
| 返金・返品損失 | 返金額、再販売不可、返品送料、CS工数を含めて見る |
| チャージバック損失 | 商品代、送料、手数料、対応工数を損失として見る |
月次では、全体粗利率だけでなく、商品カテゴリ別、決済方法別、販売チャネル別、キャンペーン別、国・通貨別、新規・リピート別で見ます。注文数が多くても、値引きが大きく、返品が多く、外部決済比率が高く、送料も重いカテゴリは利益に貢献していないかもしれません。
粗利率は、経営判断と現場改善の両方に使います。経営者はプラン、広告、商品構成を見直す。EC担当は決済方法、キャンペーン、商品説明、返品理由を見直す。経理は入金差異と会計処理を確認する。役割ごとに使える台帳にすることが重要です。
月次台帳は、最初から複雑なシステムにする必要はありません。スプレッドシートでも始められます。重要なのは、注文単位、入金単位、月次集計のどれで見るかを決め、あとから会計確認できる列を用意することです。
| 列 | 内容 | 使い方 |
|---|---|---|
| 対象月 | 売上・支払い・入金をどの月で見るか | 月次締めの単位を固定する |
| 注文番号・注文日 | Shopify注文番号と注文日 | 売上レポート、返金、問い合わせの起点にする |
| 決済確定日・支払い日 | 支払いが確定し、銀行へ支払われた日 | 支払い照合レポートと銀行入金を突合する |
| 決済方法 | Shopify Payments、PayPal、後払い、手動決済など | 手数料と返金の違いを見る |
| 売上総額・値引き・送料・税 | 注文金額を分解する | 粗利率と会計確認に使う |
| 商品原価 | SKU別またはカテゴリ別原価 | 粗利計算に使う |
| Shopify Payments手数料 | 支払い照合レポート等で確認 | 決済コストとして見る |
| 外部サービス取引手数料 | Shopify側で発生する外部決済関連費用 | Shopify請求との照合に使う |
| 外部決済手数料 | 外部決済サービス側の手数料 | 外部明細と会計処理に使う |
| 返金額・チャージバック影響 | 全額・部分返金、保留、損失、結果 | 返品理由と再発防止へつなぐ |
| 入金額・入金差異 | 銀行に入った金額と差異理由 | 銀行明細、会計ソフトと照合する |
| 会計確認メモ | 勘定科目、税区分、処理月、確認者 | 最終判断は税理士・会計担当者へ確認する |
注文が少ない場合は注文単位でも追えます。注文が多い場合は、支払い照合レポート、外部決済明細、銀行明細、会計ソフトを月次で突合し、差異が大きいところだけ注文単位へ降りる設計が現実的です。
Shopify Flowで例外通知やタグ付けを行う場合は、Shopify FlowでEC運用を自動化する設計ガイドのように、支払い未確定、返金、チャージバック、不正疑い、入金確認待ちを担当者へ渡す設計と合わせると運用しやすくなります。
銀行口座に入った金額と、Shopify上の売上が一致しないことは珍しくありません。問題は、一致しないこと自体ではなく、差異の理由を分類できないことです。
| 差異の原因 | 起きること | 確認するもの |
|---|---|---|
| 日付範囲の違い | 注文月と支払い月がずれる | 注文日、決済確定日、支払い日、銀行入金日 |
| 手数料差引 | 売上総額より入金額が少ない | 支払い照合レポート、決済明細 |
| 返金 | 売上後に返金が発生する | 返金日、返金ID、注文ステータス |
| チャージバック | 保留、異議申し立て、手数料、損失が出る | 異議申し立て画面、証拠提出、結果 |
| 外部決済 | Shopify Paymentsのレポートに含まれない | PayPalや後払いなど外部決済明細 |
| 通貨・両替 | 表示通貨、支払い通貨、入金通貨が違う | 通貨設定、支払い通貨、明細 |
| 保留・調整 | 入金が遅れる、残高に残る | 支払い照合レポートの保留・調整 |
| 銀行側処理 | 入金日、摘要、振込名義が違う | 銀行明細、会計ソフト連携 |
差異が小さい場合でも、同じ原因が毎月出ているなら、台帳設計か決済運用に問題があります。外部決済が原因なら、外部決済明細の取得タイミングを締め日に合わせる。返金が原因なら、返金承認時に会計確認メモを残す。通貨が原因なら、支払い通貨ごとに台帳を分ける。原因ごとに運用を直します。
Shopifyのプラン見直しでは、月額プラン料金だけを見ると判断を誤ります。上位プランにするかどうかは、月額、決済手数料、外部サービス取引手数料、必要機能、運用工数、レポート、権限、チェックアウト、B2B、スタッフ運用などを合わせて見ます。
| 見直し軸 | 確認すること | 判断の仕方 |
|---|---|---|
| 売上規模 | 月次売上、注文数、客単価 | 固定費と変動費のバランスを見る |
| 決済手数料 | Shopify Payments、外部決済、通貨、カード種別 | 最新料率は公式・管理画面で確認する |
| 外部決済比率 | PayPal、後払い、手動決済などの比率 | 外部サービス取引手数料と照合作業を含める |
| 返金・チャージバック | 発生件数、損失、対応工数 | 手数料だけでなく損失管理を見る |
| レポート・権限 | 経理・管理者・スタッフが必要な閲覧権限 | 月次締めのしやすさを評価する |
| API・自動化 | 会計、WMS、CRM、通知基盤との連携 | 運用工数削減と保守コストを比較する |
| 海外・複数通貨 | 通貨、配送、税、返金、入金 | 通貨別の粗利率と差異管理を見る |
| 将来の販売形態 | B2B、定期購入、越境、複数ブランド | 機能不足で後から作り直さないか見る |
プランを上げれば必ず得になるわけではありません。逆に、月額を抑えることだけが正解でもありません。決済コスト、入金照合、粗利率、返金、外部決済、運用工数を合わせて、月次で説明できるかを基準にします。
Shopifyの決済手数料や入金照合は、会計・税務判断と接続します。
ただし、記事や一般的な運用設計だけで、勘定科目、税区分、売上計上時期、返金処理、チャージバック処理を確定しない方がよいです。
| 論点 | 一般的に整理すること | 最終確認先 |
|---|---|---|
| 売上計上 | 注文日、出荷日、決済確定日、入金日のどれを基準にするか | 税理士、会計担当者 |
| 決済手数料 | 手数料をどの科目・税区分で処理するか | 税理士、会計担当者 |
| 返金 | 売上取消、値引き、返品、送料返金の扱い | 税理士、会計担当者 |
| チャージバック | 損失、手数料、保留、回収不能の扱い | 税理士、会計担当者 |
| 外部決済 | Shopify側と外部決済側の手数料・入金の処理 | 税理士、会計担当者 |
| 消費税・海外販売 | 税区分、輸出、越境、通貨の扱い | 税理士、会計担当者 |
Bitlight側で支援できるのは、会計判断そのものではなく、判断に必要なデータが揃う状態を作ることです。注文番号、決済ID、返金ID、支払いID、銀行入金、手数料、差異理由、確認メモを台帳化し、税理士や会計担当者が確認しやすい証跡を残します。
Shopifyの決済手数料を見るときは、料金表の数字だけで判断しない方がよいです。
重要なのは、次の順番で運用に落とし込むことです。
決済手数料は、ECの利益率を静かに削ります。だからこそ、数字を断片的に見るのではなく、月次の売上、入金、返金、会計確認までつながる台帳として管理する必要があります。
Shopifyの決済手数料は、安い・高いの比較だけではなく、月次で説明できる仕組みにすることが大事なんですね。
その通りです。最新料率は公式情報で確認しつつ、実務では入金差異、返金、チャージバック、粗利率、会計確認まで含めて設計する方が、EC運営の判断に使える数字になります。
Bitlightでは、Shopifyのストア構築だけでなく、Shopify Payments、外部決済、支払い照合レポート、月次決済コスト台帳、会計ソフト連携、返金・チャージバック対応まで含めた運用設計を支援しています。
「Shopifyの売上は見えているが、入金額や手数料、返金後の利益率を月次で説明できない」という場合は、現在の決済設定、支払いレポート、銀行明細、会計処理、外部決済明細を棚卸しし、どの粒度で台帳化・自動化するべきか整理できます。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。