予約や物販のアプリで Stripe を使ってよいか — Apple の線引きは「どこで消費されるか」です

Rork に「商品を並べて、カートから Stripe で決済できるアプリを」と頼むと、決済画面まで一気に組み上がってきます。動いているのを見ると、そのまま出せそうな気がしてきます。

ところが App Store に出す段階になって、手が止まる方が多いと思います。アプリ内で何かを売るなら、アプリ内課金（IAP）を使わなければならないのではなかったか——と。

先にお伝えしておきます。私自身のアプリは広告とアプリ内課金が中心で、物販や予約の決済を審査に出した経験はありません。ですからこの記事は審査の体験談ではなく、Apple の App Review Guidelines と Google Play の決済ポリシーを読み、売るもの別に線を引き直した個人開発者の整理メモです。

結論から書きます。Stripe かアプリ内課金かは、手数料や好みで選ぶものではなく、「買ったものがアプリの外で消費されるか、アプリの中で消費されるか」で決まります。 私はそう読んでおります。

最初の分かれ目は「アプリの外で使うかどうか」です

Guideline 3.1.1 は、機能の解放・サブスクリプション・ゲーム内通貨・プレミアムコンテンツのような「アプリの中で価値が完結するもの」を売るなら、アプリ内課金を使うことを求めています。

一方で 3.1.3(e) は、物理的な商品や、アプリの外で受けるサービスを買う場合は、アプリ内課金以外の方法で決済を集めることを求めています。「使ってもよい」ではなく「使わない方法で集める」という書きぶりです。Apple Pay やクレジットカード入力が例に挙がっています。

つまり物理的な商品に IAP を使うのは、守るべき向きと逆になります。ここは意外に感じる方が多い部分です。

売るもの別の判定表

手元で迷いやすい組み合わせを、8 つに並べました。

表の最後の行が、判定でいちばん揉めやすい場所です。「物販アプリだから外部決済でよい」と一括りにせず、1 品目ずつ「それは誰の手元で、どこで消費されるか」を確認する作業になります。

手数料で決めてはいけない理由

Apple のアプリ内課金の手数料は原則 30% で、小規模事業者向けのプログラムなら 15% です。Stripe を使えばその分を抑えられるように見えます。

そこで、デジタルコンテンツを Stripe に流したくなる気持ちは、個人開発の立場ではよく分かります。ただ、それは 3.1.1 に正面から当たる構成です。審査で止まるだけでなく、公開後に気づかれて更新を止められると、アプリ全体の収益が止まります。

正直なところ、30% という数字を見て揺れない開発者は少ないのかもしれません。線の引き方を逆から見ると、気持ちが整理しやすくなります。IAP の手数料を払うのは、「アプリの中でしか成立しない価値」を売る対価です。物販や来店予約はその価値の外側にあるので、そもそも IAP の土俵ではないのです。

なお日本向けには、2025 年 12 月の法施行にあわせて外部決済の扱いが広がる動きがあります。国や時期で条件と手数料が変わりうるため、ここでは日本のストアで従来どおり審査を受ける前提で書いています。公開直前に、必ず原文で確認してください。

手元で線を引くための小さな関数

迷う品目が増えると、頭の中だけでは判定が揺れます。私は新しい販売品目を足すたびに、次の関数に通して結果を残す方法を勧めたいと思います。判定そのものは Apple の解釈の写しではなく、「どの品目をどちらに寄せたか」を記録する台帳として使うものです。

// lib/paymentRoute.ts
export type SaleKind =
  | "physical-good"
  | "in-person-service"
  | "live-one-to-one"
  | "live-group"
  | "digital-content"
  | "digital-feature"
  | "subscription-access"
  | "credit-for-later";
 
export type PaymentRoute =
  | "external"            // Stripe など。物理的な商品・アプリ外で受けるサービス
  | "external-with-note"  // 外部決済だが、審査メモで 1 対 1 であることを説明する
  | "iap"                 // アプリ内課金
  | "review-note";        // 解釈が分かれる。メモを書き、IAP も併せて用意する
 
export function paymentRoute(kind: SaleKind): PaymentRoute {
  switch (kind) {
    case "physical-good":
    case "in-person-service":
      return "external";
    case "live-one-to-one":
      return "external-with-note";
    case "credit-for-later":
      return "review-note";
    default:
      return "iap";
  }
}

default に、live-group から subscription-access までのデジタル系をまとめて落としています。「迷ったら IAP 側」という向きを、コードの形で固定しているわけです。物理的な商品だけを明示的に外へ出す書き方にすると、新しい品目を足し忘れたときも、外部決済に流れてしまう事故を避けられます。

審査メモに書く 3 行

外部決済を使う品目があるなら、審査メモに次の 3 行を残しておくと、レビュアーが迷う時間を減らせます。

1. 何を売っているか（例: 店舗で提供するヘアカットの予約と支払い）
2. どこで消費されるか（例: 予約した店舗の店内。アプリ内では何も解放されません）
3. アプリ内のデジタル機能は別の課金か（例: 広告非表示は IAP で提供しています）

3 行目が意外に効きます。物販アプリの中に「会員限定ページ」や「広告を消す」といったデジタル機能が混ざっているなら、そこだけは IAP に分けているとはっきり書いておく。混在しているアプリは、この説明が無いと一括で外部決済と見られがちです。

Android 側の見え方

Google Play にも同じ向きの決済ポリシーがあります。アプリ内のデジタルアイテムには Google Play の課金システムを使い、物理的な商品やアプリ外で提供するサービスは対象外、という整理です。

iOS と Android の線は完全には重なりません。Apple では 1 対多のライブ授業が IAP 側に入る点など、細部の読み方が違います。両ストアに出すなら、品目ごとに表を 2 列にして、それぞれの判定を残しておくと、あとで見直すときに助かります。

次の一手

まず、今のアプリが売っている（または売る予定の）品目を書き出してください。次に、上の関数か表で 1 品目ずつ「外」か「中」かを決めます。最後に、外部決済を使う品目だけ、審査メモの 3 行を書きます。

審査で聞かれる観点は、別の記事Rork アプリの App Store 審査実践ガイド — リジェクトを防ぐ実践チェックリストにまとめられています。IAP 側でサブスクの権利をどう持つかは、StoreKit 2 のサブスクをサーバー側で検証する — 端末を信じない権利付与の設計が参考になります。Stripe を Web 側で使う場合の構成は、Rork + Stripe で Web SaaS の決済基盤を構築する：Next.js × Cloudflare Workers × Supabaseで扱っています。

ガイドラインの条文は更新されることがあります。実際に提出する前に、必ず Apple の原文をご自身の目で読み直していただければと思います。