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 |
|
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 |
|
Element | SecurePaymentVersion1 |
Xpath |
|
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 |
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 |
|
Description | Contains all information for the result of 3D-Secure authentication process. |
Sub-elements |
More information about ECI can be found in: (ECI)
More information about the meaning of the fields can be found in (3DS 2.x Reference) |
Element | SecureProgram |
Xpath |
|
Description | Contains enrolment information of the Payment Card. e.g. Verified by Visa. |
Sub-elements |
|
Element | SellerOwnCardInd |
Xpath |
|
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 |
---|---|---|
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 |
|
More information
UPDATE as of December 17, only people with an Iberia or IAGGBS account will be able to access them. Write to jira.support.ib@iberia.es and we will help you with the change. ACTUALIZACIÓN a partir del 17 de diciembre, sólo podrán acceder a ellas personas con cuenta de Iberia o IAGGBS. Escribe a jira.support.ib@iberia.es y te ayudaremos con el cambio.