1. 決済ゲートウェイは、ゲスト、決済処理事業者、金融ネットワークの間で決済リクエストを安全に伝達します。
2. ホテルの統合決済は、その取引を予約、残高、返金、レポート作成の業務フローに結び付けます。
3. Stripeとの直接連携は、アカウントの所有権、入金状況の可視性、手数料、支払いに関する異議申し立て、サポート責任に関わります。
4. PCI DSSへの対応は引き続き共同で担う責任です。準拠した事業者を利用しても、ホテルの義務がなくなるわけではありません。
決済ゲートウェイとしてのホテル決済システムと、ホテル業務に統合された決済ソリューションでは、導入する内容が異なります。決済ゲートウェイは、取引の承認と送信経路の制御を支援します。一方、システム連携の仕組みによって、ホテルのスタッフが正しい予約にひも付いた決済を確認し、適切な予約金を徴収し、返金を処理し、入金を照合して、正確な残高を引き継げるかどうかが決まります。
オーナーが導入時に問うべきなのは、単に「ゲストがオンラインで支払えるか」ではありません。「加盟店アカウントを誰が管理し、資金がどこに入金され、ホテル管理システムが決済結果をどう把握し、フロントデスクと経理にどのような作業が残るか」です。
決済ゲートウェイの役割
決済ゲートウェイは、承認を得るために決済情報を送信する、安全な接続の仕組みです。ゲストの支払い方法、決済処理事業者または加盟店契約会社、金融ネットワークの間で取引情報を受け渡す役割を担います。決済ゲートウェイは、承認、拒否、追加手続きが必要といった結果を返します。
その結果だけでホテルの予約情報が自動更新されるわけではありません。単独の決済ゲートウェイで支払いを正常に受け付けても、ホテル管理システムには未払い残高が表示されたままになることがあります。その場合、スタッフは別のダッシュボードを検索し、ゲストを特定して、支払いを手入力で記録する必要があります。
見積もりに含まれるサービスが決済ゲートウェイのみなのか、決済処理、加盟店アカウントのサポート、現地の支払い方法、不正対策ツール、返金、異議申し立て、入金、ホテル管理システムとの連携まで含むのかを確認しましょう。責任範囲や手数料が異なっていても、事業者がこれらを「決済」という一つの名称にまとめている場合があります。
ホテルの統合決済で実現できること
統合決済は、取引を予約とホテルの業務フローに結び付けます。予約金の支払いリクエストには予約金額を使用でき、支払いが完了すると残高を更新し、返金も元の請求にひも付けたまま管理できます。
業務上のメリットが表れるのは、フロントデスクです。スタッフは、OTAが支払いを回収済みか、ホテルが予約金を受領済みか、直接予約の残高が残っているか、決済が失敗したかを確認できます。経理担当者は、別々に出力したデータでゲスト名を突き合わせることなく、予約売上と取引・入金を照合できます。
Smart Orderのホテル決済システムは、決済を予約、ホテル管理システムの業務、取引の一元表示に結び付けます。システムに統合されたオンライン決済の受付に対応し、決済状況を予約の業務フローと連携させます。
すべての決済を正しい予約にひも付ける
請求、残高、返金、取引状況をフロントデスクと経理が一つの画面で確認。別の決済ゲートウェイのダッシュボードとの照合作業を減らせます。
Stripeとの直接連携が意味すること
Stripeとの直接連携とは通常、別の事業者の加盟店アカウントを経由して資金を受け取るのではなく、ホテル自身のStripeアカウントをホテルのシステムに接続することを意味します。ホテルは、アカウントを所有する法人、入金先の銀行口座、ユーザーと認証の管理者、異議申し立てとコンプライアンス対応の担当者を確認する必要があります。
Smart OrderはStripeを含む決済事業者との連携に対応しており、ホテルが接続したアカウントで支払いを受け取りながら、ホテル管理システム上で予約の業務フローに沿って取引を確認できます。ただし、利用可否、料金、通貨、支払い方法は国やアカウントによって異なる場合があるため、導入前に実際の設定内容を確認しましょう。
決済が拒否された場合、入金が遅れた場合、ホテル管理システムの表示がStripeの状況と異なる場合に、誰がサポートするのかを確認しましょう。「直接連携」であっても、問題解決の責任者が決まらないまま、ホテルが二つの事業者間の調整を任される状態であってはなりません。
PCI DSS:ホテルが引き続き担う責任
PCI DSSは、カード会員データを保存、処理、送信する組織に適用されます。準拠した決済事業者と、リスクの低いホスト型またはトークン化された決済フローを利用することで、ホテルのシステムが扱うカードデータを減らし、ホテルのコンプライアンス対応の負担を軽減できます。
ただし、PCIに関する責任がなくなるわけではありません。ホテルは引き続き、承認された決済フローを使用し、自施設の構成に必要な準拠確認を実施し、スタッフのアクセスを管理し、アカウントと端末を保護する必要があります。また、カード情報の全内容をメール、チャット、メモ、スプレッドシートにコピーしてはいけません。
システムを比較する際は、カードデータの入力場所、ホテルのウェブサイトやホテル管理システムを経由するか、スタッフが閲覧できる決済情報、トークンの使用方法、施設が毎年実施するコンプライアンス対応を確認しましょう。「PCI準拠」という説明だけで、セキュリティの説明が十分だと判断しないことが大切です。
一つの決済をホテル業務の全工程で追跡する
デモでは、実際の予約を想定した例を使いましょう。ゲストがホテルの予約エンジンで予約し、予約金を支払い、宿泊内容を変更し、残額を支払い、追加サービスを購入し、その後に一部返金を受けるという流れです。
各処理が予約情報、宿泊者の精算明細、取引画面、入金記録、レポートのどこに表示されるか、事業者に実演してもらいましょう。決済状況が自動的に変わるか、スタッフが承認、売上確定、決済精算、返金、失敗、異議申し立てをどのように区別するかを確認します。
次に、OTAが支払いを回収する予約をテストしましょう。OTAからの入金待ちを、ゲストがホテルへの支払いをまだ済ませていないかのように表示してはいけません。統合決済の価値が発揮されるのは、支払いの回収を担当する相手に合った状況が表示される場合です。
重複計上を避けて手数料を比較する
提案を比較する前に、費用を項目ごとに分けましょう。決済ゲートウェイまたは決済処理の手数料、支払い方法別の手数料、通貨換算、越境取引の手数料、返金時の手数料の扱い、異議申し立ての手数料、入金手数料、ホテル管理システムの取引手数料、ソフトウェアの月額料金です。
どの手数料が入金前に差し引かれ、どの費用が別の請求書で請求されるかを確認しましょう。返金した取引の決済処理手数料が返還されるか、現地の電子ウォレットで料金が異なるか、決済の失敗や異議申し立てによって追加費用が発生するかも確認します。
決済処理の手数料率が低くても、手作業の照合や回収の遅れによる負担が、そのメリットを上回ることがあります。統合ソリューションは取引ごとの費用が高くなる場合がありますが、予約金の回収漏れ、二重請求、スタッフの作業時間を減らせます。ホテルで実際に運用する業務フローを基準に、総コストを比較しましょう。
照合とレポート作成を確認する
予約総額、支払済み金額、未払い残高、返金、手数料、入金額は関連していますが、同じものではありません。システムには、経理担当者が一つの予約からその決済履歴を確認し、一つの入金から対象となる取引をたどれる機能が必要です。
ホテルのレポート与分析を活用し、予約売上、回収額、未払い残高、チャネル別の実績、取引記録を比較しましょう。会計レポートでは、収益が発生する時点と銀行口座に入金される時点の違いを明確に区別する必要があります。
修正がどのように処理されるかを確認しましょう。スタッフが決済を誤った予約にひも付けた場合、監査証跡には元の操作と修正内容が記録され、履歴が知らないうちに置き換えられない仕組みが必要です。
フロントデスクの操作権限を評価する
フロントデスクのユーザーには、承認された金額の回収、安全な支払いリクエストの送信、状況の確認、ホテルの返金手順の実施に必要なアクセス権限が求められます。通常、加盟店アカウントの全管理権限、制限のないデータ出力、機密性の高いカードデータへのアクセスは必要ありません。
役割別の権限、管理者の承認が必要となる金額基準、返金上限、端末からのアクセス、シフト間の引き継ぎを確認しましょう。拒否された決済と、ゲストには成功したように見えてもホテル管理システムに反映されていない決済をテストします。
最も安全な業務フローは、スタッフに許可された操作を明確に示します。繰り返しの請求を防ぎ、状況が確定していない決済を確認できる状態に保ち、管理者が問題を担当窓口へ引き継げる仕組みが必要です。
導入判断の基準
施設にすでに信頼できる予約への決済記録と照合の仕組みがあり、専門的な決済事業者を必要とし、別々のシステムを運用する作業を受け入れられる場合は、単独の決済ゲートウェイを選びましょう。
オンラインでの支払い回収、決済状況、残高、返金、レポート作成を各予約に結び付けて管理したい場合は、ホテルの統合決済を選びましょう。パートナーページにロゴが掲載されているだけで業務フロー全体に対応していると判断せず、連携の範囲と深さを確認することが大切です。
どちらを選ぶ場合も、契約前に、加盟店アカウントの所有権、対応する国と通貨、支払い方法、入金時期、手数料、返金、異議申し立て、PCIに関する責任、データへのアクセス、サポートの責任主体、解約・移行条件を文書で確認しましょう。
よくある質問
決済ゲートウェイと決済処理事業者は同じですか?
いいえ。決済ゲートウェイは決済リクエストを安全に送信し、決済処理と加盟店契約・精算の機能は、金融ネットワークを通じて取引を処理し、資金を精算します。事業者がこれらのサービスを一括で提供する場合もあります。
ホテルの決済が「統合されている」とは、どういう意味ですか?
取引が予約と業務記録に結び付いており、予約金、残高、返金、決済状況、照合の管理を手作業の再入力に頼らずに行えることを意味します。
Stripeを利用すれば、ホテルは自動的にPCI準拠になりますか?
いいえ。安全なStripe連携により、ホテルが扱うカードデータを減らし、対応義務を簡素化できます。ただし、承認されたフローを使用し、自施設の構成に必要なコンプライアンス要件を満たす責任は、引き続きホテルにあります。
Stripeとの直接連携について、ホテルは何を確認すべきですか?
アカウントの所有権、銀行口座への入金、対応する市場と支払い方法、手数料、返金、異議申し立て、ユーザーのアクセス権限、PCI対応、ホテル管理システムの状況更新、サポート責任を確認しましょう。
小規模ホテルには、どちらが適していますか?
少人数のチームで予約の残高と取引状況を一つのシステムで管理する必要がある場合、統合決済のほうが使いやすいことが多くあります。ホテルにすでに十分な決済運用体制があり、専門的な要件がある場合は、単独の決済ゲートウェイが適することもあります。