This 1-character configuration setting is used to identify the type of device used by the merchant for accepting mobile Point of Sale (mPOS) transactions. Valid values are:

By default the control automatically selects the correct ACI for the type of transaction being attempted. This configuration setting is for advanced users, and it is not recommended it be changed. That being said, this 1-character field contains the Requested ACI used to identify an authorization request as potentially qualifying for CPS (Custom Payment Services) and MasterCard Merit programs. If a merchant chooses not to participate in CPS, the ACI may be set to "N". The following table provides a summary of the codes currently supported by both Visa and MasterCard. Please note that not all of these ACI values are supported in Direct Marketing and Retail transactions.

This is an action config which when called will authenticate a POS device with TSYS. Authentication is required when processing transactions using Voltage Encryption or Tokenization. An AuthenticationCode is required to be specified, as is MerchantZip and/or MerchantServicePhone, to perform authentication. After a POS device is successfully authenticated, GenKey will be populated.

When this setting is True, if the credit card being authorized does not contain sufficient funds to cover the TransactionAmount, the card will not be declined. Instead, the transaction will be authorized for a lesser amount. The customer must then use another form of payment to make up the remainder. The total amount authorized by TSYS will be returned in the ResponseAuthorizedAmount configuration setting. For instance, if the TransactionAmount is $100.00, but the card only has a $50.00 balance, the card is charged for $50.00, and the ResponseAuthorizedAmount will be "50.00". The merchant may then collect the remaining $50 in cash, check, credit card, or any other acceptable form of payment. This setting is False by default.

This field is used for American Express transactions that are submitted via an Aggregator, Payment Service Provider or Facilitator to identify the Aggregator's Name. The maximum length of this field is 20 characters. It must be upper-case and should not contain spaces.

This configuration setting takes a vertical bar (|) separated list of name-value pairs. The available field names and their applicable values can be found below. The fields can be set in any order and not all fields are required to be set (unless you wish to change their default values).

Code Example: TSYSECommerce.Config("AmexAirlinePassengerData=DepartureDate=20170601|PassengerName=FROST~JANE~M~MRS|CardMemberName=FROST~CHARLES~F~MR|Origin=ABC|Destination=DEF|NumberOfCities=4|RoutingCities=ABC/DEF/GHI/JKL|NumberOfAirlineCarriers=3|AirlineCarriers=AB/XY/BC|FareBasis=ABC123DEF456GHI789JKL012|NumberOfPassengers=1|ETicket=True|ReservationCode=ABCDE1234567890");

NOTE: The tilde character "~" = character space.

This configuration setting takes a vertical bar (|) separated list of name-value pairs. The available field names and their applicable values can be found below. The fields can be set in any order and not all fields are required to be set (unless you wish to change their default values).

Code Example: TSYSECommerce.Config("AmexCNPInternetPhoneData=CustomerEmail=CFFROST@EMAILADDRESS.COM|CustomerHostName=PHX.QW.AOL.COM|BrowserType=MOZILLA/4.0~(COMPATIBLE;~MSIE~5.0;~WINDOWS~95)|ShipToCountry=840|ShippingMethod=02|ProductSKU=TKDC315U|CustomerIP=127.142.005.056|CustomerANI=6025551212|CustomerIIDigits=00");

This configuration setting takes a vertical bar (|) separated list of name-value pairs. The available field names and their applicable values can be found below. The fields can be set in any order and not all fields are required to be set (unless you wish to change their default values).

Code Example: TSYSRetail.Config("AmexCPGoodsSoldData=ProductCode=1000");

This field is used to specify the AuthenticationCode, assigned by TSYS, to authenticate a POS device (made via a call to ActivateTerminal).

This field defines the type of authorization request and must be included on all MasterCard authorization request transactions.

Valid values are:

This applies to merchants that are enrolled in the Visa Consumer BillPay program.

Valid values are:

Note: When enrolled in the Visa Consumer BillPay program, the MerchantName field must be in the 'CBPS Name * Biller' format and must match what is registered with Visa.

Sending a value of "Y" in this Mastercard only field indicates the merchant accepts Canada domestic Debit Mastercard. This value must be sent in every Credit Authorization Request for merchants that accept Canada region-issued Debit Mastercard cards.

If Canada Domestic Indicator was present in the original transaction it must be included in a reversal message.

By default the control automatically computes the CardholderId based on several factors. Changing this config setting will override this automatic calculation. Clear this setting to "" (empty string) to restore automatic calculation. Please see the TSYSDetailRecord control's CardholderId property for more information.

This setting is used to pass 3D Secure CAVV data on to the transaction server. This field must be formatted as a 28-byte Base-64 encoded value. This control may be used in conjunction with the ThreeDSecure control from the E-Payment Integrator toolkit or with any other 3D Secure MPI implementation. Other values necessary for passing 3D Secure data include XID and ECI. This setting is only valid for E-Commerce transactions.

This 4-character field indicates whether the transaction was initiated by the Cardholder or the Merchant (Mastercard only).

Valid values are:

Customer Initiated Transaction (CIT)

Merchant Initiated Transaction (MIT) - Recurring or Installment

Merchant Initiated Transaction (MIT) - Industry Practice

Note: If CIT/MIT Indicator was present in the original transaction it must be included in a reversal message.

This field contains a three digit number assigned by the signing member or processor to identify the merchant's location country. These codes are specified by ISO-3166-1. The default is "840", indicating the United States.

This configuration setting is required for Visa and Discover Incremental transaction. When supporting incremental authorizations, you must manually keep track of the sum of all authorizations made for a single transaction (all based on the same transaction id). This total will be sent on G3v022 (additional amounts) with amount type 43.

This field contains a three digit number assigned by the signing member or processor to identify the merchant's authorization currency. The default is "840", indicating US Dollars. Other values may be used when processing multi-currency.

This is the current number of outstanding transactions that have not yet received a response. This is a read-only configuration setting.

This is an action config which when called will deactivate the POS device specified via GenKey with TSYS.

The Digital Payment Cryptogram is a 28 byte value and is used to send a Digital Secure Remote Payment (DSRP) cryptogram for DSRP transactions submitted as electronic commerce.

The Directory Server Transaction ID is a 36 byte value generated by the EMV 3DS Mastercard Directory Server during the authentication transaction and passed back to the merchant with the authentication results. This field allows the merchant to pass the Directory Server Transaction ID during authorization in order to link authentication and authorization data.

This configuration setting is read only and can be used to explicitly close the interleaved connection. This is usually used when all response packets are received.

This configuration setting is read only and can be used to process any available events. If no events are available, it waits for a preset period of time, and then returns.

This contains a 1-character transaction indicator identifying the type of transaction being authorized. This is also known as "MOTO". This value is used only for Card Not Present transactions. See the table below for a list of supported values.

Note: Other values necessary for passing 3D Secure data are CAVV and XID.

Note: Please make sure to send the SPACE (" ") value inside quotes. For Example:

