항공 API 연동

검색부터 전자항공권까지 TBO 항공 API 연동

TBO 계정을 PHPTRAVELS 항공 모듈에 연결하고 웹사이트와 에이전트 포털에서 TBO 항공 운임을 판매하세요. 모든 운임은 결제 전에 다시 확인되고, 모든 호출에는 추적 ID가 붙으며, 팀은 매일의 항공권 판매를 안정적으로 유지하는 로그, 재시도 규칙, 예약 관리 도구를 갖게 됩니다.

실시간 TBO 항공 운임
결제 전 가격 재확인
모든 호출에 추적 ID
B2C 결제와 B2B 포털

판매하는 것

자체 예약 엔진 안에서 완성하는 TBO 항공 API 연동

TBO는 B2B 여행 유통사로, 항공 API를 통해 여행사가 재판매할 수 있는 항공 운임을 제공합니다. PHPTRAVELS 항공 모듈은 고객사의 TBO 인증 정보로 이 API를 호출하고, 검색 결과에 운임을 보여 주며, 운임 규정, 가격 재확인, 승객 정보, 결제, 예약, 발권까지 예약 전 과정을 처리합니다.

모든 운임이 같은 방식으로 동작하지는 않습니다. 운임에 따라 일부(주로 저비용 항공사)는 한 번에 예약과 발권이 이뤄지고, 다른 운임은 예약으로 보류한 뒤 나중에 발권할 수 있습니다. 모듈은 이 차이를 팀이 볼 수 있게 표시해, 올바른 다음 단계 없이 결제되는 운임이 없도록 합니다.

기반항공 항공권 예약 소프트웨어 여행 API

DEL → DXB · 2026-11-14성인 1명 · 일반석

LCC06:10 – 08:253h 45m · 직항TBO저비용예약 시 발권기내 수하물만환불 불가₹18,450선택
FSC09:40 – 11:503h 40m · 직항TBO보류 가능위탁 수하물 포함환불 불가₹21,980선택
FSC21:15 – 23:353h 50m · 직항TBO보류 가능위탁 수하물 포함환불 가능₹26,300선택

예시 운임입니다. 각 결과에 공급사 태그가 남아 있어 지원팀이 항상 출처를 알 수 있습니다.

호출 흐름

검색과 발권 사이의 여섯 번의 호출

단계를 선택하면 TBO가 무엇을 돌려주는지, PHPTRAVELS가 그것으로 무엇을 하는지, 그 단계에서 흔히 무엇이 잘못되는지 볼 수 있습니다.

검색

돌아오는 것: 노선, 날짜, 좌석 등급, 승객 구성별 운임과 각 운임에 붙은 후속 호출용 결과 토큰.
PHPTRAVELS가 하는 일: 결과를 표준화하고, 마크업을 적용하고, 검색을 캐시하며, 항공사·경유·수하물·출발 시간 필터를 추가합니다.
잘못될 수 있는 것: 캐시된 운임을 너무 오래 보여 주는 것. 캐시는 짧고 이후 모든 단계에서 다시 확인합니다.

운임 규정

돌아오는 것: 선택한 운임의 변경·취소 조건, 수하물 허용량, 운임 참고 사항.
PHPTRAVELS가 하는 일: 운임 카드와 결제 직전에 규정을 다시 보여 주며, 공급사가 구조화된 데이터를 주면 쉬운 말로 표시합니다.
잘못될 수 있는 것: 고객이 이해하지 못한 운임을 산 뒤 운임이 허용하지 않는 환불을 요구하는 것.

가격 재확인

돌아오는 것: 고객이 선택한 운임의 현재 가격과 좌석 여부.
PHPTRAVELS가 하는 일: 표시된 가격과 비교합니다. 같으면 진행하고, 올랐으면 고객에게 확인을 요청하며, 사라졌으면 검색 결과로 돌려보냅니다.
잘못될 수 있는 것: 바뀐 운임에 예전 가격을 청구해 분쟁과 수동 환불이 생기는 것.

부가 서비스

돌아오는 것: 항공사와 운임이 제공하는 좌석, 기내식, 추가 수하물.
PHPTRAVELS가 하는 일: 선택지를 가격과 함께 보여 주고 결제 전에 예약 총액에 더합니다.
잘못될 수 있는 것: 운임이 지원하지 않는 부가 서비스를 판매하는 것. 반환된 선택지만 제공합니다.

예약

돌아오는 것: 예약 번호, 또는 좌석이나 가격이 더 이상 없을 때의 실패 사유.
PHPTRAVELS가 하는 일: 추적 ID, 승객 데이터, 결제 기록과 함께 예약을 저장하고 예약 타임라인을 시작합니다.
잘못될 수 있는 것: 결제 후 시간 초과. 모듈은 두 번째 예약을 보내기 전에 반드시 예약 상태를 조회합니다.

발권

돌아오는 것: 항공사가 발행한 승객별 전자항공권 번호.
PHPTRAVELS가 하는 일: 항공권 번호를 저장하고, 여정을 이메일로 보내며, 변경·취소·환불을 위해 예약을 엽니다.
잘못될 수 있는 것: 보류된 예약이 만료될 때까지 발권되지 않는 것. 보류 예약에는 팀이 볼 수 있는 기한이 붙습니다.

가격 재확인

누군가 결제하기 전에 운임을 다시 확인합니다

실패하는 항공 예약의 대부분은 검색과 결제 사이에 바뀐 가격에서 시작됩니다. 결제 단계가 처리하는 세 가지 결과를 직접 확인해 보세요.

결제 규칙

01결제를 받기 전에 모든 운임을 TBO에서 다시 확인합니다.
02결제는 추적당 한 번만 승인되며, 재시도 시 다시 청구하지 않습니다.
03결제 단계에서 운임 규정과 수하물을 다시 보여 줍니다.
04운임이 사라져도 검색 조건과 승객 정보는 유지됩니다.

결제 흐름:결제 게이트웨이 에이전트 지갑

운임 재확인DEL → DXB · LCC

검색 시 가격: ₹18,450
재확인 시 가격: ₹18,450
차액: ₹0

고객이 본 가격 그대로 결제가 진행됩니다.

검색 시 가격: ₹18,450
재확인 시 가격: ₹19,120
차액: ₹+670

고객이 새 가격을 보고 결제 전에 확인합니다. 확인하기 전까지는 아무것도 청구되지 않습니다.

검색 시 가격: ₹18,450
재확인 시 가격: 판매 불가
차액: —

고객은 같은 검색 조건과 이미 입력된 승객 정보로 새 검색 결과로 돌아갑니다.

성인 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이 추적에 대해 결제를 한 번 승인함
10:06:19WARNbook공급사 시간 초과, 두 번째 예약 대신 상태 조회 전송
10:06:27OKstatus상태 조회로 예약 확인, 예약 번호 저장
10:06:40OKticket전자항공권 번호 저장, 여정 이메일 발송

추적 예시: 가격이 바뀌었고, 고객이 수락했으며, 예약 호출이 시간 초과되었고, 상태 조회로 이중 예약 없이 예약이 확인되었습니다.

요청 로그와 추적 ID
검색, 재확인, 예약, 발권 호출을 하나의 참조 번호로 기록해 문제를 빠르게 좁힐 수 있습니다.
테스트 노선 라이브러리
변경할 때마다 실행하는 노선, 날짜, 좌석 등급, 승객 구성의 고정 세트.
시간 초과와 재시도 정책
짧은 네트워크 장애에서 복구하면서도 이중 예약 위험은 피합니다.
장애 급증 알림
오류율이 오르면 매출에 영향이 가기 전에 팀에 알립니다.

오픈 계획

TBO 운임 판매까지 다섯 단계

운영 요건을 늦게 발견하면 팀은 몇 주를 잃습니다. 이 계획은 그것을 맨 앞에 둡니다.

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