Skip Navigation

Digital Connect 22.07 Release Notes

Release Identification

Release Version Type (Version, Update, or Patch) Date Approved by Description of Change
22.07 Version July 2022

 

 Software updated

Enhancements

Digital Connect introduces the following enhancements:

  • Apple Pay support (DC APIs)
  • Support for consumed status for EMD-S (DC APIs and DC Core)
  • Ancillary IQ - seat price override (DC APIs and DC Core)
  • Authorization failure notification enhancement (DC APIs and DC Core)
  • Paid and free seat booking enhancement (DC APIs)
  • Booking class verification to avoid fraud (DC Core)
  • Modification of SSR DOCO – Redress/Known Traveler Number and Visa Info (DC Core)
  • Overbook Branded Fare class (DC Core)
  • Cancellation fee configuration (DC Core)
  • DRW Backward Compatibility - PNR Migration (DC Core)
  • Post-booking flows – Seats (DC Core)
  • Middle name reuse for passenger enhancement (DC Core)
  • Refund to Travel Bank without login (DC Core)

Defect fixes

Digital Connect introduces the following defect fixes as part of this release:

  • Duplicate ticket issue

Enhancements

Apple Pay support (DC APIs)

Digital Connect introduces changes to the /purchase service that enable airlines to offer Apple Pay as a payment option to their customers. Apple Pay is a way that a customer can store their credit cards with Apple in a way that syncs between Apple products such as the iPhone, iPad, or Mac. Apple Pay uses a ‘Wallet’ which is a place where the customer’s card data is securely stored and can be used on-demand with different merchants or providers.
There are two ways Apple Pay can be used:

  1. The airline obtains the Apple Pay token and decrypts it to get the card details – card number, CAVV and ECI. The authentication data is then populated in the Payment Request with the card number to Sabre PWS for authorization.

Sample request:

AuthRemarks1="AUTH-VISA/VI0585/20MAY*APAY/01711463728851422104" AuthRemarks2="  AUTH-APV/X12543/00/BHD58.000" PaymentRef="01711463728851422104">
<CSC_Result CSC_ResultCode="M" CSC_Remarks="  AUTH-3DS CSC MATCHED/M"/>
<AVS_Result AVS_ResultCode="Y" AVS_Remarks="  AUTH-3DS AVS SUCCESS-Y/ADDRESS AND ZIP/POSTAL MATCH/Y"/>

The response is similar to what DC utilizes today, with the first remark showing APAY, used to indicate Apple Pay. In the case of approval, DC will use the approval code and the card number from the ticketing command.

  1. The airline obtains the Apple Pay token and passes it via DC to the Payment Request. PWS decrypts the blob to obtain the card number and authentication data and sends the authorization request to the vendor with the authenticated data.

Sample request

<PaymentCard CardCode="VI" ApplePayInd="true">
<ApplePayCryptogram>
{
    "version":"EC_v1",
              "data":"sampledata",
    "signature":"samplesignature",
    "header":{
              "ephemeralPublicKey":"samplekey",
        "publicKeyHash":" samplekey ",
        "transactionId":"sampleid"
    }
}
</ApplePayCryptogram>

Sample response

AuthRemarks1="AUTH-VISA/VI0585/20MAY*APAY/01711463728851422104" AuthRemarks2="  AUTH-APV/X12543/00/BHD58.000" PaymentRef="01711463728851422104">

<CSC_Result CSC_ResultCode="M" CSC_Remarks="  AUTH-3DS CSC MATCHED/M"/>
<AVS_Result AVS_ResultCode="Y" AVS_Remarks="  AUTH-3DS AVS SUCCESS-Y/ADDRESS AND ZIP/POSTAL MATCH/Y"/>       
<LocalCardDetail CardCode="VI" CardNumber="400137######0585" ExpireDate="######" Description="Visa"/>

Response to the above request will include the “pseudo” card number. DC will use this pseudo card number and approval code in the ticketing command. The first remark will have the APAY identifier to indicate Apple Pay.

This enhancement applies to B2C Shop & Book and B2C Book Now Pay Later flows.

Prerequisites

None.

Limitations

None.

Support for consumed status for EMD-S (DC APIs and DC Core)

