ShopifyでStripe（ストライプ）は使える？決済インフラとShopify Paymentsの関係を整理

1-1. 決済インフラ事業者という業態の考え方

オンラインで「カード番号を入力してボタンを押すと、数秒後に決済が完了する」——この体験の裏側では、カード会社への与信照会、不正利用の検知、複数の通貨・決済手段への対応、規制への準拠など、非常に多くの技術的・法的な処理が走っています。決済インフラ事業者は、こうした複雑な処理を標準化されたAPIの形でパッケージ化し、EC事業者やプラットフォームが自前でゼロから構築せずに済むようにする役割を担っています。多くのカートシステム、予約システム、マッチングサービスなどが、こうした決済インフラを基盤に、自社独自の決済体験を組み立てています。

1-2. 「決済代行」と「決済インフラ」の違いのイメージ

日本では従来、複数の決済手段（クレジットカード、コンビニ決済、銀行振込など）をまとめて導入できるようにする「決済代行」というサービス形態が広く普及してきました。決済インフラ事業者は、これに近い機能を持ちつつも、開発者がAPIで柔軟にカスタマイズできる点や、グローバルでの多通貨・多地域対応に強みを持つとされることが多く、両者は完全に同じものではありませんが、「決済という専門領域をアウトソースする」という目的においては近い役割を果たします。用語の細かい違いにこだわるより、「決済まわりの複雑さを、専門の事業者に委ねる」という発想そのものを理解することが重要です。

1-3. なぜプラットフォーム側がこうした決済インフラを採用するのか

ShopifyのようなECプラットフォームの立場で考えると、決済処理を自社だけで一から作り上げるのは、莫大な開発コストとセキュリティ対応の負荷を伴います。決済インフラ事業者の基盤を活用（あるいは提携）することで、プラットフォーム側は決済という専門性の高い機能を早く・安全に提供でき、マーチャント側も個別に外部サービスと契約せずに済むという利点が生まれます。プラットフォームと決済インフラ事業者が協業する構造自体は、EC業界において珍しいものではありません。

• 開発コストの圧縮：決済処理をゼロから作らずに済む
• セキュリティ対応の外部化：専門事業者の基盤に準拠すればよい
• マーチャント側の導入の手軽さ：個別契約なしで決済機能を使い始められる

1-4. 本記事のスタンス——断定を避け、実務判断に使える整理を

決済インフラの提携関係や、料率・条件といった具体的な情報は、契約や時期によって変わり得るうえ、一次情報以外での断定は誤解を招くリスクがあります。本記事では、こうした点について「〜と説明されることがあります」「契約条件・時期により異なる場合があります」といった慎重な表現を用い、あくまで一般的な構造・実務上の判断材料として整理することに徹します。個別の契約内容や最新の料率は、必ず各サービスの公式情報・公式窓口でご確認ください。

2-1. Shopifyにおける決済の3つの層

Shopifyの決済は、大きく①ストアフロント（顧客が決済情報を入力する画面）、②決済処理インフラ（実際にカード会社等とやり取りする裏側の基盤）、③管理画面（マーチャントが売上・入金を確認する場所）という3つの層に分けて理解すると整理しやすくなります。マーチャントが日常的に触るのは①と③ですが、決済の信頼性や手数料、対応通貨を決めているのは②の部分です。この②の層に、標準機能（Shopify Payments）を使うか、外部の決済ゲートウェイを使うかという選択肢が存在します。

2-2. Shopify Payments：Shopify自身が提供する標準決済

Shopify Paymentsは、Shopifyというプラットフォーム自身が提供する決済機能です。これを有効化すると、外部の決済代行会社と個別に契約する手間なく、クレジットカード決済などを受け付けられるようになります。管理画面が一元化されることが大きな利点で、注文情報と入金情報を同じ画面で完結して確認できます。多くのマーチャントにとって、まず検討すべき選択肢がこのShopify Paymentsです。

2-3. サードパーティの決済ゲートウェイという選択肢

Shopifyでは、Shopify Payments以外にも、外部の決済代行会社や決済インフラ事業者が提供する決済ゲートウェイを選択できる仕組みが用意されているとされています。これにより、既に別の決済アカウントで実績のある事業者や、特殊な決済フローが必要な事業者にも対応できる柔軟性が確保されています。ただし、外部の決済ゲートウェイを利用する場合、Shopify Payments利用時にはかからない追加の手数料が発生する場合があるとされており、コストの見立ては事前に確認しておくべきポイントです。

