プラットフォームが決済を持つと、売上はどこから立つのか

Shopifyが2026年8月5日にSECへ提出したForm 10-Qの連結損益計算書は、売上を2行で開示しています。2026年4〜6月期は、Subscription solutions が802百万ドル、Merchant solutions が2,781百万ドル。合計3,583百万ドルのうち、月額プランにあたる行は全体の4分の1に届きません（当社計算で約22%）。

「サブスクリプションのソフトウェア会社」として語られる企業の売上が、すでにサブスクリプションを主にしていません。海外のプラットフォームで進んでいるのは、ソフトウェアの利用料とは別に、加盟店の取引量に連動する売上を自社の中へ持つという形です。決済はその中心にあります。

この記事は、公表資料だけでこの構造を分解します。使うのは4つです。ShopifyがSECへ提出した四半期報告書（金額）、Shopifyの日本向け料金ページ（加盟店が払うもの）、Stripe Connectの料金ページ（プラットフォーム側にかかるもの）、Stripeの公式ドキュメント（資金の通り道と責任の所在）。金額は各ページの表記どおり、米ドルと円のまま書き、通貨換算はしていません。確認日は2026年9月7日です。

読み終えたときに判断できるようにしたいのは1点です。自社のサービスに決済を組み込むかどうかは、料率をどう取るかの話ではなく、返金と不正利用の負担を誰の残高で引き受けるかの話だ、ということです。

サブスクリプション企業の売上の4分の3は、サブスクリプションではない

まず金額を見ます。Form 10-Qの連結損益計算書に載っている2つの行と、その前年同期です。

区分（10-Qの表記）	2025年4〜6月	2026年4〜6月	増減（当社計算・概数）
Subscription solutions	656百万ドル	802百万ドル	＋22%
Merchant solutions	2,024百万ドル	2,781百万ドル	＋37%
合計	2,680百万ドル	3,583百万ドル	＋34%

増減は、開示されている金額から当社が計算し、小数点以下を丸めたものです。2つの行の伸び方が違うため、構成比が動いています。Merchant solutions の構成比は、当社の計算でおよそ76%から78%へ上がりました。6か月累計でも、Subscription solutions が1,552百万ドル、Merchant solutions が5,201百万ドル、合計6,753百万ドルで、比率はおよそ77%です。

ここで1つ断っておきます。損益計算書のこの2区分に、それぞれ何が含まれるかの定義は、今回確認した連結損益計算書のページには書かれていません。中身を推測して「決済の売上」と言い換えることはできないため、この記事では金額の対比までにとどめます。それでも読み取れることははっきりしていて、伸びている側は月額の契約数ではなく、加盟店の取引に連動する側の行です。

同じ「値段の付け方を変える」動きは、AIエージェントの世界でも起きています。請求が立つ瞬間を契約時点から解決時点へ動かした例は、AIエージェントの成果課金は、何を「1件」と数えているのかで扱いました。今回はそれとは逆に、請求の単位を「利用者の数」から「流れた取引」へ移す側の話です。

加盟店が実際に払っているのは、月額だけではない

売上の側から見たら、次は加盟店が払う側を見ます。Shopifyの日本向け料金ページには、プランごとに3つの数字が並んでいます。

プラン	月払い	年払い	オンラインの標準カード料率	外部サービスの取引手数料
Basic	4,850円	3,650円	3.55% + 0円	2%
Grow	13,500円	10,100円	3.4% + 0円	1%
Advanced	58,500円	44,000円	3.25% + 0円	0.6%
Plus	368,000円〜	記載がありません	「業界最安水準の料率」（具体的な料率の記載がありません）	0.2%

3つの数字は同じ向きに動きません。月額が上がるほど、カード料率は3.55%・3.4%・3.25%と下がり、外部サービスの取引手数料も2%・1%・0.6%・0.2%と下がります。定額を多く払う側は従量が安く、定額を抑える側は従量が高い。定額と従量は交換の関係に置かれています。

注目したいのは「外部サービスの取引手数料」の行です。加盟店が自社の決済ではなく他社の決済サービスを選んだ場合、その決済会社へ払う料率とは別に、プラットフォームへ手数料がかかります。決済を持つ側から見れば、決済を使ってもらえなかったときの取りこぼしを埋める行です。加盟店から見れば、外部の決済が数字の上で安く見えても、この手数料を足してから比べる必要があります。