TSYSRetail.Config("ECI=\" \"");

This 10 character field provides a unique value to identify a Gateway or Aggregator. This number is provided by TSYS Acquiring Solutions during the certification process.

This field is used to specify retrieve or specify a GenKey value for a terminal. This field will be populated after a successful call to ActivateTerminal is made. The Genkey must be stored in the POS device, must be sent with every request to the TSYS Acquiring Solutions host after authentication (by setting this field), and will be checked against the terminal hierarchy. A GenKey value is required when processing transactions using Voltage Encryption or Tokenization.

The specified value must be 4 characters or less. Note that this value is required to comply with MasterCard's Authorization Data Accuracy Initiative.

This field allows you to specify the Heartland E3 encryption mode used when processing Heartland transactions. The available values are (descriptions describe the data that will be encrypted):

Note you will also need to set Processor to 1 (Heartland) and HeartlandKeyBlock if you wish to process Heartland E3 transactions.

This field allows you to specify the key block that was used to encrypt the data specified by HeartlandEncryptionMode. This value will be obtained from an E3 magnetic stripe reader and is used by Heartland to decrypt the encrypted data.

This configuration setting is required when sending an Incremental transaction, when the ACI is set to "I". It should be set with the ResponseApprovalCode from the original (first) authorization. You must keep track of the total authorized amount, which is the sum of the original authorization and all subsequent incremental authorizations, and set the TotalAuthorizedAmount configuration setting in the TSYSDetailRecord control before settlement. Only one detail record should be submitted, no matter how many incremental transactions are authorized.

This configuration setting is required when sending an Incremental transaction, when the ACI is set to "I". It should be set with the ResponseRetrievalNumber from the original (first) authorization. You must keep track of the total authorized amount, which is the sum of the original authorization and all subsequent incremental authorizations, and set the TotalAuthorizedAmount configuration setting in the TSYSDetailRecord control before settlement. Only one detail record should be submitted, no matter how many incremental transactions are authorized.

This configuration setting is required when sending an Incremental transaction, when the ACI is set to "I". It should be set with the ResponseTransmissionDate from the original (first) authorization. You must keep track of the total authorized amount, which is the sum of the original authorization and all subsequent incremental authorizations, and set the TotalAuthorizedAmount configuration setting in the TSYSDetailRecord control before settlement. Only one detail record should be submitted, no matter how many incremental transactions are authorized.

This configuration setting is required when sending an Incremental transaction, when the ACI is set to "I". It should be set with the ResponseTransactionId from the original (first) authorization. You must keep track of the total authorized amount, which is the sum of the original authorization and all subsequent incremental authorizations, and set the TotalAuthorizedAmount configuration setting in the TSYSDetailRecord control before settlement. Only one detail record should be submitted, no matter how many incremental transactions are authorized.

This configuration setting is required when sending an Incremental transaction, when the ACI is set to "I". It should be set with the ResponseTransactionTime from the original (first) authorization. You must keep track of the total authorized amount, which is the sum of the original authorization and all subsequent incremental authorizations, and set the TotalAuthorizedAmount configuration setting in the TSYSDetailRecord control before settlement. Only one detail record should be submitted, no matter how many incremental transactions are authorized.

This configuration setting indicates the number of recurring or installment payments that were agreed upon between the cardholder and the merchant. This field is used in both the initial and subsequent payment transactions. The current usage of this field is for Discover cards only. Valid values are:

This configuration setting is used to identify the sequence number of a transaction when there are multiple installment payments. This field is used in both the initial and subsequent payment transactions. The rcfgInstallmentNumber; should be populated in ascending order. The current usage of this field is for Discover cards only.

To settle a transaction authorized with the ttInstallment TransactionType, you must specify the number of this installment and the total count of all installments to be made using TSYSECommerce control. For instance, if the purchase was for "Three easy payments of $19.95", and this is the first payment, then the installment number will be 1, and the installment count 3. An example is included below:

TSYSECommerce.TransactionType = ttInstallment TSYSECommerce.TransactionAmount = "1995" TSYSECommerce.Config("InstallmentCount=3") TSYSECommerce.Config("InstallmentNumber=1") TSYSECommerce.Authorize() TSYSSettle.DetailAggregate[5] = TSYSECommerce.GetDetailAggregate()

Interleaved Mode is intended for high volume transaction environments. When using this communication mode, transaction data is transmitted and received simultaneously without blocking. The advantage of an Interleaved Session is that the connection can stay up and is stateless once connected. Up to 10 simultaneous requests can be sent at a time. By default the value for this configuration setting is False. For instance:

//Interleaved Transaction Mode TSYSECommerce1.Config("InterleavedMode=True"); //Maximum number of pending response packets. TSYSECommerce1.Config("MaxPendingResponseCount=10"); TSYSECommerce1.OnResponse += (sender, args) => { Console.WriteLine("Response received for {0}, {1}, {2}, {3}", args.TransactionId, args.ResponseCode, args.ResponseText, args.ResponseApprovalCode); }; TSYSECommerce1.Authorize(); //Explicitly Disconnect TSYSECommerce1.Config("DisconnectInterleaved");

When InterleavedMode is set to True the control will return immediately when Authorize is called. This setting specifies the timeout (in seconds) for which the component will wait for a response. If no response is received within InterleavedTimeout seconds the Error event will fire and the connection will be closed.

The default value is 60 (seconds).

This field, when set to 'True', indicates that the transaction is a Bill Payment transaction and will be processed as such. When set to 'False' (default value) the transaction will be processed normally.

Set this to True when the amount sent in the initial transaction is an estimate. Default value is 'False'.

To process a Merchant Initiated Transaction you need to set this IsMerchantInitiatedTransaction flag to True. Default value is False.

This 11-digit value is assigned to the Service Provider designated as an ISO (Independent Sales Organization) during registration with the card brand and must be included on all MasterCard or Discover transactions where the merchant has a relationship with an ISO.

This configuration setting should be set to 'True' to process Passenger Transport transaction in Mail Order (Direct Marketing) and eCommerce environments. When set to 'False' (default value) the transaction will be processed normally.

To process an online Purchase Return transaction you need to set this IsPurchaseReturnAuthorization flag to True. Default value is 'False'.

Note: To Reverse a Purchase Return Authorization you should use the TSYSReversal control and set the ReversalType to rtCreditAuthorization (5) before calling the Reverse method.

This field is used to identify the merchant's street address where the transaction took place. The maximum length is 38 characters (upper-case). For American Express transactions that are submitted via an Aggregator/Payment Service Provider the maximum length is 20 characters and if necessary this value should be truncated rather than abbreviated.

This field is used to identify the name of the city where the transaction took place. The maximum length is 21 characters (upper-case). For American Express transactions that are submitted via an Aggregator/Payment Service Provider the maximum length is 13 characters.

This field is used to identify the country code of the location where the transaction took place. For example, the country code for USA is "840." The maximum length is 3 characters.