Digital Connect improves the handling of standalone Electronic Miscellaneous Documents (EMD-S) to prevent revenue loss for the airlines. Before the change, EMD-S remained in “OK” status irrespective of the ancillary filing. After the change, the indicator will be set to “USED” status based on the ancillary filing.

There is no new configuration introduced and the enhancement does not require contract changes in Digital Connect.

This enhancement applies to the following flows:

  • B2C (DC APIs)
  • B2C:BNPL (DC APIs)
  • B2C:RBE (DC Core)
  • MYB:CI (DC Core)
  • MYB:BNPL (DC Core)
  • MYB:MTO (DC Core)

Prerequisites

None.

Limitations

None.

Ancillary IQ - seat price override (DC APIs and DC Core)

Digital Connect introduces an enhancement that allows airlines to override the seat price at seat sell to match the seat map offer price ensuring parity between 'look to book', in addition to the existing Offer Id cache solution. This enhancement is applicable for DC direct channel and is supported by both ATPCO and non-ATPCO seats. The price override mechanism is supported in QPX-M and ATSEv2 pricing engines in stateful DC flows.

Prerequisites

None.

Limitations

  • Price override is not supported on indirect channels and Offersnap
  • This enhancement does not apply to the stateless flows

Authorization failure notification enhancement (DC APIs and DC Core)

Digital Connect introduces an improvement to the customer notifications that are sent in case of a payment error. DC provides more accurate error messages during the purchase flow, making it easier for the customers to complete the transaction without the need for call center support. The enhancement also allows airlines to receive the supplier response code containing the sub-element in the transaction failure response.

DC will continue to send the transaction id and will receive the supplier response code upon both successful and failed authorization. DC will then send the supplier response code for all suppliers supported by payment web services. If there will be no supplier code included in the response, there will be an empty value with the key included.

This enhancement applies to the following:

  • DC APIs (Shop and book)
  • DC Core (post booking)
  • DC Stateless payment service
  • Mint Upgrade

Prerequisites

None.

Limitations

None.

Paid and free seat booking enhancement (DC APIs)

Digital Connect introduces an enhancement to the paid and free seat booking logic. Before the introduction of this enhancement, in a scenario when a purchase call was sent with two EMDs for paid seats and one of the seats was no longer available, Digital Connect has only issued PNR for the successfully booked seat and placed it in the Success Queue. The airline's UI did display a booking error message to the customer, however, the airline did not receive an error or warning. With the introduction of the enhancement, the appropriate details for failure warning are returned in the purchase response whenever one or all seats fail to book. All failed seats are also placed in the failure queue.

The enhancement applies to the B2C flow.

Prerequisites

None.

Limitations

None.

Booking class verification to avoid fraud (DC Core)

Digital Connect improves the booking class verification in the upgrade flow to remove the possibility of fraudulent booking that avoids upgrade fees. Before the introduction of this enhancement, it was possible to upgrade from the Economy class to Premium Economy using Interact without exchanging the ticket, and in a later step use the airline UI to upgrade Premium Economy to Business Class causing a revenue loss for the airline. DC now compares booking classes in the original VCR and current PNR in real time and blocks the possibility to upgrade in case of a discrepancy between the itinerary and VCR. If the booking classes match VCR and itinerary, the upgrade is possible with the upgrade fee as per normal booking flow. The enhancement can be enabled and disabled by configuration.

Prerequisites

Airlines need to enable the Flat Fee Upgrade (FFU)

Limitations

None.

Modification of SSR DOCO – Redress/Known Traveler Number and Visa Info (DC Core)

Digital Connect introduces changes to the post-booking flows (PNR Retrieval and Change Passenger Details – MYB:CPD). There are two new elements introduced to the GET /passenger and POST /passengers (passengerInfo) services following IATA standards:

  • A Country Code element is introduced for both Redress and Known Traveler Number. The new element is kept optional in the API.
  • An Expiry Date element is added to Visa Info. The new element is kept optional in the API.

This enhancement is applicable to Secure Flight Formats (SFPD), 3DOCS and 4DOCS. There are no other

changes applied to SSR DOCS.

Prerequisites

None.

Limitations

None.

Overbook Branded Fare class (DC Core)

