Gateway-generated transaction identifier returned in the response of the original transaction. This indicates the transaction from which card data will be reused.
Note: When using a prior transaction id, card data should not be sent and original transaction reference data will be required.
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.
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 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
Transaction description that is concatenated to a configurable merchant DBA name. The resulting string is sent to the card issuer as the Merchant Name.
Note: Updates to the device are required to utilize this feature. See your Heartland representative for more details.
Surcharge amount information; this defines the portion of the total amount provided as part of this request that was specifically for a surcharge. This is informational only and will not alter the amount processed as part of the transaction.
Note: This field is limited to 8 digits with implied decimal.
When processing with an EMV capable client, this element may need to be provided. It consists of certain online authentication data or the reason for not utilizing the EMV capabilities. EMV tag data should be sent in the separate TagData field.
This must be provided when the POS was not able to successfully communicate to the chip card and was required to fall back to a magnetic stripe read on an EMV capable terminal.
Cryptogram received from wallet payment. Supported formats are DSRP, TokenBlocks and TAVV cryptograms. Must be encoded using base16 (Hex encoding) or base64 encoding.
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.
Indicates the method used by the sender to fund an OCT.
The tag is required in all domestic and cross-border money trans-fer OCTs destined to U.S. recipient issuers.
Valid values include:
01 = Visa credit
02 = Visa debit
03 = Visa prepaid
04 = Cash
05 = Debit/deposit access accounts other than those linked to a Visa card (includes checking/savings accounts and proprietary debit/Automated Teller Machine (ATM) cards)
06 = Credit accounts other than those linked to a Visa card (includes credit cards and proprietary credit lines)
Denotes whether the tax ID is a business or individual tax ID when the Identification Type Code contains the value of TXIN (Tax identification). This field is applicable only for Visa OCT.
The expiration date of the identification specified for the IdType
Source
<xs:elementname="Block1"type="SendFundsReqBlock1Type"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><pxmlns="http://Hps.Exchange.PosGateway"/></xs:documentation></xs:annotation></xs:element>
