--- title: "宿泊施設の決済システム：事前決済・デポジットとチェックアウト精算、PMS連携の判断基準" url: "https://www.issoh.co.jp/column/details/19082/" published: 2026-10-30 updated: 2026-10-30 categories: ["Webシステム"] publisher: "株式会社一創" --- # 宿泊施設の決済システム：事前決済・デポジットとチェックアウト精算、PMS連携の判断基準 宿泊施設の決済システムは、予約を受けた時点、チェックインの時点、チェックアウトの時点という3つの場面で、誰からいくらを受け取るかを決めて実行する仕組みです。この記事では、事前決済と現地決済の分け方、デポジットとして与信だけを押さえるオーソリ保持の期限、キャンセル料とノーショーの請求、チェックアウト精算で起きる差額と宿泊税の計算を順に整理します。そのうえで、決済の結果をPMS（ホテル管理システム）へ戻す連携とカード情報保護の要件を確認し、既製の組み合わせで足りる施設と決済連携の開発に進む施設の分かれ目まで示します。 ## まとめ：宿泊施設の決済は請求の時点とPMSへの戻し方で仕組みを選ぶ 宿泊施設の決済システムを、使える決済手段の数や手数料率から選び始めると判断を誤ります。先に決めるのは、予約時に全額を受け取るのか、与信だけを押さえるのか、到着まで何も受け取らないのかという請求の時点です。この方針で、ノーショーの損失、フロントの締め作業、返金の件数が決まります。 次に決めるのが、決済の結果をPMSの宿泊者ごとの請求明細（フォリオ）へ自動で戻すかどうかです。単独施設で既製のクラウドPMSを使い、そのPMSが標準で決済代行と連携しているなら、既製の組み合わせで足ります。自社の予約エンジンを持つ、複数施設の入金を1つの会計にまとめる、会員の保存カードで再訪時に決済したい、のいずれかに当たる施設は、決済連携を作る段階です。どちらの場合も、カード番号を施設側のシステムに通さない設計を前提にします。 ## 宿泊施設の決済が物販と違う、予約から精算まで続く請求の構造と入金経路 ### 予約時・チェックイン時・チェックアウト時の3時点で分かれる請求の組み立て 物販や飲食店の決済は、商品を渡すその場で1回請求すれば完結します。宿泊は違います。予約から宿泊日まで数か月空くことがあり、滞在中に食事や売店の付帯売上が増え、最終的な請求額はチェックアウトの瞬間まで確定しません。 | 請求の時点 | 主な方式 | 施設側の利点 | 残る課題 | | -------- | -------------- | ----------- | ------------ | | 予約時 | 事前決済（全額） | ノーショーの損失がない | キャンセル時の返金処理 | | 予約時 | カード保証（番号の保存のみ） | 予約の離脱が少ない | 請求時にカードが通らない | | チェックイン時 | デポジット（オーソリ保持） | 付帯売上の未収を防げる | 保持期限と解除の手間 | | チェックアウト時 | 現地決済・差額精算 | 確定額で1回請求できる | フロントの行列と現金管理 | 多くの施設は、これを1つに絞らず組み合わせています。決済システムを選ぶ前に、予約プランごとにどの時点で請求するかを表にしておくと、必要な機能が絞れます。 ### 自社サイト・OTA・電話予約で入金経路と消込の手間が変わる3つの流れ 同じ1泊でも、どこで予約されたかで代金の流れは変わります。自社サイトの予約エンジンで事前決済した代金は、施設が契約した決済代行から入金される仕組みです。OTA（宿泊予約サイト）経由では、OTAが宿泊者から代金を受け取り手数料を差し引いて施設へ支払う方式と、OTAが発行するバーチャルカードで施設が決済する方式があり、入金の時期も明細の形もOTAごとに違います。電話予約は、到着時の現地決済になるのが一般的です。 経理で手間がかかるのは、これらの入金を予約1件ずつに突き合わせる消込です。OTAの在庫と予約の連動は[サイトコントローラーとPMS・予約エンジンの役割分担](https://www.issoh.co.jp/column/details/16176/)で整理していますが、入金の消込はサイトコントローラーの守備範囲外です。予約経路ごとの入金明細をどこで突き合わせるかは、決済システムの選定と同時に決めます。 ## 事前決済とデポジットのオーソリ保持で決まる、ノーショー対策と未収の防ぎ方 ### 事前決済の比率を上げてフロントの現金と締め作業を減らす方法と返金の負担 事前決済の比率を上げると、到着時に扱う現金とカード決済の件数が減り、夜間の締め作業も短くなります。ノーショーの代金も最初から受け取っているため、後から請求する手間がありません。 その代わり、キャンセルのたびに返金が発生します。返金は決済代行の管理画面で処理しても、PMS側の予約と売上を取り消さないことが、帳簿と入金がずれる原因です。事前決済を主にする施設ほど、返金の結果をPMSへ戻す連携の有無で経理の手間が変わります。決済手段ごとの手数料は[キャッシュレス決済の手数料と総コストの比べ方](https://www.issoh.co.jp/column/details/18875/)で扱っており、返金時に手数料が戻らない契約もあるため、返金率の高いプランでは手数料の扱いも確認してください。 ### オーソリの有効期間は原則7日で宿泊は最大30日、JCBは延長対象外という制約 デポジットは、カードの利用枠を一時的に押さえる与信（オーソリ）だけを行い、売上の確定（キャプチャ）をチェックアウトまで待つ方式です。押さえた枠には期限があります。Stripeの[オーソリ延長の公式ドキュメント](https://docs.stripe.com/payments/extended-authorization)では、多くのカードネットワークで既定の有効期間はオンライン決済が7日、対面の端末決済が2日とされ、延長すると最大30日まで保持できます。 延長には条件が付きます。対象はVisa・Mastercard・アメリカン・エキスプレス・ディスカバーの4ブランドだけで、JCBは含まれていません。Visaはホテル・宿泊施設などのカテゴリで30日ですが、実際の期間は29日18時間です。アメリカン・エキスプレスは宿泊で30日まで延びるものの、滞在の終了までに売上を確定させる必要があります。さらに、延長が認められるのは原則として与信の時点で最終金額が決まっていない取引です。 実装では、与信だけを行う指定（`capture_method=manual`）に延長の要求（`request_extended_authorization=if_available`）を加え、決済ごとに返る `capture_before` の期限をPMS側に保存します。国内の宿泊客はJCBの利用が多いため、「予約時に与信を取って宿泊日に確定する」設計は、宿泊日が7日より先の予約では成り立たない場合があると考えてください。仕組みの詳細は[オーソリと売上確定の違いと実装パターン](https://www.issoh.co.jp/tech/details/15420/)で解説しています。 ### キャンセル料とノーショーを後から請求するためのカード保存と同意の取り方 与信だけを押さえる[支払い方法の保留](https://docs.stripe.com/payments/place-a-hold-on-a-payment-method)は、期限内に売上を確定させることが前提の仕組みです。期限が足りない予約では、カード番号そのものではなく、決済代行が発行するトークンとしてカードを保存し、キャンセル料やノーショーが確定した時点で宿泊客がその場にいない状態の請求として決済します。 後から請求する方式で揉めないためには、予約画面で次の3点を宿泊客に示し、同意の記録を予約データと一緒に残します。 - キャンセル料が発生する期日と、期日ごとの料率 - ノーショーのときに請求する金額（初日分か全泊分か） - 保存したカードへ施設側から請求する場合があること 同意の記録が予約エンジンにしか残らず、PMSのキャンセル処理から参照できない構成は避けます。請求のたびにフロントが別の画面で規定を確かめることになり、請求漏れが出ます。 ## チェックアウト精算で起きる差額と宿泊税の計算、自動精算機に任せる範囲の判断 ### 事前決済額と部屋付けの付帯売上の差額を追加請求と返金で精算する手順 チェックアウト精算では、事前に受け取った金額と最終的な請求額の差を処理します。差が出る原因は、レストランや売店の部屋付け、延泊やアーリーチェックイン、人数の変更による宿泊料金の変動、宿泊税です。 1. PMSのフォリオで、宿泊料金・付帯売上・宿泊税を確定させる 2. 事前決済額とデポジットの与信額を、確定額と突き合わせる 3. 不足分は与信の確定か追加請求、超過分は一部返金か与信の取り消しで処理する 4. 処理結果をフォリオへ戻し、領収書を確定額で発行する 手順3は、与信額を超える金額を確定できるかが決済代行とカードブランドで違うため、契約前に確認が要る箇所です。部屋付けの売上をPMSへ正しく載せる照合の作り方は[宿泊施設のセルフオーダーと部屋付け精算の連携](https://www.issoh.co.jp/column/details/19080/)で扱っているので、付帯売上の入口はそちらと合わせて設計してください。 ### 東京都の宿泊税が令和9年度に定額から3%の定率へ変わり精算額の計算が変わる点 宿泊税は、事前決済の金額に含めるのか、チェックアウト時に別で受け取るのかを予約経路ごとに決めておく必要があります。[東京都主税局の宿泊税の案内](https://www.tax.metro.tokyo.lg.jp/shitsumon/leisure/general%5F01)によると、現行は1人1泊の宿泊料金が10,000円未満なら課税されず、10,000円以上15,000円未満が100円、15,000円以上が200円です。令和9年度の改正（予定）後は、13,000円未満が課税されず、13,000円以上は宿泊料金の3%の定率方式に変わり、簡易宿所と民泊も課税対象になります。 定額方式なら、宿泊料金が多少変わっても税額は区分が変わらない限り同じです。定率方式では、アップグレードや割引で宿泊料金が1円変わるだけで税額も変わります。事前決済の時点で税込の金額を受け取っている施設は、チェックアウト時に税額を再計算して差額を精算する処理が必要です。自治体ごとの税率表をPMSに持たせる考え方は[PMSの宿泊会計とナイトオーディットの解説](https://www.issoh.co.jp/column/details/16688/)で触れています。 ### 自動精算機とセルフチェックアウトで足りる施設と、フロント対応を残す条件 自動精算機やスマホのセルフチェックアウトに任せられるのは、精算額が事前に確定している宿泊です。素泊まりのビジネスホテルで、事前決済済みかつ付帯売上の無い宿泊客が大半なら、フロントを通さない精算に切り替えても問題は起きません。 次のどれかが多い施設は、フロントで精算する経路を残します。 - 部屋付けの付帯売上が多く、内容の確認を求める宿泊客がいる - 法人の請求書払いや、宿泊者と支払者が違う予約がある - 入湯税や宿泊税の区分を宿泊客ごとに判断する場面がある - 領収書の宛名や分割発行の依頼が多い 自動精算機の導入は、精算件数の何割を機械で終えられるかを先に見積もってから決めます。機械で終えられる割合が低い施設では、精算機を入れてもフロントの人員は減らせず、機器の費用だけが増えます。 ## PMSと決済代行をつなぐ方式と、カード情報を施設側で持たないための線引き ### 決済結果をWebhookでPMSのフォリオへ戻す連携と、消込の不一致が出る箇所 決済代行とPMSの連携は、決済の結果を誰がPMSへ書き込むかで2つに分かれます。PMSが決済代行のAPIを直接呼ぶ構成なら、PMSの画面から与信・確定・返金を操作でき、結果も同じ画面に残る仕組みです。自社の予約エンジンなどPMSの外で決済する構成では、決済代行が送るWebhook（決済完了などの通知）を受け取り、PMSのフォリオへ書き込む連携を別に用意します。 不一致が出やすいのは次の3箇所です。決済代行の管理画面から直接行った返金がPMSへ戻らない。与信の期限切れがPMS側で検知されず、チェックアウト時に確定できない。Webhookの再送で同じ入金が2回計上される。3つ目は、決済ごとの識別子をPMS側に保存し、同じ識別子の通知を2回目以降は無視する作りにすれば防げます。決済代行への接続方式の違いは[決済システムの仕組みと決済代行との接続方式](https://www.issoh.co.jp/column/details/15263/)で比較しています。 ### クレジットカード・セキュリティガイドライン6.1版で施設が守る対面とWebの要件 カード決済を受ける施設は、日本クレジット協会が公表するクレジットカード・セキュリティガイドラインに沿った対策が求められます。[同協会の資料ページ](https://www.j-credit.or.jp/security/document/index.html)では最新版を6.1版としており、6.0版の改訂ポイントとして、対面取引での「PINバイパスの廃止」、EC加盟店での「EMV 3-Dセキュアの導入」と「脆弱性対策の実施」が挙げられています。 宿泊施設に当てはめると、フロントの決済端末は暗証番号の入力を省略しない運用に、自社サイトの事前決済は本人認証（EMV 3-Dセキュア）を通す設定にします。予約フォームでカード番号を受け取ってPMSや予約台帳に保存する作りは、この枠組みでは持たないことが前提です。番号の入力は決済代行の画面か入力部品で受け、施設側にはトークンだけを残します。宿泊者名簿や本人確認の扱いは[旅館業法の宿泊者名簿と本人確認の解説](https://www.issoh.co.jp/column/details/18226/)を参照してください。 ## 既製PMSと決済代行で足りる施設と、決済連携の受託開発に進む施設の判断条件 ### 単独施設でPMS標準の決済連携が使える宿は既製の組み合わせで足りる条件 次の3つがそろう施設は、既製のPMSと決済代行の組み合わせで済ませます。単独施設であること。予約の大半がOTAとPMS付属の予約エンジン経由であること。PMSが標準で連携している決済代行の中に、必要な決済手段と与信・返金の機能がそろっていること。 この条件で決済連携を作ると、カードブランドの規則変更や決済代行のAPI更新を自前で追い続けることになり、費用に見合いません。比較するときは、決済手数料率だけでなく、PMS連携の追加料金、返金時の手数料の扱い、入金サイクルを同じ条件でそろえて見積もります。フロント・予約・清掃を含めてどの業務から手を付けるかは[ホテルDXの進め方と、SaaSと受託開発の判断基準](https://www.issoh.co.jp/column/details/19072/)で順序を整理しています。 ### 自社予約エンジン・複数施設・会員基盤を持つ施設が決済連携の開発に進む条件 次のいずれかに当たる施設は、既製の組み合わせでは連携の壁に当たります。 - 自社開発の予約エンジンや会員サイトで事前決済を受けており、結果をPMSのフォリオへ自動で戻したい - 複数施設の入金と返金を1つの会計基幹に集め、施設をまたいで消込を回したい - 会員が保存したカードで、再訪時の予約や館内の付帯売上を決済したい - OTAのバーチャルカードと自社決済の入金を、同じ画面で予約単位に突き合わせたい この段階で作るのは決済そのものではありません。決済代行のAPIとWebhookを受け、PMS・予約エンジン・会計の間で与信・確定・返金の状態をそろえる連携の部分です。カード番号を受け取らない構成のまま、与信期限の管理と二重計上の防止を組み込みます。一創では、決済代行との接続とPMS・会計との連携を含めた[決済・サブスクリプションシステム開発](https://www.issoh.co.jp/service/system/payment/)を、請求時点の整理の段階から受け付けています。 ### 決済システムを自社開発してはいけない場面と、カード番号を受け取る設計の失敗 カード番号を自社のサーバーで受け取り、保存して後から請求する決済システムは作りません。カード情報を保持する事業者に求められる対策の範囲が一気に広がり、宿泊施設の規模で維持できる水準を超えます。保存が必要なら、決済代行のトークンで代替できます。 もう1つの失敗は、与信の期限を考えずに「予約時に与信、宿泊日に確定」を全予約へ当てはめる設計です。宿泊日が7日より先の予約や、延長の対象外のブランドでは、確定の時点で与信が切れています。予約から宿泊日までの日数とカードブランドで、事前決済・与信・カード保存のどれを使うかを分岐させてください。飲食店のように来店時の1回の請求で完結する業態の設計をそのまま持ち込まないことも大切で、違いは[飲食店の決済システムの選び方](https://www.issoh.co.jp/column/details/16089/)と比べると分かります。 ## 宿泊施設の決済システムの事前決済・オーソリ・精算に関するよくある質問 宿泊施設の支配人や運営担当の方から寄せられやすい質問をまとめました。 ### 宿泊施設は事前決済と現地決済のどちらを主にすべきですか？ ノーショーやキャンセルの損失が大きい施設は事前決済を主にし、返金処理の手間を連携で減らす方向が向いています。団体や法人の予約が多く、請求書払いや当日の人数変更が頻繁な施設は、現地決済とカード保証の組み合わせのほうが運用が止まりません。予約プランごとに分ける方法もあり、割引率の高い返金不可プランだけを事前決済にしている施設も多くあります。どちらにしても、PMS側で請求の時点を予約単位に持てるかを先に確認してください。 ### デポジットの与信はいつまで有効ですか？ 有効期間はカードブランドと決済代行によって異なります。Stripeの公式ドキュメントでは、多くのカードネットワークで既定はオンライン決済が7日、対面の端末決済が2日で、Visa・Mastercard・アメリカン・エキスプレス・ディスカバーは宿泊のカテゴリで最大30日まで延長できるとされています。JCBは延長の対象に含まれていません。実際の期限は決済ごとに返る値で確認し、期限が切れる前に確定するか、カード保存による請求へ切り替える設計にします。 ### キャンセル料は保存したカードから請求できますか？ 予約時にキャンセル料の規定と、保存したカードへ施設側から請求する場合があることを示し、宿泊客の同意を得ていれば請求できます。カード番号を施設側で保存するのではなく、決済代行が発行するトークンとして保存するのが前提です。同意の記録が残っていないと、宿泊客がカード会社へ申し立てたときに反論できません。予約画面で示した規定の版と同意の日時を、予約データと一緒に保存してください。 ### OTA経由の予約の代金はいつ施設に入金されますか？ 入金の時期と方式はOTAごとに違います。OTAが宿泊者から代金を受け取り、手数料を差し引いた金額を定期的に施設へ支払う方式と、OTAが発行するバーチャルカードを施設が自分の決済端末や決済代行で決済する方式の2通りです。後者は施設側の決済手数料がかかり、決済できる期間が決められていることもあるため、契約しているOTAの精算条件を一覧にしておくと消込が楽になります。 ### 既存のPMSに新しい決済手段を追加できますか？ PMSが標準で連携している決済代行がその決済手段に対応していれば、設定の変更で追加できる場合が多くあります。PMSの連携先に無い決済代行を使いたい場合は、PMSが外部から入金を書き込むAPIを公開しているかが分かれ目です。APIがあれば、決済代行のWebhookを受けてフォリオへ書き込む連携を作れます。APIが無い場合は、入金をCSVで取り込む運用か、PMSの入れ替えを検討することになります。 ## 関連記事 - [ホテル予約システムとは？機能・料金の選び方とOTA・PMS連携から見る自社開発の判断基準](https://www.issoh.co.jp/column/details/15277/)：事前決済を受ける予約エンジンとOTA連携の仕組みです。 - [宿泊施設の客室タブレット：館内案内・ルームサービスとPMS連携、既製品か開発かの判断](https://www.issoh.co.jp/column/details/19078/)：客室でのチェックアウト精算を入れるかの判断を扱っています。 - [ホテル管理システム（PMS）とは？クラウド型PMSの機能と移行・連携の判断基準](https://www.issoh.co.jp/column/details/16688/)：決済の結果を受け取るPMSの機能範囲です。 - [決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説](https://www.issoh.co.jp/column/details/15263/)：業種を問わない決済システムの全体像です。 - [キャッシュレス決済の手数料一覧｜決済手段別の料率と内訳、総コストの比べ方](https://www.issoh.co.jp/column/details/18875/)：決済代行を比べるときの手数料の見方です。 --- 出典: [宿泊施設の決済システム：事前決済・デポジットとチェックアウト精算、PMS連携の判断基準]()（株式会社一創）