Digital Connect optimizes the use of waiver codes used for PNRs affected by IROP. When airline passengers undergo an involuntary ticket exchange, the enhancement prioritizes returning exchange classes that are free and applicable to the new itinerary after the exchange. Only if there are no free options available, DC returns the remaining offers. This enhancement helps the airlines mitigate revenue risk by preventing the airlines from providing additional benefits to the customers that have originally booked lower-class tickets. It also benefits the airlines in reducing the number of customer contact centre calls, as they can self-serve better.

The enhancement works by including a Branded Fare id in the request when processing the exchange, and a pricing id tag in the exchange response to match up the fare originally booked by the airlines’ customers.

Prerequisites

  • Backend SSRCM Rules Processor table is set up in advance defining cabins
  • Rules are set up by airline users in SSRCM GUI to allow passengers to rebook resulting in overbooking of original fare class
  • Overbooking in SAME CABIN is set to ON

Limitations

None.

Cancellation fee configuration (DC Core)

Digital Connect introduces a configuration that allows airlines to include or forgo a cancelation fee when their customers cancel a booking that has been purchased with award points. If the configuration is set to true, customers will be charged for cancelling their itinerary, and if the configuration is set to false, no ancillary fee is added allowing the customers to successfully cancel their PNR with award booking. Since most airlines prefer to charge their customer a cancellation fee, the configuration is set to true by default. We have updated the DC Core code where we are adding the ancillary fee, so it is only added when the configuration is set to true.

Prerequisites

None.

Limitations

  • Partial refunds or refunds for seats/ancillaries paid for with points are not supported
  • Scenarios, where any part of the itinerary has been flown, are not supported
  • In cases when any of the segments have been upgraded, there were involuntary exchanges or any unconfirmed schedule changes for any segments,  passengers need to contact the airline’s call center
  • Split PNR functionality is not supported in SSW
  • Tickets with zero value cannot be refunded

DRW Backward Compatibility: PNR Migration (DC Core)

Description

In the current redemption flows (TrueBlue 2.0), the POS (Interact and web) is directly integrated with Comarch redemption services to authorize redemption and refund of points from the Loyalty Management System (LMS). The details of the points authorization are contained in the host payfields in these PNRs.  

With Dynamic Rewards (DRW) enabled, all redemption PNRs will have Open System Payfields created to facilitate the automatic refund of points to LMS through Payment Webservices (PWS) (DRW LP3 – cancel/refund).

Prerequisites

  • Host payfields need to be migrated to open system payfields.
  • DC changes to allow refund of points to LMS using LP3 cancel/refund flows for the migrated bookings.

Limitations

  • If a PNR is exchanged and tagged as migrated, the PNR gets blocked from being refunded.
  • A migrated PNR with JT type of payment gets blocked.  Seats and Ancillaries paid in points (JT) will get blocked.
  • Only Dynamic Awards on migrated PNRs are supported.
  • Multi-City is not supported.
  • Any migrated PNR that fails to follow Open System payfields format will not be able to process the Cancel and Refund through LP3 in DC.

Post Booking Flows - Seats (DC Core)

Description

When a purchase call is sent with two seats (free/paid) and if one of the seats is no longer available, Digital Connect issues the one that was successfully booked and queues the PNR to the Seat Success Queue.

DC returns a warning 'As Is' and Queue Place the PNR with the following results:

  • Case 1: All Seats are successfully booked  - queue place as Seat Success Queue.
  • Case 2: At least Seat assignment is unsuccessful - queue place to Seat Failure Queue and Seat Pass Queue
  • Case 3: All Fail – Seat Fail Queue
  • Case 4: Expose appropriate details for failure warning (existing functionality) in purchase response (RS)

Prerequisites

None.

Limitations

Supports only DC CORE All Post Booking Flow (free, paid).

Middle name reuse for passenger enhancement (DC Core)

Description

Digital Connect introduces an enhancement to the middle name reuse for passenger. Before the introduction of this enhancement, in DC, Manage My Bookings (MYB)/ Manage Trip Options (MTO) flows, enhancedSetMap response from downline showed invalid currency for seats, with respect to the currency using which it was previously purchased.

