DEMO | 「ManaV(マナヴィー)」決済まわり(Stripe Connect)の実装イメージ ・ はちあ様の募集要項をもとに作成
決済のしくみ

お金は、こう流れます。

ManaV は Stripe Connect を使った「マーケットプレイス型」の決済です。生徒がレッスン料金を支払うと、料金の80%が講師へ、残り20%から決済関連費用を引いた額が ManaV の収益になります。下のスライダーで金額を動かすと、内訳がリアルタイムで変わります。

資金フロー・シミュレーター

詳細な前提(Stripe手数料など)

※ 日本の Stripe 標準価格(カード3.6%)をもとにした初期値です。Connectの月額・入金手数料・国際カードの追加料率などは契約条件により変わるため、実装時に確定します。

生徒 レッスンを予約 支払い ¥3,500 ManaV 残高 Stripe プラットフォーム アカウント 80% を送金 ¥2,800 講師の Connect アカウント → Stripe payout で銀行口座へ 20% が手数料 ¥700 ManaV の取り分 − Stripe手数料 ¥126 純利益 ¥574
講師 80%
ManaV

緑=講師の取り分 / 赤=Stripe決済手数料 / 紫=ManaVの純利益

この決済の内訳

生徒のお支払い¥3,500
講師へ送金¥2,800
ManaV 手数料¥700
└ Stripe 決済手数料−¥126
└ ManaV 純利益¥574
純利益率(対 レッスン料金)16.4%

💡 気づき

この料金なら、ManaV の20%手数料でも Stripe 決済手数料を引いて十分な利益が残ります。

カード手数料が定率なので純利益率はほぼ一定ですが、低単価ほど1回あたりの利益額が小さく、返金・サポート対応1件で吹き飛びます。最低料金手数料の下限(例:最低¥300)、返金時に戻らない決済手数料の扱いは、早めに決めておくと安全です。

「20%」で本当に足りる? 単価別シミュレーション

上のスライダーの前提(還元率・手数料率)を使って、料金別の採算を一覧にしました。1回あたりの利益が薄い行は注意で表示します。

レッスン料金講師へ(80%Stripe決済手数料ManaV 純利益純利益率判定

※ Connectの月額固定費・入金手数料・返金時に戻らない決済手数料などは、この表には含めていません。実運用の採算はそれらも含めて設計します。

実装の設計

「どのChargeの型を使うか」から決めます

Stripe Connect には資金の流し方が3通りあります。ManaV の「レッスン完了後に80%を送る」という要件では、Separate charges and transfers(決済と送金を分ける方式)が最も素直です。

方式資金の流れ送金タイミングManaV での向き
Direct charges講師アカウントで直接決済し、手数料を ManaV が受け取る即時不向き 返金や紛争の窓口が講師側になり、初心者運営には重い
Destination chargesManaV で決済し、transfer_data で講師へ自動分配決済と同時条件付き シンプルだが「完了後に送金」を挟みにくい
Separate charges & transfersManaV で決済 → 後から transfers.create で講師へ送金任意(レッスン完了後)推奨 返金期限の経過を待ってから送金でき、キャンセル処理が安全

① 予約時:決済だけ行う

// サーバ側。金額はDBの講師設定から取得(クライアントを信用しない)
const lesson = await db.getLesson(lessonId);
const pi = await stripe.paymentIntents.create({
  amount: lesson.priceJpy,          // 例: 3500
  currency: 'jpy',
  transfer_group: `lesson_${lessonId}`,
  metadata: { lessonId, teacherId: lesson.teacherId },
}, { idempotencyKey: `pi_${lessonId}` });

② レッスン完了+返金期限経過後:送金する

// Cron もしくは「レッスン完了」Webフックから
const teacherCut = Math.round(lesson.priceJpy * 0.8);
await stripe.transfers.create({
  amount: teacherCut,               // 例: 2800
  currency: 'jpy',
  destination: teacher.stripeAccountId,
  transfer_group: `lesson_${lessonId}`,
  metadata: { lessonId },
}, { idempotencyKey: `tr_${lessonId}` });

監視すべき Webhook

  • checkout.session.completed / payment_intent.succeeded … 予約を確定
  • charge.refunded … キャンセル返金の反映
  • account.updated … 講師の charges_enabled / payouts_enabled を追跡
  • transfer.created / payout.paid … 講師への支払い状況
  • charge.dispute.created … チャージバック対応

決済まわりの安全設計チェック

  • Webhook は必ず署名検証STRIPE_WEBHOOK_SECRET
  • すべての作成系APIに冪等キー(再送で二重決済・二重送金を防ぐ)
  • 金額・講師IDはサーバ側でDBから確定。リクエストボディを信用しない
  • Supabase の RLS を有効化。service_role キーはサーバのみ
  • 送金は「レッスン完了 & 返金不可時刻の経過」を両方満たしてから

資金の流れとタイミング

⚠️ 法務・コンプライアンスについて

マーケットプレイス型で「生徒のお金をいったん預かって講師へ渡す」構造は、収納代行/資金移動業の該当性特定商取引法の表記講師との業務委託関係の明確化利用規約・返金規定などの検討が必要です。これらは弁護士・税理士など専門家への確認をおすすめします(実装側では、決まった方針に沿って安全に作る部分を担当します)。

まずは、最初の1件を安全に。

講師1名 → 生徒1名が予約・決済 → ManaV内でレッスン → 講師へ80%。この1本の流れを、確実に成立させるところから始めます。

開発の進め方を見る