Split Ticketing Search and Book

You are here

AirReqRsp.xsd

Low Fare Shopping (Synchronous)

Split Ticketing Search allows a customer to execute only one search request to get one-way and roundtrip fares aggregated in the response in order to uncover lower fares, saving processing time/cost incurred by multiple shop requests.

• Split Ticketing Search applies to simple roundtrip flight types only (A-B-A), and is not compatible with Flex explore or flex options.

• If the SplitTicketingSearch element is included, Split Ticketing Search will be executed.

• If it's not included, a regular roundtrip search will be executed. The default behavior is not to execute a Split Ticketing Search.

Important:

• Split ticketing search can be sent only in a LowFareSearch request.

• A Travelport Account Manager MUST be contacted to activate Split Ticketing.

Benefits

• Split ticketing search can expose cheaper prices at search when two one-ways are cheaper than the round trip.

• Split ticketing search lets you make one shopping call versus three calls (one for round trip and one each for the one-ways).

• Split ticketing search provides the potential of tuning diversity, sensitivity, and markets around when to return the one-ways (via Search Control Console and/or Universal API).

• Split ticketing search provides savings on look to book.

Initial analysis of Split Ticketing Search results indicate: 

• Lowest one-way splits beat lowest roundtrip 21% of the time.

• Lowest priced inbound or outbound in a one-way combination is cheaper than the corresponding roundtrip with the same inbound or outbound 39% of the time.

• On the same airline, when matching the one-ways to the round trip combination, Split Ticketing Search identifies a lower fare 14.8% of the time.

• Response time when comparing the same input parameters (time and origin/destination) across Split Ticketing Search versus three separate requests yields a comparable LowFareSearch response time (no response time impact as compared to a roundtrip).

Each split follows Travelport's normal search diversity path:

• Configured number of cheapest price points

• Online directs

• Online connections

• Interlines

• Unique content

Restrictions

• Applies to Galileo, Apollo, and Worldspan only.

• Only simple round trips are returned.

• Price points must be specified in the request (@SolutionResult="false", which is also the default).

• API-connected carriers through the Airline Content Hub are not returned in the response.

• Flex Options or Flex Explore cannot be requested.

• Compatible with both Branded Fares and ePricing META. However, you cannot combine with both Branded Fares and ePricing META.

• The customer is responsible for handling booking, ticketing, and correlation.

Schema

Split Ticketing Search requires Low Fare Shopping v38.0 or greater:

• LowFareSearchReq
• LowFareSearchRsp

How To

Note: Split booking is not supported in a book-on-book scenario:

• In a book-on-book scenario for split ticketing, the request will fail with the error message, "Split Booking is not enabled for book on book scenarios."

• You must use the split ticketing function on new PNRs only.

1. Enter the minimum required data for LowFareSearchReq:

   • Information to identify the requestor, sent in BillingPointOfSaleInfo @OriginApplication.

   • Elements in SearchAirLeg for a simple roundtrip: origin, destination, and travel dates.

   • A Passenger Type Code (PTC), sent in SearchPassenger @Code.

2. Price Points must be specified (LowFareSearchReq @SolutionResult="false").

3. Include LowFareSearchReq/SplitTicketingSearch, which indicates that both one-ways and round trips should be returned in a single search response.

4. Optionally, specify LowFareSearchReq/SplitTicketingSearch @RoundTrip to indicate the percentage of round trip price points to be returned in the response.

   Notes on @RoundTrip

   The RoundTrip attribute specifies the percentage (%) pricepoint mix between roundtrip (R/T) and one-way fares (O/Ws). This interacts with MaxSolutions and the customer's Tier level.

   • The number of pricepoints the customer is provisioned for will be applied to each of the oneways and roundtrip as default, if MaxSolutions is not specified, so that customers can receive a similar amount of data as if they did a separate search for each of the outbound, inbound, and roundtrip.

     • In that way, the Tier level is essentially multiplied by three (3) for Split Ticketing transactions.

     • If customers specify a MaxSolutions value, truncation will occur if the MaxSolutions value is greater than three (3) times the Tier level.

     • Similarly, truncation will also occur if the MaxSolutions value is less than the Tier level for each of the outbound, inbound, and roundtrip data chunks.

     • Travelport is putting in place logic internally where we can adjust the multiplier at the Travelport level (currently set at three), and we may tune it based on feedback from the Alpha.

   For example, if the customer is a Galileo (1G) Tier 2 shopping customer (eligible for 50 pricepoints) and does not specify any MaxSolutions value or any Roundtrip percent (%) value (in the simplest use case), up to 50 pricepoints will be returned for the outbound, up to 50 pricepoints will be returned for the inbound, and up to 50 pricepoints would be returned (up to 150 total).

   • If availability or fares aren't available, less than 50 may be returned for each chunk.

   • If the Roundtrip attribute is set and no MaxSolutions value is set, the total number of eligible pricepoints (150) would be distributed between the Outbound/Inbound/Roundtrip results as dictated by the Roundtrip percent.

   • To continue the example, if Roundtrip=”80” (80%), 120 pricepoints are returned for the Roundtrip results, and each of the one-ways will return 15 results.

     • If then a MaxSolutions value is also sent in with a Roundtrip percent value, further truncation per chunk will occur.

     • If MaxSolutions="100" and Roundtrip="80", then truncation will occur and result in 80 roundtrip pricepoints, 10 outbound pricepoints, 10 inbound pricepoints.

     • If MaxSolutions="200" (or is greater than a setting we configure internally that is today three (3) times the number a customer is eligible for by Tier level) and Roundtrip="80", then truncation will occur and result in 120 roundtrip pricepoints, 15 outbound pricepoints, 15 inbound.

     • This use case is therefore the same as NOT sending in a MaxSolutions value.

     Note: If there is a shortfall between any of the result sets (fewer results returned than requested), Travelport will try to fill the shortfall with results from an overage from one of the other sets. For example, If there are too many roundtrip results and not enough outbound results, we will return more of the roundtrip results to fill the shortfall.

   Thus, for @RoundTrip

   • This value should be an even number.

   • The remaining one-way price points returned are evenly divided between outbound and inbound results.

   Code Sample

   The following Split Ticketing Search request does not specify the optional RoundTrip percentage.

   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

     <soap:Body>

       <air:LowFareSearchReq TargetBranch="123" TraceId="123" AuthorizedBy="Testing" xmlns:air="http://www.travelport.com/schema/air_v38_0" xmlns:com="http://www.travelport.com/schema/common_v38_0">

         <com:BillingPointOfSaleInfo OriginApplication="UAPI"/>

         <air:SearchAirLeg>

           <air:SearchOrigin>

             <com:CityOrAirport Code="ORD"/>

           </air:SearchOrigin>

           <air:SearchDestination>

             <com:CityOrAirport Code="SEA"/>

           </air:SearchDestination>

           <air:SearchDepTime PreferredTime="2020-03-20"/>

         </air:SearchAirLeg>

         <air:SearchAirLeg>

           <air:SearchOrigin>

             <com:CityOrAirport Code="SEA"/>

           </air:SearchOrigin>

           <air:SearchDestination>

             <com:CityOrAirport Code="ORD"/>

           </air:SearchDestination>

           <air:SearchDepTime PreferredTime="2020-03-30"/>

         </air:SearchAirLeg>

         <air:AirSearchModifiers>

           <air:PreferredProviders>

             <com:Provider Code="XX"/>

           </air:PreferredProviders>

         </air:AirSearchModifiers>

        <air:SplitTicketingSearch/>

         <com:SearchPassenger Code="ADT"/>

       </air:LowFareSearchReq>

     </soap:Body>

   </soap:Envelope>