2-4. 決済手段の「種類」と「処理基盤」は別の話

ここで混同しやすいのが、「クレジットカード・コンビニ決済・後払い」といった決済"手段"の種類と、その裏側で処理を担う決済"インフラ"（処理基盤）は別の話だという点です。同じ「クレジットカード決済」という手段でも、それを処理する基盤がShopify Paymentsなのか、外部の決済ゲートウェイなのかで、手数料や入金サイクル、管理画面での見え方が変わります。この2つのレイヤーを区別して考えることが、決済まわりの理解を整理するコツです。

2-5. Shop Payなど周辺サービスの位置づけ

Shopifyのエコシステムには、購入時のワンクリック決済を実現する仕組みや、ストア運営者向けの資金・口座管理サービス、独自の残高管理機能など、決済に関連する周辺サービスが複数存在するとされています。これらは決済インフラの技術基盤の上に構築された、購入体験や資金管理を便利にするための付加サービスという位置づけで理解すると分かりやすく、標準の決済処理とは役割が異なります。名称や提供状況は今後変わる可能性もあるため、最新情報は公式情報で確認するのが確実です。

3-1. 「基盤を利用している」と説明されることがある構造

Shopify Paymentsについては、決済処理の技術的な基盤の一部として、大手の決済インフラ事業者の仕組みを利用していると説明されることがあります。これは、Shopifyというプラットフォームが自社で決済のすべてをゼロから構築するのではなく、専門の決済インフラ事業者と協業することで、迅速かつ安全に決済機能を提供しているという、EC業界ではよく見られる構造の一例と理解できます。ただし、この協業の具体的な契約内容や技術的な統合範囲は公表されている情報が限定的であり、外部からすべてを正確に断定することはできません。

3-2. ユーザー体験としては「Shopifyの機能」

背後の技術構造がどうであれ、マーチャントや購入者から見た体験としては、Shopify PaymentsはあくまでShopifyというプラットフォームの一機能です。管理画面のUI、サポート窓口、契約主体はShopifyであり、外部の決済インフラ事業者と個別に契約を交わすわけではありません。この「体験としての一体感」と「技術的な基盤の由来」は分けて考える必要があり、混同すると「Stripeと直接契約している」といった誤解につながりやすい点に注意が必要です。

3-3. 共同ブランドのサービスが存在するとされる点について

プラットフォームと決済インフラ事業者が協業する中で、購入体験を高速化するチェックアウト機能や、独自通貨・トークンでの決済対応など、共同での取り組みと説明されるサービスが展開されることがあるとされています。こうした周辺サービスの存在は、両者の関係性が単なる一過性の技術利用にとどまらず、継続的な協業関係にあることを示唆する情報のひとつとして語られることがありますが、これも具体的な契約形態を保証するものではなく、時期により提供内容が変わる可能性があります。

3-4. なぜ「関係性」を正確に語るのが難しいのか

企業間の業務提携やインフラ利用契約は、多くの場合、契約の詳細（対象範囲、地域、料率、独占性の有無など）が非公開です。外部の第三者が公開情報だけから「どこまでが提携で、どこからが単なる技術利用か」を正確に切り分けるのは本質的に困難です。したがって、本記事のようなガイド記事では、「〜と説明されることがある」「〜とされている」といった慎重な言い回しに留め、断定を避けることが誠実な情報提供の姿勢だと考えています。読者の皆様も、契約や導入を検討する際は、必ず一次情報や公式窓口での確認を行ってください。

3-5. マーチャントにとって実務上重要なのはどちらか

正直なところ、多くのマーチャントにとって重要なのは「背後の技術提携の詳細」よりも、「自社にとって使いやすく、コストが見合っているか」という実務的な結果です。次章以降では、この関係性の詳細にこだわりすぎず、「直接連携したいというニーズがなぜ生まれるのか」「実務上どう決済手段を選べばよいのか」という、日々の運営に直結するテーマに焦点を移していきます。

4-1. 背景①：他プラットフォームからの移行

