Setting Up the Credit Card Interface

This chapter provides an overview of credit card processing and discusses how to:

• Set up the credit card interface.

• Configure the Java interlink plug-in.

• Configure the PeopleSoft Application Designer plug-in.

• Set transaction inputs and outputs.

See Also

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Business Interlinks, “Business Interlinks for Runtime Plug-in Programming”

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Business Interlinks, “Business Interlinks for Application Developers”

Understanding Credit Card Processing

Use the credit card processing interface to integrate with credit card processing vendors. You have the following options for credit card processing:

• CyberSource integration.

• XML-based integration.

• Manual processing.

Understanding a CyberSource Integration

If you use CyberSource, agents processing credit cards can use an application-specific credit card transaction page to submit the transaction to CyberSource for authorization, billing, authorization and billing, or credit. You can choose which types of transactions to permit.

Integration with other vendors may require customizations. There are third-party applications, such as TouchNet, that conform to CyberSource’s API. TouchNet follows CyberSource's API standard.

The Credit Card Authorize Bill and Credit integration point enables interaction between PeopleSoft applications and CyberSource by way of the EOEC_CCI_TRANSACTION business interlink. Activate the business interlink by entering a CyberSource merchant ID on the Credit Card Interface Installation page.

PeopleSoft does not ship CyberSource code or programs. Contact CyberSource to contract for its services and obtain a CyberSource merchant ID and supporting files. When contacting CyberSource, identify yourself as a PeopleSoft customer.

Note. PeopleSoft applications use PeopleSoft Business Interlink architecture to interface with CyberSource and CyberSource-compliant credit card processing vendors. To configure interfaces with unsupported vendors, create an interlink plug-in.

See Also

http://www.cybersource.com

Understanding an XML-Based Integration

PeopleSoft delivers the following XML messages for use with XML-based credit card processing vendors. Ensure that the XML message is transformed into the format that the vendor is expecting.

Note. If you have upgraded from a previous PeopleTools 8.48x release, the upgrade program creates service operations for these messages. The service operation names and message names are the same.

Agents can then process credit cards using their application-specific credit card transaction page to submit the transaction to the vendor for authorization, billing, authorization and billing, or credit. You can choose which types of transactions to permit.

If you use an XML-based interface, you must use PeopleSoft Integration Broker to set up the node to which the XML messages should be sent and to indicate where the processor is located.

In configuring the node, specify that the node type is External,.. Also specify the authentication option that you arranged with the credit card processor.

See Also

Enterprise PeopleTools 8.48 PeopleBook: PeopleSoft Integration Broker

Enterprise PeopleTools 8.48 PeopleBook: Security Administration, “Setting up Digital Certificates and Single Signon”

Understanding Manual Processing

If you decide not to use CyberSource or an XML-based credit card processing system, then your application-specific credit card transaction page captures information for use with your own solution for processing credit card payments.

To support manual processing, you must build your own process to read credit card data from the PeopleSoft tables and process the credit card transaction.

Setting Up the Credit Card Interface

This section discusses how to:

• Define connection parameters.

• Define accepted credit card types.

• Test the credit card interface.

• Test the credit card transaction.

Pages Used in Setting Up the Credit Card Interface

Defining Connection Parameters

Access the Credit Card Interface Installation page.

Entering information on this page is required for CyberSource, CyberSource-compliant, and XML-based processing systems. Verify connection requirements with your vendor.

Allowed Transaction Types

Connection Parameters

CyberSource, and CyberSource-compliant and XML-based third-party vendors provide you with information to connect with their systems. Enter that information to enable PeopleSoft to make the connection when you submit a transaction for processing.

Defining Accepted Credit Card Types

Access the Card Type page.

This page is required for all types of credit card processing.

PeopleSoft delivers data for most popular credit card types. You can modify existing definitions and add new ones.

Testing the Credit Card Interface

Access the Test Credit Card Interface - Card Entry/Display page.

The test you can run on this page does the following:

• Verifies that the card number you enter meets the requirements defined in the Credit Card Valid Prefixes field for the associated card type on the Card Type page.

• If you have set the Use Check Digit Algorithm field value to Y, verifies that the card number is valid based on the MOD 10 check digit algorithm.

• Verifies that you have entered values in the Exp. Month, Expiration Year, First Name, and Last Name fields on this page.

