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".

This field allows you to get or set an XML aggregate built from all of the fields from this type. "EPCardType" is the root element, and the names of the fields create the tags under the root. For instance: <EPCardType> <Number>4444333322221111</Number> <CVV2Data>996</CVV2Data> <CVVIndicator>cvPresent</CVVIndicator> <ExpMonth>12</ExpMonth> <ExpYear>2010</ExpYear> <CardType>ctVisa</CardType> </EPCardType>

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)

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 property is validated.

By default, when the Number field is set, the value will be validated and normalized. For instance, "4444-33332222 1111" will be normalized as "4444333322221111". 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 field, 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.

Customer's credit card number for the transaction.

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

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.

iCharge 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.

This configuration setting is used to specify the sales channel the shopper gives their card details through and whether the shopper is a returning customer. Default value is 0.

Available values are:

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 config is used to specify the type of request which will occur when the Sale method is called. By default it is set to Normal (0), in which case the class will send a normal transaction sale request.

The other options are used to instruct the class to send the appropriate type of request needed to query, create, update, or delete a customer vault record when Sale is called.

Possible values for this setting are:

• 0 - Normal (default)
• 1 - Add Customer Vault Record
• 2 - Update Customer Vault Record
• 3 - Delete Customer Vault Record
• 4 - Query Customer Vault Record

Please see the gateway setup information for American Payment Solutions for more details on how to use the ICharge class to work with customer vault records. Refer to American Payment Solutions' documentation for more information about the customer vault in general.

This configuration setting is used to specify the company in the billing information for the customer.

Note that this is only valid when the Gateway property is set to gwAuthorizeNetXML.

This config is used to specify the ID of a payment profile to be used to perform a transaction. A payment profile is tied to a AuthNetCIMProfileId and is used to identify the payment option to charge. With the Authorize.NET CIM gateway, transactions are performed using profiles to access customer information stored on their Customer Information Manager (CIM) instead of sending raw card and billing data with the transaction. Therefore this property is required. Note: The RecurringBilling class can be used to manage payment profiles.

This config is used to specify the ID of a profile to be used to perform a transaction. A profile is used to identify the customer initiating the transaction. With the Authorize.NET CIM gateway, transactions are performed using profiles to access customer information stored on their Customer Information Manager (CIM) instead of sending raw customer data with the transaction. Therefore this property is required. Note: The RecurringBilling class can be used to manage profiles.

When requesting a CIM profile to be created by setting the AuthNetCreateCIMProfile configuration setting to True, this configuration setting will contain the response. For Example: icharge.Config("AuthNetCreateCIMProfile=True"); icharge.Sale(); Console.WriteLine(icharge.Config("AuthNetCIMProfileResponse"));

Note that this is read-only and only valid when Gateway property is set to gwAuthorizeNetXML.

This config is used to specify the ID of a shipping address profile to be used to perform a transaction. A shipping address profile is tied to a AuthNetCIMProfileId and is used to identify the shipping location of the item purchased in the current transaction. With the Authorize.NET CIM gateway, transactions are performed using profiles to access shipping information stored on their Customer Information Manager (CIM) instead of sending raw shipping data with the transaction. This property is optional. If an shipping address ID is not specified, shipping information will not be included with the transaction. Note: The RecurringBilling class can be used to manage shipping address profiles.

Whether to create a CIM profile for the customer during a Sale or AuthOnly transaction. By default this configuration setting is set to False. When set to True, the response for the profile creation will be returned in the AuthNetCIMProfileResponse configuration setting. For Example: icharge.Config("AuthNetCreateCIMProfile=True"); icharge.Sale(); Console.WriteLine(icharge.Config("AuthNetCIMProfileResponse"));

Note that this is only valid when the Gateway property is set to gwAuthorizeNetXML.

This configuration setting is used to specify the value of the cryptogram received from the token provider. This configuration setting is required when AuthNetTokenizedCard configuration setting is set.

Note that this is only valid when calling Sale method and the Gateway property is set to gwAuthorizeNetXML.

This configuration setting is used to specify the customer type to send during a request to the Authorize.NET XML gateway. Default value is 0.

Available values are:

