旅行予約の決済
すべての決済を予約に紐付け続ける旅行向け決済ゲートウェイ連携
予約サイトや B2B ポータルを、お客様が利用する決済プロバイダーに接続します。チェックアウトは予約フローの中で完結し、カードが要求する場面では 3D Secure が実行され、すべてのオーソリ、売上確定、返金、webhook がチームが扱う予約番号に紐付けて保存されます。
- 予約フロー内でのチェックアウト
- プロバイダーが対応する範囲で多通貨
- 3D Secure とトークン化カード
- 取消、返金、消込
安全な旅行チェックアウト
予約フローに組み込まれた旅行向け決済ゲートウェイ連携
お客様は航空券、ホテル、ツアー、送迎の代金を、切り離された決済リンクではなく自社のチェックアウトページで支払います。予約システムが金額、通貨、予約番号を送信し、ゲートウェイは予約側が処理できる結果を返します。
同じフローが航空券予約ソフトウェア、ホテル予約エンジン、ツアーオペレーター向けソフトに対応します。予約を保留し、決済を受け付け、決済が成功した場合にのみサプライヤー確認へ進みます。
多通貨
プロバイダーと加盟店アカウントが対応する通貨で表示し、決済します。
安全な認証
トークン化カード、3D Secure、プロバイダー独自のリスクチェック。
追跡可能な記録
取引、予約、返金、決済参照番号が常に紐付いたままになります。
PT-48213- 詳細
- 支払い
- 3D Secure
- 確定
- 航空券、大人 2 名$612.00
- ホテル、3 泊$438.00
- 予約手数料$15.00
- 航空券、大人 2 名€566.00
- ホテル、3 泊€405.00
- 予約手数料€14.00
- 航空券、大人 2 名£486.00
- ホテル、3 泊£348.00
- 予約手数料£12.00
カード情報はゲートウェイに直接送信されます
サンプル金額です。通貨、決済手段、手数料はゲートウェイと加盟店アカウントによって異なります。
取引のライフサイクル
決済ステータスと予約ステータスはどのように連動するか
カードが承認されても旅行の決済は終わりません。シナリオを選んで、各ステップでゲートウェイが何を報告し、予約が何をするかを確認してください。
支払い済み・確定
売上確定確定- 0100:00予約が金額、通貨、参照番号をゲートウェイに送信決済保留中予約保留中
- 0200:04ゲートウェイがカードを承認し、資金を保留決済オーソリ済み予約保留中
- 0300:09サプライヤーが予約を確認決済オーソリ済み予約確定
- 0400:10保留中の資金を売上確定決済売上確定予約確定
- 0500:11署名付き webhook を予約に紐付けて保存決済売上確定予約確定
サプライヤー確認後に売上確定することで、存在しない予約に対してお客様に請求が発生することはありません。
3D Secure チャレンジ
売上確定確定- 0100:00予約が金額、通貨、参照番号をゲートウェイに送信決済保留中予約保留中
- 0200:03銀行が 3D Secure チャレンジを要求決済要対応予約保留中
- 0300:41お客様が本人確認を完了し、決済がオーソリされる決済オーソリ済み予約保留中
- 0400:46サプライヤーが予約を確認決済オーソリ済み予約確定
- 0500:47保留中の資金を売上確定決済売上確定予約確定
お客様が本人確認を行う間、予約は保留のままです。チャレンジが失敗またはタイムアウトすると、保留は解放され、何も請求されません。
価格変更
売上確定確定- 0100:00請求前にサプライヤーと価格を再検証決済未開始予約保留中
- 0200:02新しい価格をお客様に提示して承認を求める決済未開始予約再価格設定
- 0300:30お客様が承認し、新しい金額で決済を作成決済保留中予約再価格設定
- 0400:34ゲートウェイがカードを承認し、資金を保留決済オーソリ済み予約再価格設定
- 0500:39サプライヤーが予約を確認決済オーソリ済み予約確定
- 0600:40保留中の資金を売上確定決済売上確定予約確定
決済前に再検証することで、代理店が把握していない運賃や料金の値上げを負担せずに済みます。
決済後にサプライヤーが失敗
取消済み失敗- 0100:00予約が金額、通貨、参照番号をゲートウェイに送信決済保留中予約保留中
- 0200:04ゲートウェイがカードを承認し、資金を保留決済オーソリ済み予約保留中
- 0300:12サプライヤーが予約を拒否決済オーソリ済み予約失敗
- 0400:13売上確定前にオーソリを取消、請求なし決済取消済み予約失敗
- 0500:14お客様と運用チームに両方の参照番号で通知決済取消済み予約失敗
資金はオーソリのみだったため、返金ではなく取消で解放されます。プロバイダーが即時売上確定する場合、同じステップが返金になります。
例示的な流れです。先にオーソリするか即時売上確定するかは、ゲートウェイと設定によります。
仕組み
予約番号を運ぶリクエスト、webhook、返金
ゲートウェイへのすべての呼び出しは予約番号と冪等キーを持ち、ゲートウェイからのすべてのイベントは予約を変更する前に検証されます。
- 1予約番号はメタデータとして渡されるため、プロバイダーのダッシュボードと管理パネルが同じ予約を表示します。
- 2冪等キーにより、ダブルクリックやネットワークの再試行で二重請求されることを防ぎます。
- 3金額は明示的な通貨コードとともに最小単位で送信されます。
- 1何かを変更する前に、署名を webhook シークレットと照合します。
- 2イベント種別が予約の処理を決めます：確定、解放、または要確認としてフラグ付け。
- 3同じイベントの重複配信は認識され、無視されます。
- 1部分返金の金額は、代理店またはサプライヤーが保持するキャンセル料をカバーします。
- 2返金は元の決済とキャンセルされた予約を指します。
- 3理由コードはプロバイダーへ送られ、サポートや紛争対応のために記録にも残ります。
まだ接続されていないプロバイダーはカスタムAPI連携として対応します。主要なゲートウェイには個別ページがあります：Stripe決済とPayPal 決済。
POST /v1/paymentsIdempotency-Key: bk_PT-48213_a1{ "amount": 106500, "currency": "USD", "capture": "after_confirmation", "metadata": { "booking": "PT-48213", "pnr": "X7K2LM" }}POST /webhooks/paymentsSignature: t=1791012345,v1=5f3ac1…{ "id": "evt_8841", "type": "payment.captured", "payment": "pay_3QK19", "metadata": { "booking": "PT-48213" }}→ 200 OK booking=PT-48213 status=confirmedPOST /v1/refundsIdempotency-Key: rf_PT-48213_1{ "payment": "pay_3QK19", "amount": 41800, "currency": "USD", "reason": "cancelled_by_customer", "metadata": { "booking": "PT-48213", "retained_fee": 2000 }}一般的な例です。フィールド名は選択したゲートウェイの API に従います。
旅行業特有の運用
旅行業で起こる問題に対応する決済コントロール
価格は変動し、サプライヤーは失敗し、お客様はキャンセルします。各コントロールは、運用チームが日常的に直面する状況に応えます。
- 状況01
検索から決済までの間にホテル料金が上がった。
コントロール価格の再検証
お客様に請求する前にサプライヤーの最新価格を確認し、変更があれば承認のために表示します。
- 状況02
回線が遅く、お客様が支払うボタンを 2 回押した。
コントロール冪等な予約フロー
繰り返しのリクエストには最初の結果を返し、二重請求や二重予約を作りません。
- 状況03
お客様はユーロで支払い、サプライヤーはドルで請求する。
コントロール通貨とマークアップのルール
チェックアウト通貨、予約金額、マークアップ、決済金額をそれぞれ記録します。
- 状況04
5 泊のうち 2 泊がキャンセルされた。
コントロール取消と部分返金
全額または一部の返金は、原因となったキャンセルや変更に紐付けられます。
- 状況05
旅行の数か月後にカード会員が請求に異議を申し立てた。
コントロール紛争とチャージバック
プロバイダーのイベント、認証結果、予約書類を証拠として一緒に保管します。
- 状況06
すでにキャンセル済みの予約に webhook が届いた。
コントロールWebhook とアラート
検証済みイベントは予約を更新し、合致しないものは担当者の確認用にフラグ付けされます。
プロバイダーの対応範囲
市場とお客様に合わせてゲートウェイを選ぶ
利用可否は加盟店審査、対応国、通貨、決済手段によって決まります。多くの代理店はグローバルなカードゲートウェイに地域プロバイダーと B2B 精算の選択肢を組み合わせています。
- A
グローバルカードゲートウェイ
カード受付、トークン化、3D Secure、返金、複数市場でのチェックアウト。
- B
地域プロバイダー
現地通貨、国内決済ネットワーク、市場固有の決済手段。
- C
デジタルウォレット
承認済みウォレットアカウントを好むお客様向けのより速いチェックアウト。
- D
B2B 決済フロー
代理店与信、手動の入金記録、管理された決済ワークフロー。
| ニーズ | Aグローバルカードゲートウェイ | B地域プロバイダー | Cデジタルウォレット | DB2B 決済フロー |
|---|---|---|---|---|
| 国際カード | 通常対応 | 通常対応 | プロバイダーによる | 通常は適さない |
| 現地決済手段と銀行ネットワーク | プロバイダーによる | 通常対応 | プロバイダーによる | 通常は適さない |
| 3D Secure | 通常対応 | プロバイダーによる | プロバイダーによる | 通常は適さない |
| 返金と取消 | 通常対応 | プロバイダーによる | プロバイダーによる | 通常対応 |
| 複数通貨 | 通常対応 | プロバイダーによる | プロバイダーによる | プロバイダーによる |
| 代理店与信と預り金 | 通常は適さない | 通常は適さない | 通常は適さない | 通常対応 |
- 通常対応
- プロバイダーによる
- 通常は適さない
連携ディレクトリに掲載されたゲートウェイ
これらの名称はライブのすべての連携から取得しています。加盟店アカウントと取引手数料は、選択した決済会社と直接取り決めます。
プロジェクトのスコープ
決済連携のスコープ策定に必要なもの
明確なプロバイダーアカウントと定義された取引ワークフローがあれば、スコープ、テスト、納品を正確に決められます。すでにお持ちのものにチェックを入れてください。
0/5準備済み
スコープチェックリスト
本番移行までの道のり
- 01
サンドボックスキー
プラットフォームをプロバイダーのテスト環境に対して動作させます。
- 02
テストケース
承認、拒否、3D Secure、取消、返金をそれぞれテスト予約で確認します。
- 03
Webhook エンドポイント
署名を検証し、すべてのイベント種別を予約の処理に対応付けます。
- 04
本番キー
本番認証情報を有効化し、失敗した決済を監視します。
チェックアウトを計画する
ゲートウェイの作業は予約プラットフォームと一緒にスコープを決めます。PHPTRAVELS はソースコード付きの買い切りライセンスで 2,499 ドルから、お客様自身のサーバーにホストします。各プランの内容は料金をご覧ください。
旅行予約サイトやポータルを決済プロバイダーに接続し、お客様がチェックアウト時に支払えるようにするとともに、予約システムが各予約のオーソリ、売上確定、返金、決済ステータスを安全に追跡できるようにするものです。
PHPTRAVELS は、連携ディレクトリに掲載されたさまざまなグローバルおよび地域のゲートウェイに対応しています。最適な選択肢は、国、加盟店審査、通貨、決済手段、そしてアカウントで利用できるプロバイダー API によって異なります。
はい。選択したゲートウェイと加盟店アカウントが、必要な表示通貨と決済通貨に対応している場合に可能です。通貨換算、マークアップ、精算ルールはプロジェクトのスコープ策定時に確認します。
プロバイダーが対応し、加盟店アカウントで有効になっている場合に 3D Secure が含まれます。連携では認証結果、リダイレクトまたは埋め込み型チャレンジ、最終的な決済ステータスを処理します。
はい。プロバイダーの API が対応していれば可能です。全額または一部の返金、取消、キャンセル料は、該当する予約番号と取引番号に紐付けられます。
決済会社です。お客様が選択したプロバイダーで加盟店アカウントを開設し、手数料を直接取り決めます。PHPTRAVELS は、お客様から提供された認証情報でプラットフォームをそのアカウントに接続します。