結論
Stripe Terminal は 実店舗でカードを読み取り、PaymentIntent を完了させる ためのプロダクト群です。
「端末SDKの話」だけで閉じると、在庫・会計・レシート と決済の境界が曖昧になり、返品や日次締めで不整合が出やすいです。
Stripe 公式でも、Terminal は 対面決済とオンライン決済を統一的に扱う 文脈で説明されています。
そのため、端末単体ではなく「注文 ID と店舗 ID と決済 ID をどう揃えるか」が本質です。
このテーマで判断すべき軸
- 店舗ごとの Stripe 設定（ロケーション、端末の紐づけ）
- オフライン時の扱い（通信断、再送）
- レシートと返品 の責務（POS か決済か）
- オンライン決済との ID 設計 を共通化するか分けるか
アーキテクチャで押さえること
| 層 | 役割 |
|---|---|
| Reader | カード読み取りと顧客操作 |
| Terminal SDK | 端末との接続と支払い開始 |
| 自社 backend | 注文、在庫、会計、店舗 ID の正 |
| POS / 店舗アプリ | 商品選択、返品、レシート、店員操作 |
この 4 つが別責務だと最初から分けておくと、障害切り分けが楽になります。
実装の基本フロー
- 店舗・レジ・端末を識別子でマスタ管理し、取引ログに必ず載せる
- 注文確定と決済確定の順序ルール（先払いか後払いか）を固定する
- Webhook で成功・失敗・取消を取り込み、POS 側の状態と突合する
- 日次の売上照合（Stripe のレポートと POS の締め）を手順化する
失敗しやすい点
- 画面表示だけで成功とみなし、POS と Stripe の状態を突合しない
- 端末のシリアルと店舗の対応が手運用になり、問い合わせ時に追えない
- オンライン用の Customer 設計をそのまま店舗に持ち込み、不要な複雑さが増える
運用で見る指標
- 端末別の決済成功率と通信エラー率
- 取消・返品の件数と処理時間
- 日次差異（POS と Stripe）の有無
次に読む記事
用語: Terminal、PaymentIntent。一覧は 用語集 です。
よくある質問
EC と同じ Stripe アカウントで使えますか？
アカウント設計は事業形態とレポート要件次第です。オンラインと店舗で事業者情報や税処理が分かれる場合は、事前に税理士・Stripeサポートと擦り合わせるのが安全です。
オフラインでも Webhook は必要ですか？
非同期で状態が変わるなら、オンライン同様に Webhook を正にする設計が無難です。