You can use the following credit card sample data in your test transactions:

Testing Credit Card Transactions

Access the Credit Card Transaction Test page.

Sequence and Request	Display a combination of numbers that distinguish the transaction from other transactions. They are similar to a run control or job number.
Amount	Enter a transaction amount and click the Look up button to select a transaction currency.
Trans. Type (transaction type)	Choose a transaction type to test: Authorize Only: Verify that the card is valid for the charge. Bill Only: Bill the card without first verifying that the card is valid for the charge. Authorize and Bill: Perform both authorization and billing during the same transaction. Credit Only: Credit the customer’s credit card.
Class ID	Select Test Transaction (the default) or one of the following interface types that has been specified on the Credit Card Interface Installation page. ProcessBrokerTransaction: Select if you want to test your XML-based interface. Interlink Transaction: Select if you want to test your CyberSource-compliant interface. See Defining Connection Parameters.
Process	Click to process the test transaction.
Return Code	Enter a return code to test whether proper error messages and results are returned. Available codes and their descriptions are discussed in the Return Codes section below.
Test Results	The results of the transaction test appear in this text box. Test result interpretations are discussed in the following sections.

Return Codes

You can enter any of the following return codes and click Process to view the corresponding description and error message in the Test Results area. These return codes and their corresponding errors can appear in multiple areas. For example, when using the Test Credit Card Interface component, they appear on this test page. When using the Business Interlink Tester, they are displayed in the various return fields. In an application, they appear as appropriate to that application's method of interacting with the credit card interface.

Configuring the Java Interlink Plug-In

PeopleSoft delivers a Java interface to your third-party credit card authorization and payment application.

This section provides an overview of the Java interlink plug-in and discusses how to:

• Set up the CyberSource API and Java plug-in on Microsoft Windows NT systems.

• Set up the CyberSource API and Java plug-in on Solaris systems.

Understanding the Java Interlink Plug-In

Using PeopleSoft Business Interlink technology, the Java interface supports four types of transactions:

• Authorize only.

• Bill only.

• Authorize and bill.

• Credit.

Use the plug-in to interface with the CyberSource credit card processing services product. The business interlink Java plug-in (delivered with your PeopleTools installation) uses the CyberSource Java API, version 3.7.11. Before you configure your system, obtain the CyberSource Java API from the Support Center in the CyberSource website.

Note. This distribution was tested and developed with JDK 1.2.1on Solaris-2.6. If you use a JVM other than that provided by Sun Microsystems, you might encounter problems. This version of the Java SDK does not support JDK 1.1.7.

Download the zipped API files and use the instructions in this section to configure the environment. You must obtain the Java version of the API even if you are already using the C++ plug-in and API.

See http://www.cybersource.com

We support CyberSource API version 3.7.11 when used with the following:

• Java Development Kit (JDK) version 1.1.8, 1.2.2, or later; installed and running.

• Solaris 2.6 operating system on SPARC or Windows NT Server 4.0 on Intel.

• If you use a Java Virtual Machine that is not developed and supported by Sun Microsystems, you may encounter problems with the Internet Commerce Suite CyberSource Development Kit for Java.

   

  Note. When you upgrade to PeopleTools 8.47 or higher, you must upgrade to Cybersource 3.7.11.

Note. Other UNIX platforms are not known to be supported, but please refer to the CyberSource website for a current listing of supported platforms.

Setting Up the CyberSource API and Java Plug-in on Microsoft Windows NT Systems

This section discusses how to:

• Set up the business interlink environment on Windows NT.

• Set up the CyberSource API on Windows NT.

• Set up the plug-in on Windows NT.

Setting Up the Business Interlink Environment

To set up the business interlink environment:

1. Ensure that two entries in the PATH environment variable point to the Java Run-Time Environment (JRE) bin.

   Do not confuse the JRE bin with the Java Development Kit (JDK) bin. The two entries in the PATH environment variable should point to the JRE home\jre\bin and JRE home directory\jre\bin\classic.

2. Create an entry in the CLASSPATH environment variable.

   Point the entry in the CLASSPATH environment variable to the psinterlinks.jar file. The psinterlinks.jar file is located in <PS_HOME>\class.

   You must include the name of the .jar file in the CLASSPATH entry; for example, <PS_HOME>\class\psinterlinks.jar.