This field is used for American Express transactions that are submitted via an Aggregator/Payment Service Provider. It is used to identify the Aggregator's e-mail address. The maximum length is 20 characters and if necessary this value should be truncated rather than abbreviated.

This field is used to identify the merchant name that appears on the storefront and/or customer receipts and statements. The maximum length is 38 characters (upper-case). For American Express transactions that are submitted via an Aggregator/Payment Service Provider the maximum length is 30 characters and if necessary this value should be truncated rather than abbreviated.

This field is used for American Express transactions that are submitted via an Aggregator/Payment Service Provider. It is used to identify the Aggregator's phone number. This value should be 10 characters in length and it must include the area code.

This field is used to identify the postal / zip code of the location where the transaction took place. The maximum length is 15 characters. For American Express transactions that are submitted via an Aggregator/Payment Service Provider the maximum length is 10 characters.

This field is used to identify the region code that corresponds to the state, province, or other country subdivision of the merchant location where the transaction took place. The maximum length is 3 characters.

This 3-character value provides information about transactions initiated through the Masterpass Online platform or through the Mastercard Digital Enablement Service (MDES) and identifies the Wallet Provider. For MDES, Mastercard inserts the Wallet Identifier that is in the system, when available. For Masterpass, Mastercard passes the Wallet Identifier as sent in from the Point of Sale.

The following values apply to both Masterpass and MDES transactions:

The following values only apply to MDES transactions:

This is the maximum number of outstanding transactions that have not yet received a response. This should not exceed the maximum number of 10 interleaved transactions that can be sent at the same time. If an authorization is attempted that would exceed the maximum number of pending response an error occurs.

The default value is 10.

This field contains a two digit language indicator. This value designates the language to be used in formatting the authorization response text message.

This field is used for American Express transactions that are submitted via an Aggregator/Payment Service Provider. It contains a maximum 20-byte numeric code that uniquely identifies an American Express Payment Service Provider's (Aggregator's) seller or vendor code.

This field is used to identify Merchant Initiated or Deferred Authorizations for Visa.

Merchant Initiated Transactions A Merchant Initiated Transaction (MIT) is any transaction that relates to the previous consumer-initiated transaction but is conducted without the consumer being present and without any cardholder validation performed. Valid values are:

Deferred Authorizations If the merchant's Point-of-Interaction (POI) authorization system is offline and cannot process transactions, the merchant often completes the transaction with the cardholder and will then defer the authorization until their POI system is back online. Valid value is:

This configuration setting is required when sending an Merchant Initiated Transaction, when the IsMerchantInitiatedTransaction is set to 'True'. It should be set with the ResponseTransactionId from the original (first) authorization. This configuration setting is required when sending MIT Recurring, MIT Installment, MIT Standing Instruction or MIT Industry Practice transactions. To send an MIT Standing Instruction you need to set the POSEnvironmentIndicator to specify the type of merchant initiated transaction. To send an MIT Industry Practice you need to set the MessageReasonCode to specify the reason for this merchant initiated transaction.

Note: For Merchant Initiated Transactions you need to set the POSDataCode.CardInputMode to '7'.

The Merchant Payment Gateway Identifier (MPGID) is a unique value that is generated and provisioned by Mastercard. Payment gateways must register directly with Mastercard to obtain a unique value, and include it on the incoming authorization message. Maximum length for this field is 11 digits.

This configuration setting is required for Discover Merchant Initiated Transactions (MIT) with TransactionStatus: (P) Partial Shipment, (R) Recurring Payment, or (A) Re-authorize for Full Amount. It should be used in conjunction with OriginalAmountAccountType. The control will send the OriginalAmount on group G3v022 with amount type 57 (Original Amount).

Note: When supporting MIT transactions for Discover cards, you must keep track of the Original Amount from the initial CIT transaction.

This 2-character value configuration setting indicates the account type such as "30" for Credit Card, "40" for Universal etc. (see TSYS Specs G3v022 for complete list). It should be used in conjunction with OriginalAmount.

This unique digit internal identification code is assigned by the Acquirer to it's merchant. Discover assigns this 20-character field during registration via the Discover Network.

This 3-character field is used by marketplaces to uniquely identify domestic transactions in which the retailer is in a different country than the marketplace. Visa classifies an entity as a marketplace if it handles payments on behalf of retailers through an online marketplace that brings together multiple buyers and retailers. This field must be sent when the retailer is foreign.

Valid values are:

This 11-digit value is assigned to the Service Provider during registration with the card brand and must be included on all Visa, MasterCard, or Discover transactions where the merchant has a relationship with a Payment Facilitator/Service Provider.

Note: For Visa Marketplaces, the Marketplace ID must be included in this field.

This 25-character field is a subfield of Payment Facilitator and must be included on all transactions where the merchant has a relationship with a Payment Facilitator. It has two usages:

Usage 1 - Payment Facilitator Name*Sub-Merchant Name

This usage is valid for Visa, Mastercard, and Discover.

For Payment Facilitators, the field contains two parts in a concatenation of two fields separated by an asterisk (*). For Visa, Mastercard, and Discover the name submitted should match what the PayFac registered with each brand and should follow the requirements defined by each brand.

Usage 2 - Marketplace Name

For Visa Marketplaces, the field should contain the name of the Marketplace.

This 13-character field is a subfield of Payment Facilitator.

For Visa and Mastercard transactions, enter the city of the sub-merchant location (not the Payment Facilitator location).

For Discover transactions, enter the location where the transaction took place; this may or may not be the sub-merchant location.

For Direct Marketing merchants and preferred customer/passenger transport and card not present transactions, this field must contain a phone number for merchant customer service in format XXX-XXXXXXX. The dash is required. This field can also be used for e-mail or a URL.

This 3-digit field indicates the country of the Sub-Merchant location (not the Payment Facilitator location) using ISO-specified numeric codes. It is used for Visa, Mastercard, and Discover transactions and must be included on all transactions where the merchant has a relationship with a Payment Facilitator.

This 15-character field, assigned by the Payment Facilitator or the Acquirer, must be provided on all Visa, Mastercard, or Discover transactions where the merchant has a relationship with a Payment Facilitator.

This 9-character field indicates the postal code of the Sub-Merchant location (not the Payment Facilitator location). This field must be included on all transactions where the merchant has a relationship with a Payment Facilitator. It is used for Visa, Mastercard, and Discover transactions.

This 2-character field indicates the state or province code of the Sub-Merchant location (not the Payment Facilitator location). If the Sub-Merchant is non-U.S. and non-Canadian, this field should be '00'. This field must be included on all Visa, Mastercard, and Discover transactions where the merchant has a relationship with a Payment Facilitator.

This is port that this control connects to on the server. The default value for TSYS is 5003 for the live server, and 5004 for the test server. The default live server values for Heartland is 22341 for Authorization and 22342 for Settlement. The Heartland test server values are 12341 for Authorization and 12342 for Settlement.