どのプランが安いかは、月商の規模で入れ替わります。取引額が小さいうちは、料率が高くても月額の低いプランのほうが総額を抑えられます。取引額が増えるほど料率の差が効き、どこかで月額の高いプランのほうが安くなります。分岐点は自社の月商と決済手段の内訳で変わるため、料金ページの数字を自社の実績に当てて計算してください。

ここで確かめたいのは、どのプランが得かではありません。プラットフォームの売上が、加盟店の取引量が増えるほど自動的に増える形になっているという構造のほうです。加盟店が成長すれば、契約数が変わらなくても売上が伸びます。

決済を持つと、資金の通り道が変わる

では、決済を組み込むと資金はどう流れるのか。Stripeの公式ドキュメントは、Connectを使う場合の支払いを3種類に分けています。ダイレクト支払い、デスティネーション支払い、支払いと送金別方式です。ドキュメントは、この選択が「プラットフォーム、連結アカウント、Stripe間での資金の分配方法」を決め、さらに顧客の明細書にどちらの名前が出るか、返金とチャージバックをどのアカウントから引き落とすかまで決めると説明しています。

ダイレクト支払いは、連結アカウントで支払いを作ります。ドキュメントは「連結アカウントは顧客と直接取引するため、顧客はプラットフォームの存在に気付かないことがよくあります」と説明し、この方式が向く例としてSaaSのプラットフォームを挙げ、Shopifyとオンライン講座のThinkificを名指しで挙げています。売上は連結アカウントの残高に入り、プラットフォームは指定したプラットフォーム手数料を自分の残高へ受け取ります。

デスティネーション支払いでは、プラットフォームが支払いを作り、売上の一部または全額を連結アカウントへ即時に送金します。ドキュメントは「プラットフォーム残高に残る売上の部分は、連結アカウントに請求する手数料に相当します」と書いています。ライドシェアのようなブランド名入りのサービスや、マッチング型のマーケットプレイスが例に挙がっています。

支払いと送金別方式は、支払いと送金を切り離します。1件の取引に複数の連結アカウントが関わる場合や、送金先が決まる前に支払いを作る場合に使う形で、ドキュメントはデリバリープラットフォームのDoorDashを例にしています。柔軟な代わりに「より複雑な Connect 導入が必要」で、必要な場合にのみ使うようにと書かれています。

Stripeの手数料をどちらが払うかも、方式で変わります。ダイレクト支払いでは、Stripe手数料を連結アカウントから引くかプラットフォームから引くかを選べます。デスティネーション支払いと支払いと送金別方式は、一般にプラットフォームの料金プランを使って計算されます。

返金とチャージバックは、誰の残高から引かれるか

決済を持つと決めたときに、いちばん後から効いてくるのがここです。同じドキュメントの記載を、3方式で並べます。

支払いタイプ	返金の引き落とし元	不審請求の申請（チャージバック）	資金が足りないとき
ダイレクト支払い	連結アカウントの残高から直接	連結アカウントの残高から。手数料の請求先はプラットフォームか連結アカウントかを設定できる	返金は保留になり、残高に資金が入ると作成順に自動で処理される
デスティネーション支払い	プラットフォームの残高から	プラットフォームの残高から、申し立て額と手数料が自動で引き落とされる	連結アカウントへの送金を差し戻して回収する。プラットフォーム残高が不足すれば返金は保留
支払いと送金別方式	プラットフォームの残高から	プラットフォームの残高から、申し立て額と手数料が自動で引き落とされる	同じく送金の差し戻しで回収する

行を横に読むと分かります。プラットフォームが顧客との取引の当事者になる方式を選ぶほど、返金もチャージバックも自分の残高から出ていきます。連結アカウントから回収する手段は用意されていますが、それはいったん自社の資金で立て替えたあとに取り戻すという順番です。売上が伸びるほど、立て替えの総額も伸びます。

ドキュメントには、レガシーのExpressアカウントとCustomアカウントを使っている場合、不審請求の申請と不正利用の責任はプラットフォームが対応する、とも書かれています。決済を持つという判断は、料率を取る権利と同時に、この負担を引き受けるという判断です。

プラットフォーム側にかかる費用を、公式の料金表で確かめる

プラットフォーム側が払うものも見ておきます。Stripe Connectの料金ページは、料金体系を「Stripe が管理」する形と「貴社が管理」する形の2つに分けています。

