決済端末ビジネスを、決済会社だけのものにしない/stripe_terminal_business

決済端末ビジネスを、決済会社だけのものにしない：
Stripe Terminalで始める店舗インフラ事業
https://connect2026.jpstripes.com/sessions/track-b-1650/

1. Stripe Connect 2026 決済端末ビジネスを、 決済会社だけのものにしない Stripe Terminalで始める店舗インフラ事業 榊原昌彦 一般社団法人リレーションデザイン研究所
2. 自己紹介 0 / INTRO OSS × 自社プロダクト × 事業伴走 榊原 昌彦 一般社団法人リレーションデザイン研究所 代表理事 OSS capacitor-community/stripe メンテナ BUILD 自社でB2C・B2Bアプリを開発・提供 OSS maintainer Ionic Developer Expert ADVISE 都内複数社の CTO・技術顧問 Stripe Community Expert 技術と事業、両方の現場から話します 02
3. つくる → 提供する → 学ぶ → 次へ 0 / INTRO プロダクトから得た知見を、 OSSと事業伴走へ循環させる B2C tipsys B2B 食品表示印刷 B2B winecode みたいなお仕事をしています。 03
4. 市場の空白 配られた決済端末が、 突然止まった。 しかも、決済済みの売上金が入金されない。
5. 全東信とは 1 / MARKET ORIGIN ROLE 歓楽街の相互扶助 決済の駆け込み寺 1987年、大阪の飲食事業協同組 合から始まった 一般の審査に通りにくい店舗にも 決済を提供 店舗同士のつながりから全国へ 端末だけでなく、営業網を持った 端末より先に、業界との関係があった 05
6. なぜ全東信は重用されたのか 1 / MARKET 高機能な端末より、店舗が必要としていたもの 01 02 03 加盟店審査 早い入金 店舗との関係 開業直後・夜間業態 カード加盟店になりにくい 月6回払いなど 資金回収が早い 歓楽街の口コミと 店舗同士のつながり 価値は、業界固有の摩擦を引き受けたこと 06
7. 早期入金には、対価があった。 VALUE 1 / MARKET PRICE 代替しにくい価値 早期入金の対価 審査に通りにくい店舗も支え、 月6回で入金する 手数料を負担しても、 早い入金には価値があった 店舗の資金繰りを支えた 資金繰りの選択肢になった 審査対応と早期入金が、代替しにくい価値だった 07
8. 決済は、飲食店の生命線 1 / MARKET 飲食店のキャッシュフローを考える 01 02 03 仕入れ 人件費 固定費 営業前に食材や酒を 現金で確保する 一定日にまとまった 支払いが発生する 家賃・光熱費は 売上に関係なく発生 入金サイクルの短さが、店舗の生存を左右する 08
9. 月6回払いが意味したこと 売上発生 仕入れ 1 / MARKET 給与 入金 次の営業 月6回 早期支払い 決済サービスが、資金繰りまで支えていた 09
10. 端末停止は、店舗インフラの再選択を迫った 1 / MARKET 全東信の破産で起きたこと 問い 01 02 03 決済端末が利用できない 決済済み売上金が入金されない 店舗側には切り替えの時間がない 店舗の決済を 誰が支えるのか？ 店舗の継続を支える、 新しい担い手が求められている。 店舗インフラを、選び直す 10
11. 端末は「配られて使うもの」だった 1 申し込む 申込書 1 / MARKET 2 → 審査を待つ ブラックボックス 3 → 端末が届く 4 → 完成品 指示どおり使う 変更できない カスタマイズするものではない 決済体験も、売上データの使い方も、提供者が決めていた 11
12. いま、2つの意味で世界が開いた MARKET 1 / MARKET TECHNOLOGY 市場の空白 技術の解放 既存の担い手が揺らぎ、 店舗が次のインフラを選び直す 決済を自社サービスへ組み込み、 端末上の体験まで作れる 誰が支えるかが開いた 何を作るかが開いた この交点が、新規事業のタイミング 12
13. 以前も作れた。だが、続けるのが難しかった 2 / BUILD 高額な開発費より、深刻だったもの 01 02 03 組み込み人材 認証・決済 端末運用 超専門の文脈。見つけにくい Web人材より希少 安全性と規格へ 継続対応 故障・交換・更新を 年単位で支える “作れる”と“事業として続く ”の間に、大きな壁があった 13
14. Stripe Terminalとは 2 / BUILD STRIPE TERMINAL 対面決済を、 自社アプリへ組み込む 認定済みリーダー SDK / API オンライン決済と同じ基盤で、 店舗の決済を扱う 端末を配る製品ではなく、対面決済を組み込むための基盤 14
15. 開発方法は一つではない 2 / BUILD Androidネイティブ Web技術 Java / Kotlin Android SDKで構築 端末機能へ直接アクセス HTML / CSS / JavaScript CapacitorでAndroid化 既存Webチームを活用 公式SDK OR コミュニティ実装 ※ 「端末の配布相当」に限定した話をしています。 Web、iOS・Androidデバイスから端末に決済を指示するやり方もあります 15
16. 決済の難所は Stripeへ。体験づくりは自社へ。 2 / BUILD Stripeが担う 私たちが担う ✓ PCI準拠認定済みハード ✓ 対面決済の処理 ✓ SDK / API ✓ オンライン決済との統合 ✓ 業界固有の業務 ✓ 店舗・顧客の UX ✓ 予約・会員・在庫 ✓ 新しい収益モデル 決済基盤 + 差別化 16
17. 端末アプリが、 Web技術者の射程に入った 2 / BUILD HTML CSS Stripe Terminal Capacitor → Web → Android → 決済 + 端末上のアプリ JavaScript / TS 店舗の接点 既存のWebチーム 希少な組み込み人材だけに依存しない 17
18. Webチームで試せると、何が変わるか 2 / BUILD 安いことより、試行回数が増えること 01 02 03 プロトタイプ フィールド 改善 数日で画面を作り 仮説を形にする 実店舗で顧客と スタッフに試す 反応を見ながら すぐに改善する 店舗UXを、ソフトウェアの速度で改善できる 18
19. 次に設計するもの 自分たちで作れる。 では、端末で何を作るのか？ 決済画面ではなく、 顧客体験を設計する
20. 顧客体験とは 3 / EXPERIENCE iPhoneを“使う瞬間 ”だけが体験では ない 届く前 待つ時間がわくわくする 開ける 箱を開ける行為が気持ちいい 使い続ける 手放す 同期やエコシステムが当たり前になる リセールバリューまでうれしい UX = 製品との接点を通じた、時間をまたぐ累積的な体験 20
21. 飲食店の体験：これまで 1 予約 名前と時間 3 / EXPERIENCE 2 → 3 来店 予約票を確認 → 会計 POSへ金額を入力 4 → 退店 関係が一度切れる 各接点が分断されている 顧客は一人でも、システム上では別々の人 21
22. 飲食店の体験：これから 3 / EXPERIENCE 予約前 来店 ① 好み・来店目的 店内 ② → 決済後 ③ 予約IDで認識 → ∞ 注文と体験 → 会員・次回提案 顧客を中心に、体験とデータがつながる 決済は関係を閉じるのではなく、次へ渡す 22
23. 同じ4,800円でも、体験は違う 3 / EXPERIENCE これまで ✓ 金額を入力 ✓ カードをかざす ✓ 売上を記録 ✓ そこで終了 決済処理 これから V S ✓ 顧客を認識 ✓ 会員・好みと接続 ✓ 特典や次回来店へ ✓ 関係を蓄積 顧客体験 23
24. 店舗の体験も、来店前から蓄積まで続く 来店前 3 / EXPERIENCE 店内 ① 退店後 ② 発見・予約 本人確認等 → 蓄積 ③ 案内・注文 決済 → 領収書やリコメ ンド・手紙 ∞ → 会員・嗜好 再来店 決済は終点ではなく、体験をつなぐ識別点 “支払った人”を、その前後の行動や関係へ接続できる 24
25. 従来POSが見ているのは「点」 来店前 店内 3 / EXPERIENCE 決済 退店後 再来店 ¥ 4,800 決済・売上データ 誰が、なぜ来て、その後どうなったかは切れている 25
26. DEMO IDEA 10秒チャレンジ START 10.00 止める → 結果を見る → 支 払う 決済端末そのものが ゲームの舞台になる 支払いを “作業”から“記憶に残る体験 ”へ
27. 特別な魔法ではない。普通の Webアプリ。 3 / EXPERIENCE だから <button id="start">START</button> Webの開発チーム が 店舗体験を試作で きる .timer { font-size: 92px; color: #65D6C0; } startButton.addEventListener(...) 小さく試す → 現場で学ぶ → すぐ改善する 参入障壁が下がった最大の意味は、試行回数を増やせること 27
28. OSSで、技術的な入口を開く 3 / EXPERIENCE capacitor-community/stripe OSSでできること Terminal package 技術的に組める コミュニティで改善できる → ・Web技術からネイティブ機能へ ・コミュニティで実装を共有 ・採用例の声が Issueに集まる 私: メンテナ メンテナとして見えていること 技術の選択肢と、実装相談が広がっている 技術の入口を、コミュニティで広げる 28
29. 端末から、店舗ネットワークへ 4 / PLATFORM 01 02 03 Terminal Connect Identity → 対面決済 端末上の体験 → 複数店舗 資金の流れ 事前本人確認 信頼の入口 決済機能 → プラットフォーム → 信頼を伴う実世界のマーケットプレイス 29
30. 端末は、会員化と再来店の入口になる 4 / PLATFORM MARGIN 決済の瞬間に、 ロイヤルティ登録を促す 統合開始から決済 受付まで : 1週間 10か月で決済量 5倍 端末上の登録体験と、 顧客データ活用を一つにした ビール・ワイン・酒類の小売業者の業務プロセス最適化 決済後の関係まで設計する 30
31. Marginは、決済を会員化へつないだ 来店 4 / PLATFORM 決済 ① 登録 ② 商品を選ぶ → 再来店 ③ Terminalで支払 う → その場で会員化 ∞ → 関係を蓄積 支払いの直後が、最も自然な登録タイミング 端末上で体験が完結する 31
32. Marginから持ち帰ること PAYMENT 4 / PLATFORM RELATIONSHIP 決済画面 顧客との関係 支払いを正確に、短時間で完了す る 会員化し、次回来店へつなげる 従来の端末が得意だったこと プログラマブル端末で増えた役割 端末の1画面が、 LTV（総支払額向上）の入口になる 32
33. Connectで、一店舗から “店舗網”を運営する 4 / PLATFORM あなたのプラットフォー ム SaaS / Marketplace ↓ ↓ ↓ 店舗 A 店舗 B 店舗 C 直営 加盟店 出店者 オンボーディング 売上・手数料 入金 端末管理 サポート データ 33
34. 業務SaaSが、決済事業へ広がる TRAXERO 4 / PLATFORM DINES レッカー業務 SaaS → TowPay 飲食オペレーション → 統合決済 4週間でTowPayベータ開始 取引量は前年比4倍の成長見込み すでに知っている業務へ、決済という収益レイヤーを足す 34
35. Traxeroが、すでに持っていたもの WORKFLOW 4 / PLATFORM TRUST レッカー業務 SaaS 業界ドメイン 配車・案件管理・請求を日常業務 で支える 決済を単なるカード受付ではなく、 レッカー業務の完了までつなげら れた 決済前の業務を知っていた 新規顧客をゼロから集めなくてよい 決済会社が業務を学ぶより、業務 SaaSが決済へ入る 35
36. Traxeroは、4週間でベータ開始 依頼 4 / PLATFORM 業務 ① 決済 ② レッカーを手配 → 既存SaaSで管 理 入金 ③ → TowPayで支払 う ∞ → Connectで管理 既存ワークフローへ、決済という収益レイヤーを足した Professional Services支援で、4週間でベータ開始 36
37. Dinesが、すでに持っていたもの ORDER 4 / PLATFORM DATA 注文と店舗運営 注文と商品のデータ メニュー・注文・スタッフ業務を一 つにする決済前の店内体験を持っ ていた 1回の注文に複数店舗が混ざる 中、何が、いつ、どの店で売れた かまでを一本化。 決済前の店内体験を持っていた 売上の前後をつなげられる 会計だけでなく、飲食体験全体を設計する 37
38. Dinesは、注文から決済まで一つにした 来店 注文 ① 店舗・席を認識 4 / PLATFORM 決済 ② → 再訪 ③ Dinesでオー ダー → Terminalで支払 う ∞ → 顧客データへ接 続 会計だけを置き換えず、会場体験全体を統合 公表時点：取引量は前年比4倍の成長見込み 38
39. Connectで、出店者登録から精算までつなぐ 4 / PLATFORM 1 2 3 出店者登録 加盟店確認 メニュー・端末設 定 店舗・事業者情報 → Stripe Connect → 商品・価格・売場 4 → 当日販売 注文・決済・売上記録 主催者は会場全体を管理しながら、 出店者ごとの売上を正確に精算できる ※ 売上は自動的にに Connectを経由して振込 39
40. 店舗インフラ事業の成長階段 4 / PLATFORM 4 3 業界の標準にな る 2 複数店舗を支え る データと運用を蓄積 1 体験を組み込む Connectで店舗網を運営 決済を組み込む 会員・予約・ゲーム・案内 自社アプリで対面決済 最初から巨大な決済事業を作る必要はない 40
41. 店舗インフラ事業は、どこで収益をつくるか ASSET 5 / BUSINESS REVENUE すでに持っているもの 収益の組み合わせ 顧客接点 業務データ 業界からの信頼 SaaS利用料 決済に連動する収益 導入・運用サービス料 業界固有の摩擦から始める 一つに絞らなくてよい 業界固有の摩擦 × Stripeの基盤 × 自社の運用 41
42. APIをつなぐだけでは、店舗インフラにならない 5 / OPERATIONS 01 02 03 04 契約・審査 端末物流 現場支援 責任分界 誰を受け入れるか 発送・交換・在庫 設置・教育・問い合わ せ 障害時に誰が動くか 技術は参入を可能にする。運用が継続を可能にする。 店舗が困った瞬間に、逃げない設計までが商品 42
43. 運用も、プロダクトとして設計できる 5 / OPERATIONS MINDBODY 端末の注文・発送・店舗への 事前紐付けを自動化 注文フロー実装 : 4か月 端末注文 1件あたり 2時間削減 “届いたらすぐ使える”までがUX バックオフィスの摩擦も、店舗体験の一部 43
44. AIで、“作ること ”そのものは難しくなくなる 6 / START これまで これから 実装できる人が 強かった 顧客と業界を 一番知る人が強い 作業を外へ丸投げしがち → AIへ指示し、共に“帆走”する AIは風。ドメイン知識が舵。 44
45. TAKEAWAY 誰がやるかではなく、 誰からやるか。 MARKET + TECH + 決済処理基盤を、ゼロから構築する必要はない。 顧客と店舗に対する事業責任は、自社が持つ。 DOMAIN START あなたが一番知っている業界から、 端末を“配られるもの”から“作るもの”へ変える。 Stripe Terminalで、店舗インフラ事業を始めよう