This configuration setting takes a semi-colon separated list of name-value pairs. The available field names and their applicable values can be found below. The fields can be set in any order and not all fields are required to be set (unless you wish to change their default values).

Code Example: TSYSRetail.Config("POSDataCode=CardholderAuthCap=1;CardInputMode=2;CardInputCap=2");

CardInputCap (Terminal card data input capability)

CardholderAuthCap (Terminal cardholder authentication capability)

CardCaptureCap (Terminal card-capture capability)

TerminalOpEnv (Terminal operating environment)

CardholderPresent (Cardholder present data)

CardPresent (Card present data)

CardInputMode (Card data input mode)

NOTE: AMEX defines ApplePay with value C - Online Chip

CardholderAuthMethod (Cardholder authentication method)

CardholderAuthEntity (Cardholder authentication entity)

CardOutputCap (Card data output capability)

TerminalOutputCap (Terminal data output capability)

PINCaptureCap (PIN capture capability)

Note: Setting this configuration setting in TSYSDetailRecord control will not update the POSDataCode tag in the detail aggregate of the original transaction.

This Visa only configuration setting is used to provide additional information about the transaction. This value should be set in the following scenarios with the respective values:

If the merchant initiates a transaction using a stored payment credential, the value in POSDataCode.CardInputMode should be '7' for Credential on File transactions.

This field allows you to specify the processor that you are connecting to (thus allowing the control to correctly generate the request and parse the response). The available values are:

Note that when set, this property will set the Server and Port to the default values for the specified processor. Additionally, this config must be set prior to setting Card to ensure the card data is formatted correctly.

The Program Protocol must be provided by the merchant if they are using the Mastercard Identity Check program to authenticate the cardholder. This value identifies the version of the EMV 3D-Secure protocol and it is the merchant's responsibility to know which version applies. Allowable values are:

To achieve the best interchange rate for Direct Marketing (e-commerce and MOTO) transactions, you may be required to send 25-character purchase identifier in the settlement. Normally this would require the use of the TSYSDetailRecord control to add the purchase Id to the detail aggregate before adding that aggregate to the batch. However, setting the PurchaseIdentifier configuration setting will include the identifier when calling the GetDetailAggregate method, so that the intermediary steps using the TSYSDetailRecord control are unnecessary.

For instance, instead of this: TSYSECommerce.Authorize() DetailRecord.ParseAggregate(TSYSECommerce.GetDetailAggregate()) DetailRecord.PurchaseIdentifier = "123456" TSYSSettle.DetailAggreate[0] = DetailRecord.GetDetailAggregate() You can do this: TSYSECommerce.Config("PurchaseIdentifier=123456") TSYSECommerce.Authorize() TSYSSettle.DetailAggregate[0] = TSYSECommerce.GetDetailAggregate()

This configuration setting is used to specify the date when the cardholder last voluntarily changed his or her registered profile (Discover, Diners, JCB, and CUP transactions only). The format for this field is DDMMYYYY.

When set to 'True' prior to an Authorize request, a token will be requested for the specified Card data. Provided the authorization and token generation was successful, a token will be returned in the response and can be retrieved via Token. Additionally the status of the token will be returned via ResponseTokenStatus. The returned token can then be used to process future transactions without the use of Card data with the exception of the expiration details. The default value is 'False'.

NOTE: When using this request, verification and authorization of the card will be performed.

This response data is returned when SendExtendedAVS is set to 'True' and is only available for American Express and Discover cards. This data is arranged in order of 5 bytes, one for each result of a cardholder identification data element:

The possible values for each byte are:

For Discover transactions, byte 3 will be populated with the following values:

This CAVV Result code indicates whether the authentication value submitted in the CAVV field can be validated by either Visa or the card issuer. The table below shows the possible values returned from Vital/TSYS.

Possible returned values are:

The value of this field is used to correctly match responses with transactions by comparing its value to that of the MerchantStoreNumber. This is particularly useful when making a multi-merchant or multi-store routing system. If the system that originally made the transaction receives a response where the ResponseStoreNumber is not identical to the MerchantStoreNumber the transaction should not be stored for batch settlement. This field is read-only.

The value of this field is used to correctly match responses with transactions by comparing its value to that of MerchantTerminalNumber. This is particularly useful when making a multi-terminal routing system within a merchant location. If the terminal that originally made the transaction receives a response where the ResponseTerminalNumber is not identical to the MerchantTerminalNumber, the transaction should not be stored for batch settlement. This field is read-only.

This read only configuration setting if returned in the Response message contains 4 characters that represent the last 4 digits of the actual cardholder PAN. This can be used to print on the paper receipt for cardholder reference.

This field will be populated after a token is requested via RetrieveToken or RequestToken. The applicable values are:

This read-only configuration setting contains a 2-character value when returned in the response of MasterCard Credit transactions. This value encompasses the fundamental safety and security of credit transactions, including the assessment of both the validity of the card and the cardholder.

This UCAF Result code indicates the security level and cardholder authentication associated with the transaction. Mastercard's processing rules allow merchants to gain a liability shift and interchange benefit if they submit their electronic commerce transactions for cardholder authentication. If the cardholder authentication detail is not present in UCAFData field for MasterCard SecureCode transactions, MasterCard will downgrade and send the transaction to the Issuer. This field is read-only and is only returned for MasterCard SecureCode E-Commerce transactions to indicate if the transaction was downgraded or not.

This is an action config which when called will send a token only request to the TSYS Host. Provided the request was successful, a token will be returned for the specified Card. The token can be retrieved via Token and the status of the token will be returned via ResponseTokenStatus. For this request, no card verification or authorization will be performed.

If an authorization returns ambiguously or times out without receiving a response, you may send the same transaction over again with this Retry flag set to True. This will prevent you from double-charging your customers in the case of a communications error (only available for credit card transactions. Does not apply to Debit, Gift Card, or EBT transactions).

If set to True (default), the ResponseCommercialCardType property will indicate whether the credit card submitted for authorization is a Business, Corporate, or Purchasing Card (this is the default function). If False, the contents of the ResponseCommercialCardType property must be ignored.

When set to 'True', AVS data will be sent in the extended AVS field for the transaction. ResponseCardholderVerification will contain the extended AVS verification results. When set to 'False' (default value), the CustomerAddress and CustomerZip values will be sent using the simple AVS data fields.

This is name of the server to which all transactions are posted. Do not use an IP address, use the actual name, as a server's IP address may change. The default (Live) TSYS server is "ssl2.vitalps.net", but you may use "ssltest.tsysacquiring.net" for testing. The default (Live) Heartland server is "txns.secureexchange.net", but you may use "test.txns.secureexchange.net" for testing. Note that there are several MerchantBankIds and MerchantNumbers that will always run in test mode regardless of whether you are using the live server. See the included demos for examples.

This field contains the name of the city where the cardholder received the services, if it is different from the location identified by the acceptor city name. This value will be sent as part of group G3v089 in authorization and group ODG41 (Tag: "SLD") in settlement.

The maximum length for this field is 13 characters.

This field contains the code of the country where the cardholder received the services, if it is different from the location identified by the acceptor country code. This value will be sent as part of group G3v089 in authorization and group ODG41 (Tag: "SLD") in settlement.

The maximum length for this field is 3 characters.

This field contains the code of the country subdivision where the cardholder received the services, if it is different from the location identified by the acceptor country subdivision code. This value will be sent as part of group G3v089 in authorization and group ODG41 (Tag: "SLD") in settlement.

The maximum length for this field is 3 characters.

This field contains the postal code of the country where the cardholder received the services, if it is different. This value will be sent as part of group G3v089 in authorization and group ODG41 (Tag: "SLD") in settlement.

The maximum length for this field is 10 characters.

This field describes selected special conditions at the point of sale.

Valid values are:

This configuration setting is for informational purposes only and any surcharge amounts charged to the customer should be included in the TransactionAmount.

The format of this field is 'annnnnnnn' where 'a' is either 'D' for debit or 'C' for credit. 'nnnnnnnn' is the numeric fee amount with the decimal implied. For example: 'D00000150' is a $1.50 transaction fee amount debited to the cardholder's account.

Note: If an amount is only specified, the component will generate the format above by prepending a 'D' and the necessary number of 0's.

The Transaction Link Identifier (TLID) is used to track the life cycle of activity occurring after the original transaction and other related transactions. The TLID will be returned by Mastercard in the authorization response message. The returned value will also be present in the aggregate returned from the GetDetailAggregate method and for all subsequent transactions that utilize the aggregate (such as reversals, incrementals, settlement) the value will be automatically included in the request. When not utilizing the aggregate, you may explicitly set this config with the TLID value that was saved when the original transaction was performed.

This field will contain the token received from TSYS from either a RetrieveToken or RequestToken request. This field is also used to specify a token value, used in place of Card data, to be sent in an Authorize request. The token is formatted as a card number, with the last 4 digits preserved. Other characters in the number will be letters rather than numbers. Tokens are used as an added security measure to protect a customer's Card and may also help decrease PCI Compliance verification as storing credit card data is no longer needed.

This eleven digit value is used for Card Brand Tokenization only. If present, this configuration setting should be included in the authorization request. The component will send this value as part of group G3v062.

If Card Brand Token Requestor ID was present in the original transaction it must be included in a reversal message.

Note: The component will also send this value as part of DetailExtension Config of TSYSDetailRecord control (Group ODG41 - tag "TRI").

Use this 1-character configuration setting to indicate the purpose or status of the request.

The tables below provide the valid values for each card brand.

Valid value for Visa is:

Valid values for Mastercard are:

Valid values for Discover are:

Note: For Purchase Return Authorization Requests: Value must be 0 (Mastercard and Discover).

This field is used to specify the Base-64 encoded ETB (Encryption Transmission Block) used by TSYS to decrypt Voltage encrypted data. The value is retrieved from the POS device containing the Voltage encryption software. When specified, the transaction will be sent as a Voltage encrypted transaction. The encrypted card data will be specified as normal via the CardMagneticStripe or CardNumber fields.

This configuration setting is used to pass encoded MasterCard SecureCode issuer or cardholder-generated authentication data. This is a variable length security field up to 32 bytes in length. This setting is only valid for MasterCard E-Commerce transactions.

This configuration setting is used to pass the UCAF Collection Indicator in MasterCard SecureCode e-commerce credit transactions. Mastercard's processing rules allow merchants to gain a liability shift and interchange benefit if they submit their electronic commerce transactions for cardholder authentication. Merchants need to pass the appropriate authentication detail in UCAFData. Other values necessary for passing SecureCode data include UCAFData and ECI. This setting is required in all MasterCard SecureCode E-Commerce transactions. The valid values for this configuration setting are:

This configuration setting is used to pass the UCAF electronic commerce indicators representing the security level and cardholder authentication associated with the transaction. Mastercard's processing rules allow merchants to gain a liability shift and interchange benefit if they submit their electronic commerce transactions for cardholder authentication. Merchants need to pass the appropriate authentication detail in UCAFData. Other values necessary for passing SecureCode data include UCAFIndicator, UCAFData and ECI. This setting is recommended in all MasterCard SecureCode E-Commerce transactions. The valid values for this configuration setting are:

This setting is used to pass the 3D Secure TransactionId (XID) data on to the credit card processor. This setting must be formatted as a 20-byte plaintext value, or a 28-byte Base-64 encoded value. This control may be used in conjunction with the ThreeDSecure control from the E-Payment Integrator toolkit or with any other 3D Secure MPI implementation. For example: Other settings necessary for passing 3D Secure data are CAVV and ECI. This setting is only valid for E-Commerce transactions.

When set, this configuration setting allows you to specify a different timeout value for establishing a connection. Otherwise, the control will use Timeout for establishing a connection and transmitting/receiving data.

This configuration setting is provided for use by controls that do not directly expose Firewall properties.

If a FirewallHost is given, requested connections will be authenticated through the specified firewall when connecting.

If the FirewallHost setting is set to a Domain Name, a DNS request is initiated. Upon successful termination of the request, the FirewallHost setting is set to the corresponding address. If the search is not successful, an error is returned.

Note: This setting is provided for use by controls that do not directly expose Firewall properties.

If FirewallHost is specified, the FirewallUser and FirewallPassword settings are used to connect and authenticate to the given firewall. If the authentication fails, the control fails with an error.

Note: This setting is provided for use by controls that do not directly expose Firewall properties.

The FirewallPort is set automatically when FirewallType is set to a valid value.

Note: This configuration setting is provided for use by controls that do not directly expose Firewall properties.

The appropriate values are as follows:

Note: This setting is provided for use by controls that do not directly expose Firewall properties.

If the FirewallHost is specified, the FirewallUser and FirewallPassword settings are used to connect and authenticate to the Firewall. If the authentication fails, the control fails with an error.

Note: This setting is provided for use by controls that do not directly expose Firewall properties.

When set, TCPKeepAlive will automatically be set to True. A TCP keep-alive packet will be sent after a period of inactivity as defined by KeepAliveTime. If no acknowledgment is received from the remote host, the keep-alive packet will be sent again. This configuration setting specifies the interval at which the successive keep-alive packets are sent in milliseconds. This system default if this value is not specified here is 1 second.

Note: This value is not applicable in macOS.

When set, TCPKeepAlive will automatically be set to True. By default, the operating system will determine the time a connection is idle before a Transmission Control Protocol (TCP) keep-alive packet is sent. This system default if this value is not specified here is 2 hours. In many cases, a shorter interval is more useful. Set this value to the desired interval in milliseconds.

This property controls how a connection is closed. The default is True.

In the case that Linger is True (default), two scenarios determine how long the connection will linger. In the first, if LingerTime is 0 (default), the system will attempt to send pending data for a connection until the default IP timeout expires.

In the second scenario, if LingerTime is a positive value, the system will attempt to send pending data until the specified LingerTime is reached. If this attempt fails, then the system will reset the connection.

