3DS in NDC Messages

NDC Messages Affected

Any message which contains information regarding payment by Credit Card is affected, which as of today includes the OrderCreateRQ and the OrderChangeRQ messages. The solution is identical for both although the examples below make reference always to the OrderCreaeRQ

NDC 19.2

The first version of the IATA NDC messages that is able to handle both 3DS1 and 3DS2 is the 19.2 version. Iberia has not implemented 19.2 however we have decided to include in our 17.2 messages an Augmentation Point with the element structure taken from 19.2.

The elements that give support to 3DS in both OrderCreate and OrderChange are the following:

  • SecurePayerAuthenticationVersion: 3DS Version

  • SecurePaymentVersion1: Data for 3DS 1.x

  • SecurePaymentVersion2: Data for 3DS 2.x

  • SecureProgram: Name of the secure payment program

  • SellerOwnCardInd: Indicator for whether the Credit Card belongs to the Travel Agent or the customer.

 

Element

SecurePayerAuthenticationVersion

Xpath

/IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentMethodCriteria/PaymentCardCriteria/SecurePayerAuthenticationVersion (XSD Viewer)

Description

Used by Seller if 3D-Secure is supported. Seller can specify which version of 3D-Secure is supported. Note: 3D-Secure context should be used when the Customer-Seller interaction type is web and/or mobile.

Sub-elements

  • CardEnrollmentVersionText - Version of 3D-Secure for which the card is enrolled.

  • SupportedVersionText - Specifies the exact supported 3D-Secure version.

Element

SecurePaymentVersion1

Xpath

/IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentCard/SecurePaymentVersion1 (XSD Viewer)

Description

Contains the indicators and fields that convey the result of the 3D Secure authentication transaction. Applicable for 3D Secure Version V 1.0.

Sub-elements

  • PayerAuthenticationResponseText - The authentication response for the 3-D Secure transaction. It is used to determine whether or not the customer has been authenticated by the card issuer. It must be included in the final authorization request. Example: eJzVWFmzosgSfudXdPQ8Gt1sbkzYRhQ7KCjI/sYOsimgoL/+lp7Tp5c5t2d67tMw8yv/WqiluJXS8WyyVFEQT28qz

This field is the text from the PARes in Base64. (More information about PARes can be found in: PARes (3DS 1.x))

Element

SecurePaymentVersion2

Xpath

/IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentCard/SecurePaymentVersion2 (XSD Viewer)

Description

Contains all information for the result of 3D-Secure authentication process.

Sub-elements

  • AuthenticationMerchantName - Name of the merchant

  • AuthenticationValue - Authentication value

  • DirectoryServerTrxID - DS (Directory Server) transaction ID

  • ElectronicCommerceInd - ECI (electronic commerce indicator)

More information about ECI can be found in: (ECI)

  • ProgramProtocolText - Program Protocol

  • TrxStatusReasonText - outcome of authentication coming from the DS - see EMVCO documentation for list of possible values.

  • TrxStatusText - outcome of authentication - see EMVCO documentation

More information about the meaning of the fields can be found in (3DS 2.x Reference)

Element

SecureProgram

Xpath

/IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentCard/SecureProgram (XSD Viewer)

Description

Contains enrolment information of the Payment Card. e.g. Verified by Visa.

Sub-elements

  • EnrollmentStatusText - 3D Secure Program Enrollment Status. Examples: CardNotEnrolled, CardEnrolled, CardMayBeEnrolled, Unknown

  • SecurePaymentProgramName - Name of the secure payment program. E.g. Verified by Visa.

Element

SellerOwnCardInd

Xpath

/IATA_OrderCreateRQ/Request/PaymentFunctions/PaymentProcessingDetails/PaymentMethod/PaymentCard/SellerOwnCardInd (XSD Viewer)

Description

When TRUE, indicates the seller is using their own card. If FALSE, customer card is being used.

Sub-elements

 

NDC 17.2

The IATA 17.2 version does not support 3DS 2.x, and although is does partially support 3DS 1.x the structure of the information is very different to previous versions.

Given the situation with 17.2, the solution for 3DS 1.x has changed and 3DS 2.x is not contemplated, Iberia has decided to include an Augmentation Point with the element structure taken from 19.2, for both 3DS 1.x and 3DS 2.x. In this way the solution is reusable in the future and we forcing that the elements used for both versions are within this Augmentation Point, ignoring any data that could be in the elements meant for the 3DS 1.x in the 17.2 standard.

Augmentation Point

The AugmentationPoint will be in the section for metadata for forms of payment:

xpath: /OrderCreateRQ/Query/Metadata/Other/OtherMetadata/PaymentFormMetadatas/PaymentFormMetadata/AugmentationPoint

