Type of credit card being used in this transaction. This field contains the customer's credit card type. This is automatically computed after the Number is set, but it can also be changed manually. A list of valid card types is included below.

Three digit security code on back of card (optional).

This alphanumeric field contains the three digit Visa "Card Verification Value" (CVV), MasterCard "Card Verification Code" (CVC), or four-digit American Express "Card Identification Number" (CID). This value appears as additional characters embossed on the card signature line following the credit card account number on the back of the credit card. This is an optional field which can be used to determine if the customer is actually in possession of the credit card.

Even if the CVVData is incorrect, the transaction may still be authorized. It is up to the merchant to examine the ResponseCVVResult field and decide whether to honor the transaction or not.

Note: When set to a non-empty value, CVVPresence will be automatically set to cvpProvided. If set to empty string (""), CVVPresence will be automatically set to cvpNotProvided.

Indicates the presence of the card verification value.

This field is used to indicate the presence of CVVData.

The class will automatically set this value to cvpProvided when a CVVData value is specified. You can explicitly specify the CVVPresence indicator by setting this property.

Available values are:

• cvpNotProvided (0)
• cvpProvided (1)
• cvpIllegible (2)
• cvpNotOnCard (3)

This field contains a 1-character code identifying the source of the customer data. The table below shows all supported values for this field.

Expiration month of the credit card specified in Number.

This field contains the expiration date of the customer's credit card, and must be in the range 1 - 12.

Expiration year of the credit card specified in Number.

This field contains the expiration date of the customer's credit card. This field must be in the range 0 - 99, or 2000 - 2099. Any date before the year 2000 or after 2099 cannot be specified.

Determines whether data set to the Number or MagneticStripe fields is validated.

By default, when the Number or MagneticStripe fields are set, the value will be validated and normalized. For instance, "4444-33332222 1111" will be normalized as "4444333322221111" and MagneticStripe data will be parsed for the track specified by EntryDataSource. However, any other non-numerical data entered will cause an exception to be thrown. It may be useful in some gateways to send other data in the Number or MagneticStripe fields, and this can be accomplished by setting IsEncrypted to true. However, please note that in doing so automatic calculation of the CardType may be affected, and the card number will not be verified.

Track data read off of the card's magnetic stripe.

If EntryDataSource is not one of the manually entered enumerations, then this field must be set with the track1 or track2 data from the magnetic stripe on the back of the customer's credit card. This includes everything after but not including the start sentinel (% or ;) and up to but not including the end sentinel (?) and LRC check character. You may only set this field with track 1 or track 2 data, and may not pass both. Use the EntryDataSource field to indicate which track you are sending.

The following example shows how to set the MagneticStripe and EntryDataSource fields if the data read off the card is "%B4788250000028291^TSYS^05121015432112345678?;4788250000028291=05121015432112345678?"

class.Card = new CCCard("B4788250000028291^TSYS^05121015432112345678", dsTrack1) or class.Card = new CCCard("4788250000028291=05121015432112345678", dsTrack2) or CCCardType Card = new CCCard() Card.MagneticStripe = "B4788250000028291^TSYS^05121015432112345678" Card.EntryDataSource = dsTrack1

Industry regulations do not allow merchants or processors to store track data in any form of persistent storage. Failure to abide by this regulation can result in significant fines and other penalties.

Customer's credit card number for the transaction.

If you're sending the transaction with MagneticStripe data, this field should be left empty.

This is the date on which this certificate becomes valid. Before this date, it is not valid. The following example illustrates the format of an encoded date:

23-Jan-2000 15:00:00.

This is the certificate (PEM/base64 encoded). This field is used to assign a specific certificate. The Store and Subject fields also may be used to specify a certificate.

When Encoded is set, a search is initiated in the current Store for the private key of the certificate. If the key is found, Subject is updated to reflect the full subject of the selected certificate; otherwise, Subject is set to an empty string.

This is the certificate (PEM/base64 encoded). This field is used to assign a specific certificate. The Store and Subject fields also may be used to specify a certificate.

When Encoded is set, a search is initiated in the current Store for the private key of the certificate. If the key is found, Subject is updated to reflect the full subject of the selected certificate; otherwise, Subject is set to an empty string.

This is the date the certificate expires. After this date, the certificate will no longer be valid. The following example illustrates the format of an encoded date:

23-Jan-2001 15:00:00.

This is a comma-delimited list of extended key usage identifiers. These are the same as ASN.1 object identifiers (OIDs).

This is the hex-encoded, 16-byte MD5 fingerprint of the certificate. This property is primarily used for keys which do not have a corresponding X.509 public certificate, such as PEM keys that only contain a private key. It is commonly used for SSH keys.

The following example illustrates the format: bc:2a:72:af:fe:58:17:43:7a:5f:ba:5a:7c:90:f7:02

This is the hex-encoded, 20-byte SHA-1 fingerprint of the certificate. This property is primarily used for keys which do not have a corresponding X.509 public certificate, such as PEM keys that only contain a private key. It is commonly used for SSH keys.

The following example illustrates the format: 30:7b:fa:38:65:83:ff:da:b4:4e:07:3f:17:b8:a4:ed:80:be:ff:84

This is the hex-encoded, 32-byte SHA-256 fingerprint of the certificate. This property is primarily used for keys which do not have a corresponding X.509 public certificate, such as PEM keys that only contain a private key. It is commonly used for SSH keys.

The following example illustrates the format: 6a:80:5c:33:a9:43:ea:b0:96:12:8a:64:96:30:ef:4a:8a:96:86:ce:f4:c7:be:10:24:8e:2b:60:9e:f3:59:53

This is the issuer of the certificate. This field contains a string representation of the name of the issuing authority for the certificate.

This is the password for the certificate's private key (if any).

Some certificate stores may individually protect certificates' private keys, separate from the standard protection offered by the StorePassword. KeyPassword. This field can be used to read such password-protected private keys.

Note: this property defaults to the value of StorePassword. To clear it, you must set the property to the empty string (""). It can be set at any time, but when the private key's password is different from the store's password, then it must be set before calling PrivateKey.

This is the private key of the certificate (if available). The key is provided as PEM/Base64-encoded data.

Note: The PrivateKey may be available but not exportable. In this case, PrivateKey returns an empty string.

This field shows whether a PrivateKey is available for the selected certificate. If PrivateKeyAvailable is True, the certificate may be used for authentication purposes (e.g., server authentication).

This is the name of the PrivateKey container for the certificate (if available). This functionality is available only on Windows platforms.

This is the public key of the certificate. The key is provided as PEM/Base64-encoded data.

This field contains the textual description of the certificate's public key algorithm. The property contains either the name of the algorithm (e.g., "RSA" or "RSA_DH") or an object identifier (OID) string representing the algorithm.

This is the length of the certificate's public key (in bits). Common values are 512, 1024, and 2048.

This is the serial number of the certificate encoded as a string. The number is encoded as a series of hexadecimal digits, with each pair representing a byte of the serial number.

The field contains the text description of the certificate's signature algorithm. The property contains either the name of the algorithm (e.g., "RSA" or "RSA_MD5RSA") or an object identifier (OID) string representing the algorithm.

This is the name of the certificate store for the client certificate.

The StoreType field denotes the type of the certificate store specified by Store. If the store is password protected, specify the password in StorePassword.

Store is used in conjunction with the Subject field to specify client certificates. If Store has a value, and Subject or Encoded is set, a search for a certificate is initiated. Please see the Subject field for details.

Designations of certificate stores are platform-dependent.

The following are designations of the most common User and Machine certificate stores in Windows:

In Java, the certificate store normally is a file containing certificates and optional private keys.

When the certificate store type is PFXFile, this property must be set to the name of the file. When the type is PFXBlob, the property must be set to the binary contents of a PFX file (i.e. PKCS12 certificate store).

This is the name of the certificate store for the client certificate.

The StoreType field denotes the type of the certificate store specified by Store. If the store is password protected, specify the password in StorePassword.

Store is used in conjunction with the Subject field to specify client certificates. If Store has a value, and Subject or Encoded is set, a search for a certificate is initiated. Please see the Subject field for details.

Designations of certificate stores are platform-dependent.

The following are designations of the most common User and Machine certificate stores in Windows:

In Java, the certificate store normally is a file containing certificates and optional private keys.

When the certificate store type is PFXFile, this property must be set to the name of the file. When the type is PFXBlob, the property must be set to the binary contents of a PFX file (i.e. PKCS12 certificate store).

If the type of certificate store requires a password, this property is used to specify the password needed to open the certificate store.

This is the type of certificate store for this certificate.

The class supports both public and private keys in a variety of formats. When the cstAuto value is used the class will automatically determine the type. This field can take one of the following values:

This is the subject of the certificate used for client authentication.

This field will be populated with the full subject of the loaded certificate. When loading a certificate the subject is used to locate the certificate in the store.

If an exact match is not found, the store is searched for subjects containing the value of the property.

If a match is still not found, the property is set to an empty string, and no certificate is selected.

The special value "*" picks a random certificate in the certificate store.

The certificate subject is a comma separated list of distinguished name fields and values. For instance "CN=www.server.com, OU=test, C=US, E=support@nsoftware.com". Common fields and their meanings are displayed below.

If a field value contains a comma it must be quoted.

This field contains comma-separated lists of alternative subject names for the certificate.

This field contains the MD5 hash of the certificate. It is primarily used for X.509 certificates. If the hash does not already exist, it is automatically computed.

This field contains the SHA-1 hash of the certificate. It is primarily used for X.509 certificates. If the hash does not already exist, it is automatically computed.

This field contains the SHA-256 hash of the certificate. It is primarily used for X.509 certificates. If the hash does not already exist, it is automatically computed.

This field contains the text description of UsageFlags.

This value will be of one or more of the following strings and will be separated by commas:

• Digital Signatures
• Key Authentication
• Key Encryption
• Data Encryption
• Key Agreement
• Certificate Signing
• Key Signing

If the provider is OpenSSL, the value is a comma-separated list of X.509 certificate extension names.

This field contains the flags that show intended use for the certificate. The value of UsageFlags is a combination of the following flags:

Please see the Usage field for a text representation of UsageFlags.

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

This field contains the certificate's version number. The possible values are the strings "V1", "V2", and "V3".

Customer's street address. This field is used as part of the Address Verification Service (AVS) and contains the customer's street address as it appears on their monthly statement. Only the street number, street name, and apartment number are required in This field. City, state, and zip code are set in the City, State, and Zip fields.

The length of this field varies by gateway. If the customer's address is very long, it is admissible to include only the street number in This field.

NOTE: For the Moneris gateway, this field should contain only the customer's street number. The street name should be added via the AddSpecialField method. For example:

