중요한 네 가지 기능
섹션 제목: “중요한 네 가지 기능”| 기능 | 의미 | 이 기능 없으면 제품이 멈추는 이유 |
|---|---|---|
| 실시간 요금 및 가용성 | 날짜별로 실제 예약 가능한 현재 가격과 상태 | 캐시된 요금은 확인 시 실패하고 신뢰를 떨어뜨림 |
| 예약 생성 | 호텔이 받는 실제 예약 생성 | 없으면 제품이 아닌 추천 링크에 불과 |
| 결제 | 예약 과정에서 결제 처리 | 다른 사이트로 넘기면 전환율이 떨어짐 |
| 확인 및 웹훅 | 고객, 호텔, 시스템에 예약 완료 알림 | 그렇지 않으면 지원 부하와 정산 문제 발생 |
대부분의 개발자가 찾는 “호텔 API”는 첫 번째와 때로는 두 번째 기능만 제공합니다. 거래는 가장 어려운 부분이며, 제품 여부를 결정하는 핵심입니다.
누구의 공급을 통합하나요?
섹션 제목: “누구의 공급을 통합하나요?”이 질문이 이후 모든 것을 결정합니다. 체인을 통해 재판매되는 공급은 요금에 마진이 포함되고, 가용성이 오래되며, 예약 문의를 호텔에 직접 할 수 없습니다. 호텔에서 직접 제공되는 공급은 호텔 자체 요금, 실시간 가용성, 그리고 예약이 존재함을 아는 호텔을 포함합니다.
여행자가 호텔 공식 웹사이트와 비교할 가능성이 있는 모든 경우 — 대부분의 경우 — 호텔이 직접 관리하는 공급이 가격이 더 나쁠 때의 난처한 상황을 피할 수 있습니다.
누가 상인인가
섹션 제목: “누가 상인인가”직접 호텔 예약을 구축하면 상인이 된다는 것은 결제 책임, 청구 취소, 환불, 세금 처리, 그리고 종종 각 시장에서 여행사 라이선스를 취득해야 함을 의미합니다.
Wink에서는 호텔이 상인으로 남아 결제가 호텔을 위해 수집되므로 통합자가 그 책임을 지지 않습니다. 상인 계약은 파트너가 실제로 결제를 직접 받아야 하는 API 통합에 제공되며, 해당 경로는 별도의 라이선스 요구사항이 있습니다.
세 가지 통합 수준
섹션 제목: “세 가지 통합 수준”- 웹 컴포넌트. 예약 가능한 검색, 객실 목록 또는 체크아웃을 기존 페이지에 삽입. 백엔드 작업 불필요; 레이아웃 제어는 가장 적음.
- REST API. 검색, 요금, 예약 생성 및 확인을 완전 제어, OAuth2 인증. 예약 흐름이 제품 자체 경험의 일부일 때 사용.
- MCP 서버. AI 에이전트에 동일한 기능 제공, 어시스턴트가 사용자 대신 예약을 검색, 가격 책정 및 완료 가능.
세 가지는 상호 배타적이지 않으며, 제품은 마케팅 표면에 컴포넌트를, 핵심 흐름에 API를 사용하는 경우가 많습니다.
무엇을 먼저 구축해야 하나요
섹션 제목: “무엇을 먼저 구축해야 하나요”- 한 도시와 한 날짜 범위에 대한 검색 및 가격 책정. 실제 요금이 흐르도록 먼저 구축하세요.
- 결제 및 확인을 포함한 테스트 예약을 한 건 끝까지 생성.
- UI를 구축하기 전에
booking.create및 취소 이벤트 구독. - 초기부터 귀속 모델 결정 — 예약과 함께 출처 컨텍스트가 전달되어야 하며, 그렇지 않으면 나중에 보고가 추측이 됨.
- 실패 사례 처리: 견적과 예약 사이 가용성 상실, 결제 거절, 부분 환불 등.
개발자가 알아야 할 가격 정책
섹션 제목: “개발자가 알아야 할 가격 정책”Consumer 및 Booking Engine API는 무료입니다. Partner API는 월 10,000 호텔-박 무료 할당량이 포함되며, 이후 단위별 과금됩니다. 확정된 예약에는 호텔의 1.5% 플랫폼 수수료와 카드 처리 비용이 부과되며, 10% 기본 수수료가 제품이 예약을 유도한 경우 적용됩니다 — 이것이 통합자가 비용을 지불하는 대신 수익을 얻는 방식입니다.
흔한 실수
섹션 제목: “흔한 실수”- 캐시된 요금으로 구축하기. 개발 시에는 괜찮아 보이나 운영에서는 실패함.
- 결제를 리디렉션에 맡기기. 모든 전환에서 예약이 손실됨.
- 출시 전까지 웹훅 무시하기. 정산이 수작업이 됨.
- 필요 없이 상인이 되기. 라이선스와 책임 문제이며 단순 기술 문제가 아님.
- 출처 컨텍스트 전달하지 않기. 귀속을 나중에 재구성할 수 없음.