At this section we will include the structure relevant to 3DS that is in the 19.2 version. The structure of the AugmentationPoint will potentially allow for multiple PaymentCardSecureInfo elements, and within these we will have the part of the structure that is from 19.2 with which we need to amplify the 17.2 version of the schema. We are not including all of the fields, but only those strictly necessary in orderto not create duplicate fields.

PaymentCardSecureInfo contains an attribute ObjectKey in order to be referenced from the forms of payment.

The Augmentation Point will be as follows:

<AugPoint> <Backport_IberiaSecurePayment> <PaymentCardSecureInfo ObjectKey=""> <PaymentFunctions> <PaymentMethodCriteria> <PaymentCardCriteria> <SecurePayerAuthenticationVersion> <CardEnrollmentVersionText>...</CardEnrollmentVersionText> <SupportedVersionText>...</SupportedVersionText> </SecurePayerAuthenticationVersion> </PaymentCardCriteria> </PaymentMethodCriteria> <PaymentProcessingDetails> <PaymentMethod> <PaymentCard> <SecurePaymentVersion1> <PayerAuthenticationResponseText>...</PayerAuthenticationResponseText> </SecurePaymentVersion1> <SecurePaymentVersion2> <AuthenticationMerchantName>...</AuthenticationMerchantName> <AuthenticationValue>...</AuthenticationValue> <DirectoryServerTrxID>...</DirectoryServerTrxID> <ElectronicCommerceInd>...</ElectronicCommerceInd> <ProgramProtocolText>...</ProgramProtocolText> <TrxStatusReasonText>...</TrxStatusReasonText> <TrxStatusText>...</TrxStatusText> </SecurePaymentVersion2> <SecureProgram> <EnrollmentStatusText>...</EnrollmentStatusText> <SecurePaymentProgramName>...</SecurePaymentProgramName> </SecureProgram> <SellerOwnCardInd>...</SellerOwnCardInd> </PaymentCard> </PaymentMethod> </PaymentProcessingDetails> </PaymentFunctions> </PaymentCardSecureInfo> </Backport_IberiaSecurePayment> </AugPoint>

Referencing the Augmentation Point

The information of the payments with credit card is in the PaymentCard element of the payment methods.

xpath: /OrderCreateRQ/Query/Payments/Payment/Method/PaymentCard

When the credit card has 3DS authentication information, this should be in the Augmentation Point, and as such we will have the credit card information split, which will require the two places to be referenced to each other. The way in which this is done is by including in the attribute reference of the PaymentCard the value of the attribute ObjectKey of the PaymentCardSecureInfo.

  • /OrderCreateRQ/Query/Metadata/Other/OtherMetadata/PaymentFormMetadatas/PaymentFormMetadata/AugmentationPoint/AugPoint/Backport_IberiaSecurePayment/PaymentCardSecureInfo/@ObjectKey

  • /OrderCreateRQ/Query/Payments/Payment/Method/PaymentCard/@ref

Example:

... <PaymentCardSecureInfo ObjectKey=”key1”> ... <PaymentCard ref=”key1”> ...

Augmentation Point Schemas

The AugmentationPoint has an independent schema, and the “master” schema of IATA stays as is. Just as IATA do, Iberia has defined a Backport with the “additional” schema for the extension of the message.

This additional schema, which contains all the structure defined for the AugmentationPoint mentioned in the previous point, can be used in either the OrderCreateRQ or the OrderChangeRQ and can be used for both 3DS1 and 3DS2 with authentication via a third party.

The credit card information has to referenced to the 3DS authentication information:

<Payments> <Payment> <Type>CC</Type> <Method> <PaymentCard refs="this_is_the_key_of_the_payment_card_secure_info"> ... </PaymentCard> ... </Payment> </Payments>

In the AugmentationPoint, indicate that the AugmentationPoint is for IB and define the key to reference it from the credit card details. If there were to be more that one credit card, then there would be as many PaymentCardSecureInfo elements as necessary, with each on referencing the applicable credit card.

 

Name

Description

File

Name

Description

File

Backport_IberiaSecurePayment_17.2.xsd

Additional schema for the extension of the OrderCreateRQ y OrderChangeRQ messages.

OrderCreateRQ_17.2_Augmented_3DS1.xml

Example of an OrderCreateRQ 17.2 with CreditCard payment, with the contents of a 3DS 1.x authentication in the AugmentationPoint and with the schemas referenced to validate the document.

The addition parts with respect to a standard OrderCreate are marked with a comment:

<!-- ########################### -->

OrderCreateRQ_17.2_Augmented_3DS2.xml

Example of an OrderCreateRQ 17.2 with CreditCard payment, with the contents of a 3DS 2.x authentication in the AugmentationPoint and with the schemas referenced to validate the document.

The addition parts with respect to a standard OrderCreate are marked with a comment:

########################### -->

More information