ECサイトの構築サービスは複数存在し、事業の成長段階に応じてプラットフォームを乗り換えるケースは珍しくありません。移行元のプラットフォームで既に決済インフラ事業者のアカウントを使い、取引実績・入金履歴・顧客の決済情報（トークン化されたカード情報など）を蓄積してきた事業者にとっては、Shopifyへの移行後もその実績や設定を引き継ぎたいという動機が生まれます。ゼロから決済の実績を積み直すのではなく、連続性を保ちたいというニーズです。

4-2. 背景②：既存の決済契約・料率を活かしたい

既に決済インフラ事業者と直接契約し、自社の取引量や実績に応じた条件で運用している事業者は、その契約条件をShopifyでの販売にもそのまま適用したいと考えることがあります。特に複数チャネル（自社ECと実店舗、複数のカートシステムなど）で同じ決済基盤を使うことで、管理の一元化や、決済データの横断的な分析を実現したいという動機は、事業規模が大きくなるほど強くなる傾向があります。

4-3. 背景③：サブスクリプションや特殊な決済フローへの対応

定期購入・都度課金・従量課金・分割払いなど、標準の決済機能だけではカバーしきれない複雑な課金フローを実現したい場合、開発者向けAPIを直接扱える決済インフラ事業者と連携し、独自の決済ロジックを組み込みたいというニーズが生まれます。これはある程度の開発リソースを持つ事業者に多い動機で、標準機能の枠を超えたカスタマイズを求めるケースです。

4-4. 背景④：複数チャネル・グローバル展開での基盤統一

ウェブサイト、モバイルアプリ、実店舗のPOS、マーケットプレイスなど、複数の販売チャネルを同時に運営する事業者にとって、決済データを一つの基盤に集約できることのメリットは大きいとされます。チャネルごとに異なる決済基盤を使うと、売上や入金の突合作業が煩雑になりますが、基盤を統一できれば経理・分析の負荷を軽減できます。グローバル展開を視野に入れる事業者ほど、こうした基盤統一への関心が高まる傾向があります。

5-1. 判断軸①：手数料の総額で比較する

決済手数料は、基本の料率だけでなく、外部決済ゲートウェイを利用した場合に追加でかかる可能性のある手数料、月額固定費の有無、為替手数料（海外通貨での決済がある場合）まで含めたトータルコストで比較する必要があります。表面上の料率だけを見て「安い」と判断すると、後から想定外のコストが発生することがあります。具体的な料率は契約条件・時期により異なるため、必ず見積もり段階で総額を確認しましょう。

5-2. 判断軸②：対応通貨・対応決済手段の幅

国内向け販売が中心なら、コンビニ決済や後払いなど国内定番の決済手段がどれだけ揃うかが重要です。越境ECで海外に販売するなら、多通貨での決済対応、海外発行カードへの対応、現地で好まれる決済手段への対応が判断材料になります。自社の主戦場が国内か海外かによって、優先すべき論点が変わります。

5-3. 判断軸③：入金サイクル

決済されてから実際に自社口座へ入金されるまでの周期（入金サイクル）は、資金繰りに直結する重要な論点です。在庫を先行して仕入れる物販事業では、入金サイクルが長いと運転資金が圧迫されやすくなります。入金頻度（日次・週次・月次）や、初回入金までのタイムラグ（審査期間を含む）は、事業立ち上げ期には特に重視すべきポイントです。

5-4. 判断軸④：導入・運用の手間

標準の決済機能は、管理画面が一元化され、設定もシンプルな傾向にあります。一方、外部の決済ゲートウェイを組み込む場合、設定の複雑さ、問い合わせ窓口の分散、売上と入金の突合作業の増加といった運用負荷が発生しがちです。開発リソースや管理体制が限られる小規模事業者ほど、導入・運用のシンプルさを重視すべきだと言えます。

5-5. 4軸の早見表

※ 実際の手数料率・入金サイクル・対応範囲は契約条件や時期により異なります。数値の断定は避け、必ず公式情報・見積もりでご確認ください。

6-1. サードパーティ決済ゲートウェイの基本的な仕組み