The default behavior (which is also the default mode for stream sockets) might result in a long delay in closing the connection. Although the control returns control immediately, the system could hold system resources until all pending data are sent (even after your application closes).

Setting this property to False forces an immediate disconnection. If you know that the other side has received all the data you sent (e.g., by a client acknowledgment), setting this property to False might be the appropriate course of action.

LingerTime is the time, in seconds, the socket connection will linger. This value is 0 by default, which means it will use the default IP timeout.

The LocalHost setting contains the name of the local host as obtained by the gethostname() system call, or if the user has assigned an IP address, the value of that address.

In multi-homed hosts (machines with more than one IP interface) setting LocalHost to the value of an interface will make the control initiate connections (or accept in the case of server controls) only through that interface.

If the control is connected, the LocalHost setting shows the IP address of the interface through which the connection is made in internet dotted format (aaa.bbb.ccc.ddd). In most cases, this is the address of the local host, except for multi-homed hosts (machines with more than one IP interface).

This must be set before a connection is attempted. It instructs the control to bind to a specific port (or communication endpoint) in the local machine.

Setting this to 0 (default) enables the system to choose a port at random. The chosen port will be shown by LocalPort after the connection is established.

LocalPort cannot be changed once a connection is made. Any attempt to set this when a connection is active will generate an error.

This; setting is useful when trying to connect to services that require a trusted port in the client side. An example is the remote shell (rsh) service in UNIX systems.

MaxLineLength is the size of an internal buffer, which holds received data while waiting for an EOL string.

If an EOL string is found in the input stream before MaxLineLength bytes are received, the DataIn event is fired with the EOL parameter set to True, and the buffer is reset.

If no EOL is found, and MaxLineLength bytes are accumulated in the buffer, the DataIn event is fired with the EOL parameter set to False, and the buffer is reset.

The minimum value for MaxLineLength is 256 bytes. The default value is 2048 bytes.

This configuration setting can be used to throttle outbound TCP traffic. Set this to the number of bytes to be sent per second. By default, this is not set and there is no limit.

This configuration setting optionally specifies a semicolon-separated list of hostnames or IP addresses to bypass when a proxy is in use. When requests are made to hosts specified in this property, the proxy will not be used. For instance:

www.google.com;www.nsoftware.com

If set to True, the socket's keep-alive option is enabled and keep-alive packets will be sent periodically to maintain the connection. Set KeepAliveTime and KeepAliveInterval to configure the timing of the keep-alive packets.

Note: This value is not applicable in Java.

When true, the socket will send all data that is ready to send at once. When false, the socket will send smaller buffered packets of data at small intervals. This is known as the Nagle algorithm.

By default, this config is set to false.

When set to 0 (default), the control will use IPv4 exclusively. When set to 1, the control will use IPv6 exclusively. To instruct the control to prefer IPv6 addresses, but use IPv4 if IPv6 is not supported on the system, this setting should be set to 2. The default value is 0. Possible values are:

When SSLProvider is set to Internal, this setting controls whether SSL packets should be logged. By default, this setting is False, as it is only useful for debugging purposes.

When enabled, SSL packet logs are output using the SSLStatus event, which will fire each time an SSL packet is sent or received.

Enabling this setting has no effect if SSLProvider is set to Platform.

This functionality is available only when the provider is OpenSSL.

The path set by this property should point to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). OpenSSL recommends to use the c_rehash utility to create the necessary links. Please refer to the OpenSSL man page SSL_CTX_load_verify_locations(3) for details.

This functionality is available only when the provider is OpenSSL.

The file set by this property should contain a list of CA certificates in PEM format. The file can contain several CA certificates identified by

-----BEGIN CERTIFICATE-----

... (CA certificate in base64 encoding) ...

-----END CERTIFICATE-----

sequences. Before, between, and after the certificates text is allowed which can be used e.g. for descriptions of the certificates. Please refer to the OpenSSL man page SSL_CTX_load_verify_locations(3) for details.

This functionality is available only when the provider is OpenSSL.

The format of this string is described in the OpenSSL man page ciphers(1) section "CIPHER LIST FORMAT". Please refer to it for details. The default string "DEFAULT" is determined at compile time and is normally equivalent to "ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH".

This functionality is available only when the provider is OpenSSL.

By default OpenSSL uses the device file "/dev/urandom" to seed the PRNG and setting OpenSSLPrngSeedData is not required. If set, the string specified is used to seed the PRNG.

If set to true, the control will reuse the context if and only if the following criteria are met:

• The target host name is the same.
• The system cache entry has not expired (default timeout is 10 hours).
• The application process that calls the function is the same.
• The logon session is the same.
• The instance of the control is the same.

This setting specifies one or more CA certificates to be included in the request when performing SSL client authentication. Some servers require the entire chain, including CA certificates, to be presented when performing SSL client authentication. The value of this setting is a newline (CrLf) separated list of certificates. For instance:

-----BEGIN CERTIFICATE-----
MIIEKzCCAxOgAwIBAgIRANTET4LIkxdH6P+CFIiHvTowDQYJKoZIhvcNAQELBQAw
...
eWHV5OW1K53o/atv59sOiW5K3crjFhsBOd5Q+cJJnU+SWinPKtANXMht+EDvYY2w
F0I1XhM+pKj7FjDr+XNj
-----END CERTIFICATE-----
\r \n
-----BEGIN CERTIFICATE-----
MIIEFjCCAv6gAwIBAgIQetu1SMxpnENAnnOz1P+PtTANBgkqhkiG9w0BAQUFADBp
..
d8q23djXZbVYiIfE9ebr4g3152BlVCHZ2GyPdjhIuLeH21VbT/dyEHHA
-----END CERTIFICATE-----

This setting specifies whether the control will check the Certificate Revocation List specified by the server certificate. If set to 1 or 2, the control will first obtain the list of CRL URLs from the server certificate's CRL distribution points extension. The control will then make HTTP requests to each CRL endpoint to check the validity of the server's certificate. If the certificate has been revoked or any other issues are found during validation the control fails with an error.

When set to 0 (default) the CRL check will not be performed by the control. When set to 1, it will attempt to perform the CRL check, but will continue without an error if the server's certificate does not support CRL. When set to 2, it will perform the CRL check and will throw an error if CRL is not supported.

This configuration setting is only supported in the Java, C#, and C++ editions. In the C++ edition, it is only supported on Windows operating systems.

This setting specifies whether the control will use OCSP to check the validity of the server certificate. If set to 1 or 2, the control will first obtain the OCSP URL from the server certificate's OCSP extension. The control will then locate the issuing certificate and make an HTTP request to the OCSP endpoint to check the validity of the server's certificate. If the certificate has been revoked or any other issues are found during validation the control fails with an error.

When set to 0 (default) the control will not perform an OCSP check. When set to 1, it will attempt to perform the OCSP check, but will continue without an error if the server's certificate does not support OCSP. When set to 2, it will perform the OCSP check and will throw an error if OCSP is not supported.

