A common element used in several different transactions for supplying payment method information.
This includes a choice of typical payment representations like track data, manually entered data, and token information. It also includes options for specifying how the supplied data has been encrypted or to request a multi-use token be supplied in the response.
Note: Swipe is not allowed for a voucher purchase.
Note: Multi-use and single-use tokens are not supported for EBT.
Note: For EBTVoucherPurchase transactions, a null expiration date is represented by setting the ExpMonth to 1 and the ExpYear to 9999 in the CardData.ManualEntry node.
CVV Number ("Card Verification Value"); 3 digits on VISA, MasterCard, Discover and UnionPay and 4 on American Express.
CVV numbers are also known as CSC numbers ("Card Security Code"), as well as CVV2 numbers, which are the same as CVV numbers, except that they have been generated by a 2nd generation process.
Note: This field is not used for EBT transactions.
Note: If expiration month and year are provided, they will be used for processing the transaction rather than the stored values associated with the provided token. This is for the current transaction only and will not be stored for future use.
CVV Number ("Card Verification Value"); 3 digits on VISA, MasterCard, Discover and UnionPay and 4 on American Express.
CVV numbers are also known as CSC numbers ("Card Security Code"), as well as CVV2 numbers, which are the same as CVV numbers, except that they have been generated by a 2nd generation process.
Note: This field is not used for EBT transactions.
For PAN encryption, use version "02" or "04" for Heartland E3 encryption. This requires the client to parse the E3 MSR output. The encrypted PAN is passed in the card data element as the manual entry card number. The KTB must be provided as part of the encryption data. If sending an encrypted CVV2, use version "04" which expects the PAN and CVV2 to be encrypted.
For PAN encryption, use version "05" for TDES DUKPT encryption with and without CVV encryption. This requires the client to parse the output. The encrypted PAN is passed in the card data element as the manual entry card number. The KSN must be provided as part of the encryption data.
For track encryption, use version "01", "02", or "04" for Heartland E3 encryption. Version "01" will not require parsing and it will not require additional fields in the encryption data, but the full E3 MSR output must be passed in the card data element as track data. Version "02" and "04" requires the client to parse the E3 MSR output. The KTB must be provided as part of the encryption data. In addition, the client must parse the data specific to either encrypted track 1 or track 2 and provide this in the card data element as track data as well as supply the track number as EncryptedTrackNumber.
For track encryption, use either version "03" for AES encryption with DUKPT, or "05" for TDES encryption with DUKPT. The "03" option supports the IdTECH card readers. The "05" option will work with any device that supports TDES with DUKPT data encryption per AINSI 9.24-1. Both options require the client to parse reader output. The KSN must be provided as part of the encryption data. In addition, the client must parse the data specific to either encrypted track 1 or track 2 and provide this in the card data element as track data as well as supply the track number as EncryptedTrackNumber.
For track encryption "05" is used for TDES encryption with DUKPT. The "05" option will work with any device that supports TDES with DUKPT data encryption per ANSI 9.24-1. Both options require the client to parse reader output. The KSN must be provided as part of the encryption data. In addition, the client must parse the data specific to either encrypted track 1 or track 2 and provide this in the card data element as track data, as well as supply the track number as EncryptedTrackNumber.
This is used to request the gateway to return a multi-use token for the supplied card data. If a token is provided in the card data and this flag is set, it will be echoed in the response.
PIN block generated from the encrypted cardholder PIN and key serial number (KSN); see the guide for the specific PIN pad device being used to determine how to obtain the data elements required to create a PIN block.
Note: Portico requires the order of the data to be encrypted PIN followed by the KSN. If the encrypted PIN was 11111111 and the KSN was 22222222, the PIN block would have to be 1111111122222222 when sent to the gateway.
Note:This field has been deprecated. EBTVoucherPurchase does not support PINBlock verification and is ignored when sent.
This is important in cases where the client processes a large number of similar transactions in a very short period of time; sending "Y" will skip duplicate checking on this transaction.
Used to log Merchant specific customer identification.
Note: For GETI check transactions, this is sent in the CUSTOM3 field.
Source
<xs:elementname="Block1"type="EBTFSVoucherReqBlock1Type"xmlns:xs="http://www.w3.org/2001/XMLSchema"><xs:annotation><xs:documentation><pxmlns="http://Hps.Exchange.PosGateway">Contains a series of required and optional elements</p></xs:documentation></xs:annotation></xs:element>