Skip to main content

​
Purpose

This page explains how to implement multicontracting in both the Push model and the Pull model. It also clarifies how RatePlan codes are structured under multicontracting and shows concrete XML examples.

​
Overview

Multicontracting lets you distribute multiple contracts under a single hotel code so that the system can surface the best availability and rates across different contracting models (e.g., integrated vs. manual), and also support simple packages (hotel + other products). This functionality is ready for PROD. Under multicontracting, the RatePlan code is extended from the original 5-character concept to a three-part code: [simple-package-code]-[contract-code]-[rateplan-code] Example: AR-OWN1-S0000 Where AR is a simple package (Accommodation + Car), OWN1 is the contract code, and S0000 is the rateplan code.
Note on RatePlan code details: visit RatePlan codes
RatePlan codes are constructed from the below elements Rate Type(1), Rate Group(1), Rate Refund(1), Rate Sub Type(2) There is also a possibility of duplicating RatePlan which already exists in the contract. In this case the “.” character, and a number starting with 1, and then subsecuently every iteration. Example: BHSP2.1

​
Code Construction

RatePlan codes are constructed from the below elements:
Rate Type (1), Rate Group (1), Rate Refund (1), Rate Sub Type (2)
Rate TypeRate GroupRate RefundRate Sub Type
0Rates0undefined0Undefined00Undefined
RRetail ratesHHotel onlyNNon refundableA0Advanced Purchase
SStatic ratesPPackagingSSemi-flexibleA2Advanced Purchase 2
FFIT RatesOOpaqueFFlexibleA3Advanced Purchase 3
BBAR ratesRRackP0Promotional Rate
P2Promotional Rate 2
P3Promotional Rate 3
P4Promotional Rate 4
P5Promotional Rate 5
P6Promotional Rate 6
P7Promotional Rate 7
P8Promotional Rate 8
P9Promotional Rate 9
01[1]
02[2]
03[3]
04[4]
05[5]
06[6]
07[7]
08[8]
09[9]

​
Rate Type

  • 0 → Not defined – rate stays unchanged like in the basic contract edition.
  • B → Bar - best available rates (changing due to rate updates)
  • S → Static – unchanged contract rate till the time of a promotion or an offer introduction
  • F → FIT - free individual traveller rates
  • R → Retail – advised end-price

​
Rate Group

  • H → Hotel only - rates valid when booking contains only hotel
  • P → Packaging - rates valid when booking contains hotel + another product
  • O → Opaque - hotel rates must not be visible for end consumer
  • R → Rack - walk-in hotel rates for end consumer

​
Rate Refund

  • N → Non refundable - immediately after booking
  • S → Semi-flexible – cancellation without fees up to 12 hours after booking
  • F → Flexible – cancellation without fees up to 24 hours after booking

​
Rate Sub Type

  • A → Advanced Purchase - booking has to be paid before confirming
  • P → Promotion Rate
Functionality logic of Rate Group – 3nd character of rateplan:
  • If there is a character N on the rateplan 3rd position means it’s completely non-refundable OR at the roomtype code on the last position
  • When the character is 0 and IF there is no rateplan NOR N as the last character of the room code, means the room is refundable and conditions will be shared on the Vendor Messages on the AvailRS and ResRS (Quote/Book)
And in Rate Sub Type:
  • A→ Advanced Purchase - booking has to be paid before confirming
  • P→ Promotion rate

​
Pull Model

​
What Changes in Search Results

Search results for the same hotel may include multiple contracts as RatePlans, allowing integrated and manual contracts to compete for best availability and price across seasons/windows. If you need to de‑duplicate or filter multicontracting search results, you can use the following request switches explained in OTA_HotelAvailRQ

​
What to Send / Receive in Realtime

  • Use RoomTypeCode in realtime messages instead of a RatePlan ID.
OTA RS examples (RoomTypeCode variations under multicontracting): 
<!-- Before: single-contract style -->
<RoomType RoomTypeCode="STSD000000;FP000" />

