Bubble × Stripe Connect で作る！予約決済プラットフォームの作り方【第3回】Destination Charges と手数料計算

Bubble × Stripe Connect で作る！予約決済プラットフォームの作り方

第3回：予約決済の実装 – Destination Charges と手数料計算

前回のおさらい

第2回では、Stripe Connect の設計を解説しました。

Express アカウントの特徴
オンボーディング（店舗登録）の流れ
stripe_account_id の保存

今回は、いよいよ 予約決済の実装 です。

Destination Charges とは

Stripe Connect には、お金の流れを制御する方法が複数あります。

方式	お金の流れ	用途
Direct Charges	ユーザー → 店舗	店舗が主体
Destination Charges	ユーザー → プラットフォーム → 店舗	プラットフォームが主体
Separate Charges	分割して処理	複雑なケース

今回は Destination Charges を使います。

なぜ Destination Charges か

ユーザーが3,000円を決済
    │
    ↓
プラットフォームが受け取る
    │
    ├─→ 手数料150円を差し引く
    │
    └─→ 店舗に2,850円を送金

メリット:

プラットフォームが決済の主体になる
手数料を柔軟に設定できる
返金もプラットフォームから操作可能

application_fee_amount

application_fee_amount は、プラットフォームが受け取る手数料です。

計算例

ユーザーが 3,000円 を決済する場合：

決済金額: 3,000円
Stripe手数料（3.6%）: 108円
application_fee_amount: 150円（5%）

店舗の受取額: 3,000 - 108 - 150 = 2,742円

…あれ？計算が合わない？

重要：手数料の取られ方

実は、Stripe手数料は 店舗の受取額から 引かれます。

決済金額: 3,000円

プラットフォームの取り分: 150円（application_fee_amount）
    └─→ ここからStripe手数料は引かれない

店舗への送金: 2,850円
    └─→ ここからStripe手数料 108円が引かれる
    └─→ 店舗の実際の受取額: 2,742円

店舗に「手数料5%」と伝えている場合、実質的には 5% + Stripe手数料が引かれることになります。

店舗への説明

正直に伝える場合：

「プラットフォーム手数料5% + Stripe決済手数料3.6%がかかります」

シンプルに伝える場合：

「売上の約8.6%が手数料として差し引かれます」

どちらが良いかはビジネス判断ですが、事前に明示することが重要です。

Bubble での実装

Stripe Checkout Session の作成

Bubble の API Connector で Stripe API を呼び出します。

API設定:

Method: POST
URL: https://api.stripe.com/v1/checkout/sessions
Headers:
  Authorization: Bearer sk_test_xxx
  Content-Type: application/x-www-form-urlencoded

Body パラメータ:

パラメータ	値	説明
mode	payment	一回払い
success_url	https://xxx/success	成功時のリダイレクト先
cancel_url	https://xxx/cancel	キャンセル時のリダイレクト先
line_items[0][price_data][currency]	jpy	通貨
line_items[0][price_data][unit_amount]	{{金額}}	決済金額（円）
line_items[0][price_data][product_data][name]	{{商品名}}	表示名
line_items[0][quantity]	1	数量
payment_intent_data[application_fee_amount]	{{手数料}}	プラットフォーム手数料
payment_intent_data[transfer_data][destination]	{{acct_xxx}}	送金先の店舗アカウント

手数料の計算

Bubble のワークフローで：

決済金額 = メニュー料金 × 卓数 × 時間
手数料 = 決済金額 × 0.05（5%）

注意：手数料は整数で渡す

Stripe API は小数を受け付けません。

150.5 → ❌ エラー

150 → ✓ OK

Bubble では rounded down で切り捨てます。

Bubble ワークフロー例

[決済ボタンをクリック]
    │
    ↓
[計算]
決済金額 = Parent group's メニュー's 料金 * Dropdown 卓数's value * Dropdown 時間's value
    │
    ↓
[計算]
手数料 = 決済金額 * 0.05 :rounded down
    │
    ↓
[API Call: Create Checkout Session]
・unit_amount = 決済金額
・application_fee_amount = 手数料
・destination = 店舗's stripe_account_id
    │
    ↓
[Open external website]
Result of step's url

決済画面の表示

Checkout Session を作成すると、URLが返ってきます。

{
  "id": "cs_test_xxx",
  "url": "https://checkout.stripe.com/c/pay/cs_test_xxx..."
}

このURLに遷移すると、Stripe の決済画面が表示されます。

ユーザー体験:

1. 予約内容を確認

2. 「決済する」ボタンをクリック

3. Stripe の決済画面に遷移

4. カード情報を入力

5. 決済完了 → 成功ページに戻る

metadata の活用

決済と予約データを紐付けるために、metadata を使います。

Checkout Session 作成時:

metadata[reservation_id]={{予約のユニークID}}
metadata[user_id]={{ユーザーID}}
metadata[store_id]={{店舗ID}}

Webhook で受け取る時:

{
  "metadata": {
    "reservation_id": "xxx",
    "user_id": "xxx",
    "store_id": "xxx"
  }
}

これで、どの予約に対する決済かを特定できます。

テスト方法

テスト用カード番号

カード番号	結果
4242 4242 4242 4242	成功
4000 0000 0000 0002	拒否
4000 0000 0000 3220	3Dセキュア

有効期限: 未来の日付（例: 12/30）

CVC: 任意の3桁（例: 123）

確認すべきポイント

1. 決済が成功するか

2. 金額が正しいか（Stripe ダッシュボードで確認）

3. application_fee_amount が正しいか

4. 店舗への送金額が正しいか

Stripe ダッシュボード → 支払い → 該当の決済をクリック

支払い金額: ¥3,000
プラットフォーム手数料: ¥150
送金先: acct_xxx
送金額: ¥2,850

よくあるエラー

1. Invalid integer

Error: Invalid integer: 150.5

手数料が小数になっている。:rounded down で整数にする。

2. No such account

Error: No such account: acct_xxx

店舗の stripe_account_id が間違っている、または存在しない。

3. Transfers not allowed

Error: Your destination account needs to have at least one of the following capabilities enabled: transfers

店舗のオンボーディングが完了していない。

charges_enabled と payouts_enabled を確認。

次回予告

第4回では、クーポンの罠 を解説します。

Stripe プロモーションコードが使えない問題
Destination Charges の制約
Bubble 側での回避策

お楽しみに！

このシリーズの目次

回	タイトル	内容
1	イントロ	プラットフォーム決済の設計
2	Stripe Connect設計	Express アカウント、オンボーディング
3	予約決済の実装	← 今ここ
4	クーポンの罠	プロモコードが使えない問題と回避策
5	サブスク課金	有料掲載・広告プランの実装
6	Webhook設計	決済完了の検知、ステータス更新
7	本番デプロイ	テスト→本番の切り替え、審査対策

いいね・フォローしていただけると励みになります！

実装のご相談

予約システム・サブスク決済の導入でお困りの方へ。

・Stripe / Stripe Connect の設計・実装

・Bubble / Make.com でのノーコード開発

・テスト環境→本番デプロイまで一貫対応

初期設定から運用まで、初心者の方にも丁寧にサポートします。

👉 ココナラで相談する

Bubble × Stripe Connect で作る！予約決済プラットフォームの作り方【第3回】Destination Charges と手数料計算