Setting Up the CyberSource API

To set up the CyberSource API:

1. Install the CyberSource API using CyberSource instructions.

2. Follow the CyberSource installation directions for making CLASSPATH entries.

3. Update the CyberSource properties file for your CyberSource environment.

   Update the file CyberSource Home\ics_3.7.11\properties\ICSClient.props to point to the key and certificate files located in the keys directory. If you are using version 3.7.12, the path is CyberSource Home\ics_3.7.12\properties\ICSClient.props.

   Use a forward slash—not a backslash—to separate the directories, as follows:

   # file with the location of your private key required
   myPrivateKey=<CyberSource Home>/keys/<filename.pvt>
   # file with the location of your cert required 
   myCert=<CyberSource Home>/keys/<filename.crt>
   # file with the location of the CyberSource cert
   serverCert=<CyberSource Home>/keys/CyberSource_SJC_US.crt

4. Run the Java class ICSAuthTest.class.

   The Java class ICSAuthTest.class is located in the directory where you installed CyberSource. You must run this to ensure the API is set up properly. To run the ICSAuthTest.class:

   1. Edit the ICSAuthTest.java code to change the expiration to a future date.

   2. Open the Windows command prompt and change drives and directories to point to the test directory.

   3. Type Javac ICSAuthTest.java to recompile the edited file.

   4. Type Java ICSAuthTest to run the test.

   5. Verify that the Java class ICSAuthTest.class ran successfully.

Setting Up the Plug-in

To set up the plug-in:

1. Move the pscreditcard.jar file to the desired directory.

   The pscreditcard.jar file is installed in <PS_HOME>\class. You can move this .jar file to another directory for more stringent security access. The .jar file operates with execute permission only.

2. Update the CLASSPATH variable to point to the pscreditcard.jar file.

   Include the file name in the CLASSPATH entry.

3. Open PeopleSoft Application Designer, and select File, New, Business Interlink.

4. Select pscreditcard.dll.

5. Verify that the text that appears in the Version field in the new Business Interlink dialog box begins with plugin.

   If the text reads Failed to initialize JVM, your PATH environment variable is not pointing to the JRE directories. Ensure that your PATH points to both the JRE bin and classic directories; for example: JRE Home\jre\bin and JRE Home\jre\bin\classic.

6. If you are using three-tier architecture while accessing this plug-in, update the psappsrv.env file.

   To update the psappsrv.env file:

   1. Locate the psappsrv.env file in your application server domain folder (<PS_HOME>\appserv\your domain\psappsrv.env), and open it in a text editor.

   2. Append the path to your JRE \bin\classic directory to the end of the PATH variable in psappsrv.env.

   3. Ensure that there is a semicolon between path entries.

Setting Up the CyberSource API and the Java Plug-in on Solaris Systems

This section discusses how to:

• Set up the business interlink environment on Solaris.

• Set up the CyberSource API on Solaris.

• Set up the plug-in on Solaris.

• Configure the application server on Solaris.

Setting Up the Business Interlink Environment

To set up the business interlink environment:

1. Ensure that pspkgs.sh was run as part of the installation process.

2. Verify that the file psinterlinks.jar file exists in $PS_HOME/appserv/classes.

   If psinterlinks.jar does not exist, pspkgs.sh may have been run incorrectly.

3. Verify that the Java Virtual Machine is installed under the Tools home directory.

   If the Java Virtual Machine is not installed, pspkgs.sh may have run incorrectly.

4. Locate psconfig.sh, and open it in a text editor.

5. Ensure that there is an entry in the PATH environment variable in psconfig.sh pointing to the JRE bin.

   Do not confuse the JRE bin with the JDK bin. The entry in the PATH environment variable should point as follows: PATH=$PS_JRE/bin:$PATH;export PATH

6. Create an entry in the PS_CLASSPATH environment variable in psconfig.sh.

   Point the entry to the psinterlinks.jar file located in $PS_HOME/appserv/classes. You must include the name of the .jar file in the PS_CLASSPATH entry; for example, $PS_HOME/appserv/classes/psinterlinks.jar.

Setting Up the CyberSource API

Complete these steps for application servers.

To set up the CyberSource API:

1. Install the CyberSource API using the CyberSource documentation.

