航空券 API 連携
検索から e チケットまでの TBO 航空券 API 連携
TBO アカウントを PHPTRAVELS のフライトモジュールに接続し、自社サイトとエージェントポータルで TBO の航空運賃を販売できます。すべての運賃は支払い前に再確認され、すべての呼び出しにトレース ID が付き、日々の航空券販売を安定させるログ、リトライ規則、予約管理ツールがチームに用意されます。
- TBO のリアルタイム運賃
- 支払い前の価格再確認
- すべての呼び出しにトレース ID
- B2C 決済と B2B ポータル
販売するもの
自社の予約エンジンの中で完結する TBO 航空券 API 連携
TBO は B2B の旅行流通会社で、その航空 API は旅行会社が再販できる航空運賃を返します。PHPTRAVELS のフライトモジュールはお客様自身の TBO 認証情報でこれを呼び出し、検索結果に運賃を表示し、運賃規則、価格再確認、旅客情報、支払い、予約、発券まで予約全体を処理します。
すべての運賃が同じ動きをするわけではありません。運賃によっては（多くは LCC）予約と発券が一度に行われ、別の運賃は予約として保留し後で発券できます。モジュールはこの違いをチームに見える形で示すため、正しい次の手順なしに運賃が請求されることはありません。
- LCC06:10 – 08:253h 45m · 直行便₹18,450選択
- FSC09:40 – 11:503h 40m · 直行便₹21,980選択
- FSC21:15 – 23:353h 50m · 直行便₹26,300選択
サンプル運賃です。各結果に仕入先タグが残るので、サポートは常に出どころを把握できます。
呼び出しの流れ
検索から発券までの 6 つの呼び出し
ステップを選ぶと、TBO から何が返り、PHPTRAVELS がそれをどう扱い、そこで何が起きやすいかを確認できます。
検索
- 返ってくるもの
- 路線、日付、クラス、旅客構成ごとの運賃。それぞれに後続の呼び出しで使う結果トークンが付きます。
- PHPTRAVELS の処理
- 結果を統一形式に整え、マークアップを適用し、検索をキャッシュし、航空会社・経由・手荷物・出発時刻のフィルターを加えます。
- 起こりうる問題
- キャッシュ運賃を長く表示しすぎること。キャッシュは短く、後続のすべてのステップで再確認します。
運賃規則
- 返ってくるもの
- 選択した運賃の変更・取消条件、手荷物許容量、運賃の注記。
- PHPTRAVELS の処理
- 規則を運賃カードと支払い前の両方で表示し、仕入先が構造化データを返す場合は分かりやすい言葉で示します。
- 起こりうる問題
- 内容を理解しないまま運賃を購入し、後から運賃が認めない払い戻しを求められること。
価格再確認
- 返ってくるもの
- お客様が選んだ運賃の現在の価格と空席状況。
- PHPTRAVELS の処理
- 表示価格と比較します。同じなら続行、上がっていればお客様に確認を求め、なくなっていれば検索結果に戻します。
- 起こりうる問題
- 変わった運賃に古い価格を請求し、紛争や手作業の返金につながること。
オプション
- 返ってくるもの
- 航空会社と運賃が提供する座席、機内食、追加手荷物。
- PHPTRAVELS の処理
- 選択肢を価格付きで表示し、支払い前に予約合計に加えます。
- 起こりうる問題
- 運賃が対応しないオプションを販売すること。返された選択肢だけを提示します。
予約
- 返ってくるもの
- 予約番号、または座席や価格がなくなった場合の失敗理由。
- PHPTRAVELS の処理
- トレース ID、旅客データ、支払い記録とともに予約を保存し、予約タイムラインを開始します。
- 起こりうる問題
- 支払い後のタイムアウト。モジュールは 2 回目の予約を送る前に必ず予約状況を照会します。
発券
- 返ってくるもの
- 航空会社が発行した各旅客の e チケット番号。
- PHPTRAVELS の処理
- チケット番号を保存し、旅程をメールで送り、変更・取消・払い戻しのために予約を開きます。
- 起こりうる問題
- 保留予約が期限切れまで未発券のまま残ること。保留予約にはチームが確認できる期限が付きます。
価格再確認
誰かが支払う前に運賃をもう一度確認
失敗する航空券予約の多くは、検索と支払いの間に変わった価格から始まります。決済が扱う 3 つの結果を試してください。
決済のルール
- 01支払いを受ける前に、すべての運賃を TBO で再確認します。
- 02支払いはトレースごとに 1 回だけ。リトライで再請求はしません。
- 03支払いステップで運賃規則と手荷物を再表示します。
- 04運賃がなくなっても、検索条件と旅客情報は保持されます。
決済フロー：決済ゲートウェイエージェントウォレット
- 検索時の価格
- ₹18,450
- 再確認時の価格
- ₹18,450
- 差額
- ₹0
お客様が見た価格のまま支払いに進みます。
- 検索時の価格
- ₹18,450
- 再確認時の価格
- ₹19,120
- 差額
- ₹+670
お客様は新しい価格を確認し、支払い前に承認します。承認するまで何も請求されません。
- 検索時の価格
- ₹18,450
- 再確認時の価格
- 販売終了
- 差額
- —
同じ検索条件と入力済みの旅客情報で、最新の検索結果に戻ります。
大人 1 名の例示金額です。
運用
1 つのトレース ID がすべての呼び出しで予約を追跡
対応が必要な予約があれば、サポートはそのトレースを開いて起きたことを順に確認できます。開発者にサーバーログを探してもらう必要はありません。
trace TBO-FL-7Q2K9 --route DEL-DXB --pax ADT1
- 10:02:11INFOsearchこの検索の結果をキャッシュ
- 10:03:40INFOrules選択運賃に運賃規則と手荷物を付加
- 10:05:02WARNrecheck価格変更、新運賃の確認をお客様に依頼
- 10:05:31OKrecheckお客様が新運賃を承認
- 10:06:12INFOpayこのトレースで支払いを 1 回だけ確定
- 10:06:19WARNbook仕入先タイムアウト、2 回目の予約ではなく状況照会を送信
- 10:06:27OKstatus状況照会で予約確定、予約番号を保存
- 10:06:40OKtickete チケット番号を保存、旅程をメール送信
トレースの例：価格が変わり、お客様が承認し、予約呼び出しがタイムアウトし、状況照会で二重予約なしに予約が確定しました。
リクエストログとトレース ID
検索、再確認、予約、発券の各呼び出しを 1 つの参照番号で記録し、問題をすばやく切り分けます。
テスト路線ライブラリ
変更のたびに実行する、路線・日付・クラス・旅客構成の固定セット。
タイムアウトとリトライの方針
短いネットワーク障害から復旧しつつ、二重予約のリスクを避けます。
障害急増アラート
エラー率が上がると、売上に影響が出る前にチームへ通知します。
公開までの計画
TBO の運賃を販売するまでの 5 ステップ
運用上の要件に気づくのが遅いと、チームは何週間も失います。この計画はそれを最初に置きます。
- 01
アクセスと認証情報
TBO アカウントを開設し、航空 API へのアクセスを申請してテスト用認証情報を受け取ります。
- 02
接続と検証
管理画面に認証情報を登録し、タイムアウトを設定してテスト路線ライブラリを実行します。
- 03
検索と価格の管理
マークアップ、通貨、フィルターを設定し、再確認後の価格が決済と一致することを確かめます。
- 04
予約と確定
旅客情報、支払い、予約、発券、旅程メールを通しでテストします。
- 05
運用と拡大
本番用認証情報に切り替え、アラートとサポート手順を整えてからトラフィックを開放します。
テスト路線ライブラリ
| 路線 | 旅程 | 旅客 | クラス | 確認できること |
|---|---|---|---|---|
| DEL → BOM | OW | 1 ADT | Y | 基本的な国内運賃と即時発券 |
| BOM → DXB | RT | 2 ADT · 1 CHD | Y | 小児運賃と往復の組み合わせ |
| DEL → LHR | RT | 1 ADT · 1 INF | Y | 幼児運賃とパスポート項目 |
| BLR → SIN | OW | 1 ADT | C | ビジネスクラス運賃とその規則 |
| HYD → JED | OW | 2 ADT | Y | 長距離区間の手荷物規則 |
実際に販売する路線を使ってください。これは例です。
必要なときの導入支援
- キックオフと範囲路線、市場、価格ルール、業務フローの要件。
- 実装と QA検索、再確認、予約成功のテスト。
- 公開時のサポート監視の手順書とサポートチームへの引き継ぎ。
選択肢
TBO の航空券を販売する方法の比較
どの方法でも実現できます。違いは、自社でどこまで構築し運用するかです。
| 選択肢 | 公開までの期間 | 継続的な作業量 | 向いているケース |
|---|---|---|---|
| TBO API で直接開発 | 公開までの期間中〜長期：UI、価格設定、再確認、ログ、サポートツールを自社で構築 | 継続的な作業量高い | 向いているケース社内に開発と運用の体制がある大規模チーム |
| GDS 接続 | 公開までの期間長期：より深い契約手続きと実装 | 継続的な作業量高い | 向いているケース複雑な航空コンテンツが必要な場合 |
| 別のアグリゲーター API | 公開までの期間中期：早く始められるが、予約後の業務は自社に残る | 継続的な作業量中程度 | 向いているケース素早い最初のバージョン |
| PHPTRAVELS と TBOすぐに使える | 公開までの期間より短期：予約フローと管理ツールがすでにある | 継続的な作業量低〜中程度 | 向いているケースOTA、旅行会社、ツアーオペレーター、DMC |
PHPTRAVELS は買い切りのライセンスで、商用ライセンスのもとソースコードが付属し、自社サーバーにインストールします。TBO との契約と認証情報はお客様のものです。
TBO アカウントに航空 API へのアクセスがあることを確認し、テスト用認証情報を取得します。次にフライトモジュールに登録し、実際の路線と日付の小さなライブラリで検索、再確認、予約、取消を一通り通してから、顧客体験を磨き込みます。
検索から支払いまでの価格変動、お客様が見ていなかった運賃規則の制限、確定時のタイムアウトです。モジュールは支払い前にすべての運賃を再確認し、各ステップを 1 つのトレース ID で記録し、タイムアウト後は再予約ではなく予約状況を照会します。
はい。1 つの予約エンジンで両方に対応します。顧客は公開の決済画面を使い、エージェントはエージェントポータルで独自の価格、マークアップ、レポートを利用できます。
いいえ。多くのチームは CRM や会計ツールをそのまま使い、API と webhook で予約エンジンと連携しています。オフィスの業務を変えずに航空券販売を追加できます。
TBO のホテルは宿泊モジュールの別コネクターを使います。契約で認められていれば、同じ TBO アカウント情報で航空券、ホテル、またはその両方を有効にできます。
はい。ホテル、ツアー、レンタカー、送迎を後から追加でき、顧客アカウント、決済、レポートはそれぞれ 1 つのまま保てます。