The checkpass and validate calls were modified to respond to an .INI setting in ww.INI.

 

 

This is passed along to all validation calls in absence of a specific <dci> tag passed with the call.

 

Any valid IP address, plus :4203

 

Note: The port is configurable, but defaults to 4203

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

Text string (quotes optional)

“” (empty string)

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

The ww.dll uses any settings in [ValidationNNNNN] in favor of any of the other settings.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

While the [Axess] section is still allowed, it is now preferred for the Axess data to be inside the Validation section(s) and be labeled as AxessGoodScan and AxessBadScan.

 

The ww.dll can now recognize multiple [Validation] sections

 

The ww.dll can now recognize multiple [Validation] sections when in the ww.INI file. The main [Validation] section is used except when a <poedata> tag is passed to checkpass or validate pass from SiriusAxessSoap. In these cases, ww.dll looks for a ValidationNNNNN section (where NNNNN is the poedata).

 

While the [Axess] section is still allowed, it is now preferred for the Axess data to be inside the Validation section(s) and be labeled as AxessGoodScan and AxessBadScan.

 

To support the Axess gate integration, two more settings are required when ww.dll is being called from the Axess Gate Soap Service.

 

 

All eight of the xml fields listed in GoodScan and BadScan are required for the Axess integration to work correctly. Validations are performed like this:

 

 

Optional parameters are location, operator, salespoint, ip, port, decrypt, axessdata and timeout (three seconds is the default). A call with all options would look like this:

 

 

The axessdata parameter means to return the axessdata specified in the ww.INI file (depending on if the scan is good or bad). This function returns valid, msg, detail and perhaps an axessdata tag.

 

 

To support the Axess gate integration, two more settings are required when ww.dll is being called from the Axess Gate Soap Service.

 

 

All eight of the xml fields listed in GoodScan and BadScan are required for the Axess integration to work correctly. Validations are performed like this:

 

 

Optional parameters are location, operator, salespoint, ip, port, decrypt, axessdata and timeout (three seconds is the default). A call with all options would look like this:

 

 

The axessdata parameter means to return the axessdata specified in the ww.INI file (depending on if the scan is good or bad). This function returns valid, msg, detail and perhaps an axessdata tag.

 

 

This setting enables ww.dll and Sales to check AVS and CVV information associated with the credit card used in a Sale or an E-Commerce transaction. If a match does not occur, the transaction does not process. The message, “Sorry. An error has occurred!” CCV Check, in the case of a failed CVV2 match or AVS Check, in the case of a failed AVS match (Zip code or street address). In E-Commerce, this results in the error.aspx page when the check fails. In order for the checks to occur in Sales, the operator must enter the CVV2 and/or AVS information. If the information is not entered, the credit card transaction is always approved. A $0.00 transaction is written to ProtoBase when an AVS or CCV check fails. These checks only occur against VISA or MASTERCARD transactions. The setting Moto=TRUE must be present for the checks to occur.

Set to FALSE to disable checking CVV2.

 

This setting enables ww.dll and Sales to check AVS and CVV information associated with the credit card used in a Sale or an E-Commerce transaction. If a match does not occur, the transaction does not process. The message, “Sorry. An error has occurred!” CCV Check, in the case of a failed CVV2 match or AVS Check, in the case of a failed AVS match (Zip code or street address). In E-Commerce, this results in the error.aspx page when the check fails. In order for the checks to occur in Sales, the operator must enter the CVV2 and/or AVS information. If the information is not entered, the credit card transaction is always approved. A $0.00 transaction is written to ProtoBase when an AVS or CCV check fails. These checks only occur against VISA or MASTERCARD transactions The setting Moto=TRUE must be present for the checks to occur..

Set to FALSE to disable checking Zip code.

 

This setting enables ww.dll and Sales to check AVS and CVV information associated with the credit card used in a Sale or an E-Commerce transaction. If a match does not occur, the transaction does not process. The message, “Sorry. An error has occurred!” CCV Check, in the case of a failed CVV2 match or AVS Check, in the case of a failed AVS match (Zip code or street address). In E-Commerce, this results in the error.aspx page when the check fails. In order for the checks to occur in Sales, the operator must enter the CVV2 and/or AVS information. If the information is not entered, the credit card transaction is always approved. A $0.00 transaction is written to ProtoBase when an AVS or CCV check fails. These checks only occur against VISA or MASTERCARD transactions. The setting Moto=TRUE must be present for the checks to occur.

Set to FALSE to disable address checking.

 

When NetLog is set to TRUE (the default if this setting is not present in ww.ini), the SingleLog setting is ignored in favor of new settings that are part of the logging library.

These two settings affect how log files are created and named.

These two settings affect how log files are created and named.

The ww.dll can process credit card transactions through Elavon's Fusebox functionality.

 

 

CCTerminalID=ECOM,TSTLAR,SIRIUS sets terminal, chain and location settings if the chain and location settings are not entered they are read from SysManager > Preferences > Financial > Credit Cards setting. One method or the other must be used. An, “INVALID TERM ID” error message results if chain and location setting are not in either location.