事前決済に加えて、店内での現地決済とQRオーダー、 そして3事業をまとめた経営管理まで含めた場合にどうなるかを整理しました。 結論から言うと Cloudflare と Stripe だけで作れますが、 日本ならではの制約が4つあり、それを知らずに作ると確実に詰まります。
Cloudflare と Stripe だけで完結します。店内のカード決済も、Stripe の「サーバー主導型」という方式なら Worker から直接カードリーダーを操作できます。iOS / Android のアプリを作る必要はありません。
| サービス | 事前決済（オンライン） | 現地決済（店内） | 注文の受け方 |
|---|---|---|---|
| restaurantEat | 6名以上のみカード登録no-show 対策。その場では請求しない | Stripe Reader S700カード / Apple Pay / Google Pay | QRオーダー または口頭席のQRを読む → メニュー → 注文 |
| directions_carDrive | レンタル料を全額前払い＋保証金を与信保留 | 延長・給油不足・傷の精算同じリーダーを使い回す | サイトの予約フォーム |
| luggageStore | 空港配送は前払い発送したら回収できないため | 店内預かりは受け取り時に精算日数で金額が変わるため | サイトの申込フォーム |
Stripe の公式ドキュメントに「Terminal を日本に導入する（プレビュー）」と明記されています。使えるスマートリーダーは Stripe Reader S700 の1機種だけで、他国で使える WisePOS E や S710 は日本では選べません。
正式版になっていない機能を店の会計の根幹に置くかどうかは、経営判断として先に決めておく必要があります。
Stripe Terminal が対応しているのは国際規格の非接触決済だけです。日本独自の iD / QUICPay しか載っていないカードや Apple Pay は、Visa のロゴが付いていてもリーダーで弾かれます。
NINJA のお客さんは大半が海外の方なので実害は小さいですが、日本人のお客さんには失敗が起きます。現金は残す前提で設計します。
Terminal で QR 決済に対応しているのは WeChat Pay・PayNow・Affirm ですが、WeChat Pay は日本では地域制限で使えません。PayPay と Suica などの交通系ICは、そもそも Stripe Terminal の対象外です。
これらを受けたいなら、Stripe とは別の端末をもう1台置くことになります。
Worker からリーダーを動かす方式は、Stripe のドキュメントで「オフライン中のカード決済には対応していない」と明記されています。赤倉で冬にネットが落ちたら、その間はカード会計そのものが止まります。
オフライン対応が必要なら iOS アプリを作る方式に変える必要があり、これは Cloudflare 完結という前提から外れます。
4番は営業に直結するので、先に決めたい論点です。「ネットが落ちたら現金のみで回す」と割り切れるなら Cloudflare 完結で問題ありません。割り切れないなら、決済だけは既存の端末を残す、という選択になります。
3サービスで決済の形がまったく違います。同じ仕組みに揃えようとすると、どれかが不自然になります。サービスごとに分けて設計するのが結論です。
予約時に決済を挟むと、それだけで予約のハードルが上がります。客単価 ¥1,000〜2,000 の店で事前決済は割に合いません。 ただし2時間×2回転しかできない店で6名の予約が飛ぶと、その枠が丸ごと死にます。そこだけ手当てします。
ここが決済を入れる価値が一番高い部分です。車両を押さえる＝在庫を潰すので、無断キャンセルの損害が大きい。 キャンセルポリシーも、先にお金を預かっていないと機能しません。
空港配送は発送してしまうと回収できないので前払い。金額も個数で確定するので、決済としては一番単純です。 店内預かりは滞在日数で金額が動くので、受け取り時に S700 で精算します。
カードの与信保留（オーソリ）は通常7日で失効します。ところが日本に拠点があるアカウントの JPY 建て取引に限り、最長30日まで保留できます（Visa / Mastercard / JCB / Diners / Discover）。
スキー旅行は2〜4週間前の予約が普通なので、「予約時に保留 → 返却時に解放」が日本では現実的に成立します。海外の同業ではこれができません。
Amex と JPY 以外の取引は通常どおり7日で失効します。ここだけ分岐が必要です。
この分岐を作るかどうかは、運用の手間との相談です。
左のスマホで注文すると、右の厨房画面にすぐ出ます。実際に押して試せます。技術的にはこれが一番簡単な部類で、難しいのは運用のほうです。
席のQRは ninja.../t/5 のようなURLを指すだけ。メニューは D1 から出し、注文はDurable Object（テーブル1つにつき1個）が受け持ちます。厨房画面へは WebSocket で即座に届きます。
Durable Object は Workers の無料プランでも使えます（SQLite バックエンド）。接続しっぱなしの課金を避ける Hibernation という仕組みもあるので、コストはほぼ問題になりません。
サイトが英語・日本語・中国語で作ってあるので、メニューもそのまま3言語で出せます。「英語のメニューを紙で用意する」手間がなくなるのは、この店には大きい効果だと思います。
Stripe の「サーバー主導型」という方式を使います。Worker から Stripe の API を叩くとリーダーの画面が切り替わる、という仕組みなので、アプリを作らずに店内決済ができます。下のリーダーも押して動かせます。
テーブル5の注文が D1 から集計され、金額が確定します。
POST /v1/terminal/readers/{id}/process_payment_intent を叩くだけ。リーダーとは直接つながっていません。
Stripe 側からリーダーに指示が飛びます。お客さんはカードをタッチするだけ。
terminal.reader.action_succeeded を受けて、D1 の伝票を「会計済」にし、テーブルを空けます。
海外のお客さんが大半なので相性は良いのですが、日本人のお客さん向けに現金は残すのが現実的です。
事前決済は全員、海外からスマホで払います。ここが設計を決めます。下の画面は実際に押して進められます。
お客さんの6割以上がオーストラリア。豪州は世界でもタップ決済の普及率が最も高い国のひとつです。カード番号を手で打たせるより、ウォレット決済のほうが完了率が明確に上がります。
海外カードでは3Dセキュア（本人認証）が頻繁に発生します。銀行のアプリに飛ばされて戻ってくる、という流れを自前で扱うのは事故のもとです。
Stripe のホスト型決済画面（Checkout）に任せれば、3Dセキュアもウォレットも全部向こうが処理します。PCI DSS の負担も最小の区分で済みます。カード番号がこちらのサーバーを通らないためです。
多通貨対応は複雑さの割に効果が薄いので、JPY 固定を推奨します。ただし「約 A$◯◯」の目安を併記すると、豪州のお客さんの心理的ハードルが下がります。
レンタカーは免許証の確認と貸渡証が法律上必要です。決済は「予約の確定」であって「引き渡しの完了」ではないという区別を、画面でも明示します。
3事業の売上が1画面に乗ります。これが「まとめる」ことの一番の価値です。飲食・レンタカー・荷物がバラバラだと、その日いくら売れたのかを出すのに毎回集計が要ります。
| 受付 | サービス | お名前 | 日程 | 金額 | 決済 | 保証金 |
|---|
予約と注文は Cloudflare の D1 に、決済は Stripe にあります。放っておくと真実の源が2つできて、必ずズレます。「払ったのに予約が入っていない」「予約はあるが未払いのまま」が実際に起きます。
なので Stripe から Webhook を受けて、決済の状態を D1 に書き戻します。古澤さんはこの画面だけ見れば済む、という状態を作るのが設計の目的です。
この3つ以外は、上の画面で完結させます。
飲食の会計を扱うということは、1日の終わりに現金とカードを突き合わせる作業が発生するということです。いままで無かった業務なので、画面で完結するように作らないと、かえって手間が増えます。
技術の難易度より、運用の難易度のほうが高い機能群です。「作れるか」で言えば全部作れます。問題は「毎日回せるか」のほうです。
| 機能 | 技術 | 運用 | 目安 | 備考 |
|---|
Stripe Payment Link で始めます。実装はほぼゼロ。金額が確定していて、在庫がなく、返金の判断も単純。ここで決済の運用に慣れます。
ここから本番です。Checkout ＋ Webhook ＋ D1同期 ＋ 管理画面統合。在庫・返金・チャージバックが全部絡みます。
リーダーを1台入れて、レンタカーの延長精算と荷物の受け取り精算から使い始めます。件数が少ないところで実機を試すのが安全です。
ここが一番重い。繁忙期にいきなり入れてはいけません。シーズン前の空いている時期に、1テーブルだけで試すところから始めます。