2. Update CLASSPATH and PS_CLASSPATH in psconfig.sh to point to the API .jar file. The API .jar file is ics.jar.

3. Update CLASSPATH in psconfig.sh to point to the test directory under the API’s ics_3.7.11 or ics_3.7.12 directory.

4. Save your changes to psconfig.sh.

5. Update the CyberSource properties file.

   Update the file CyberSource Home/ics_3.7.11/properties/ICSClient.props to point to the key and certificate files located in the keys directory. For version 3.7.12, update the file to CyberSource Home/ics_3.7.12/properties/ICSClient.props.

   Be sure to use a forward slash—not a backslash—to separate the directories, as follows:

   # file with the location of your private key required
   myPrivateKey=<CyberSource Home>/ics/keys/<filename.pvt>
   # file with the location of your cert required 
   myCert=<CyberSource Home>/ics/keys/<filename.crt>
   # file with the location of the CyberSource cert
   serverCert=<CyberSource Home>/ics/keys/CyberSource_SJC_US.crt

6. Run psconfig.sh to set the properties.

7. Run the Java class ICSAuthTest.class.

   The Java class ICSAuthTest.class is located in the directory where you installed CyberSource. You must run this class to ensure that the API is set up properly.

   Before you run the test, edit the ICSAuthTest.java code to change the expiration to a future date and then recompile ICSAuthTest.java by typing Javac ICSAuthTest.java at the prompt.

Note. You do not need to make a system-level CLASSPATH entry in addition to the CLASSPATH entry in psconfig.sh. If the Java class ICSAuthTest.class runs successfully, you can remove the CLASSPATH references to the test directory and the ics.jar file.

Setting Up the Plug-in

Complete these steps for application servers and PeopleSoft Process Scheduler servers.

To set up the plug-in:

1. Confirm that the pscreditcard.jar file is located in $PS_HOME/appserv/classes.

   You can move this .jar file to another directory to tighten security and limit access. If you move this .jar file to a different location, ensure that you reference the new location in the following steps.

2. Update PS_CLASSPATH in psconfig.sh to point to the pscreditcard.jar file in the classes directory.

   Include the file name in the entry.

3. Confirm that the libpscreditcard file is in the $PS_HOME/bin/InterfaceDrivers directory.

   Note. Use the same naming convention as the libpsjavaproxy file for the libpscreditcard file.

4. Stop and restart the application server.

   Stop the services; do not stop the machine.

Configuring the Application Server

To configure the application server:

1. Copy the ICSClient.props file from the CyberSource properties directory to the application server domain directory.

2. Open the psappsrv.env text file that is located in your application server (not the web server) domain folder.

3. Append the path to your JRE/bin/classic directory to the end of the PATH variable.

   Ensure that there is a semicolon between path entries. You can find the JRE path in your PATH system variable.

4. Shut down and restart your application server.

Configuring the PeopleSoft Application Designer Plug-in

This section discusses how to:

• Configure access to account information.

• Configure proxy server support.

• Set up tracing.

• Check parameter check logic.

• Set the decryption option.

Note. All credit card transactions are supported through one business interlink transaction.

Configuring Access to Account Information

The following configuration parameters are needed to complete any transaction:

• Merchant ID

• Private key file

• Certificate file

• Server ID

• Server certificate

• Server URL

The plug-in offers the following three configuration options:

• Maintain the six configuration parameters in a properties file.

  Use this option if you are building a new credit card processing application.

• Pass the merchant ID and server URL as input parameters, and specify the path of the key and certificate files.

  Use this option if you have an existing application that has used the C++ plug-in, but which you are now porting to Solaris.

• Use this plug-in just as you use the C++ version.

  The plug-in gets the certificate and key files from <CyberSource Home>\keys. Use this option if you have been using the C++ plug-in and want to continue to operate on a Microsoft Windows platform.

Note. The following configuration options demonstrate default input parameter values. After setting up a transaction, set the input parameter values as default values to test them in the Business Interlink Tester. Typically, PeopleCode sets these input parameter values at runtime.

In PeopleSoft Application Designer, select File, Open, Business Interlink to open a business interlink transaction. Define the configuration parameters for your credit card business interlink definition on the Settings and Input pages.

Option 1: Keep All Configuration Parameters in a Properties File