This setting can be set to an Authorize.Net opaque data descriptor in order to use it in place of explicit card or bank account information. AuthNetOpaqueValue must also be set.

This setting is only valid with the gwAuthorizeNetXML and gwAuthorizeNetCIM gateways, it cannot be used with the gwAuthorizeNet gateway.

This setting can be set to an Authorize.Net opaque data value in order to use it in place of explicit card or bank account information. AuthNetOpaqueDescriptor must also be set.

This setting is only valid with the gwAuthorizeNetXML and gwAuthorizeNetCIM gateways, it cannot be used with the gwAuthorizeNet gateway.

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 configuration setting is used to specify the credit card token to perform a Sale transaction.

Note that this is only valid when calling Sale method and the Gateway property is set to gwAuthorizeNetXML.

This configuration setting is used to set the API passcode when using the passcode option for authentication with Bambora.

This configuration setting is required for some merchants when calling the Sale method, and must be set to the name of the card issuer. For example: icharge.Config("BankName=Wells Fargo"); icharge.Sale();

By default (value of 'False'), all maintenance transactions (such as Capture, Refund, and VoidTransaction) will close the transaction after the operation is performed. When set to 'True', the operation will be performed and the transaction will be left open for further processing. This config works in conjunction with the following methods:

AuthOnly

Capture

Refund

VoidTransaction

By default (value of 'False'), the Refund method will send a partial or full refund which closes the transaction. When this setting is set to 'True', a partial refund transaction will be sent and the transaction will be left open for another potential refund.

If BASYSProcessRecurringCredit is set to True this must be set to the credit card profile id value assigned to the payment method when it was added to the system.

Note: BASYSCardInfoKey can be obtained via the RecurringBilling class.

Determines whether to process the transaction via customer's Credit Card profile. By default this configuration setting is set to False. If set to True, BASYSCardInfoKey and MerchantCode configuration settings must also be set. For instance: icharge.Config("MerchantCode=YourBASYSMerchantKey"); icharge.Config("BASYSProcessRecurringCredit=True"); icharge.Config("BASYSCardInfoKey=YourBASYSCardInfoKey"); icharge.TransactionAmount = "1.00"; icharge.Sale();

Determines whether to process the transaction using a Credit Card Token provided by BASYS Gateway. By default this configuration setting is set to False. If set to True, BASYSTokenMode and BASYSToken must also be set. For Instance: icharge.Config("BASYSProcessTokenCredit=True"); icharge.Config("BASYSToken=YourToken"); icharge.TransactionAmount = "1.00"; icharge.Sale();

If BASYSProcessTokenCredit is set to True, this must be set to the token value assigned to the payment method when it was added to the system.

Note: BASYSToken can be obtained via the RecurringBilling class.

Indicates the type of token that is being used for the transaction. If BASYSProcessTokenCredit is set to True this must be set to one of the following values.

Possible values:

If BASYSVoidMode is set to "0" (default), VoidTransaction sends a void to undo an unsettled transaction. If BASYSVoidMode is set to "1" (Reversal), this ensures the transaction is unsettled and also removes the authorization from the issuing bank.

Possible values:

By default, when VoidTransaction is called with gwBluefin selected the request will use the REFUND transaction type, which is used to void an unsettled Sale transaction. Set this configuration setting to True to use the REVERSAL transaction type instead, which will void an uncaptured authorization. Note that the REVERSAL transaction type may or may not be allowed depending on the payment processor for the account.

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

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.

This setting can be set to a JSON object like the following one in order to send Enterprise UDFs when calling Sale or AuthOnly: {"udf": [ { "udfValue": "aaa", "udfName": "ENT_UDF1" }, { "udfValue": "bbb", "udfName": "ENT_UDF2" } ]} Note: Content set using this setting will be used as the value of the transactionFraudInfo.enterpriseUdfs JSON field in the request body; it is not validated or manipulated first, it is used "as-is".

Each time this setting is queried, it will retrieve a new pfToken from BlueSnap. This token can then be passed to BlueSnap's hosted payment fields libraries, and then later passed in the transaction request using the special field pfToken or securityCodePfToken. Refer to BlueSnap's documentation for more information about hosted payment fields.

Setting this to a card transaction ID (or querying it with the TransactionId property set) will cause the class to retrieve the associated transaction and populate its fields accordingly. Please refer to the BlueSnap section of the "ICharge Gateway Setup and Required Properties" page for more information on how the class's fields map to BlueSnap's fields.

This setting can be set to a JSON object like the following one in order to send Enterprise UDFs when calling Sale or AuthOnly: {"metaData": [ { "metaValue": 20, "metaKey": "stateTaxAmount", "metaDescription": "State Tax Amount" }, { "metaValue": 20, "metaKey": "cityTaxAmount", "metaDescription": "City Tax Amount" }, { "metaValue": 10, "metaKey": "shippingAmount", "metaDescription": "Shipping Amount" } ]} Note: Content set using this setting will be used as the value of the transactionMetaData JSON field in the request body; it is not validated or manipulated first, it is used "as-is".

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.

This configuration setting is used to specify the last 4 digits of the credit card in certain scenarios.

This configuration setting is used to specify the encryption handler when requesting a token from CardPointe (gwCardPointe). This should be set to "RSA" if using a private key provided by CardPointe to encrypt the account value before sending. If the account value in the token request is not encrypted, this setting is not necessary.

This configuration setting is used to request a token from CardPointe (gwCardPointe). If CardToken is set, it will be used for the account in the request. If not, Number will be used instead.

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 configuration setting is used to specify the credit card token (sometimes called a "nonce") to perform a transaction.

Note that this is only valid when the Gateway property is set to gwConverge, gwMoneris, gwNuvei, gwSquare, gwSquarePayments, gwStripe, or gwQBPayments.

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 configuration setting is used to request a token when making a request to gwConverge. If this is set to 1 or 2 before calling Sale or AuthOnly, Converge will return a token in the response, which will be available through the CardToken configuration setting.

Possible values for this setting are:

• 0 - Don't request a token (default)
• 1 - Generate a token and return it in the response.
• 2 - Generate a token, add it to Converge's Card Manager, and return it in the response.

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 configuration setting is used to specify a customer profile Id when performing a transaction.

Note that this is only valid when the Gateway property is set to gwCardPointe.

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 config is used when sending 3D Secure data to the DataCash gateway. It indicates whether the cardholder was registered for 3D Secure and the PARes or VERes status. Available values are:

This config is used to specify whether an AuthOnly transaction should be treated as final. If the final settlement amount is not known, this config should be set to 'False' to indicate that the settlement amount will likely be changed prior to settlement. When set to 'True' or '' (empty string) (default value) the transaction will be treated as final. Note that with '' (empty string) the transaction will be treated as final unless the merchant configuration has been set up or there is a risk of reversal. MasterCard Europe and Maestro have created this mandate to improve the management of cardholder 'open to buy' limits.

The specified aggregate will be contained within the "ExtendedPolicy" element of the request.

The three available policies (elements) that can be specified are: "cv2_policy", "postcode_policy", and "address_policy". Each of these elements have five available attributes, "notprovided", "notchecked", "matched", "notmatched", "partialmatch", of which have the following available values: "accept" and "reject".

Below is a sample XML aggregate: <cv2_policy notprovided="reject" notchecked="accept" matched="accept" notmatched="reject" partialmatch="reject"/> <postcode_policy notprovided="reject" notchecked="accept" matched="accept" notmatched="reject" partialmatch="accept"/> <address_policy notprovided="reject" notchecked="accept" matched="accept" notmatched="reject" partialmatch="accept"/>

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.

This is an action config that will send a GetMethods request to the ExPay gateway. Method information returned in the response can be parsed via the GetResponseVar method or the X*** configuration settings.

This is an action config that will send a GetStatus request to the ExPay gateway. TransactionId or ExPayPaymentId is required (specifying both will result in an error). Status information returned in the response can be parsed via the GetResponseVar method or the X*** configuration settings.

This config is used to specify a payment Id to retrieve a transaction status for via ExPayGetStatus.

This config is used to specify the Id of the service (retrieved via a ExPayGetMethods call) and is required to perform an authorization via an AuthOnly call.

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: