【ITニュース解説】Stripe, Merchant of Record, or In-App Purchases? Picking a Payments Stack Without Regretting It

アプリケーション開発で、ユーザーに製品やサービスを有料で提供する際、支払いをどのように処理するかは非常に重要な決定事項だ。単に「購入ボタン」を設置するだけではなく、その裏側で誰が販売者としての法的責任を負うかによって、税金の処理、顧客からの問い合わせ、返金や紛争の解決など、運用上の大きな負担が決まる。手数料の大小も気になる要素ではあるが、最も根本的な違いは「誰がレシートに記載される販売者となるか」という点にある。この選択肢は主に三つ存在する。

一つ目は「決済プロセッサー」を利用する方法で、Stripe（ストライプ）などがその代表例だ。この場合、アプリケーションを運営するあなた自身が法的な販売者となる。決済プロセッサーは単にお金の流れを仲介するだけであり、それ以外の責任は全てあなたが負うことになる。最大のメリットは、手数料が一般的に最も低いことだ。また、チェックアウト画面のデザインや料金設定のロジックなど、支払いに関するあらゆる側面を自由に制御できる。しかしその反面、税金に関する責任は全てあなたが負う必要がある。例えば、国境を越えて商品を販売する場合、それぞれの国の消費税（VATなど）を計算し、徴収し、そして税務当局に申告・納税する作業が発生する。Stripe Taxのようなツールは税額計算を手助けしてくれるが、税務登録や実際の申告作業は自分で行わなければならない。顧客からのチャージバック（クレジットカード会社への異議申し立て）や紛争についても、あなたが直接対応し、証拠を提出する必要がある。技術的には、決済プロセッサーからの支払い完了やキャンセルなどのイベントを受け取る「ウェブフック」の処理が重要となる。これは、署名を検証して通知が本物であることを確認し、同じイベントが二度処理されないよう「冪等性（べきとうせい）」という仕組みを考慮して実装する必要がある。この方法は、ウェブベースのSaaS（Software as a Service）で、自社で経理や法務を扱うチームがあり、細かな料金設定やプロモーションを自由に展開したい場合に特に適している。

二つ目は「Merchant of Record（MoR）」、日本語では「記録上の販売者」と訳されるサービスを利用する方法だ。Paddle（パドル）やLemon Squeezy（レモンスクイージー）などがこれに該当する。この場合、MoRサービス自体があなたの製品やサービスの販売者となる。つまり、顧客のレシートにはMoRの会社名が記載され、彼らが税金の計算、徴収、そして世界中の複雑な税務当局への申告・納税を全て代行してくれる。これにより、あなたは税金に関するあらゆる頭の痛い問題から解放される。特に、EUやイギリス、インド、オーストラリアなど、複数の国に顧客を持つ場合に、個別の税務登録なしにグローバル展開できるのは非常に大きな利点だ。しかし、この便利さには代償もある。決済プロセッサーに比べて手数料は高く、一般的に5%プラス固定費用がかかる場合が多い。また、MoRが提供するチェックアウト画面やサブスクリプションモデルに沿う必要があるため、決済プロセッサーほどの自由な制御はできない。売上の入金も隔週や月次となることが一般的で、毎日入金される決済プロセッサーに比べて遅い傾向がある。ウェブフックの処理自体は決済プロセッサーの場合と似ており、どの支払いプロバイダーからイベントが来たとしても、アプリケーションのエンタイトルメント（ユーザーが利用できる権利）を適切に更新できるような設計が求められる。この方法は、経理や法務に詳しいスタッフがいない個人開発者や小規模チームが、グローバルに製品やサービスを提供したい場合に最適だ。

三つ目は「アプリストア課金」を利用する方法だ。AppleのApp Store（App内課金）やGoogle Playストア（Google Play課金）がこれに該当する。あなたがネイティブモバイルアプリを開発し、そのアプリ内でデジタルコンテンツやサービスを販売する場合、この選択はほとんど避けて通れない制約となる。この場合、プラットフォーム（AppleやGoogle）が法的な販売者となる。これにより、税金の処理やチャージバックなどの問題はプラットフォーム側が引き受けてくれる。しかし、手数料は最も高く、売上の15%から30%がプラットフォームに支払われる。さらに、AppleとGoogleでは異なるレシート形式やサーバー通知システムがあり、これらを個別に管理するのは非常に複雑だ。RevenueCat（レベニューキャット）のようなサービスは、これら二つのプラットフォームからの通知を統合し、処理を簡素化する手助けをしてくれる。サブスクリプションの管理、キャンセル、返金も全てアプリストア側で行われ、あなたはそれらのイベントに反応して、ユーザーの利用権限を更新する必要がある。特に、iPhoneで購読したユーザーがウェブ版でもアクセスできるといった「クロスプラットフォーム」での利用を可能にするには、工夫が必要となる。この方法は、ネイティブモバイルアプリでデジタル機能を提供する場合に必須の選択肢であり、他の支払い方法と併用して、ウェブ上でのより安価な購入経路も同時に提供することを計画するのが賢明だ。

どの支払い方法を選択しても、最終的にアプリケーション側で共通して構築する必要があるのが「エンタイトルメントレイヤー」だ。これは、ユーザーが現在どのプランに加入しており、どの機能にアクセスできるか、という利用権限を一元的に管理する仕組みを指す。具体的には、データベースに「ユーザーID」「プラン名」「支払い元（Stripe、Paddle、App Storeなど）」「有効期限」といった情報を保存するテーブルを作成する。そして、ウェブフックを通じて、支払い完了時には利用権限を付与し、サブスクリプションのキャンセル時には権限を失効させる、という処理を記述する。重要なのは、一人のユーザーがStripe経由とApp Store経由で同時にサブスクリプションを持っているようなケースも考慮し、「ユーザーID」と「支払い元」の組み合わせをユニークなキーとして利用することだ。これにより、「iPhoneで購読したユーザーがウェブサイトでもプロ機能を利用できる」といった、クロスプラットフォームでのスムーズな体験を実現できる。複数の支払いチャネルを導入する前に、このエンタイトルメントレイヤーを最初に設計し構築しておくことが、将来的な開発の複雑さを大幅に軽減する鍵となる。

最終的な支払い方法の選択は、手数料の多寡だけで決めるべきではない。目に見える手数料よりも、目に見えない運用コストの方がはるかに大きくなる場合が多いためだ。最も重要なのは、あなたのアプリケーションがどこで提供されるか、顧客はどこにいるか、そして、経理や法務に関する複雑な問題を誰に任せたいか、という点だ。例えば、ネイティブモバイルアプリならアプリストア課金は必須となるが、ウェブからの購入経路も用意し、そこで手数料の安い支払い方法を提供するのが良いだろう。複数の税管轄区域に顧客がいる小規模なチームであれば、MoRを選ぶことで税務処理の負担から解放される。逆に、ウェブSaaSで請求処理を管理する専門チームがあり、カスタムな料金設定をしたい場合は、決済プロセッサーが適している。Stripeを選んだものの、数ヶ月後に複雑な税金申告に追われることになったり、アプリストア課金を先に導入してしまい、もっと安価なウェブ決済の可能性を見逃したり、といったよくある間違いを避けるためにも、誰が法的な販売者となるか、という根本的な問いから最適な選択を導き出すことが重要だ。