Use this option if you are building a new credit card processing application.

To keep all of the configuration parameters in a properties file:

1. Update the CyberSource properties file.

   Update the file <CyberSource Home>\ics_3.7.11\properties\ICSClient.props to point to the key and certificate files located in the keys directory. If you are using version 3.7.12, update the file to Update the file <CyberSource Home>\ics_3.7.12\properties\ICSClient.props

   Use a forward slash to separate directories, as follows:

   # file with the location of your private key required
   myPrivateKey=<CyberSource Home>/keys/<filename.pvt>
   # file with the location of your cert required 
   myCert=<CyberSource Home>/keys/<filename.crt>
   # file with the location of the CyberSource cert
   serverCert=<CyberSource Home>/keys/CyberSource_SJC_US.crt

2. Set the value of the properties_file configuration parameter to the path of the ICSClient.props file.

   In PeopleSoft Application Designer, select the Settings tab to set the value. Use a forward slash to separate directories.

3. Leave the privateKeyFile, myCertFile, serverCertFile, and certServerID fields blank.

Option 2: Pass the Merchant ID and Server URL as Input Parameters, and Specify the Path of the Key and Certificate Files

Use this option if you have an existing application that has used the C++ plug-in but which you are now porting to Solaris.

To pass the merchant ID and server URL as input parameters and to specify the path of the key and certificate files:

1. Delete the value of the properties_file configuration parameter on the Settings page.

   Enter the paths for the key and certificate files in their appropriate configuration parameters. Use a forward slash to separate directories. The default value for the certificate server ID is CyberSource_SJC_US.

2. Include the merchant and server_host input parameters in your transaction.

   Do not include the text http:// in the server URL string.

Option 3: Use the Java Plug-in as You Use the C++ Version

Use this option if you have been using the C++ plug-in and want to continue to operate on a Windows platform.

To use the Java plug-in as you use the C++ version:

1. Delete the values of the properties_file, certificate, key, and server ID field parameters on the Settings page of the business interlink definition.

2. Use the merchant and server_host field input parameters in your transaction.

   Do not include the text http:// in the server URL string.

Configuring Proxy Server Support

The Java plug-in supports the HTTP proxy without a user name and password, and it supports the SOCKS proxy protocols.

See CyberSource ICS2 Developer's Guide

The following example shows the settings for configuring proxy support:

To implement proxy server support:

1. Select the proxy type from the useProxyServer configuration parameter.

2. Enter the values of the host and port in the proxyHost and proxyPort configuration parameters.

Setting Up Tracing

The plug-in and the CyberSource API support the use of a trace file. To keep a log of the transactions, use the plug-in’s trace file and reserve the API’s trace file for debugging. The plug-in trace file:

• Uses the input names as they appear in PeopleSoft Application Designer, not CyberSource API property names.

• Prints only the last four digits of the credit card number.

• Prints output values and any error messages.

Activating Tracing

There are two methods for activating tracing in the Java plug-in:

• Leave the trace_file blank and use the trace input parameter to toggle tracing.

  The trace file writes to c:\temp\crcard.txt.

• Enter a path and file name in the trace_file configuration parameter, and use the trace input parameter to enable the tracing (trace=Y) or disable the tracing (trace =N).

  Use this method for new credit card definitions, for porting existing credit card definitions to Solaris, or for writing the trace file to a directory other than c:\temp. Use forward slashes when specifying directory paths.

  See Defining Connection Parameters.

The following screen shot illustrates the second method.

Activating Trace Run-Only Mode

To see the input values that are sent to the CyberSource API and to confirm that the plug-in can instantiate the CyberSource interface without sending the transaction to CyberSource, pass a value of T with the trace input parameter. If a trace file has been specified in the trace_file configuration parameter, the system uses that trace file. Otherwise, the system uses the c:\temp\crcard.txt trace file.

Setting Parameter Check Logic

If the paramchk parameter is set to Y, the plug-in runs in trace run-only mode and performs additional checks in the input parameters to ensure that the parameters do not exceed maximum allowed field lengths. The system sends the transaction information to the CyberSource API.

Setting the Decryption Option

Credit card numbers can be sent encrypted to the plug-in. Do not change this option unless you also change the PeopleCode to pass the credit card number as plain text.