<!-- After: multicontracting examples -->
<RoomType RoomTypeCode="STSD000000;-ABC1-" />                <!-- Contract identified by ABC1 -->
<RoomType RoomTypeCode="STSD000000;AR-ABC1-FP000" />         <!-- Simple package AR + contract ABC1 + rateplan FP000 -->
<RoomType RoomTypeCode="STSD000000;-OWN1-FP000" />            <!-- Manual contract OWN1 + rateplan FP000 -->
<RoomType RoomTypeCode="STSD000000;AR-ABC1-" />               <!-- AR package + contract ABC1 with no specific rateplan code -->

​
Package Examples (Search / Book)

  • Accommodation+Car: AR-OWN1-S0000 (room might be STSD000000-ECMR for car class).
  • Other simple packages supported conceptually: ski (SP1), golf, spa, yoga, cooking classes, etc. (package prefix + contract + rateplan).

​
Implementation Notes

  • For non‑refundable identification, ensure you read the 3rd character from the end of the RatePlan code (due to the extended prefixing), not the 3rd from the start.
  • Clients using pull and push models have no behavioral impact beyond the longer RatePlan codes.

​
Push Model

​
What You Receive

Partners with a multicontracting + rateplan integration receive the relevant information via notification files; the format is equivalent across notification variants.

​
How RatePlans Are Delivered

You can consume RatePlans in notifications in two ways:
  1. Concatenated into the RoomCode, e.g. RMSD000000;OwWN1-P0N00 (no dev to add a new field, but existing room mapping must be updated and any “best price” logic on mapped codes may only surface the cheapest option). Non‑refundable plans may exist in rooms without an N at the 10th position.
  2. Separate attribute via RoomKey / RatePlanID, e.g. RoomCode RMSD000000 and RoomKey P0N00.2. This keeps mapping unchanged, but requires implementing the RoomKey attribute (not available in OTDS).

​
Examples (Separate Code)

OTA 
<RatePlans HotelCode="AESSVQ4GKU">
  <RatePlan RatePlanID="OWN1-P0N00" ...>
    ...
  </RatePlan>
</RatePlans>
<SellableProducts>
  <SellableProduct InvCode="RMSD000000" InvType="ROOM" ... />
</SellableProducts>
EDF / ASNF: 
<!-- EDF (RoomKey + RateCode provided) -->
<Room Code="AP00T10000" RateCode="-SUP1-0P000" RoomKey="-SUP1-0P000" />

<!-- ASNF (RatePlans element) -->
<Room Code="AP00T10000" Name="1 Bedroom Apartment">
  <RatePlans>
    <RatePlan Code="-SUP1-0P000" />
  </RatePlans>
</Room>

​
Packaging Support in Notifications

Simple packages are supported via the simple-package-code prefix. For instance, an Accommodation+Car package uses AR, with the car type appended to the room when applicable (e.g., STSD000000-ECMR).

​
Flatfile Users

If you opted for concatenated codes, the room code field and the rateplan code size are extended in Version 3 of the flatfile definition.

​
At a Glance

Examples tied to a single hotel & room:
  • HotelCode AESPMI1234, RoomCode RMSDDB0000, RateplanCode="-ABC1-0P0A0" → Contract ABC1 with a Packaging Advanced Purchase rateplan from the hotel.
  • HotelCode AESPMI1234, RoomCode RMSDDB0000, RateplanCode="-DEF1-S0N00" → Contract DEF1 with a Static, Non‑Refundable rate.
  • RateplanCode="-OWN1-" → Manual contract with no rateplans in the contract.
  • RateplanCode="AR-OWN1-S0000", RoomCode STSD000000-ECMR → Accommodation + Car package using contract OWN1 and static rates; ECMR denotes an Economy Manual A/C car class.

​
Next Steps

  • INT examples (RQ/RS) and a Postman collection are available for integration tests. Provide feedback on your test cases, complete certification for multicontracting, and then roll out to PROD.

​
Appendix

  • If your distribution excludes Opaque or Packaging rates on hotel‑only websites, re‑check any code parsing logic to account for the prefixed code structure.
  • Test users: TST3 (separate code/RoomKey) and TST4 (concatenated code).