In MTO/MYB flows if there was a need to modify the seat/ancillary the key (composite in nature), it needed to match against the one with which the seat/ancillary was  actually purchased; for example: if there was a change in the name of the passenger during MTO/MYB flow, that led to a cache key mismatch, that in turn caused a different currency for seat/ancillary prices.

If a passenger with a valid middle name buys seats/ancillary using Interact and then come back via DC and try to do an MTO or MYB, there is a configuration that may truncate the middle name to one character for downline enhancedSeatMap calls, which results in offer mismatch and cause errors in enhancedSeatMap response from downline.

With this enhancement, a flag ‘postBookingInvocation’ is added from DC core to Service Engine (SE) to indicate that it is a post booking seat map call, if RECLOC existed for the flow. In SE, an additional logic is added  to check postBookingInvocation flag value set to ‘true’ then bypass the logic to truncate the middle name of the passenger to a single character to avoid any offer mismatch further downline.

Prerequisites

None.

Limitations

None.

Refund to Travel Bank without login

Digital Connect introduces the ability for the passengers to receive refunds to their original Travel Bank (TB) account without the need to enter their TB account information. With the introduction of this enhancement, only a single TB account can be used as a Form of Payment (SFOP) per one ticket, and in case the ticket is refunded, the funds are allocated on the original TB account that was used to book the flight. To achieve this, a new configuration has been introduced into DC code that allows skipping to provide the passengers' account details if the reservation is paid for with Travel Bank.

Project Scope

  • A new configuration has been added to activate this project effort. This configuration will not force the user to login into the Travel Bank account, if the reservation is paid with Travel Bank and refund is due back to Travel Bank. Please contact the activation team for further details.
  • The following work flows are in scope of this enhancement:
    1. DC Core for MYB:CI
    2. DC Core for MYB:CR
    3. DC Core for MYB:MTO
  • In case of using multiple Travel Bank accounts as well as multiple Forms of Payment per document, refunding to the original form of payment and to voucher is not possible as the solution has no way of determining to which Travel Bank account the funds should be redirected. Such cases have to be handled as they have been before the introduction of this enhancement.

Out of scope:

  • Digital Connect Platform
  • Digital Connect Middleware
  • DCMC for B2C
  • DC Core for B2C
  • DC Core for MYB:BNPL
  • DC Core - ACL as a form of payment

Scenarios (Single Form of Payment per document):

Single transaction

a.       B2C paid with Travel Bank