Setting Transaction Inputs and Outputs

If you create a new business interlink definition, you need to set inputs and outputs.

This section provides an overview of required parameters for available transactions and discusses how to:

• Use authorize-and-bill transactions.

• Use authorize-only transactions.

• Use bill-only transactions.

• Use credit transactions.

• Use the address verification service.

• Use the fraud screen service.

• Identify input fields that are not used or supported.

Identifying Required Parameters

The service and merchant_ref input parameters are required in all credit card transactions. The method that you use to configure the plug-in determines which fields are required.

The service and merchant_ref input parameters are required in all credit card transactions. The method that you use to configure the plug-in determines which fields are required.

Service Input Field

The system uses the service parameter to determine which of the four credit card transactions it should conduct through business interlink transactions. The service parameter values perform the following functions:

Merchant_ref Input Field

The merchant_ref field is a merchant-generated order reference or tracking number, which contains information such as an order number. Use the merchant_ref_number field as your own tracking number for the order, to keep track of requests sent to CyberSource relating to the same order.

Using Authorize-and-Bill Transactions

The authorize-and-bill transaction (service=2) performs both authorize and bill actions and returns a bill amount for verification of the amount billed.

Required input data includes:

• Service

• Merchant_ref

• Fname

• Lname

• Addr1

• City

• Country

• State

• Zip

• Email

• Expmo

• Expyr

• Ccnum

• Amount

• Currency

Output data includes:

• return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

• Bill_amount

Using Authorize-Only Transactions

The authorize-only transaction (service=1) authorizes the amount passed in and returns a request ID to be used later in a bill transaction.

Required input data includes:

• Service

• Merchant_ref

• Fname

• Lname

• Addr1

• City

• Country

• State

• Zip

• Email

• Expmo

• Expyr

• Ccnum

• Amount

• Currency

Output data includes:

• Return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

Using Bill-Only Transactions

The bill-only transaction (service=3) requires the use of a request ID obtained from an authorize-only transaction.

Required input data includes:

• Service

• Merchant_ref

• Amount

• Currency

• Rqstid

Output data includes:

• Return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

• Bill_amount

• Trans_ref_no

Using Credit Transactions

You can use one of the following methods to perform a credit transaction.

Use a Request ID

This option enables you to use the value of a request ID returned from a previous request for bill transactions. This value is matched with a previous bill for the same order. If this field is present and there is no matching bill, the transaction fails. If the bill request ID is not present, the credit transaction requires the customer billing information.

Required input data includes

• Service

• Merchant_ref

• Amount

• Currency

• Rqstid

Output data includes:

• Return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

• Credit_amount

• Trans_ref_no

Use Billing Information

Required input data includes:

• Service

• Merchant_ref

• Fname

• Lname

• Addr1

• City

• Country

• State

• Zip

• Email

• Phone

• Expmo

• Expyr

• Ccnum

• Amount

• Currency

Output data includes:

• Return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

• Credit_amount

Using the Address Verification Service

CyberSource returns the decline code DAVSNO if the billing address does not match the billing address for the credit card. If you set the value of the avs_ignore field to yes and include it in your business interlink definition, the system allows the authorization transaction to proceed despite the billing address discrepancy. If the value of the avs_ignore field is anything other than yes, the address verification proceeds as usual.

The address verification service returns a value that is stored in the ret_avs field. The values are:

Using the Fraud Screen Service

Both the authorize-only and the authorize-and-bill transactions support the fraud screen transaction.

See CyberSource documentation.

The Fraud_screen field determines if the fraud screen transaction request should be sent with the current transaction.

The Score_criteria_modified field determines if fraud screen score tuning parameters were altered for this transaction. If this field is set to yes, all of the following score tuning parameter fields must be included in the transaction.

Required data input includes:

• Service

• Merchant_ref

• Fname

• Lname

• Addr1

• City

• Country

• State

• Zip

• Email

• Phone

• Expmo

• Expyr

• Ccnum

• Amount

• Currency

Output data includes:

• Return_status

• Return_status_msg

• Ret_msg1

• Ret_msg2

• Ret_authcd

• Ret_authdttm

• Rqstid_out

• Bill_amount (authorize/bill transaction)

Identifying Input Fields That Are Not Used or Supported

The following input fields are not used or supported as of 11/06/00: