個人開発の決済システム：インボイス制度を踏まえたStripeとPaddleの比較

Stripeの国内決済手数料は3.6％＋30円、Paddleは5％＋0.50ドル台。表面上はStripeの方が安い。ただし、両者は同じ種類のサービスではない。Stripeは決済処理を担う事業者で、販売者は開発者自身。一方のPaddleは、販売元代行、いわゆる販売者代行の仕組みを取る。

この違いは、手数料の差より大きい。インボイス制度への対応、海外の付加価値税や消費税の処理、返金時の顧客対応、税務申告の責任が、どこに残るかが変わるからだ。

個人開発の決済で見るべきなのは、安い決済手段ではない。自分がどこまで販売者として責任を持つのか、その範囲を決めることである。

PSP（決済代行）とMoR（販売元代行）——売り主が誰かで全部が変わる

StripeとPaddleの根本的な違いは、誰が顧客に対する販売者になるかという一点に集約できる。

Stripeは、一般的な決済代行のモデルだ。カード情報を安全に扱い、与信処理を行い、決済結果を通知し、売上を開発者の口座へ振り込む。定期課金や請求書発行、支払い失敗時の再試行など、販売に必要な機能も提供する。

しかし、サービスそのものを販売しているのは開発者である。利用規約上のサービス提供者も、顧客との売買契約の当事者も、基本的には開発者側になる。Stripeは販売の主体ではなく、決済インフラとして機能する。

Paddleは販売元代行、つまり販売者としての役割を引き受けるモデルだ。顧客との決済をPaddleが受け付け、デジタル商品やソフトウェアの販売についても、Paddleが販売者として前面に立つ。開発者はPaddleに商品やサービスを提供する側として参加する。

この構造を簡単に整理すると、次のようになる。

PSPとMoRの違いは、手数料の差ではない。税務・コンプライアンス責任の所在地の差だ。

この違いを確認せずに料金だけを比べると、後から設計をやり直すことになる。特に海外向けにサブスクリプションを販売する場合、税率の計算だけでなく、どの国で誰が税務上の販売者になるのかまで整理しなければならない。

MoRは何を代行するのか

販売元代行という言葉は、決済画面を借りられるという意味ではない。PaddleのようなMoRは、顧客との販売関係の一部を引き受ける。

たとえば、次のような業務が対象になる。

• 顧客の所在地や取引内容に応じた税率の判定
• 請求額への税の加算
• 税を含む請求書や領収書の発行
• 一部地域における税務申告と納税
• 返金や支払い失敗に関する顧客対応
• 販売者として必要になる本人確認や審査

もちろん、Paddleを使えば何も考えなくてよいわけではない。取り扱える商品、禁止される用途、返金条件、販売地域、アカウント審査などは確認が必要だ。開発者が商品を作り、サポートし、品質を保つ責任までPaddleに移るわけでもない。

それでも、海外販売で最も面倒になりやすい税務上の販売者業務を、一定範囲で外部に出せる点は大きい。StripeとPaddleの手数料差は、この業務を内製するか、外部に任せるかの料金として見る方が実態に近い。

インボイス制度と税務処理——個人開発者が負う範囲

日本では2023年10月1日から、適格請求書保存方式、いわゆるインボイス制度が始まった。法人顧客が仕入税額控除を受けるには、原則として、必要な事項が記載された適格請求書を保存しなければならない。

個人開発者のサービスで問題になりやすいのは、法人向けのSaaS、業務ツール、買い切り型のソフトウェア、チーム向けの有料プランだ。個人ユーザーだけを相手にしている場合と違い、法人顧客は決済が完了すれば終わりではない。経理処理に使える請求書を受け取れるかどうかが、契約継続の条件になることがある。

ここで重要なのは、決済事業者が請求書を表示できるかではない。その請求書が、誰の販売に関するものとして発行され、適格請求書発行事業者の登録番号がどこに記載されるかである。

請求書の見た目が整っていても、発行者と取引の関係が曖昧なら、顧客企業の経理部門は処理に迷う。営業担当者が購入を決めても、経理確認の段階で追加資料を求められたり、契約更新時に別の請求方法を指定されたりすることがある。決済画面の導入前に、購入後に顧客へ何が渡るのかを確認しておきたい。

Stripeを使う場合の責任

Stripeを使う場合、販売者は開発者側に残る。開発者が適格請求書発行事業者として登録しているなら、その登録番号を請求書に表示する設計が必要になる。Stripeの請求書機能を利用する場合でも、どの情報を登録し、どの形式で顧客へ渡すかは、自社の運用として確認しなければならない。

必要になる作業は、決済画面の実装だけではない。

1. 自分の事業が課税事業者に該当するかを確認する。

2. 適格請求書発行事業者として登録するか判断する。

3. 登録した場合は、登録番号を請求書や領収書に表示する。

4. 税率、税額、取引内容、発行日など、請求書に必要な項目を整える。

5. 顧客がダウンロードした請求書と、自社の売上・入金記録を対応させる。

6. 返金やプラン変更があった場合に、請求書や取引記録をどう修正するか決める。

Stripeが請求書を生成してくれることと、Stripeが税務上の責任を引き受けることは別の話だ。請求書作成の機能があっても、販売者としての申告や帳簿管理まで自動的に完了するわけではない。

個人事業のまま登録するのか、法人化と合わせて考えるのかも、決済サービスだけでは決められない。売上規模、顧客の構成、経費、納税負担、事業の継続性を含めた税務上の判断になる。

また、決済額と売上計上額が常に同じになるとは限らない点にも注意が必要だ。返金、割引、無料期間、プラン変更、決済事業者からの入金時期があるため、管理画面の入金額だけを見て帳簿を作ると、後で取引の対応関係が分からなくなる。注文、請求、返金、入金を追跡できる識別子を自社側にも保存しておくと、月次処理が安定する。

Paddleを使う場合の確認点

Paddleでは、販売元代行としての立場から、海外顧客に対する税の計算や徴収、申告・納税をPaddle側が担う範囲が広い。開発者が各国の税率を個別に調査し、国ごとに請求書を設計し、納税先を管理する負担を減らせる。

これは海外販売では強い。しかし、日本のインボイス制度に関しては、MoRだから自動的にすべて解決するとは考えない方がよい。

確認すべきなのは、少なくとも次の点だ。

• 日本の法人顧客に渡される請求書の発行者は誰か
• その請求書に日本の適格請求書発行事業者の登録番号が記載されるか
• Paddleの請求書が、顧客側の経理処理で受け入れられるか
• 日本国内の取引について、税の扱いがどのように説明されているか
• 返金、請求先変更、請求書の再発行に対応できるか
• 契約する時点の最新仕様で、対象地域と対象商品がどう定義されているか

Paddleの請求書を国内法人がそのまま適格請求書として扱えるかどうかは、導入前に公式情報と契約条件を確認し、必要であれば顧客企業の経理部門にも聞いておきたい。決済画面が問題なく動くことと、取引後の会計処理が問題なく通ることは別である。

Paddleが海外税務を担う範囲が広いとしても、日本国内の自社事業に関するすべての税務判断まで消えるわけではない。Paddleから受け取る売上、手数料、返金、送金の記録をどのように帳簿へ反映するかは、自社の事業形態や契約内容に応じて整理する必要がある。

個人開発者にとって怖いのは、手数料の数値より、インボイス対応の抜けによって契約後に請求処理が止まることだ。

Stripe Taxと代理納税の境界線

海外向け販売では、Stripeの税計算機能も候補になる。顧客の所在地や商品情報をもとに税率を計算し、必要な情報を管理しやすくする機能だ。

ただし、税額を計算できることと、税務申告・納税を代行してくれることは同じではない。Stripe Taxを利用しても、販売者が開発者自身であるなら、どの国で登録が必要なのか、どの申告を行うのか、徴収した税をどこへ納めるのかという責任は残る。

ここを誤解すると、システム上は正しい税額を請求できていても、申告が必要な国への手続きが抜ける。税率計算の自動化は、税務業務の一部を軽くするものであって、販売者としての義務を消す機能ではない。

PaddleのMoRモデルは、この責任の切り分けが異なる。Paddleが販売者として対応する範囲については、Paddleが税の計算、徴収、申告、納税を行う。海外顧客を増やしたい個人開発者にとって、これは単なる管理画面の便利さではなく、事業上のリスクを外部に移す判断になる。

ただし、Paddleに移した後も、自社の売上計上や入金確認、契約関係、開発者報酬の扱いが消えるわけではない。税務処理がすべてなくなるのではなく、顧客への販売に伴う一部の責任をPaddle側に委ねる、と理解しておくのが正確だ。

手数料の損益分岐点——3.6％＋30円と5％＋0.50ドルを比べる

StripeとPaddleを比べるとき、まず見えるのは決済手数料だ。

ここでは計算条件をそろえるため、Paddleの固定額を0.50ドル、為替レートを1ドル＝150円として試算する。つまり、Paddleの1件あたりの固定額は75円として計算する。Stripeは売上の3.6％に1件あたり30円を加え、Paddleは売上の5％に1件あたり75円を加える。

計算式は次の通りだ。

• Stripe：月商×3.6％＋決済件数×30円
• Paddle：月商×5％＋決済件数×75円

返金、チャージバック、通貨換算の手数料、契約条件による追加費用などは含めていない。Paddleの固定額が0.50ドル台で変動する場合や、実際の為替レートが150円から離れた場合は、結果も変わる。

たとえば中規模の行では、Stripeは100万円×3.6％で36,000円、1,000件×30円で30,000円となり、合計は66,000円になる。Paddleは100万円×5％で50,000円、1,000件×75円で75,000円。合計は125,000円なので、差額は59,000円だ。

従来のようにPaddleを約75,000〜80,000円と置くと、売上の5％と固定額部分の二重計算にならない。1,000件の決済だけで固定額が75,000円発生するため、Paddleの手数料は売上に対する5万円を加えた125,000円になる。

この表から分かるのは、決済件数が多いサービスほど固定額の差が効くということだ。平均単価1,000円のサービスでは、Paddleの固定額75円が売上の7.5％に相当する。売上に対する5％と合わせると、固定額だけで手数料負担がかなり膨らむ。

一方、平均単価が高くなると、固定額の影響は相対的に小さくなる。平均単価1万円なら、Paddleの75円は売上の0.75％にすぎない。とはいえ、率の差が1.4ポイントあるため、売上が大きくなるほどパーセンテージ部分の差も無視できなくなる。

純粋な売上の損益分岐点は存在しない

同じ売上、同じ決済件数、同じ為替レートで比較する限り、StripeとPaddleの手数料だけを比べた損益分岐点はない。

Stripeの手数料を 0.036R＋30N、Paddleを 0.05R＋75N とすると、差額は次のようになる。

Paddleの手数料 − Stripeの手数料 ＝ 0.014R＋45N

Rは月商、Nは決済件数だ。売上と決済件数が正の値である限り、Paddleの方が高くなる。つまり、売上がいくらになればPaddleの方が手数料だけで安くなる、という分岐点は存在しない。

ここでいう損益分岐点は、手数料だけでなく、税務・請求書・返金対応などの運用コストまで含めた場合に初めて成立する。Paddleによって毎月の管理作業が減り、その時間価値が差額を上回るなら、事業全体ではPaddleが有利になる可能性がある。

たとえば中規模の試算では、Paddleの差額は月59,000円だ。この差額で、海外税務の調査、請求書の確認、返金処理、問い合わせ対応を外部化できると考えるなら、単純な決済費用の比較とは違う判断になる。逆に、国内の個人顧客だけを相手にしていて、税務処理も自分で無理なく管理できるなら、差額はそのまま利益に近い。

損益分岐点は売上だけで決まらない

実際の分岐点は、次の要素で大きく動く。

• 海外顧客が何％いるか
• 顧客が個人中心か、法人中心か
• 月額課金か、買い切りか
• 平均単価と決済件数がどの程度か
• 返金や支払い失敗がどれくらい発生するか
• 税務と請求書の対応を誰が担当するか
• 開発者自身の時間をいくらのコストとして計算するか

海外売上がほとんどなく、国内の個人顧客だけを対象にしているなら、Stripeの低い手数料がそのまま利益に効きやすい。反対に、顧客が複数の国に分散し、税率や請求書の問い合わせが増えるなら、Paddleの高い手数料が管理コストの削減費になる。

特に個人開発では、人件費が損益計算書に現れにくい。税務調査に備えた記録の整理、顧客からの請求書問い合わせ、返金時の帳簿修正、海外税務の調査は、すべて開発者の時間を消費する。それを無料の作業として扱うと、Stripeの方が安いという結論に偏る。

為替と固定額手数料

今回の試算では1ドル＝150円としたが、Paddleの固定額部分はドル建てになるため、円で売上とコストを管理する場合は為替の影響を受ける。同じ0.50ドルでも、1ドル＝140円なら70円、1ドル＝160円なら80円になる。

中規模の1,000件決済で考えると、固定額部分だけで次のように変わる。

売上100万円に対する5％は50,000円なので、固定額の変動だけでPaddleの手数料全体が10,000円変わる。料金比較を記事や社内資料に残すなら、為替レートを書かずに円換算するべきではない。

ただし、為替だけを理由にPaddleを避けるのも単純すぎる。海外顧客からドルやユーロで売上を得るなら、売上そのものにも為替変動がある。決済手数料の固定額だけでなく、入金通貨、銀行への送金、円への換算、売上の計上タイミングまで含めて考える必要がある。

試算では、少なくとも次の三つを分けたい。

1. 顧客が支払う通貨と表示価格

2. 決済事業者が手数料を差し引く通貨

3. 開発者が最終的に受け取る通貨と会計上の円換算

価格を円で固定して海外へ販売するのか、地域ごとに現地通貨で表示するのかによっても、顧客の見え方と為替リスクは変わる。

実装工数も手数料に換算する

Stripe BillingとPaddle Billingは、どちらもサブスクリプション、顧客管理、支払い失敗への対応、Webhook連携といった機能を持つ。しかし、既存システムへ組み込む際の設計は同じではない。

Laravelで会員管理を行っているなら、決済成功時にユーザーの契約状態を有効化し、更新時に期限を延長し、解約時に機能を停止する処理が必要になる。決済画面が表示されるだけでは、課金システムは完成しない。

実装時に扱うことになる主な状態は、次の通りだ。

• 初回決済が成功した状態
• 決済は成功したが、Webhookが遅れて届く状態
• 定期課金の更新に失敗した状態
• 顧客がカードを更新した状態
• 顧客が解約したが、契約期間の終了までは利用できる状態
• 管理者が返金を実行した状態
• 決済事業者側では成功しているが、自社データベースの更新に失敗した状態

Docker上の開発環境で決済処理を組む場合も、Webhookの受信経路、署名検証、再送時の重複処理、ログの保存場所を先に決めておく必要がある。決済結果を受け取るたびに単純に利用権限を書き換える実装では、同じ通知が再送されたときに契約期間を二重に延長するような事故が起こる。

決済通知は一度しか届かないとは限らない。通信のタイムアウトや自社側の一時的な障害によって、同じイベントが再送されることがある。イベントIDを保存し、処理済みかどうかを確認してから会員状態を更新するだけでも、重複処理の事故は減らせる。

StripeでもPaddleでも、決済事業者の画面から見た成功と、自社サービスの会員状態が一致しているとは限らない。決済基盤の選定では、料金表だけでなく、既存の認証・請求・顧客管理との接続まで見積もるべきだ。

グローバル展開か国内B2Bか——サービス特性で選ぶ決済基盤

決済基盤の選定は、サービスの顧客構成から考えると整理しやすい。最初に見るべきなのは、顧客の所在地と、顧客が法人か個人かである。

海外顧客の比率

海外顧客が増えるほど、販売者として抱える税務上の論点は増える。税率、顧客の所在地、商品区分、請求書の要件、申告期限、登録の有無など、国ごとに確認が必要になる。

海外売上がまだ少なく、顧客の大半が日本国内にいるなら、Stripeで始める合理性は高い。国内向けの価格表示や決済導線を作りやすく、手数料も抑えやすい。海外対応が必要になったとしても、まず顧客数と売上比率を把握してから追加の仕組みを導入できる。

反対に、販売開始時点から海外顧客が多い、あるいは今後の成長を海外中心に考えているなら、PaddleのMoRモデルが候補になる。税務を自社で管理する体制を作る前に売上だけが増えると、後から国別の対応を整理するのが難しくなるからだ。

ただし、海外顧客が半分を超えたら必ずPaddle、という固定ルールにする必要はない。売上比率だけでなく、顧客がいる国の数、法人顧客の割合、商品価格、問い合わせの量を見て判断する方が現実的だ。

同じ海外売上でも、数か国の個人顧客に限定されているサービスと、多数の国の法人へ販売するサービスでは、必要な管理の重さが違う。顧客がどこにいるかだけでなく、どのような請求書を要求するかまで見ておきたい。

法人顧客か、個人顧客か

国内B2Bでは、インボイス対応が決済基盤選定の前提になる。法人顧客にとっては、契約担当者が購入を決めても、経理部門が請求書を受け取れなければ処理が止まる。

Stripeを使う場合は、自社が販売者として請求書を発行する設計を作りやすい。適格請求書発行事業者として登録しているなら、登録番号を正しく表示し、取引内容と税額を整え、顧客が保存できる形で提供する必要がある。

Paddleを使う場合は、Paddleが発行する請求書や注文確認の内容を、取引前に確認するべきだ。顧客企業がその書類を社内処理に使えるか、登録番号や税の扱いに不足がないかは、サービスの営業上も重要になる。

個人顧客中心のB2Cでは、法人向け請求書ほどの運用負担は生じにくい。とはいえ、領収書、返金、解約、支払い失敗の案内が不要になるわけではない。問い合わせのしやすさ、決済画面の信頼感、カード情報を更新しやすいかどうかが、継続利用に影響する。

国内B2CならStripe、海外中心ならPaddleという仮説

最初の仮説としては、国内B2CのSaaSや個人向けツールならStripe、海外比率が高いデジタルサービスならPaddleが考えやすい。

国内B2CでStripeを使う場合は、決済手数料を抑えながら、料金プランやクーポン、請求周期、会員状態を自社の設計に合わせやすい。Laravelなどのアプリケーション側で会員権限を細かく管理したい場合にも向いている。

海外中心でPaddleを使う場合は、各国の税務や請求書に関する作業を減らせる。利用者に対しても、地域に応じた税を含む価格表示や請求を行いやすい。ただし、手数料が高い分、顧客単価が低いサービスでは利益への影響が大きくなる。

ここで気をつけたいのは、Paddleを選んだ場合でも、顧客との関係が完全にPaddle任せになるわけではないことだ。ユーザーサポート、サービス障害、アカウント停止、データ削除、解約方法の案内は、開発者側で責任を持つ必要がある。MoRは税務と販売処理の一部を肩代わりする仕組みであり、プロダクト運営そのものを代行するものではない。

国内と海外で決済経路を分ける場合

国内と海外で決済事業者を分ける構成もある。国内ユーザーはStripe、海外ユーザーはPaddleという設計だ。

この方法なら、国内ユーザーには円建ての分かりやすい決済画面を出し、海外ユーザーには現地向けの通貨や請求フローを提供できる。片方の事業者にすべてを依存しないため、サービス停止や審査上の問題が起きた場合の影響を分散できる可能性もある。

一方で、実装と運用は確実に複雑になる。ユーザーごとに決済事業者が異なるため、管理画面での確認方法も変わる。解約や返金の処理経路も分けなければならない。利用者が国を移動した場合、既存契約をどのように扱うかも決めておく必要がある。

地域判定は、IPアドレスだけに任せると誤判定が起きる。海外旅行中の日本人、日本語を使う海外在住者、法人の請求先と利用者の所在地が違うケースもあるからだ。IPアドレスは補助情報として使い、国と通貨をユーザーが明示的に選べる導線を用意した方が安全なことが多い。

決済ボタンの分岐だけでなく、次の情報も統一して管理したい。

• 自社ユーザーと決済事業者側の顧客識別子
• 契約中プランと契約期間
• 決済事業者ごとの請求書番号
• 返金・解約・支払い失敗の状態
• Webhookの受信履歴と再処理履歴
• 顧客が利用している決済経路

決済事業者を並走させるなら、最初から自社データベースに決済事業者固有の情報を埋め込みすぎないことも大切だ。将来の切り替えを考え、契約状態、利用権限、請求状態を自社側の共通モデルとして持っておくと、運用の変更に耐えやすい。

手数料以外に見るべき運用上の差

決済基盤を選ぶとき、実装できるかどうかだけで判断すると、公開後に困る。売上が増えたときの運用、問い合わせ、返金、監査対応まで見ておく必要がある。

支払い失敗と解約処理

サブスクリプションでは、顧客が自分から解約するケースより、カードの期限切れや利用限度額超過によって支払いに失敗するケースの方が扱いにくい。

支払い失敗が起きたとき、すぐに利用停止するのか、一定期間の猶予を置くのか、何回再試行するのかを決める必要がある。決済事業者が再試行機能を提供していても、自社サービスの利用権限がいつ変わるかは別に設計しなければならない。

特に重要なのは、決済状態と利用状態を同じものとして扱わないことだ。たとえば支払いに失敗しても、再試行期間中は利用を継続させることがある。逆に、返金済みの取引については、請求期間の残りがあっても利用を止める契約にしているかもしれない。

このルールを決めないまま実装を始めると、顧客ごとに対応が変わり、サポートの負担が増える。

返金とチャージバック

返金は、管理画面でボタンを押せば終わる処理ではない。自社の会員状態、請求書、売上計上、顧客への案内が連動する。

返金額の一部だけを戻すのか、未利用期間に応じて返すのか、年額プランを月割りするのか。サービスの利用規約に沿って、判断基準を決めておく必要がある。

チャージバックが発生した場合は、顧客が正規の利用者か、決済後にどの機能を使ったか、本人確認や利用記録が残っているかが問題になる。決済事業者に送る証拠を準備できるよう、注文情報と利用履歴を保存しておくとよい。

PaddleのようなMoRでは、顧客との請求関係をPaddleが担う範囲が広いが、サービスの利用実態を説明できる記録まで自動で整うわけではない。アプリ側の監査ログや契約履歴は、自社で管理する必要がある。

審査とアカウント停止

決済事業者は、サービス内容、販売方法、顧客層、利用規約、返金方針などを確認する。個人開発では、サービスを先に公開してから決済審査に申し込むことがあるが、審査で説明を求められると準備不足になりやすい。

最低限、次の情報はサービス内で確認できるようにしておきたい。

• 何を販売しているか
• 誰が運営しているか
• 料金と課金周期
• 解約方法
• 返金条件
• 問い合わせ窓口
• 利用規約とプライバシーポリシー

StripeでもPaddleでも、決済事業者の判断で確認や制限が入る可能性はある。MoRを使えば決済リスクが消えるのではなく、審査の窓口と契約条件が変わると考えた方がよい。

それぞれに向いているサービスの形

Stripeが向いているのは、国内顧客を中心に、アプリ側で課金ロジックを細かく制御したいサービスだ。国内B2Bで請求書の要件を自社で管理したい場合や、既存のLaravelアプリに会員権限と決済状態を密接に組み込みたい場合にも扱いやすい。

ただし、自由度が高い分、責任も自社に残る。インボイス登録、請求書の発行、税務処理、返金、海外販売時の税務確認を、自分たちの運用として整備する必要がある。

Paddleが向いているのは、海外の個人顧客へデジタル商品やSaaSを販売し、各国の税務処理をできるだけ外部化したいサービスだ。開発者が一人、あるいは少人数で運営していて、税務担当者を置く余裕がない場合は、手数料差を管理コスト削減の対価として受け入れやすい。

その代わり、料金や契約条件を完全に自社都合で決められるとは限らない。国内法人向けの請求書要件、サービスの審査、返金や顧客対応の範囲も事前に確認する必要がある。

判断を整理するなら、次のような見方になる。

• 国内の個人顧客が中心で、決済手数料を抑えたいならStripe
• 国内法人が中心で、適格請求書を自社で管理できるならStripe
• 海外の個人顧客が多く、税務処理を外部化したいならPaddle
• 国内と海外の顧客が混在し、それぞれに異なる請求体験が必要なら並走も検討
• 決済状態をアプリの業務フローに深く組み込みたいなら、実装自由度を重視してStripe
• 税務や販売者業務を最小限の体制で運用したいなら、MoRのPaddle

ここで国内法人向けサービスを選ぶ場合は、単にStripeかPaddleかを決めるのではなく、販売契約と請求書の発行主体を先に決めた方がよい。決済事業者を選んだ後で請求書の要件に気づくと、決済画面だけでなく、料金プラン、契約書、営業資料まで修正することになる。