·   Refund triggered to the Original Form of Payment – Travel Bank
(Refund to Voucher, Refund to original forms of payment will have same outcome) 

    Single transaction

    a.       B2C paid with Credit Card

    ·   Refund to Voucher - Login or create a new Travel Bank account

    ·   Refund to Original Form of Payment – Refund to Credit Card

    MYB:MTO workflow – scenario 1

    a.       B2C paid with Travel Bank (VCR)

    b.       MYB:MTO – add collect – paid with different Travel Bank account (EMD)

    ·   Refund to Original Form of Payment – Travel Bank

    1.       VCR refund forced to Travel Bank account in the VCR

    2.       EMD refund forced to Travel Bank account in the EMD

    MYB:MTO workflow – scenario 2

    a.       B2C paid with Credit Card (VCR)

    b.       MYB:MTO – add collect – paid with Travel Bank (EMD)

    ·   Refund to Original Form of Payment

    1.       VCR refund to Credit Card

    2.       EMD refund to Travel Bank

    ·   Refund to voucher

    1.       VCR and EMD refund to Travel Bank (TB account used to purchase the EMD)

    MYB:CI workflow

    a.       B2C paid with Travel Bank + Credit Card (VCR)

    b.       MYB:CI – add collect – paid with Credit Card (VCR)

    ·   Refund to Original Form of Payment
    Current behavior

    ·   Refund to voucher
    Current behavior - request user to log in

    Current behavior

    Currently, the system asks for login or creates a new Travel Bank account. If a passenger uses a new Travel Bank account to log in, the scenario fails from downline, the logic being that the original account should only be used for requesting the refund. The error message shown in this scenario is "TRAVEL BANK NBR CANNOT BE CHANGED FROM ORIGINAL FOP-RFND1".
    If the user logs in with a proper account, the refund is successful.
    Whenever there are no changes to Travel Bank details in the document such as in the scenario given for MYB:CI, the system will still continue to ask the passenger to log in.

    B2C + MYB:CI + MYB:MTO workflow (Travel Bank A, B, and C being different accounts)

    a.       B2C paid with Travel Bank A (VCR)

    b.       MYB:CI – add collect – paid with Travel Bank B (VCR)

    c.       MYB:MTO – add collect – paid with Travel Bank C (EMD)

    ·   Refund to Original Form of Payment – Travel Bank

    1.       VCR refund forced to Travel Bank account used in the exchanged VCR (Travel Bank B)

    2.       EMD refund forced to Travel Bank account used in the EMD (Travel Bank C)

    ·   Refund to voucher
    Since the refund to voucher is not possible in this scenario, the following error message will continue to be displayed:     'TRAVEL BANK NBR CANNOT BE CHANGED FROM ORIGINAL form of payment-RFND1".

    B2C + MYB:MTO – scenario 1

    a.       B2C paid with Credit Card (VCR)

    b.       EMD paid with Credit Card (EMD)

    c.       EMD paid with Travel Bank (EMD)

    ·   Refund to Original Form of Payment

    1.       EMD paid with Credit Card refunded to Credit Card

    2.       EMD paid with Travel Bank refunded to Travel Bank

    ·   Refund to voucher

    1.       VCR refunded to Travel Bank

    2.       EMD paid with Credit Card refunded to Credit Card (refundable filing)

    3.       EMD paid with Travel Bank refunded to Travel Bank

    B2C + MYB:MTO – scenario 2

    a.       B2C paid with Credit Card (VCR)

    b.       EMD paid with Travel Bank 1 (EMD)

    c.       EMD paid with Travel Bank 2 (EMD)

    ·   Refund to Original Form of Payment

    1.       VCR refunded to Credit Card

    2.       EMD 1 refunded to Travel Bank 1

    3.       EMD 2 refunded to Travel Bank 2

     

    ·   Refund to Voucher

    1.       VCR refunded to Travel Bank 1

    2.       EMD 1 refunded to Travel Bank 1

    3.       EMD 2 refunded to Travel Bank 2

    Scenarios (Multiple Forms of Payment per document):

    There should only be one unique Travel Bank account for the entire transaction paid for with Multiple Forms of Payment.

    B2C

    a.       Entire transaction (either VCR or EMD) in a B2C workflow must have a single Travel Bank account as Form of Payment e.g., Credit Card + Travel Bank

    ·   Refund to Original Forms of Payment

    1.       Payments made with Credit Card refunded to Credit Card

    2.       Payments made with Travel Bank refunded to Travel Bank

    ·   Refund to Voucher

    1.       Refund processed to Travel Bank

    B2C + MTO

    a.       Multiple Forms of Payment scenario with VCR and EMD having the same Travel Bank account e.g., VCR has Travel Bank 1 + Credit Card / EMD has Travel Bank 1

    ·   Refund to Original Forms of Payment

    1.       Refund processed back to Travel Bank 1

    ·   Refund to Voucher

    1.       Refund processed back to Travel Bank 1

    Note: when Travel Bank and Credit Card Forms of Payment are used in the same document:

    ·   Refund to Original Forms of Payment

    1.       Refund Travel Bank portion to Travel Bank and the Credit Card portion to Credit Card

    ·   Refund to Voucher

    1.       Entire refund to Travel Bank

    Out of Scope Scenarios (Multiple Forms of Payment per document):

    a.       B2C + MTO (2 different Travel Bank accounts involved)

    ·   Multiple Forms of Payment scenario with VCR and EMD having two different Travel Bank accounts e.g., VCR - Travel Bank account 1 + Credit Card, and EMD - Travel Bank account 2 + Credit Card

    Defect fixes

    Duplicate ticket issue

    Customer tracking #:

    05982977

    Sabre Tracking #:

    DC-14551

    Description:

    In some cases, Digital Connect issued duplicate tickets when using the airlines' UI due to an erroneous redirection of purchase calls.

    Resolution:

    When we enter purchase, we persist a flag in Redis for the session/execution pair. Once the flag is set it won't allow another request for the same session/execution to happen while one is still ongoing.