Sample payload
When using the PCI Booking Gateway to process inbound requests, customers need to ensure that their APIs require their partners to send the necessary data in the payload needed for tokenization.
The structure, layout and naming conversion of the data in the payload is up to the customer to define. When creating the "profile" in the gateway, the PCI Booking team will map the relevant card data fields in PCI Booking vault to those in the message payload.
The PCI Booking Gateway supports tokenizing both credit card data and 3DS authentication results. Minimum required fields for card tokenization are the card number (PAN) and expiration date.
Below is an example of a simple message payload with all possible data fields.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<AcceptFromMeCC>
<payCard>
<ccInfo>
<Cc_type>Visa</Cc_type>
<FirstName>John</FirstName>
<LastName>Doe</LastName>
<Cc_number>4580458045804580</Cc_number>
<Cc_date_month>10</Cc_date_month>
<Cc_date_year>2022</Cc_date_year>
<Cc_cvv>123</Cc_cvv>
<AuthenticationValue>AAACBDgxAnlENWNRSTECEwAAAAA=</AuthenticationValue>
<eci>05</eci>
<id>cnFwcXVLRjlKZ2pPeGpySzJieGQ=</id>
<Version>1.0</Version>
</ccInfo>
</payCard>
</AcceptFromMeCC>
</soap:Body>
</soap:Envelope>
3DS data
In 3DS, depending on the version of the authentication used (version 1 or version 2), the authentication result will contain different data.
In both cases, the authentication result will contain the AunthenticationValue (CAVV) and ECI. If version 1 was used for authentication, the merchant will have the XID value and if version 2 was used, the merchant will have the 3DS_Trans_ID value.Both the XID and 3DS_trans_ID are stored in PCI Booking interchangeably under the same field.
Updated over 3 years ago