5. Optionally, specify other LowFareSearchReq details. Flex Options or Flex Explore cannot be requested.

6. Price the split ticketing by sending AirPriceReq with @SplitPricing="true" and two different group of segments in AirSegment @Group. Release 18.1

• With Air v44.0 and later, Split Pricing is only presented with a simple round trip from a Split Search response. For example: DEN to MIA

• Split Pricing returns separate pricing solutions for different groups of segments in a pricing response when SplitPricing="true" is sent in AirPriceRequest.

• With SplitPricing, when the provider returns a successful response for all segments in a price request, Universal API forms one AirPriceResponse and returns separate AirPricingSolutions for different segment groups. Conversely, with a normal price request, Universal API forms one AirPriceResponse and returns the AirPricingInfo of different group of segments into a single AirPricingSolution.

• For example, if customer sends in a split pricing requestwith two segments for a round trip, the split pricing flow operates as follows:

  • Price Request:

    • AirSegment 1 with AirSegment@Group = 0 – DEN to DAL

    • AirSegment 2 with AirSegment@Group = 0 – DAL to MIA

    • AirSegment 3 with AirSegment@Group = 1 – MIA to DEN

  • Price Response:

    • AirPricingSolution with AirPricingInfo for AirSegment 1 and AirSegment 2

    • Upsell AirPricingSolution with AirPricingInfo for AirSegment 1 and AirSegment 2

    • AirPricingSolution with AirPricingInfo for AirSegment 3

    • Upsell AirPricingSolution with AirPricingInfo for AirSegment 3

7. The pricing solutions are ordered by Segment Groups first and then in the increasing order of price inside each set of pricing solutions.

8. To initiate a split booking, send two AirPricingSolution elements in one AirCreateReservationReq. @ProviderCode in each AirPricingSolution/AirSegment must match.

   A split booking allows you to book a round trip by submitting two separate pricing solutions in one reservation request. If you are not provisioned for split booking, submit two separate AirCreateReservation requests, one for the outbound itinerary and the other for the inbound itinerary.

   Note: @SplitReservation defaults to false. When set to ‘true’ this process creates one PNR. If there is more than one airline, it will create multiple Supplier Locator codes.

   Split Bookings for Roundtrip Tickets

   In Air v47.0 Release 19.0, Universal API supports the ability to search for and create split bookings for roundtrip tickets. Universal API supports split bookings for provisioned customers. If you are interested in this functionality, please contact your Travelport representative.

   For a split booking search a request is submitted via AirCreateReservationReq with two (and only two) AirPricingSolutions.

   • The first AirPricingSolution contains pricing details about outbound segments.
   • The second AirPricingSolutions contains pricing details about inbound segments.

   After submitting an AirCreateReservationReq with 2 AirPricingSolutions, a split booking validation process occurs.

   A split booking allows you to book a roundtrip ticket by submitting two separate pricing solutions in one reservation request. Prior to this release, you had to submit two separate booking requests, one for the outbound itinerary and the other for the inbound itinerary. You can then ticket the two segments separately under the same PNR.

   If you are provisioned for split booking, send two AirPricingSolution elements in AirCreateReservationReq to specify that a split booking should be made. @ProviderCode in each AirPricingSolution/AirSegment must match.

   The response returns one provider PNR. Each AirPricingSolution must be ticketed separately with the airlines.

9. One provider locator code is returned in a successful response. If any segment failed to book, the entire booking is canceled.

   • If multiple providers exist in the request, an error is returned: Multiple Provider bookings are not supported currently. Use book on book.

10. Use an AirTicketing request to ticket the booking.