Bubble × Stripe Connect で作る！予約決済プラットフォームの作り方【第7回】本番デプロイと審査対策
Bubble × Stripe Connect で作る！予約決済プラットフォームの作り方
第7回：本番デプロイ – テストから本番への切り替えと審査対策
前回のおさらい
第6回では、Webhook設計を解説しました。
- 決済完了の検知方法
- Bubble での Backend Workflow
- 署名検証と冪等性
今回は最終回、本番デプロイ について解説します。
本番移行の全体像
[テスト環境]
Bubble: Development
Stripe: テストモード（sk_test_xxx）
│
↓
[本番移行作業]
1. Stripe 本番アカウントの準備
2. Bubble での切り替え
3. Webhook の再設定
4. 店舗の再オンボーディング
│
↓
[本番環境]
Bubble: Live
Stripe: 本番モード（sk_live_xxx）Stripe 本番アカウントの準備
1. ビジネス情報の入力
Stripe ダッシュボード → 設定 → ビジネス設定
必要な情報:
- 事業者名（法人名または個人名）
- 住所
- 電話番号
- 業種
- 事業内容の説明
2. 銀行口座の登録
売上を受け取る銀行口座を登録。
3. 本人確認
法人: 登記簿謄本など
個人: 運転免許証、マイナンバーカードなど
4. 審査完了を待つ
通常1〜3営業日で完了。
「対応が必要」ステータスが消えれば OK。
よくある審査の問題
「対応が必要」が消えない
原因と対策:
| 原因 | 対策 |
|---|---|
| ビジネス情報が不完全 | すべての項目を埋める |
| サイトにポリシーがない | プライバシーポリシー、返金ポリシーを設置 |
| サイトが公開されていない | 最低限のランディングページを公開 |
| 連絡先が不明確 | 問い合わせ先を明記 |
必須のポリシーページ
Stripe 審査を通過するために、以下のページが必要:
1. プライバシーポリシー
– 取得する個人情報
– 利用目的
– 第三者提供の有無
2. 返金・キャンセルポリシー
– キャンセル条件
– 返金の条件と方法
– 連絡先
3. 特定商取引法に基づく表記（日本の場合）
– 販売業者名
– 所在地
– 連絡先
Bubble での切り替え
1. 本番用 API キーの設定
Bubble の Plugins → Stripe プラグイン（または API Connector）
テスト環境用:
Development:
Secret Key: sk_test_xxx
Publishable Key: pk_test_xxx本番環境用:
Live:
Secret Key: sk_live_xxx
Publishable Key: pk_live_xxxBubble は Development と Live で別々のキーを設定できます。
2. Webhook URL の更新
テスト環境:
https://あなたのアプリ.bubbleapps.io/version-test/api/1.1/wf/stripe_webhook本番環境:
https://あなたのアプリ.bubbleapps.io/api/1.1/wf/stripe_webhook重要: Stripe ダッシュボードで本番用の Webhook を新規作成
テストモードと本番モードで別々の Webhook になります。
3. Deploy to Live
Bubble の Deployment → Deploy to Live
これでテスト環境の内容が本番環境に反映されます。
店舗の再オンボーディング
テスト環境の Connected Account は使えない
テストモードで作成した店舗アカウント（acct_xxx）は、本番モードでは使えません。
対応:
- 本番移行後、店舗に再度オンボーディングしてもらう
- 店舗の stripe_account_id を本番用に更新
店舗への連絡
本番環境への移行が完了しました。
お手数ですが、売上受取設定を再度行っていただく必要があります。
[売上受取設定はこちら]（本番環境のURL）本番テスト
実際の決済をテスト
本番移行後、実際のクレジットカードで少額のテスト決済を行います。
1. 予約を作成（最小金額で）
2. 実際のカードで決済
3. Stripe ダッシュボードで確認
4. 返金処理をテスト確認項目
| 項目 | 確認方法 |
|---|---|
| 決済が成功するか | Stripe ダッシュボード |
| Webhook が届くか | Backend Workflow のログ |
| 店舗への送金 | Stripe Connect → 店舗アカウント |
| 手数料の計算 | application_fee_amount |
本番運用のチェックリスト
デプロイ前
- [ ] Stripe 本番アカウントの審査完了
- [ ] プライバシーポリシーを設置
- [ ] 返金ポリシーを設置
- [ ] 特商法表記を設置
- [ ] 本番用 API キーを設定
- [ ] 本番用 Webhook を設定
- [ ] success_url / cancel_url を本番URLに
デプロイ後
- [ ] 実カードでテスト決済
- [ ] Webhook の受信確認
- [ ] 返金処理のテスト
- [ ] 店舗への案内（再オンボーディング）
トラブルシューティング
決済が失敗する
1. API キーが本番用になっているか確認
2. Stripe ダッシュボードでエラー内容を確認
3. カードの問題（限度額、3Dセキュアなど）
Webhook が届かない
1. エンドポイントURLが本番用か確認
2. Stripe ダッシュボード → Webhook → イベント でステータス確認
3. 再送してテスト
店舗への送金ができない
1. 店舗のオンボーディングが完了しているか
2. charges_enabled = true か
3. stripe_account_id が本番用か
運用開始後の監視
Stripe ダッシュボードで見るべき場所
1. 支払い: 決済一覧、成功/失敗の確認
2. Connect → アカウント: 店舗の状態
3. 開発者 → Webhook: イベントの成功/失敗
4. 開発者 → ログ: API リクエストの詳細
アラート設定
Stripe ダッシュボード → 設定 → 通知
- 決済失敗時のメール通知
- 不正検知時の通知
- 店舗のアカウント問題
シリーズのまとめ
全7回にわたって、Bubble × Stripe Connect での予約決済プラットフォーム構築を解説しました。
| 回 | 内容 |
|---|---|
| 1 | プラットフォーム決済の設計思想 |
| 2 | Express アカウントとオンボーディング |
| 3 | Destination Charges で予約決済 |
| 4 | プロモコードの制約と回避策 |
| 5 | サブスク課金（有料掲載・広告） |
| 6 | Webhook での決済完了検知 |
| 7 | 本番デプロイと審査対策 |
学んだこと
1. Stripe Connect の仕組み
– お金の流れを制御する方法
– 手数料の取り方
2. ノーコードでも高度な決済が可能
– Bubble の API Connector で Stripe API を叩く
– Backend Workflow で Webhook を処理
3. 公式ドキュメントに書いてないこと
– Destination Charges ではプロモコードが使えない
– テスト環境の Connected Account は本番で使えない
4. 実運用に必要なこと
– ポリシーページの設置
– Stripe 審査の通過
– 店舗への丁寧な案内
おわりに
プラットフォーム決済は複雑ですが、一度設計すれば自動で回り続けます。
- 予約が入る → 自動で決済
- 売上が発生 → 自動で店舗に分配
- 月次更新 → 自動で課金
手動の銀行振込や Excel 管理から解放されます。
このシリーズが、あなたのサービス構築の一助になれば幸いです。
シリーズを読んでいただき、ありがとうございました！
実装のご相談
予約システム・サブスク決済の導入でお困りの方へ。
・Stripe / Stripe Connect の設計・実装
・Bubble / Make.com でのノーコード開発
・テスト環境→本番デプロイまで一貫対応
初期設定から運用まで、初心者の方にも丁寧にサポートします。