This configuration setting is only supported in the Java, C#, and C++ editions. In the C++ edition, it is only supported on Windows operating systems.

This minimum cipher strength largely dependent on the security modules installed on the system. If the cipher strength specified is not supported, an error will be returned when connections are initiated.

Please note that this setting contains the minimum cipher strength requested from the security library. The actual cipher strength used for the connection is shown by the SSLStatus event.

Use this setting with caution. Requesting a lower cipher strength than necessary could potentially cause serious security vulnerabilities in your application.

When the provider is OpenSSL, SSLCipherStrength is currently not supported. This functionality is instead made available through the OpenSSLCipherList config setting.

The enabled cipher suites to be used in SSL negotiation.

By default, the enabled cipher suites will include all available ciphers ("*").

The special value "*" means that the control will pick all of the supported cipher suites. If SSLEnabledCipherSuites is set to any other value, only the specified cipher suites will be considered.

Multiple cipher suites are separated by semicolons.

Example values when SSLProvider is set to Platform: obj.config("SSLEnabledCipherSuites=*"); obj.config("SSLEnabledCipherSuites=CALG_AES_256"); obj.config("SSLEnabledCipherSuites=CALG_AES_256;CALG_3DES"); Possible values when SSLProvider is set to Platform include:

• CALG_3DES
• CALG_3DES_112
• CALG_AES
• CALG_AES_128
• CALG_AES_192
• CALG_AES_256
• CALG_AGREEDKEY_ANY
• CALG_CYLINK_MEK
• CALG_DES
• CALG_DESX
• CALG_DH_EPHEM
• CALG_DH_SF
• CALG_DSS_SIGN
• CALG_ECDH
• CALG_ECDH_EPHEM
• CALG_ECDSA
• CALG_ECMQV
• CALG_HASH_REPLACE_OWF
• CALG_HUGHES_MD5
• CALG_HMAC
• CALG_KEA_KEYX
• CALG_MAC
• CALG_MD2
• CALG_MD4
• CALG_MD5
• CALG_NO_SIGN
• CALG_OID_INFO_CNG_ONLY
• CALG_OID_INFO_PARAMETERS
• CALG_PCT1_MASTER
• CALG_RC2
• CALG_RC4
• CALG_RC5
• CALG_RSA_KEYX
• CALG_RSA_SIGN
• CALG_SCHANNEL_ENC_KEY
• CALG_SCHANNEL_MAC_KEY
• CALG_SCHANNEL_MASTER_HASH
• CALG_SEAL
• CALG_SHA
• CALG_SHA1
• CALG_SHA_256
• CALG_SHA_384
• CALG_SHA_512
• CALG_SKIPJACK
• CALG_SSL2_MASTER
• CALG_SSL3_MASTER
• CALG_SSL3_SHAMD5
• CALG_TEK
• CALG_TLS1_MASTER
• CALG_TLS1PRF

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
• TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (Not Recommended)
• TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (Not Recommended)
• TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (Not Recommended)
• TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (Not Recommended)
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_DHE_RSA_WITH_DES_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA

When TLS 1.3 is negotiated (see SSLEnabledProtocols) only the following cipher suites are supported:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

SSLEnabledCipherSuites is used together with SSLCipherStrength.

Used to enable/disable the supported security protocols.

Not all supported protocols are enabled by default (the value of this setting is 4032). If you want more granular control over the enabled protocols, you can set this property to the binary 'OR' of one or more of the following values:

SSLEnabledProtocols - TLS 1.3 Notes

By default when TLS 1.3 is enabled the control will use the internal TLS implementation when the SSLProvider is set to Automatic for all editions.

In editions which are designed to run on Windows SSLProvider can be set to Platform to use the platform implementation instead of the internal implementation. When configured in this manner, please note that the platform provider is only supported on Windows 11 / Windows Server 2022 and up. The default internal provider is available on all platforms and is not restricted to any specific OS version.

If set to 1 (Platform provider) please be aware of the following notes:

• The platform provider is only available on Windows 11 / Windows Server 2022 and up.
• SSLEnabledCipherSuites and other similar SSL configuration settings are not supported.
• If SSLEnabledProtocols includes both TLS 1.3 and TLS 1.2 the above restrictions are still applicable even if TLS 1.2 is negotiated. Enabling TLS 1.3 with the platform provider changes the implementation used for all TLS versions.

SSLEnabledProtocols: SSL2 and SSL3 Notes:

SSL 2.0 and 3.0 are not supported by the control when the SSLProvider is set to internal. To use SSL 2.0 or SSL 3.0, the platform security API must have the protocols enabled and SSLProvider needs to be set to platform.

This setting specifies whether the renegotiation_info SSL extension will be used in the request when using the internal security API. This setting is by default, but can be set to to disable the extension.

This setting is only applicable when SSLProvider is set to Internal.

This setting specifies whether the Encoded parameter of the SSLServerAuthentication event contains the full certificate chain. By default this value is False and only the leaf certificate will be present in the Encoded parameter of the SSLServerAuthentication event.

If set to True all certificates returned by the server will be present in the Encoded parameter of the SSLServerAuthentication event. This includes the leaf certificate, any intermediate certificate, and the root certificate.

This setting optionally specifies the full path to a file on disk where per-session secrets are stored for debugging purposes.

When set, the control will save the session secrets in the same format as the SSLKEYLOGFILE environment variable functionality used by most major browsers and tools such as Chrome, Firefox, and cURL. This file can then be used in tools such as Wireshark to decrypt TLS traffice for debugging purposes. When writing to this file the control will only append, it will not overwrite previous values.

Note: This setting is only applicable when SSLProvider is set to Internal.

Returns the cipher suite negotiated during the SSL handshake.