最初から完璧な選択をしない

決済基盤は一度導入すると、簡単には交換できない。顧客の契約情報、請求履歴、Webhook、会員権限、返金処理がすべてつながるからだ。

それでも、最初から数年先の正解を当てる必要はない。重要なのは、将来の切り替えを完全に不可能にする実装を避けることだ。

自社側では、次の情報を決済事業者に依存しない形で管理しておくとよい。

• ユーザーの契約状態
• 利用中のプラン
• 課金開始日と次回更新日
• 解約予定日
• 決済事業者の識別子
• 最終的に確認できた支払い状態
• 請求書や返金の参照情報

決済事業者の顧客番号だけを会員の主キーにすると、別の事業者へ移行する際にデータ構造が足かせになる。自社のユーザーIDと契約IDを中心に置き、StripeやPaddleの番号は外部参照情報として扱う方が安全だ。

また、最初の運用期間では、売上だけでなく問い合わせ内容を記録したい。請求書が見つからない、解約方法が分からない、通貨表示が不安、返金の反映が遅いといった問い合わせは、料金表には出てこない運用コストである。

この記録は、単なるサポート履歴ではない。どの決済経路を残すべきかを判断する材料になる。国内ユーザーから請求書の要望が繰り返し届くなら、国内B2B向けの請求処理を優先すべきだ。海外ユーザーから税額表示や支払い方法について質問が集中するなら、Paddleのような販売元代行を導入する意味が大きくなる。

私の判断と、次に試したいこと

決済基盤に絶対的な正解はない。事業の段階、顧客の所在地、法人比率、平均単価、税務を扱える時間によって、最適な選択は変わる。

現時点での判断をまとめるなら、国内ユーザー中心のSaaSや個人向けツールは、Stripeから始めるのが自然だ。手数料を抑えやすく、料金や会員状態を自社の設計に合わせやすい。法人顧客がいるなら、適格請求書発行事業者の登録状況と、請求書に登録番号を表示する運用を先に固める。

海外ユーザーが多いサービスは、PaddleのMoRモデルを有力な候補として検討したい。5％＋0.50ドル台という手数料は安くないが、海外の税率、請求書、申告・納税の一部を自社から切り離せる。少人数でサービスを運用するなら、開発者の時間を守る効果は大きい。

今回の試算では、1ドル＝150円の場合、月商100万円・1,000件の決済でStripeが約66,000円、Paddleが約125,000円だった。差額は約59,000円である。この差額を高いと見るか、海外販売に伴う税務と請求処理を外部化する費用と見るかで、判断は変わる。

国内と海外が混在するなら、すべてを一つに寄せるより、地域ごとに決済経路を分ける方法もある。ただし、決済状態や返金処理を二重管理することになるため、導入前に運用フローを作っておく必要がある。

最終的には、次の三つを同じ表に入れて比較すると判断しやすい。

1. 決済手数料と為替を含む直接コスト

2. 請求書、税務、返金、問い合わせにかかる運用コスト

3. 決済障害や税務対応の遅れによって事業が止まるリスク

Stripeの方が安いという結論は、直接コストだけを見れば正しい。しかし、海外販売の税務まで自分で抱えるなら、差額はそのまま利益ではない。Paddleの手数料が高いという結論も、販売元代行に払う管理コストまで含めなければ不十分だ。

決済基盤は、料金表ではなく、販売者として引き受ける責任の範囲で選ぶ。

個人開発では、開発者がコード、営業、サポート、経理を一人で担当することも珍しくない。だからこそ、決済の選定では手数料の数値だけに引っ張られないことが重要になる。

国内B2Cで始めるならStripe。海外販売を本気で伸ばすならPaddle。両方を扱うなら、事業の成長に合わせて並走や段階的な移行を検討する。まずは小さな売上と実際の請求フローで検証し、顧客から何を求められ、どの作業に時間を取られるのかを記録する。

個人開発の決済システムは、最初から完璧に作るものではない。販売者としてどこまで責任を持つのかを決め、その判断を後から検証できる形にしておく。StripeとPaddleの比較は、そこから始まる。

Related reading: 個人開発のメール送信サービス：ResendとSESの無料枠と到達率の検証結果 and Stripe決済の二重課金を防ぐべき等性の内部挙動と実装設計.