Shopifyでは、標準の決済機能以外にも、外部の決済代行会社や決済インフラ事業者が提供するサービスを、決済手段のひとつとして組み込める仕組みが用意されているとされています。マーチャントは事前に外部の決済サービスと契約し、Shopifyの管理画面上でその決済ゲートウェイを選択・設定するという流れが一般的です。この場合、決済処理そのものは外部の事業者が担い、Shopifyはあくまで「その決済手段を店舗に組み込む窓口」という位置づけになります。

6-2. 確認すべきチェックリスト

• 対応地域・対応通貨：自社の販売対象地域・通貨に対応しているか
• 追加手数料の有無：標準決済にはない外部決済利用時の追加手数料が発生しないか
• 管理画面の見え方：売上・入金情報がShopifyの管理画面でどこまで確認できるか、外部の管理画面を別途見る必要があるか
• サポート体制：決済トラブル発生時、どちらの窓口に問い合わせればよいか
• 審査・契約手続きの期間：外部決済の契約審査にどの程度の期間がかかるか

6-3. サードパーティ決済を選ぶメリットとデメリット

6-4. 「まず標準機能、必要になったら外部」が現実的な順序

特別な事情がない限り、まずは標準の決済機能でスタートし、事業が成長し、明確な理由（サブスクリプション対応、複数チャネル統合など）が生じた段階で外部の決済ゲートウェイを検討する、という順序が多くの事業者にとって現実的です。開業初期から複雑な決済構成を組むと、運用の手間が増えるだけでなく、トラブル発生時の切り分けも難しくなります。段階的に検討することをおすすめします。

7-1. 国内向け販売：定番の決済手段をどれだけ揃えられるか

日本の消費者は、クレジットカードに加えてコンビニ決済、銀行振込、各種スマホ決済（QRコード決済等）、後払いといった多様な決済手段への根強いニーズを持っています。特にクレジットカードを持たない、あるいは持っていてもオンラインでの入力に抵抗がある層にとって、こうした代替手段の有無は購入するかどうかを左右する重要な要素です。国内向け販売が中心のマーチャントは、まずこれらの国内定番の決済手段をどこまで揃えられるかを軸に検討しましょう。

7-2. 越境EC：多通貨対応と為替の扱い

海外の顧客に向けて販売する越境ECでは、顧客の現地通貨での価格表示、海外発行カードへの対応、為替変動時の価格更新の仕組みが実務上の論点になります。決済インフラ側で多通貨対応が用意されていても、実際の運用では「どの通貨で入金を受け取るか」「為替差損をどう吸収するか」といった経理上の検討も必要です。越境ECを本格化する前に、こうした運用面の設計を固めておくことをおすすめします。

7-3. 特定商取引法・表示義務との整合性

決済手段を増やす際は、決済手段そのものの利便性だけでなく、特定商取引法に基づく表示（支払方法、支払時期、返品条件など）との整合性も忘れずに確認する必要があります。決済手段が増えるほど、それぞれの支払時期や手数料負担の記載も増えるため、法務・表示面のチェックも並行して行いましょう。

7-4. 実店舗との連携（オムニチャネル）を見据える場合

実店舗とネットショップを両方運営する事業者にとっては、POSレジと決済基盤の連携も検討ポイントです。オンラインとオフラインで別々の決済基盤を使うと、在庫や売上データの統合が難しくなります。オムニチャネル展開を見据えるなら、決済基盤の統一が長期的な運用効率を左右します。

7-5. 判断に迷ったときの相談先

決済手段の選定は専門性が高く、社内に詳しい担当者がいないケースも多いでしょう。Shopifyの構築・運用を手がける開発パートナーや、EC運営を包括的に支援する代理店に相談すると、自社の事業モデルに合った決済構成のアドバイスを受けられます。決済は一度設定して終わりではなく、事業の成長段階に応じて見直すべきテーマだという認識を持っておくことが大切です。

8-1. カゴ落ちの主要因のひとつ「決済手段がない」

カートに商品を入れたのに購入されずに離脱する「カゴ落ち」の原因は、送料の想定外の表示、会員登録の強制、フォームの煩雑さなど複数ありますが、「使いたい決済手段が用意されていない」ことも典型的な離脱理由のひとつとされています。クレジットカードを持たない層、あるいはオンラインでのカード入力に抵抗がある層にとって、代替手段がなければ、購入意欲があってもそこで離脱してしまいます。

8-2. 決済手段を増やすことは「保険」であって「万能薬」ではない