項目	料金体系はStripeが管理	料金体系は自社が管理
プラットフォームへの手数料	「プラットフォームに対する手数料はなし」。Stripeが連結アカウントへ直接請求する	有効なアカウントごと、月額200円
入金	ページに記載がありません	入金ごと 0.25% + 250円
アカウントデビット	ページに記載がありません	デビット額の1.5%

自社で料金体系を管理する側を選ぶと、手数料の設計は自由になりますが、アカウントの数と入金の回数に対して費用が発生します。加盟店の数が増えるほど、入金の回数が増えるほど、原価が積み上がる形です。

収益化の手段として、料金ページには4つが挙がっています。要件を満たすパートナーがカード取引の収益の一部を受け取るレベニューシェア、ネットワークコストをそのまま渡すIC+の料金体系、取引ごとに追加の手数料を取ること、関連する商品やサービスの手数料です。ただしレベニューシェアの条件と分配率は、料金ページには書かれていません。数字が公表されていない収益源は、見積もりに入れずに設計します。

組み込みを決める前に、4つの分岐を先に選ぶ

ここまでの材料を、決める順番に並べ替えます。決済を組み込むかどうかを検討する場面で、後戻りしにくいのは次の4つです。

1つ目は、支払いを誰の口座で作るかです。顧客が取引していると認識する相手が、自社なのか、出店者や事業者なのか。ここで顧客の明細書に出る名前が決まります。

2つ目は、Stripeの手数料を誰が負担するかです。ダイレクト支払いなら選べますが、間接の方式では一般にプラットフォーム側の料金プランで計算されます。加盟店へ提示する料率は、この原価の上に載ります。

3つ目は、返金とチャージバックを誰の残高から引くかです。ここは実質的に1つ目の選択で決まります。自社の残高から出ていく設計にしたなら、回収の運用と、立て替えに耐える資金を先に用意しておく必要があります。

4つ目は、料金体系を誰が管理するかです。自社で管理すれば手数料を自由に設計できますが、有効なアカウントごとの月額と入金ごとの手数料が固定費・変動費として乗ります。加盟店1社あたりの取引額が小さいサービスでは、この費用が利益を消すことがあります。

順番が大事です。4つ目から決めて料率表を先に作ると、1つ目と3つ目の負担を織り込まないまま価格を出すことになります。

公表資料で確認できなかったこと

今回の範囲では、次は確認できませんでした。埋めずに残します。

• Shopifyの四半期報告書の2区分に、それぞれ何が含まれるかの定義（今回参照した連結損益計算書のページには記載がありません）
• Stripe Connectのレベニューシェアの適用条件と分配率（料金ページに記載がありません）
• ShopifyのPlusプランのカード料率（「業界最安水準の料率」とだけ書かれています）
• 料金体系をStripeが管理する形での、入金やアカウントデビットの扱い（料金ページの該当欄に記載がありません）

いずれも、問い合わせや契約の場面でしか出てこない数字です。公表されていない値を仮に置いて試算すると、その仮定が独り歩きします。見積もりでは空欄のままにして、確認できた値だけで判断します。

決済を持つという判断は、料率の話ではない

3つの資料から出てきたことを、順番にまとめます。

金額の側では、Shopifyの四半期売上のうち、取引に連動する側の行が全体の4分の3を超えていました。伸び率も、月額プランの側より取引の側が大きく上回っています。料金の側では、月額と料率と外部決済の手数料が交換の関係で設計され、自社の決済を使うほど加盟店の負担が下がる形になっていました。仕組みの側では、支払いを作る場所を選ぶと、手数料の受け取り方も、返金とチャージバックの負担先も一緒に決まりました。

つまり、決済を組み込むかどうかは、いくら取れるかを決める作業ではありません。取引の当事者としてどこまで責任を持つかを決める作業です。取引量に連動する売上は、責任を引き受けた見返りとして立っています。

自社のサービスに置き換えるなら、最初に見る数字は料率ではなく、想定する加盟店1社あたりの月間取引額と、返金が発生する頻度です。この2つが小さいうちは、決済を自前で持たずに外部の決済へ渡し、プラットフォームとしての手数料を別に設計するほうが、負担と収益が釣り合います。料金の設計を1社ぶん分解した例としては、Plausible Analyticsの料金と自前で動かす選択肢も参考になります。