class.Customer = new EPCustomer(); class.Customer.Address = "123"; class.AddSpecialField("avs_street_name, "Nowhere Ln");

A specific detail on the customer's shipping address (such as building, suite, apartment, floor number etc.).

This field allows you to get or set an XML aggregate built from all of the fields from this type. "EPCustomer" is the root element, and the names of the fields create the tags under the root. For instance: <EPCustomer> <Address>123 Nowhere Ln.</Address> <Address2>Apt 3B.</Address2> <City>Beverly Hills</City> ... </EPCustomer>

Customer's city. This field is used as part of the Address Verification Service (AVS) and contains the customer's city as it appears on their monthly statement. Other AVS fields include Address, State, and Zip.

Customer's country. This field contains the country in which the customer is located. Most gateways use a two-letter country code, specified in ISO-3166.

Note: If using this field with the PayFuse gateway, this field should contain the ISO-3166 numeric code instead of the standard two-letter code. For example, the ISO code for the US is "840".

Customer's email address. This optional field contains the customer's email address.

Customer's fax number. This optional field contains the customer's fax number.

Customer's first name. This field contains the customer's first name.

Customer's full name. This field contains the customer's full name as it appears on the credit card or bank account. Many gateways use this field in addition to, or instead of, the FirstName and LastName fields. If a gateway requires a FullName and the field is empty, FullName will be constructed using the contents of FirstName and LastName.

Merchant-generated customer Id. This field contains a merchant-generated customer identification number. This number should be unique for each different customer that places an order with the merchant.

Customer's last name. This field contains the customer's last name as it appears on their credit card.

Customer's phone number. This optional field contains the customer's phone number.

Customer's state. This field is used as part of the Address Verification Service (AVS) and contains the two character postal abbreviation of the customer's state as it appears on their monthly statement. Other AVS fields include Address, City, and Zip.

Customer's zip code (or postal code if outside of the USA). This field is used as part of the Address Verification Service (AVS), and contains the customer's zip code as it appears on their monthly statement. Other AVS fields include Address, City, and State.

Contains an authorization code when a transaction has been approved. This field contains an authorization code when a transaction has been approved. If the Code returned indicates that the transaction is not approved, then the contents of this field should be ignored.

Indicates the status of the last transaction. This field will be True if the last transaction was approved. However, you should not rely solely on the value contained in this property. After every transaction, the Code should be inspected and evaluated according to the specifications of the Gateway in use. A list of response codes for each gateway is listed in the table of contents. However, it is recommended that the developer acquire the current list from the Gateway which is being used.

The amount approved for the transaction, this is the amount actually charged to the credit card.

This field is primarily used when gateways allow partial authorizations and AllowPartialAuths is 'True'. Thus this field is not used by all gateways and should not alone be used to determine if a transaction was successful (such as in the case that this field is not populated).

Contains the Address Verification System result code. This one character field contains the Address Verification Service (AVS) result code. An AVS result code can provide additional information concerning the authentication of a particular transaction for which cardholder address verification was requested. An AVS result code of "0" will be returned in the response message when no address verification has been requested. The value returned should be stored for later retrieval, as it may be required when voiding or refunding a transaction. Valid AVS response codes are listed below, and are identical across all Gateway (note that some gateways do not return an AVS response).

Note: Some gateways use their own response codes instead of those in the above table; those response codes are detailed below for such gateways.

Adyen

For Adyen, this field will contain the following possible values:

American Payment Solutions

For American Payment Solutions, this field will contain the following possible values:

Barclay

For Barclay, the field will contain the following possible values:

BlueSnap

For BlueSnap, the field will contain a 3-character string (if AVS checks were done), which contains the AVS checks for the following fields:

The possible values for each result character are:

HSBC

For HSBC, the field will contain the following possible values:

PayTrace / PayTraceJSON

For PayTrace / PayTraceJSON, the field will contain the following possible values:

QBMS

For the QBMS gateway, the AVSResult field will contain the result for the street address, a comma, and then the result for the zip code. The values returned are "Pass", "Fail", and "NotAvailable". Therefore, an AVSResult of "Fail,Pass" means that the street address failed validation, but the zip code passed.

DataCash

For DataCash, the field will contain the following possible values (of which correspond to both AVS and CVV checks):

Stripe

For Stripe, the field will contain the following possible values:

Worldpay

For Worldpay, the field will contain a 4-character string, which contains the AVS checks for the following fields:

The possible values for each result character are:

Worldpay Online

For Worldpay Online, the field will contain one of the following:

Indicates the status of the authorization request. This field contains the actual response code as returned by the Gateway. Unlike the Approved field, this Code field may provide more details about why a transaction was declined. Therefore, it is recommended that developers check the Code as well as the Approved field. The Point of Sale system should evaluate this response code and NOT the Text to determine nature of a response message. The current (at the time of this release) response codes for the supported Gateways are listed in the table of contents to your left.

Contains the returned CVV2 result code if it was requested. This field contains the host returned CVV2 result code (if CVV data was sent in the request). The following is a list of current result codes:

A gateway may also support custom codes or human-readable response messages in this field. Please consult your gateway documentation to determine if CVV2 codes are supported.

Note: Some gateways use their own response codes instead of those in the above table; those response codes are detailed below for such gateways.

HSBC

For HSBC, the field will contain:

Adyen

For Adyen, the field will contain:

Barclay

For Barclay, the field will contain:

BlueSnap

For BlueSnap, the field will contain:

(Note: There are some scenarios in which the field will be empty instead, refer to BlueSnap's documentation for more details.)

DataCash

For DataCash, the field will contain the following possible values (of which correspond to both AVS and CVV checks):

Stripe

For Stripe, the field will contain the following possible values:

Worldpay Online

For Worldpay Online, the field will contain one of the following:

The entire response returned from the gateway processor. This field contains the entire response returned from the gateway processor. You may use this to parse additional information that is not returned in the standard response fields.

Additional error code returned by some gateways. If a gateway returns it, this field will contain an additional code that may explain why the transaction was declined. You may also wish to inspect ErrorText for a human-readable description of this ErrorCode.

Additional error description returned by some gateways. If a gateway returns it, this field will contain a human-readable description of the error which occurred (if any). You may also wish to inspect ErrorCode for an accompanying code which may be parsed and used by your application.

Invoice number submitted in authorization request (if applicable). This field contains the Invoice Number submitted in the original transaction, echoed back by the Gateway host.

Response code from the underlying processor. Often times a Gateway will return a Code that indicates only whether the transaction is approved or declined. Many of these also include a secondary code that provides more details as to why the transaction was declined.

Note, for the PayFlowPro Gateway this field will contain a "1" if the transaction was a duplicate, a "-1" if duplicate checking service is unavailable, and will be blank for a successfully authorized transaction.

Text information that describes each response code. This field contains a response or display text message. This message can be used by the terminal to display the authorization result. The display text must not be used to determine the nature of a response message. A Gateway may translate the response according to the language indicated in the merchant account setup (if applicable).

Contains the Visa Transaction Identifier or MasterCard Reference Number. This field contains a transaction identifier or reference number. The Point of Sale (POS) device should not attempt to interpret the meaning of any data appearing in this field. Data returned in this field (if any) should be recorded and used to submit a modification of this transaction at a later time (such as voiding the transaction or capturing an authorization-only transaction, if applicable).

Customer's shipping street address.

A specific detail on the customer's shipping address (such as building, suite, apartment, floor number etc.).

Customer's shipping city.

Customer's shipping country. This field contains the country in which the customer is located. Most gateways use a two-letter country code, specified in ISO-3166.

Customer's email address.

Customer's first name.

Customer's last name.

Customer's phone number.

Customer's shipping state.

Customer's shipping zip code (or postal code if outside of the USA).

Name of special configuration field to submit in this transaction. The Name and Value fields can be used to send special gateway configuration and transaction fields for each transaction. These fields can also be used to extend the functionality of this class by submitting additional information to the gateway.

This field is not applicable for the LinkPoint, FirstData, YourPay, PayFuse, or Orbital gateways.

Value of special configuration field to submit in this transaction. The Name and Value fields can be used to send special gateway configuration and transaction fields for each transaction. These fields can also be used to extend the functionality of this class by submitting additional information to the gateway.

Note: This field is not applicable for the LinkPoint, FirstData, YourPay, PayFuse, or Orbital gateways.

This field is used to tell the class which type of authorization to perform when connecting to the proxy. This is used only when the User and Password fields are set.

AuthScheme should be set to authNone (3) when no authentication is expected.

By default, AuthScheme is authBasic (0), and if the User and Password fields are set, the component will attempt basic authentication.

If AuthScheme is set to authDigest (1), digest authentication will be attempted instead.

If AuthScheme is set to authProprietary (2), then the authorization token will not be generated by the class. Look at the configuration file for the class being used to find more information about manually setting this token.

If AuthScheme is set to authNtlm (4), NTLM authentication will be used.

For security reasons, setting this field will clear the values of User and Password.

This field tells the class whether or not to automatically detect and use proxy system settings, if available. The default value is false.

Note: This setting is applicable only in Windows.

This field contains a password if authentication is to be used for the proxy.

If AuthScheme is set to Basic Authentication, the User and Password are Base64 encoded and the proxy authentication token will be generated in the form Basic [encoded-user-password].

If AuthScheme is set to Digest Authentication, the User and Password fields are used to respond to the Digest Authentication challenge from the server.

If AuthScheme is set to NTLM Authentication, the User and Password fields are used to authenticate through NTLM negotiation.

This field contains the Transmission Control Protocol (TCP) port for the proxy Server (default 80). See the description of the Server field for details.

If a proxy Server is given, then the HTTP request is sent to the proxy instead of the server otherwise specified.

If the Server field is set to a domain name, a DNS request is initiated. Upon successful termination of the request, the Server field is set to the corresponding address. If the search is not successful, an error is returned.

This field determines when to use a Secure Sockets Layer (SSL) for the connection to the proxy. The applicable values are as follows:

This field contains a user name, if authentication is to be used for the proxy.

If AuthScheme is set to Basic Authentication, the User and Password are Base64 encoded and the proxy authentication token will be generated in the form Basic [encoded-user-password].

If AuthScheme is set to Digest Authentication, the User and Password fields are used to respond to the Digest Authentication challenge from the server.

If AuthScheme is set to NTLM Authentication, the User and Password fields are used to authenticate through NTLM negotiation.

Retail Config Settings

This setting is used to pass the 3D Secure authentication status on to the transaction server. This component may be used in conjunction with the ThreeDSecure component or with any other 3D Secure MPI implementation. Other values necessary for passing 3D Secure data include 3DSCAVV, 3DSXID and 3DSECI. This setting is only valid for E-Commerce transactions. Applicable values are:

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 component may be used in conjunction with the ThreeDSecure component or with any other 3D Secure MPI implementation. Other values necessary for passing 3D Secure data include 3DSXID and 3DSECI. This setting is only valid for E-Commerce transactions.

This setting is used to pass the directory server transaction Id to the gateway for 3DS 2.0. This component may be used in conjunction with the ThreeDSecure component or with any other 3D Secure MPI implementation. This setting is only valid for E-Commerce transactions. This setting is currently only supported when the Gateway property is set to gwNetbanx.

This contains a 1-character transaction indicator identifying the type of transaction being authorized. Supported values vary between gateways, so please consult gateway documentation for more information. Note: Other values necessary for passing 3D Secure data are 3DSXID and 3DSCAVV. This setting is only valid for E-Commerce transactions.

This setting is used to pass the cardholder's 3D Secure enrollment status to the gateway for 3D Secure 1.0.2. This component may be used in conjunction with the ThreeDSecure component or with any other 3D Secure MPI implementation. This setting is only valid for E-Commerce transactions. This setting is currently only supported when the Gateway property is set to gwNetbanx.

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

When set to 'True', partial authorizations will be allowed and must be handled accordingly. A partial authorization occurs when a customer's available funds for a specific card can only meet a portion of the total TransactionAmount. Therefore a second means of payment must be used to pay for the remaining amount. When such a case occurs, the partially approved amount will be made available via ApprovedAmount. When set to 'False', if a customer's card does not have funds the available to account for the entire TransactionAmount the transaction will be declined. The default value is 'True'.

This configuration setting can be used to specify a single input format for the TransactionAmount property. When set to a value other than 0, the class will automatically convert the amount from the specified format to the format expected by the gateway. Valid values are:

Note that this setting is only designed for use with currencies that have two digits after the decimal point, like US dollars.

This setting specifies the Base-64 encoded data containing the encrypted payment data received from Apple. The encrypted payment data must be retrieved in a separate process by communicating with the Apple Passbook app. Once the encrypted payment data is received from Apple set this configuration setting, which takes the place of Card, and perform either an AuthOnly or Sale transaction to process the payment.

This setting is applicable to the following gateways:

• Authorize.NET (gwAuthorizeNet)
• BlueSnap (gwBlueSnap)

This configuration setting can be used to set the company associated with the shipping address of the customer.

When AllowPartialAuths configuration setting is set to true and there are not enough funds to cover the full transaction amount set using the TransactionAmount property, Authorize.NET will return a Split Tender Id that can be later used, to link to the original partially authorized transaction, to charge the full amount, void, or capture.

This config is used to specify the Key Serial Number (KSN) value after encrypting card magnetic stripe (track) data and is returned using BluePay's encryption tools. Prior to specifying encrypted card data, CardEncrypted should be set to "True".

This setting takes a previous transaction's TransactionId. For any parameters that are not set, BluePay will use values from the referenced transaction.

This config is used to specify the length of the magnetic stripe (track) data prior to it being encrypted using BluePay's encryption tools. Prior to specifying encrypted card data, CardEncrypted should be set to "True".

When set to true, the component will update a prevous transaction when the Sale method is called. BluePayMasterId must be set to the TransactionId of the previous request, and the transaction can only be updated before it has been settled by BluePay.

Set this config to "True" to allow encrypted card track data to be specified and sent in the request. Note that this config must be set to "True" prior to setting MagneticStripe to the encrypted magnetic stripe data, otherwise an exception may be thrown when the component attempts to verify the magnetic stripe data format. The default value is "False".

Note: When using the BASYS, PhoeniXGate, or Repay Gateways, set this configuration setting to True so both Track1 and Track2 Data are sent in the request.

This config allows you to specify the way in which the transaction took place. This config is applicable to the Barclay, HSBC, and PayFuse gateways.

Applicable values are:

This field is used for the gateways the support International card types. Supported gateways include: Adyen, Barclay, CyberSource, FastTransact, HSBC, NetBanx, NetBilling, Orbital, PayFuse, PaymentExpress, PayPoint, PlugNPay, SagePay, SECPay, and WorldPayXML. Switch, Solo, and some Maestro cards have a 1 or 2 digit Issue number printed on the front of the card, directly following the card number. If that issue number is present, it should be set with this config setting.

When set to "True" (default value), in the case of a manually entered card, the transaction will be processed with the card being identified as present. When set to "False", the transaction will be processed as a 'Card Not Present' transaction.

This config is currently applicable to the Heartland gateway.

If there is a Start Date present on the card, set the month here and the year in CardStartYear.

If there is a Start Date on present on the card, set the year here and the month in CardStartMonth.

This config is used to specify the type of credit card being used in a retail transaction. The type will be computed by the component based on the Card data but this value can be specified to override any computed values.

The available card types are:

This property will contain the CAVV response value to the authorization and will be populated along with Response. Values vary between gateways, so please consult gateway documentation for more information.

When true, this setting indicates that the customer gave the merchant permission to perform a Card On File (COF) transaction. Currently only used by CardPointe (gwCardPointe).

This field is used to specify the total convenience fee charged for the transaction. This field is applicable to the FirstDataPayPoint and Litle / Vantiv gateway.

This config is used to specify the currency code to be used in the transaction. Default values and codes vary based on the gateway. This config will be populated with the default value for the gateway when Gateway is set.

For more information on these currency code values, please refer to the ISO 4217 standard as well as the gateway specification.

If not set, "2" is sent by default. Currently only supported in the Orbital and WorldPayXML gateways.

This config is used to specify a request token for authorization update transactions (such as captures, credits, voids, and reversals). This is only applicable when using the Atos interface.

This config allows you to specify a customer Profile Id to process a transaction using the customer's information stored within CyberSource's systems (this is known as Payment Tokenization). When specified, the ProfileId will be sent instead of the card data (when performing an AuthOnly or Sale) and thus the stored card in the customer's profile will be charged. Additionally you can Credit a card on a customer's profile by specifying a Profile Id and a TransactionId of "" (empty string). Please note that the component does NOT support creating, modifying, or deleting customer profiles. These will need to be created using the RecurringBilling component or by other means such as within CyberSource's Business Center.

If CyberSourceVoidMode is set to "Void" (default), VoidTransaction sends a void transaction to cancel a Capture or Credit request. Note a transaction can only be voided if CyberSource has not already submitted the capture or credit request to the processor (this is usually done once a day). If CyberSourceVoidMode is set to "Reverse", a full authorization reversal transaction is sent to reverse a previous authorization (i.e. after performing an AuthOnly transaction). Note in a reversal, it is required that TransactionAmount be set to the full amount authorized (as you cannot partially reverse an authorization).

If this setting is set to "True", the request field values will be XML escaped prior to being sent to the CyberSource gateway. If this setting is set to "False" (default), the class does not perform any XML escaping and the values are sent exactly as specified. The default value is "False".

This field is used to set a 19 or 20-byte Key Sequence Number (KSN). This field is associated with DebitPIN and both are required for Debit Sale transactions.

The following gateways support Debit card transactions:

• gwEprocessing(2)
• gwMerchantPartners(31)
• gwJetPay(65)
• gwBluePay(67)
• gwWorldPayLink(87)
• gwFirstDataPayPoint(90)
• gwPhoeniXGate(97)
• gwRepay(98)
• gwBASYS(106)

This field is used to set a 16-byte encrypted PIN for a Debit card. This field is associated with DebitKSN and both are required for Debit Sale transactions.

The following gateways support Debit card transactions:

• gwEprocessing(2)
• gwMerchantPartners(31)
• gwJetPay(65)
• gwBluePay(67)
• gwWorldPayLink(87)
• gwFirstDataPayPoint(90)
• gwPhoeniXGate(97)
• gwRepay(98)
• gwBASYS(106)

This field is used to specify a dynamic descriptor (sometimes called a soft descriptor) for the transaction. Typically this value is used to specify transaction specific details which will be displayed on the customer's credit card statement.

The following gateways currently support this functionality: Heartland.

When set to true, this config will cause the component to automatically escape the XML data in the request. The default value is false. This is currently only supported in the Authorize.Net XML gateway.

When returned in the response, this field will be populated with the current balance on the card used to process the transaction.

This field is used to specify the gift card transaction type you wish to perform. All gift card transactions are performed by setting the type via this config and calling the Sale method. When the transaction type is set to '0', the Sale, VoidTransaction and Refund methods can be called to perform their respective transactions. Note to process a gift card transaction, FDMSProcessGiftCard must be set to 'True'.

Applicable values are:

This config is used to specify the Key Id, obtained from FDMS, that corresponds to the HMAC Key (specified via HashSecret) and is sent within the Authorization header of the request.

When set to 'True', the current transaction will be run as a gift card transaction. The default value 'False', will perform a regular credit card transaction.

This config is used to both retrieve and specify a Transarmor Token for the First Data E4, Payeezy, and Bank Of America gateways. If your account is configured for Transarmor tokens, a token will be created by the server and returned via this config when performing a transaction using a Card data. Additionally, you can set this config to a previously retrieved token value and the token will be sent in the request rather than the Card data. This increases security as raw card data is no longer needed. Note when sending an FDMSTransArmorToken value, the CardType, ExpMonth, and ExpYear are required.

This field is used to specify a wallet provider when using a digital wallet like Apple Pay or Android Pay. By default this field is not sent, and no wallet provider is used.

Applicable values are:

This config is used to specify the refund password provided to you by Global Iris. When a refund is performed, the component will use the specified password to generate and send a 'refundhash' in the request. This value is required when performing a Refund transaction.

By default, the Password property is sent as the "password" field in all requests. If the GoEMerchantUseGatewayId configuration setting is set to True, the class will instead treat the password as the "gateway_id" field in all requests.

Certain gateways allow the request to be hashed as an additional authentication mechanism. This configuration setting controls which algorithm is used for hashing. Valid values are:

Some gateways allow for the generation of a hash for added security. The following gateways support this config.

Authorize.Net: The newest version of the protocol includes an optional Hash Secret, which may be used to verify that a server response is actually from an Authorize.Net server. The hash secret is concatenated with the MerchantLogin, TransactionId, and TransactionAmount. This value is then hashed with the MD5 algorithm and compared to the value returned by the server. If they do not match, the class throws an exception. If the AIMHashSecret is left blank, this check will not be performed. The Server's Hash Secret may be set using the Authorize.Net online merchant interface, located at https://secure.authorize.net/.

Bank of America: This value will be the HMAC Key generated for you by the gateway. This value is required and an exception will be thrown if not specified.

BarClay and Ingenico: This value is optional and when specified 'SHASIGN' parameter will be computed and sent.

Bambora/Beanstream: If hash validation is required then set this to your hash key. HashAlgorithm will also need to be set accordingly.

Nuvei: This value is required in all transactions. The value is unique to each terminal and can be set through the online interface at "https://testpayments.nuvei.com/merchant/selfcare/".

USAePay: This value is optional and when a 'Pin' value is specified, the 'UMhash' parameter will be computed and sent.

If HeartlandDeveloperId is set, the HeartlandVersionNumber should also be set. If set, this field must be exactly 6 characters in length.

This is issued by Heartland during registration.

This is issued by a Heartland Payment Systems Administrator during registration.

The Heartland gateway supports reversals of credit card transactions. To perform a reversal, TransactionAmount can be set and the VoidTransaction can be called. When performing a reversal, TransactionAmount must be set to the original authorized amount of the transaction you are performing the reversal on. This field should then be set to the settlement amount of the transaction (or the final authorized amount after the reversal is performed).

If Heartland provides a secret key for use with their API, this property can be used to send it to the gateway. When this key is set, the HeartlandLicenseId, HeartlandSiteId, HeartlandDeviceId, MerchantLogin and MerchantPassword are not required, and will not be sent to the gateway.

The ship day for the Heartland transaction. Valid values are 1 - 31.

The ship month for the Heartland transaction. Valid values are 1 - 12.

This is issued by Heartland during registration.

Heartland supplies an additional way to trace the transaction, beyond the InvoiceNumber and TransactionId.

The field is used to specify the type of token that should be returned when using the Heartland gateway. By setting this field to a value other than 0 (None), a Token will be requested and returned in the response via HeartlandTokenValue (provided one can be generated). Please see the "ICharge Gateway Setup and Required Properties" page for more details about using tokenization, as there are special merchant account configurations required.

The available mapping values are:

This field is used to retrieve a Heartland Token value when using Heartland Tokenization (which is accomplished by setting HeartlandTokenMapping to a value greater than 0). A token replaces the card number in all subsequent transactions thus increasing security. This field can also be used to specify a previously retrieved token value. When set, the specified token value will be sent in the request instead of the card number.

If HeartlandVersionNumber is set, the HeartlandDeveloperId should also be set. If set, this field must be exactly 4 characters in length.

This field is used to specify the Id for the AdvancedFraudChecks element for the Litle gateway. Custom attributes can also be included by using the AddSpecialField method with the name "CustomAttributeX", where X is a number from 1 to 5. For example: icharge.Config("LitleAdvancedFraudChecksId=ASDFG-AXXXXAB999"); icharge.AddSpecialField("CustomAttribute1", "One"); icharge.AddSpecialField("CustomAttribute2", "Two");

This config is used to specify the method used to identify the customer when performing a retail transaction.

The available values are (if not specified, the component will send 'signature' by default):

This field is used to specify an XML aggregate for Custom Billing support within the Litle gateway. When specifying custom billing, you can use either the phone or url child.

Below is a sample XML aggregate for the phone child: <phone>555-555-5555</phone> <descriptor>Billing Descriptor</descriptor>

Below is a sample XML aggregate for the url child: <url>retail.url</url> <descriptor>www.retail.com</descriptor>

The HSBC and PayFuse gateway both allow for a merchant alias to be specified (and in some cases it may be required). This field allows you to specify the alias.

For the CardPointe gateway, this configuration setting is required, and should contain your Merchant Id.

For the Litle gateway, this configuration setting is required, and should contain your Merchant Id.

For the MIT gateway, this configuration setting is required, and should contain your Merchant Number (Contado).

For the Priority Payment Systems gateway, this configuration setting is required, and should contain your Merchant Id.

For the WorldPayXML gateway, this configuration setting is optional; it is only needed if you require that the "merchantCode" sent in the request be different from your MerchantLogin (e.g., when processing AMEX transactions, or when supporting multiple currencies).

The last 4 digits of the card number are required to process transactions using a stored profile Id (via MerchantPartnersProfileId) for the MerchantPartners or WorldPay Link gateways.

This field is used to specify the Profile Id of a stored profile and is used to process a transaction instead of specifying the card data. A profile is created via the RecurringBilling component and the SubscriptionId response field is used to obtain the profile Id to be set in this field. MerchantPartnersLast4Digits is a required field when using a stored profile. Note this config is only applicable to Sale and Credit transactions processed via the MerchantPartners or WorldPay Link gateways.

This setting is used to specify the encrypted reader type used to read and encrypt a swiped card. The specified value is sent in the request and is used by the gateway to decrypt the card data so the transaction can be processed.

Valid Values:

This field is used to specify the Seed Id used to perform AES encryption. This field is provided by MIT and is required when performing AES encryption.

This field is used to specify the branch reference number for the MIT gateway (Required).

This field is used to specify the company reference number for the MIT gateway (Required).

This field is used to specify the country of operation for the MIT gateway (Required).

This field is used to specify the encryption algorithm to use for the MIT gateway. Encryption will only be performed if an encryption key is specified via MITEncryptionKey. Note when perform AES (1) encryption, you must also set MITAESSeedId.

Applicable values are:

This field is used to specify the encryption key for the MIT gateway. When set, the specified key will be used to perform the encryption specified via MITEncryptionAlgorithm.

When making a Merchant Initiated Transaction (MIT), this configuration setting should be set to true to indicate to the payment gateway that the transaction is merchant initiated. Used by the Orbital payment gateway.

When making a Merchant Initiated Transaction (MIT), this configuration setting can be used to specify the transaction Id of a previously successful authorization. Used by the Orbital and CyberSource payment gateways.

When this field is set to 'True', the component will perform a recurring transaction request when Sale is called. The fields required for a Recurring charge transaction are the same as a Sale transaction. The default value is 'False'.

This field is used to specify the operation type for the MIT gateway (Required). This value will be provided to you by MIT.

When making a Merchant Initiated Transaction (MIT), this configuration setting is used to specify the type or reason for the merchant initiated transaction. The possible values and formats for this field vary by gateway, so check the gateway's documentation for the associated values and their meanings.

The field is used to indicate whether to use the NVP API for either the gwMoneris or gwMonerisUSA gateway. When set to true, the NVP API will be used instead of the XML specification. Note that you must set Gateway to either gwMoneris or gwMonerisUSA prior to setting this field. Additionally, if you decide to use the NVP API, this field must be set directly after setting Gateway (as GatewayURL will be updated). Note: The Response Method of the DirectPost configuration must be set to "Displayed as key/value pairs on our server" in the merchant admin console when using the NVP API.

This field is used to override the default transaction type for the MyVirtualMerchant gateway. By default, the component will set the transaction type based on the method called. However this field can be set to override the default value and is particularly useful for creating recurring or installment billing transactions. Below is a list of some of the available transaction types. Note that these additional transaction types require special fields to be added via AddSpecialField. Please consult the Virtual Merchant specifications for details about the required fields.

• CCCOMPLETE
• CCADDINSTALL
• CCADDRECURRING
• CCINSTALLSALE
• CCRECURRINGSALE

This field is used to specify your MyVirtualMerchant user Id which is required (along with MerchantLogin and MerchantPassword) as part of the user authentication.

This field is used to specify an account number for the Netbanx gateway which is used in addition to the MerchantLogin and MerchantPassword properties.

The Version portion of the User-Agent HTTP header is required by NetBilling. The default value is "1".

This config is used to specify whether VoidTransaction should perform an authorization reversal or void transaction. When this config is set to 'True' and VoidTransaction is called, an authorization reversal transaction will be sent to reverse a previously authorized transaction. The default value is 'False' which sends a void transaction.

If OrbitalConnectionPassword is set, the OrbitalConnectionUsername should also be set. This field is case-sensitive.

If OrbitalConnectionUsername is set, the OrbitalConnectionPassword should also be set.

Note: This field is auto-populated to "NO" when OrbitalCustomerProfileFromOrderInd is set.

This field is used when performing a VoidTransaction to identify unique components of transactions adjusted more than one time. The default value ("NULL") should be submitted when voiding a transaction which has not been adjusted more than once or if the un-captured remainder of a split transaction (partial capture) should be voided. To void a specific partial capture, this field should be set to the value returned in the response for the partial capture. Note that this field will also be populated with the TxRefIdx value returned in a response.

This field is used to specify an amount to adjust a previous authorization when performing a VoidTransaction. Thus the specified amount will be voided (assuming that the amount is not greater than the transaction amount remaining) and the total amount minus the adjusted amount will be the new authorized amount. When a value is not specified, the full amount of will be voided.

This field is used to specify the total convenience fee charged for the transaction when using the PayDirect gateway. This field is always required when using the PayDirect gateway. The sum of this field plus PayDirectMerchantAmount must always equal the value in TransactionAmount. If no values are set for either of these two configs, the component will set PayDirectMerchantAmount to the value specified in TransactionAmount and PayDirectConvenienceFee to "0.00".

This field is used to specify the total amount of goods and services for the external client when using the PayDirect gateway. This field is always required when using the PayDirect gateway. The sum of this field plus PayDirectConvenienceFee must always equal the value in TransactionAmount. If no values are set for either of these two configs, the component will set PayDirectMerchantAmount to the value specified in TransactionAmount and PayDirectConvenienceFee to "0.00".

This field is used to set Settle Merchant Code assigned by Link2Gov for the Reconciliation of funds. This field is always required when using the PayDirect gateway.

This config is used to specify the IP address of the payer, which is required by some gateways.

Set this config to the TransactionId from the transaction you wish to retrieve. You may also call PFPInquiry without setting it to anything. In this case the Id field is required, and the PayFlow Pro gateway will return the most recent transaction for the specified Id.

This field is used to specify a token value to perform additional authorizations (via Sale or AuthOnly) and Credits (via Credit) without sending card data again. For the Payflow Pro gateway, token values are the same as the TransactionId value returned from an authorization. Below is a code example of how this config can be used (note the code starts after the initial Sale or AuthOnly transaction has been performed):

ICharge.Config("PayFlowProToken=" + ICharge.Response.TransactionId); ICharge.TransactionId = "2"; ICharge.TransactionAmount = "10.00"; ICharge.Sale();

This is an actionable config which when called will send an upload transaction to the Payflow Pro gateway. An upload transaction is used to store credit card information on the gateway server. Note that billing and shipping information can be saved as well. After a successful upload, TransactionId will contain the token value that corresponds to the credit card data stored. This token value can then be used to process transactions via PayFlowProToken.

This field allows you to specify whether Capture will send an update amount or a capture request. By default, this value is 'False', which sends a capture request to mark an AuthOnly transaction for capture. This particular function does not allow you to alter the amount but instead just marks the authorized amount (from the AuthOnly transaction) for capture. When this field is set to 'True', the Capture method will send an update amount request allowing you to alter the amount that will be captured. This method can be used after AuthOnly and Sale transactions.

This field is used to specify the client code that is assigned by 3DSI. This code uniquely identifies your organization for the purpose of accessing and authenticating to the Payment WorkSuite.

This field is used to specify the location code that uniquely identifies a specific location that is associated with the merchant identified by the specified PaymentWorkSuiteMerchantCode.

This field is used to specify the merchant code that uniquely identifies a specific merchant within the Payment WorkSuite.

The field is used to indicate whether to use the Freedom API for either the gwPayPoint and gwSECPay gateway. When set to true, the Freedom API will be used instead of the XML Hosted specification. Note that you must set Gateway to either gwPayPoint or gwSECPay prior to setting this field. Additionally, if you decide to use the Freedom API, this field must be set directly after setting Gateway (as GatewayURL will be updated).

This config is used to add Purchase Card (Level2 and Level3) Data to an existing sale transaction for the PayTrace gateway. The Level2Aggregate and Level3Aggregate fields can be set to specify the purchase card data you wish to add prior to calling this config. A TransactionId, from the response of the original sale, is required to be specified when calling this config; i.e.: ICharge.Config("PayTraceAddPurchaseCardData=123456789");

This value is assigned by PayTrace and is used for validation and tracking purposes. The default value is: "90000035NSFT".

This field is used to specify card token value that you retrieved from Protect.js (see PayTrace documentation for details). This field must be set prior to performing a transaction using a token value instead of a Card.

Note that this is only valid when calling Sale or AuthOnly methods and the Gateway property is set to gwPayTraceJSON (117)

This field is used to specify the encryption key that you retrieved from Protect.js (see PayTrace documentation for details).

Note that this is only valid when calling Sale or AuthOnly methods and the Gateway property is set to gwPayTraceJSON (117)

This is an Action config. Getting this config will cause the class to obtain a Client Key (PROTECT AUTH TOKEN) from PayTrace. The Client Key will be used to authorize your application to use Protect.js to retrieve Card Token (hpf token) and Encryption Key (enc key). Please see PayTrace documentation for details. This key is valid for 20 minutes. icharge = new Icharge(); icharge.Gateway = IchargeGateways.gwPayTraceJSON; icharge.GatewayURL = "https://api.paytrace.com"; icharge.MerchantLogin = bearerToken; string clientKeyToken = class.Config("PayTraceJSONGetClientKeyToken"); //use this key to obtain "hpf_token" and "enc_key" from Protect.js

This configuration setting is used to send an Apple Pay PKPaymentToken containing a user's credentials to a gateway. The setting should be set to the full JSON contents of the PKPaymentToken, like: icharge.Config("PKPaymentToken={\"version\":\"EC_v1\",\"data\":\"...\",\"signature\":\"...\",\"header\":{\"applicationData\":\"...\",\"transactionId\":\"...\",\"ephemeralPublicKey\":\"...\",\"publicKeyHash\":\"...\"}}"); PKPaymentToken is currently only supported in gwLitle.

When using the QBMS gateway, this setting specified whether a transaction is being sent from a mobile device ("True") or not ("False"). The default value is "False".

When using the QBPayments gateway, this setting specified whether a transaction is being sent from a mobile device ("True") or not ("False"). The default value is "False".

This may be queried after a call to any method that sends data to the gateway. This will return the request data that was sent to the gateway which may be useful for troubleshooting purposes. For instance: component.Sale() MyString = component.Config("RawRequest")

This may be queried after a call to any method that sends data to the gateway. This will return the response that was received to the gateway which may be useful for troubleshooting purposes. For instance: component.Sale() MyString = component.Config("RawResponse")

This configuration setting can be set to indicate that a request is a recurring transaction. For a list of supported values for a gateway, please see the "ICharge Gateway Setup and Required Properties" page. This configuration setting is used by the QBPayments gateway.

This is an action config which when called will send a create token request to the SagePay gateway. A successful response will contain the SagePayToken for the specified Number. Note: when using this config you must set the "VPSProtocol" SpecialFields to "3.00".

This is an action config which when called will send a remove token request to the SagePay gateway. The specified SagePayToken will be removed from the SagePay server. Note: when using this config you must set the "VPSProtocol" SpecialFields to "3.00".

This is an action config which when called will perform a Repeat transaction for the SagePay gateway. The 'TransactionId' from a previous authorization response, that you would like to repeat for the card associated with the transaction, must be specified as a parameter. For example, a Repeat transaction using a TransactionId of 123 would be: ICharge.Config("SagePayRepeat=123").

"RelatedSecurityKey" and "RelatedVendorTXCode" special fields are required for Repeats. These are parsed out of the original authorization response.

This field allows you to specify whether to have SagePay generate a token and send it in the response. When set to 'True', a token will be returned in a Sale or AuthOnly response and can be accessed via SagePayToken. Note: when using this config you must set the "VPSProtocol" SpecialFields to "3.00". The default value is 'False'.

This field allows you to specify whether to store a token and on the SagePay server. This field must be set to 'True' to have the token remain on the server after use. Otherwise, if set to 'False', the Token will be used to perform the requested transaction and then deleted from the server. Note: when using this config you must set the "VPSProtocol" SpecialFields to "3.00". The default value is 'False'.

This field is used to retrieve or specify a token value. This field will be populated after a call to either SagePayCreateToken or SagePayRequestToken is set to 'True' and a Sale or AuthOnly request is performed. This field can be specified prior to calling SagePayRemoveToken or performing a transaction using a token value instead of Card.

The SagePay gateway (formerly Protx) has two different void transaction types. If SagePayUseAbort is set to false (default), void transactions are sent with the VOID transaction type. If true, void transactions are sent with the ABORT transaction type. Aborts are used for voiding auth-only transactions, and voids are used for voiding sale/capture transactions.

The TransactionId from the original request must be passed as the parameter in the VoidTransaction method. In addition, the following Special Fields are required for both Abort and Void transactions:

This configuration setting is used to specify the AuthToken to include when making an Access Token Exchange request to the Shift4 gateway. An access token is required for any other interaction with the gateway.

This configuration setting is used to specify the Client Guid to include when making an Access Token Exchange request to the Shift4 gateway. An access token is required for any other interaction with the gateway.

This is an action config which when called will perform an Access Token Exchange request with the Shift4 gateway. Before calling this config, the MerchantLogin property and the Shift4InterfaceName, Shift4InterfaceVersion, Shift4AuthToken, and Shift4ClientGuid configuration settings should be set. MerchantPassword will be set to the access token if the request is successful. Note that an AuthToken can only be exchanged for an access token once, so be sure to save the result of the request for future use.

Shift4 requires you to identify the interface that you are using to communicate with the API (i.e. your application). This configuration setting is used to specify the name of the interface.

Shift4 requires you to identify the interface that you are using to communicate with the API (i.e. your application). This configuration setting is used to specify the version of the interface.

For the Stored Credentials framework, this configuration setting should be set to true to indicate that the merchant will be storing the customer's card information. Permission should be obtained from the customer prior to storing card data. This configuration setting is used by the CyberSource gateway.

This configuration setting is used when there is an additional fee included in the transaction to specify the amount of that fee. This field is used by the Shift4 gateway.

This config is used to specify the capability of the terminal being used in a retail transaction.

The available values for the CyberSource gateway are (If not specified, the component will set the value to either '2' or '3' based on the specified EntryDataSource.):

The available values for the Litle gateway are (If not specified, the component will set the value to 'magstripe'.):

For Shift4 this field is more complicated, and should be set to a JSON object matching the value of the device.capability field from the Shift4 documentation.

Many gateways allow/require an Id (terminal, developer, client, user, etc) sent in addition to the MerchantLogin and MerchantPassword. This config is supported for the following gateways: Adyen (required), BarClay (required), BluePay, Nuvei (required), Heartland, HSBC (required), Orbital, PayFuse (required), PaymentWorksuite, Planet Payment (required), SkipJack, and WorldPayXML (required). For Orbital, this config is optional but if not specified a value of '001' will be sent. For Heartland, this config is used for MasterCard's Card Accepter Terminal Id requirement.

This config is used to specify the manufacturer of the terminal (device) being used in a retail transaction. This config is used with the Shift4 gateway.

This config is used to specify the model of the terminal (device) being used in a retail transaction. This config is used with the Shift4 gateway.

This config is used to specify the terminal (device) type being used in a retail transaction.

The available values for Authorize.NET are (required):

The available values for USA EPay are (required):

The available values for Chase, First Data, LinkPoint, and YourPay are (required):

This configuration setting is used when there is a tip included in the transaction to specify the amount of the tip. This field is used by the Shift4 gateway.

This field is used to specify whether you wish to perform a void or void:release transaction when VoidTransaction is called. When set to "True", the void:release transaction will be sent. The void:release transaction is the same as a void with the exception that the cardholders bank is notified immediately that they can release the funds. The regular void transaction, on the other hand, does not notify the cardholder bank until the batch closes. The default value is "False" (so a regular void transaction is sent).

For the Stored Credentials framework, this configuration setting should be set to true to indicate that the merchant is using stored card information. This configuration setting is used by the CyberSource gateway.

This configuration setting is used to specify an Id for the user, if one is required. Used by the Barclay, Ingenico, Metrobank, and Shift4 gateways. For the Barclay and Ingenico gateways, this configuration setting should contain the name of your application (API) user. For Shift4 or Metrobank, this is the clerk or terminal operator.

The number of child attributes of the current element. The XChildren configuration options will be indexed from 0 to XChildrenCount-1.

The current element is specified via the XPath configuration option.

This configuration option is read-only.

Provides the name of the x'th child element of the current element.

The current element is specified via the XPath configuration option.

This configuration option is read-only.

Provides the inner text of the x'th child element of the current element.

The current element is specified via the XPath configuration option.

This configuration option is read-only.

The current element is specified via the XPath configuration option.

This configuration option is read-only.

XPath implements a subset of the XML and JSON XPath specification, allowing you to point to specific elements in the XML or JSON documents. The path is a series of one or more element accessors separated by '/'. The path can be absolute (starting with '/') or relative to the current XPath location. The following are possible values for an element accessor:

When XPath is set to a valid path, XElement points to the name of the element, with XChildren and XText providing other properties of the element.

Example (Setting XPath for XML)

Example (Setting XPath for JSON)