ここで注意したいのは、決済手段を増やせば必ずCVRが上がるわけではないという点です。決済手段の充実は、「買いたいのに決済手段がなくて離脱する」という機会損失を防ぐ「保険」としての効果が中心であり、そもそも商品ページの訴求が弱い、価格が競合と合っていないといった根本的な課題は、決済手段を増やしただけでは解決しません。決済導線の最適化は、他のCVR改善施策と組み合わせて初めて効果を発揮します。

8-3. 決済導線での摩擦を減らすチェックリスト

• 送料・手数料を早期に明示：チェックアウトの最終段階で想定外の費用が出ると離脱の原因になる
• 主要な決済手段を用意：クレジットカードに加え客層に合う代替手段を検討する
• 入力項目を最小限に：不要な入力を減らし、住所自動入力などで手間を軽減する
• ゲスト購入を用意：会員登録の強制は大きな離脱要因になり得る
• 決済エラー時の分かりやすい案内：エラー原因と再試行方法を明確に示す

8-4. 決済段階の離脱を分析で把握する

決済手段の見直しの効果を検証するには、購入ファネル（訪問→カート投入→決済画面→購入完了）のどの段階で離脱が多いかを分析画面で確認することが出発点になります。「カートには入るが決済画面で離脱している」という傾向が見えたら、決済まわりの摩擦が疑われます。感覚ではなくデータに基づいて、決済導線の改善優先度を判断しましょう。

9-1. カード情報を「どこまで自社で扱うか」がセキュリティ負荷を決める

クレジットカード情報を自社サーバーで直接保持・処理する範囲が広いほど、求められるセキュリティ基準（PCI DSSなど、カード情報を扱う事業者に求められる国際的なセキュリティ基準）への対応負荷は重くなります。多くのマーチャントにとって現実的なのは、決済処理の大部分を実績のある決済インフラ事業者やプラットフォームの標準機能に委ね、自社では必要以上にカード情報を扱わない設計にすることです。

9-2. 「自社で作り込む」より「信頼できる基盤に任せる」発想

セキュリティは、自社で頑張って独自に構築するより、専門の決済インフラ事業者やプラットフォームの標準機能に任せた方が、コストと安全性のバランスが取れるという考え方が一般的です。決済セキュリティの専門知識を持つ人材を自社で継続的に確保するのは容易ではなく、専門事業者の基盤を活用することは、多くの事業者にとって合理的な選択と言えます。

9-3. 不正利用対策も基盤側の機能を活用する

決済インフラ事業者やプラットフォームの多くは、不正利用の検知やリスクスコアリングといった機能を標準または追加オプションとして提供しているとされています。これらを活用することで、自社で不正検知の仕組みをゼロから構築する負担を避けられます。決済手段を選ぶ際には、こうした不正対策機能の有無や充実度も、判断材料のひとつとして加えるとよいでしょう。

9-4. 顧客に「安心して決済できる」と感じてもらう表示の工夫

セキュリティ対策は裏側の仕組みだけでなく、顧客に「安心して決済できる」と感じてもらう表示も重要です。信頼できる決済手段のロゴを分かりやすく表示する、SSL（暗号化通信）が有効であることが伝わるデザインにする、といった配慮は、決済段階での不安を減らし、離脱を防ぐ一助になります。実際のセキュリティ水準と、それが顧客に伝わる体験の両方を意識しましょう。

10-1. 移行チェックリスト

• 現在の決済手段が移行先で使えるか確認する
• 入金サイクル・手数料体系の変化を確認する
• 移行前後でテスト注文を行い、決済が正常に完了するか検証する
• 審査が必要な決済契約は、公開スケジュールから逆算して早めに着手する
• 特定商取引法の表示内容を、新しい決済手段に合わせて更新する

10-2. 決済まわりの変更は「小さく試して検証する」

決済手段の追加・変更は、複数を同時に行うと、どの変更が効果を生んだのか（あるいは問題を起こしたのか）が分かりにくくなります。可能であれば一つずつ変更し、分析画面でカゴ落ち率やCVRの変化を確認するというサイクルを回すことをおすすめします。決済まわりも、他のCVR改善施策と同様、仮説検証のプロセスに乗せることで、着実な改善につながります。