Note: For server components (e.g. TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedCipher[connId]");

Returns the strength of the cipher suite negotiated during the SSL handshake.

Note: For server components (e.g.TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedCipherStrength[connId]");

Returns the cipher suite negotiated during the SSL handshake represented as a single string.

Note: For server components (e.g. TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedCipherSuite[connId]");

Returns the key exchange algorithm negotiated during the SSL handshake.

Note: For server components (e.g. TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedKeyExchange[connId]");

Returns the strenghth of the key exchange algorithm negotiated during the SSL handshake.

Note: For server components (e.g. TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedKeyExchangeStrength[connId]");

Returns the protocol version negotiated during the SSL handshake.

Note: For server components (e.g. TCPServer) this is a per-connection setting accessed by passing the ConnectionId. For example: server.Config("SSLNegotiatedVersion[connId]");

The following flags are defined (specified in hexadecimal notation). They can be or-ed together to exclude multiple conditions:

This functionality is currently not available when the provider is OpenSSL.

This setting optionally specifies one or more CA certificates to be used when verifying the server certificate. When verifying the server's certificate the certificates trusted by the system will be used as part of the verification process. If the server's CA certificates are not installed to the trusted system store, they may be specified here so they are included when performing the verification process. This setting should only be set if the server's CA certificates are not already trusted on the system and cannot be installed to the trusted system store.

The value of this setting is a newline (CrLf) separated list of certificates. For instance:

-----BEGIN CERTIFICATE-----
MIIEKzCCAxOgAwIBAgIRANTET4LIkxdH6P+CFIiHvTowDQYJKoZIhvcNAQELBQAw
...
eWHV5OW1K53o/atv59sOiW5K3crjFhsBOd5Q+cJJnU+SWinPKtANXMht+EDvYY2w
F0I1XhM+pKj7FjDr+XNj
-----END CERTIFICATE-----
\r \n
-----BEGIN CERTIFICATE-----
MIIEFjCCAv6gAwIBAgIQetu1SMxpnENAnnOz1P+PtTANBgkqhkiG9w0BAQUFADBp
..
d8q23djXZbVYiIfE9ebr4g3152BlVCHZ2GyPdjhIuLeH21VbT/dyEHHA
-----END CERTIFICATE-----

This setting specifies the allowed server certificate signature algorithms when SSLProvider is set to Internal and SSLEnabledProtocols is set to allow TLS 1.2.

When specified the control will verify that the server certificate signature algorithm is among the values specified in this setting. If the server certificate signature algorithm is unsupported the control fails with an error.

The format of this value is a comma separated list of hash-signature combinations. For instance: component.SSLProvider = TCPClientSSLProviders.sslpInternal; component.Config("SSLEnabledProtocols=3072"); //TLS 1.2 component.Config("TLS12SignatureAlgorithms=sha256-rsa,sha256-dsa,sha1-rsa,sha1-dsa"); The default value for this setting is sha512-ecdsa,sha512-rsa,sha512-dsa,sha384-ecdsa,sha384-rsa,sha384-dsa,sha256-ecdsa,sha256-rsa,sha256-dsa,sha224-ecdsa,sha224-rsa,sha224-dsa,sha1-ecdsa,sha1-rsa,sha1-dsa.

In order to not restrict the server's certificate signature algorithm, specify an empty string as the value for this setting, which will cause the signature_algorithms TLS 1.2 extension to not be sent.

This setting specifies a comma separated list of named groups used in TLS 1.2 for ECC.

The default value is ecdhe_secp256r1,ecdhe_secp384r1,ecdhe_secp521r1.

When using TLS 1.2 and SSLProvider is set to Internal, the values refer to the supported groups for ECC. The following values are supported:

• "ecdhe_secp256r1" (default)
• "ecdhe_secp384r1" (default)
• "ecdhe_secp521r1" (default)

This setting specifies a comma separated list of named groups used in TLS 1.3 for key exchange. The groups specified here will have key share data pregenerated locally before establishing a connection. This can prevent an additional round trip during the handshake if the group is supported by the server.

The default value is set to balance common supported groups and the computational resources required to generate key shares. As a result only some groups are included by default in this setting.

Note: All supported groups can always be used during the handshake even if not listed here, but if a group is used which is not present in this list it will incur an additional round trip and time to generate the key share for that group.

In most cases this setting does not need to be modified. This should only be modified if there is a specific reason to do so.

The default value is ecdhe_x25519,ecdhe_secp256r1,ecdhe_secp384r1,ffdhe_2048,ffdhe_3072

The values are ordered from most preferred to least preferred. The following values are supported:

• "ecdhe_x25519" (default)
• "ecdhe_x448"
• "ecdhe_secp256r1" (default)
• "ecdhe_secp384r1" (default)
• "ecdhe_secp521r1"
• "ffdhe_2048" (default)
• "ffdhe_3072" (default)
• "ffdhe_4096"
• "ffdhe_6144"
• "ffdhe_8192"

This setting holds a comma separated list of allowed signature algorithms. Possible values are:

• "ed25519" (default)
• "ed448" (default)
• "ecdsa_secp256r1_sha256" (default)
• "ecdsa_secp384r1_sha384" (default)
• "ecdsa_secp521r1_sha512" (default)
• "rsa_pkcs1_sha256" (default)
• "rsa_pkcs1_sha384" (default)
• "rsa_pkcs1_sha512" (default)
• "rsa_pss_sha256" (default)
• "rsa_pss_sha384" (default)
• "rsa_pss_sha512" (default)

This setting specifies a comma separated list of named groups used in TLS 1.3 for key exchange. This setting should only be modified if there is a specific reason to do so.

The default value is ecdhe_x25519,ecdhe_x448,ecdhe_secp256r1,ecdhe_secp384r1,ecdhe_secp521r1,ffdhe_2048,ffdhe_3072,ffdhe_4096,ffdhe_6144,ffdhe_8192

The values are ordered from most preferred to least preferred. The following values are supported:

• "ecdhe_x25519" (default)
• "ecdhe_x448" (default)
• "ecdhe_secp256r1" (default)
• "ecdhe_secp384r1" (default)
• "ecdhe_secp521r1" (default)
• "ffdhe_2048" (default)
• "ffdhe_3072" (default)
• "ffdhe_4096" (default)
• "ffdhe_6144" (default)
• "ffdhe_8192" (default)

If AbsoluteTimeout is set to True, any method which does not complete within Timeout seconds will be aborted. By default, AbsoluteTimeout is False, and the timeout is an inactivity timeout.

Note: This option is not valid for UDP ports.

When the firewall is a tunneling proxy, use this property to send custom (additional) headers to the firewall (e.g. headers for custom authentication schemes).

This is the size of an internal queue in the TCP/IP stack. You can increase or decrease its size depending on the amount of data that you will be receiving. Increasing the value of the InBufferSize setting can provide significant improvements in performance in some cases.

Some TCP/IP implementations do not support variable buffer sizes. If that is the case, when the control is activated the InBufferSize reverts to its defined size. The same happens if you attempt to make it too large or too small.

This is the size of an internal queue in the TCP/IP stack. You can increase or decrease its size depending on the amount of data that you will be sending. Increasing the value of the OutBufferSize setting can provide significant improvements in performance in some cases.

Some TCP/IP implementations do not support variable buffer sizes. If that is the case, when the control is activated the OutBufferSize reverts to its defined size. The same happens if you attempt to make it too large or too small.

The default code page is Unicode UTF-8 (65001).

The following is a list of valid code page identifiers:

In certain circumstances it may be beneficial to mask sensitive data, like passwords, in log messages. Set this to to mask sensitive data. The default is .

This setting only works on these controls: AS3Receiver, AS3Sender, Atom, Client(3DS), FTP, FTPServer, IMAP, OFTPClient, SSHClient, SCP, Server(3DS), Sexec, SFTP, SFTPServer, SSHServer, TCPClient, TCPServer.

When set to , the control will use the system security libraries by default to perform cryptographic functions where applicable.

Setting this configuration setting to tells the control to use the internal implementation instead of using the system security libraries.

This setting is set to by default on all platforms.