Stripe決済連携 ヘルプ
概要
Stripe決済連携では、施設ご自身の Stripe アカウントを UnlockOS に接続します。接続すると、ゲストの予約・チェックイン・延長・会員登録などの支払いをクレジットカードや Apple Pay / Google Pay、PayPay で受け取れるようになります。
売上は Stripe から施設ご自身の口座へ直接入金されます。UnlockOS が代金を預かることはありません。
カード情報は UnlockOS を通りません。 ゲストが入力するカード番号・有効期限・セキュリティコードは、Stripe が提供する入力フォームからそのまま Stripe に送られます。UnlockOS のサーバーにも管理画面にも渡らず、保存もされません。詳しくは「カード情報の流れ」を参照してください。
アクセス方法
接続設定 → Stripe決済システム（/stripe-connection）
APIキーの登録・削除は組織オーナーまたはプラットフォーム管理者の権限が必要です。
詳細機能
機能1: APIキーを登録する
Stripe ダッシュボード（dashboard.stripe.com）の「開発者 → APIキー」で取得した値を入力します。
| 入力項目 | 取得場所 | 備考 |
|---|---|---|
| 公開可能キー (Publishable Key) | Stripe ダッシュボード → APIキー | pk_test_... / pk_live_... |
| シークレットキー (Secret Key) | 同上（「表示」をクリックして確認） | sk_test_... / sk_live_... |
| Webhook Secret（オプション） | Stripe ダッシュボード → Webhook | whsec_... |
| 通貨 | — | 日本国内は JPY |
シークレットキーは保存後に画面へ表示されません。再表示ではなく、必要になったら Stripe 側で新しいキーを発行して登録し直してください。
機能2: 接続を確認する
保存後、接続確認 ボタンで Stripe API への疎通を確認します。成功すると接続状態が「接続済み」になり、最終確認日時が記録されます。
「設定済み（未確認）」のまま決済を開始しないでください。キーの打ち間違いはこの確認で見つかります。
機能3: テストモードと本番モードを切り替える
テスト用と本番用のキーはそれぞれ別に保存され、画面上のラジオボタンで「いま決済に使うほう」を切り替えます。
- 両方のキーを登録済みの場合、モードを切り替えるだけならキーの再入力は不要です
- 本番運用を始める前に、必ず本番モード（
pk_live_.../sk_live_...）に切り替えてください - テストモードのまま公開すると、ゲストの支払いは実際には成立しません
機能4: Webhook Secret を登録する
Webhook を設定すると、Stripe 側で確定した支払い結果（成功・失敗・返金など）を UnlockOS が受け取れます。ゲストがブラウザを閉じてしまった場合でも支払い結果を取りこぼしません。
機能5: テスト用APIキーを取得する
「本番用キーを登録したまま、この画面の切り替えをテストモードにすればテストできる」というのはよくある誤解です。実際には、Stripe ダッシュボード側でテストモード（サンドボックス）に切り替えてから、そのモードの API キーを取得する必要があります。
- dashboard.stripe.com にログインする
- 画面右上（またはサイドバー）の テストモード / サンドボックス の切り替えを ON にする。直接 dashboard.stripe.com/test/apikeys を開いても同じ画面に入れます
- 「開発者 (Developers) → APIキー (API keys)」を開く
- 表示されている
pk_test_...（公開可能キー）とsk_test_...（シークレットキー、「表示」をクリックして確認）をコピーする - この画面のテストモード欄に貼り付けて保存する
テスト用キーと本番用キーは、Stripe 側では完全に別物として管理されています。
- テスト用キーで決済しても実際のカードには課金されません（後述のテストカード番号でのみ動作します）
- 本番用キーで決済すると実際のカードに課金されます。テストカード番号は本番用キーに対しては使えません
UnlockOS 側の「テストモード / 本番モード」ラジオボタンは、すでに登録済みの2組のキーのうち、どちらを今の決済に使うかを選ぶスイッチであり、キー自体をテスト用・本番用に変換する機能ではありません。テスト欄には必ずテスト用キー（pk_test_... / sk_test_...）を、本番欄には必ず本番用キー（pk_live_... / sk_live_...）を登録してください。
テストカードの番号（4242 4242 4242 4242 など）は Stripe 公式のテストページを参照してください。
機能6: Apple Pay / Google Pay を有効にする（決済方法ドメインの登録）
UnlockOS は施設ご自身の Stripe アカウントを接続する方式（BYOキー）のため、Apple Pay / Google Pay を予約・決済画面に表示するための「決済方法ドメイン (Payment method domains)」の登録は、UnlockOS 側ではなく施設ご自身の Stripe アカウントで行う必要があります。
登録する場所
Stripe ダッシュボード → 設定 (Settings) → 支払い方法のドメイン (Payment method domains)
直接開く場合: dashboard.stripe.com/settings/payment_method_domains
「新しいドメインを追加する」から、決済画面が表示されるドメインを1つずつ登録します。Apple Pay については、Apple 側の加盟店登録（Apple Merchant ID の作成など）は Stripe が代行するため、施設側での追加作業は不要です。
登録が必要なドメイン
実際に Stripe の決済フォーム（カード入力欄・Apple Pay / Google Pay ボタン）が表示される画面のドメインだけを登録します。
| ドメイン | 画面 |
|---|---|
booking.unlockos.io |
予約時の決済 |
member.unlockos.io |
会員登録・回数券購入 |
checkin.unlockos.io |
チェックイン時・延長時の決済 |
locker.unlockos.io |
ロッカーの決済 |
埋め込みスニペット（自社サイトへの予約フォーム設置）は、現時点では Stripe の決済フォームをそのページ内に描画しません。ドメイン登録の対象は上記4つです。
テストモードと本番モードの登録は別管理
Stripe の決済方法ドメインは、本番環境とテスト環境（サンドボックス）で別々に管理されています。
- 本番環境で登録すると、同じドメインがテスト環境（サンドボックス）にも自動的に反映されます
- テスト環境だけに登録した場合は、本番環境には反映されません。 本番運用を始める前に、必ず本番環境側でも同じドメインを登録してください
登録しないとどうなるか
登録していないドメインでは、Apple Pay / Google Pay のボタンがそもそも表示されません。カード決済（機能1〜3で登録したキーによる通常のカード入力）には影響しません。ゲストが「決済できない」状態になるわけではなく、「ウォレット決済の選択肢が表示されない」状態になります。
Google Pay もドメイン登録が必要です
「Apple Pay だけ登録すればよい」という誤解がありますが、Stripe 公式ドキュメントでは Google Pay についても「Google Pay ボタンが表示されるすべてのウェブドメインを登録する必要がある」と明記されています。上記の手順は Apple Pay と Google Pay の両方に共通です。
既知の制限: LINE アプリ内ブラウザでは Apple Pay が動作しません
ゲストが LINE のトーク画面から開いた予約・決済リンク（LINE のアプリ内ブラウザ）では、Apple Pay JS が Safari を要求する仕様のため動作しません。カード決済や PayPay は通常どおり利用できます。LINE 経由のリンクを案内する場合は、Apple Pay が選べないことがある点を伝えてください。
カード情報の流れ
Stripe連携での決済は次の順番で処理されます。
- UnlockOS が金額を計算し、Stripe に支払いの作成を依頼する（このとき送るのは金額と通貨だけです）
- ゲストの画面に Stripe が提供する入力フォーム が表示される
- ゲストが入力したカード番号・有効期限・セキュリティコードは、そのフォームから 直接 Stripe に送信される
- UnlockOS は結果として Stripe が発行する識別子（支払いID・支払い方法ID）と、ブランド名・下4桁などの表示用情報だけを受け取る
つまり、カード番号・有効期限・セキュリティコードは UnlockOS のサーバーを 通過も保存もしません。カードを次回以降のために保存する場合も、保存先は Stripe であり、UnlockOS が扱うのは Stripe の支払い方法IDだけです。
これが、後述の申告で「カード情報の非保持」に該当する理由です。
Stripeの「セキュリティ対策についてお知らせください」への回答
日本国内でオンラインのクレジットカード決済を行う事業者は、クレジット取引セキュリティ対策協議会のチェックリストに基づくセキュリティ対策の申告を Stripe に提出する必要があります。UnlockOS を利用している施設向けに、各項目の書き方をまとめます。
この申告の提出者は加盟店である貴施設です。 ここに記載しているのは UnlockOS 側の実装事実です。最終的な記載内容の判断と責任は貴施設にあります。UnlockOS 以外の予約経路（自社サイトの別カート、電話予約時のカード情報の手入力など）を併用している場合は、その経路の対策も併せて申告してください。
委託先情報の書き方
UnlockOS は、貴施設に代わって予約・決済画面（ASPカート）を提供する委託先にあたります。したがって最初の質問は 「委託先企業」 を選択します。
| 項目 | 入力する内容 |
|---|---|
| 貴社に代わってどなたがセキュリティ対策を実行しますか？ | 委託先企業 を選択 |
| 委託先企業名 | ブロックチェーンロック株式会社（UnlockOS） |
| ASP カート事業者名 | ブロックチェーンロック株式会社（UnlockOS） |
| PCI DSS 準拠の審査を行った QSA | 適用外 |
委託先企業名と ASP カート事業者名が同じでよい理由
UnlockOS の開発・運営は、いずれもブロックチェーンロック株式会社が行っています。予約・決済画面（カート）の提供者と、セキュリティ対策を担う委託先が同一のため、両方の欄に同じ社名を記載します。
欄に文字数の余裕があり、より詳しく書きたい場合は次のように補足できます。
ブロックチェーンロック株式会社（UnlockOS）— 予約・決済画面の提供。カード情報の入力・保持はストライプジャパン株式会社が行い、当該画面および委託先のサーバーはカード情報を保持しない。
QSA の欄を「適用外」と書く理由
この欄は、委託先企業と ASP カート事業者に PCI DSS の監査（QSA による審査）が要求されている場合に、その審査を行った QSA 名を記入する欄です。Stripe の入力ガイドにも「いずれにも監査が要求されていない場合は『適用外』を入力してください」と書かれています。
UnlockOS はカード情報を保存・処理・通過させない構成（前述の「カード情報の流れ」を参照）のため、QSA による PCI DSS 審査を受けておらず、要求もされていません。したがって 適用外 が正しい記載になります。
なお、カード情報を実際に取り扱う Stripe 自身は PCI DSS の最高水準（サービスプロバイダ レベル1）に準拠しており、これは Stripe 側で管理されている情報です。この欄に記入する必要はありません。
ログインセキュリティ対策の選び方
「少なくとも 1 つの対策を実施する必要があります」と書かれている項目です。UnlockOS のゲスト向け予約アプリ・会員アプリのログインは、パスワードを一切使わず、ログインのたびにメール宛の 6 桁ワンタイムパスワード（OTP）で認証する方式です。
各選択肢と UnlockOS の実装状況は次のとおりです。
| 選択肢 | UnlockOS の実装 | 判断 |
|---|---|---|
| 不審な IP アドレスからのアクセス制限 | 実装していません | チェックしない |
| 本人確認のための二段階認証または多要素認証 | ログインは毎回メール宛の使い捨て 6 桁 OTP。パスワードは存在しません | 施設の判断（下記参照） |
| ユーザー登録時の個人情報の確認（氏名・住所・電話番号・メールアドレス等） | 予約時に氏名・メールアドレス・電話番号を取得します。メールアドレスは OTP の受信をもって到達を確認済みです。住所の取得、身分証画像のアップロード、SMS による電話番号の所持確認は、施設のフォーム設定により追加できます | チェックする |
| ログイン試行回数の制限とスロットリング | 認証基盤が、IP アドレス単位でのログイン試行回数と OTP 検証回数の制限、OTP 再送の間隔制限、OTP の有効期限切れを標準で適用します | チェックする |
| ログイン時またはアカウント情報変更時のメール/SMS 通知 | ログインのたびに本人のメールアドレスへ OTP メールが届くため、第三者がログインを試みた場合も本人に通知が届きます。ただし「ログインが完了しました」という事後通知メールは別途送信していません | 施設の判断（下記参照） |
| 行動分析 | ログイン対策としては実装していません | チェックしない |
| デバイスフィンガープリント | 実装していません | チェックしない |
| その他の対策 | パスワードを保存しないパスワードレス認証 | 記載を推奨 |
| 該当なし：会員のログイン機能はありません | ゲスト予約アプリ・会員アプリにはログインがあります | チェックしない（例外は下記） |
最低限の記載
判断に迷う場合は、次の 2 つにチェックすれば要件（少なくとも 1 つ）を満たします。どちらも UnlockOS が標準で実装している事実です。
- ユーザー登録時の個人情報の確認（氏名・住所・電話番号・メールアドレス等）
- ログイン試行回数の制限とスロットリング
「二段階認証または多要素認証」にチェックしてよいか
判断が分かれる項目です。
- チェックする立場: ガイドラインが例示する対策には「ワンタイムパスワード」が含まれ、UnlockOS のログインはまさにワンタイムパスワードのみで行われます
- チェックしない立場: UnlockOS にはパスワードがなく、OTP 単独では認証の要素が 1 つ（メールを受信できること）です。文字どおりの「二段階」ではありません
厳密に記載したい場合は、この項目のかわりに 「その他の対策」 を選び、パスワードを保存せず、ログインのたびにメール宛のワンタイムパスワードで認証 と記載する方法が正確です。パスワードを保存しない方式は、パスワードの使い回しやリスト型攻撃による乗っ取りが構造的に起きないという利点があり、対策として説明できます。
「ログイン時のメール/SMS 通知」にチェックしてよいか
こちらも判断が分かれます。UnlockOS では、第三者が勝手にログインしようとすると本人のメールボックスに OTP メールが届くため、実質的には気づける仕組みになっています。一方で、これは通知そのものではなく認証手段です。事後の「ログインしました」通知メールは送っていません。
この点を正確に伝えたい場合は、「その他の対策」に含めて記載してください。
「該当なし：会員のログイン機能はありません」を選べる場合
フロントデスクやキオスク端末のみで運用し、ゲスト向け予約アプリ・会員アプリ・自社サイトへの予約画面の埋め込みを一切使っていない施設は、ゲストがログインする画面自体が存在しないため、この選択肢に該当します。
booking.unlockos.io や member.unlockos.io、自社サイトへの埋め込み予約画面のいずれかを利用している場合は該当しません。
よくある質問
Q. Stripe のアカウントは施設ごとに必要ですか。
決済を受け取る主体（組織）ごとに 1 つ必要です。売上は登録した Stripe アカウントの口座へ直接入金されます。
Q. シークレットキーを忘れました。
Stripe ダッシュボードで新しいキーを発行し、この画面で登録し直してください。UnlockOS は保存済みのシークレットキーを画面に表示しません。
Q. テストモードのまま公開してしまいました。
本番モードに切り替えて再度保存してください。テストモード中に受け付けた支払いは実際には成立していないため、該当する予約の支払い状況を個別に確認してください。
Q. テスト欄に本番用のキー（sk_live_... など）を保存しようとしたらエラーになりました。
テスト欄には pk_test_... / sk_test_... 形式のキーのみ保存できます。本番用キー（pk_live_... / sk_live_...）をテスト欄に保存しようとすると、保存時にエラー（エラーコード: STRIPE_KEY_MODE_MISMATCH）になり保存されません。同様に、本番欄にテスト用キーを保存することもできません。
この確認は、本番用キーがテスト欄に保存されてしまった施設で、画面上は「テストモード」と表示されたまま実際のカードに課金され、逆にテストカード番号（4242... など）はすべて決済拒否になるという事故が起きたために追加されました。Stripe のキーはどちらの環境のものでも一見同じ形の文字列に見えるため、取り違えに気づきにくいのが原因です。エラーが出た場合は、貼り付けたキーが正しい環境（テスト/本番）のものか、Stripeダッシュボードのモード切り替えを確認してから登録し直してください。
Q. セキュリティ対策の申告書は誰が提出しますか。
Stripe と契約している加盟店、つまり貴施設です。UnlockOS が代理で提出することはできません。この記事の内容を、貴施設の運用実態に合わせて確認のうえご記入ください。