Enable credit card encryption.

Encryption requires version 9.0 or higher of CWDirect, and version v5r3 or higher of the operating system.

Credit Card Encryption Installation and Setup: step-by-step instructions on installing credit card encryption.

Credit Card Encryption Key Switch: step-by-step instructions on encrypting credit card data using a new credit card encryption key.

For security reasons, it is recommended that you split the knowledge of the generated encryption key and key encryption key between two separate individuals in your organization.

To adhere to security best practices, it is recommended that you change your encryption key and key encryption key every 6 months.

Replace the encrypted credit card number in the CWDirect database with a token provided by the authorization service.

Credit card tokenization requires version 14.0 or higher of CWDirect and Litle as your authorization service.

Credit Card Tokenization

Turn off logging in any CWIntegrate site that passes customer credit card information.

Examples of CWIntegrate sites that pass credit card information include integrations with authorization services (such as Paymentech and Chase), and any integration that passes order messages (such as the integration with CWStore). Logging is typically helpful during the installation, testing, and certification phase of site implementation, but should be turned off before passing actual customer data.

Individual site documentation, such as the Paymentech Integration manual or the FDMS Chase Integration manual.

Define a credit card masking format for all credit card pay types.

The masking format is user-definable, but a typical format masks all but the last four digits of the credit card, replacing the other digits with asterisks (for example, **** **** **** 4567).

Credit Card Number Format

Enter Y in the Prevent Storing the Customer’s Last CC# and Exp Date (J86) system control value to prevent the storing of the customer’s credit card number and expiration date that was most recently used on an order in the Customer Sold To and Customer Ship To Order History files.

Conversion program: Run the following conversion program to remove the credit card numbers and expiration dates that currently exist in the Customer Sold To and Customer Ship To Order History files: Call CVR0719 parm(‘’ x’999F’), where 999 is the company code.

Note: If you do not run this conversion program and you enter Y in the Prevent Storing the Customer’s Last CC# and Exp Date (J86) system control value, the system will retain the credit card numbers and expiration dates that currently exist in the Customer Sold To and Customer Ship To Order History files. However, once you place a new order for a customer, the system will then clear the customer’s credit card number and expiration date from the Customer Sold To and Ship To Order History files.

Prevent Storing the Customer’s Last CC# and Exp Date (J86)

Use the Credit Card Retention Days (K65) system control value to define the number of days to retain credit card numbers in closed or cancelled orders.

Run the SECRISK function once to permanently replace credit card numbers up to 12 digits with asterisks (*), remove expiration dates, and deactivate pay types in order-related tables. Then run the process daily to update credit card data based on the Credit Card Retention Days (K65) system control value. See Security Risk Purge.

Credit Card Retention Days (K65)

Use the Restrict Access to Credit Card Numbers in OI and OM (A88) secured feature to restrict credit card access for all but specific users.

Set this secured feature to *EXCLUDE at the company level, and override the setting to *ALLOW only for users who require access to credit card information. MICROS user ID’s should not have access under this secured feature.

Setting Up Secured Features

Use the Display Full Credit Card Number (B14) secured feature to restrict display of the credit card number for all but specific users.

Set this secured feature to *EXCLUDE at the company level, and override the setting to *ALLOW only for users who require access to credit card information on screens and reports. MICROS user ID’s should not have access under this secured feature.

Setting Up Secured Features

Run the Encrypt Virtual Card File Periodic Function each time you receive new records in the Virtual Card Number file from an external system.

The system encrypts the virtual card numbers in the Virtual Card Number file when you initially install credit card encryption and when you perform a credit card encryption key switch to encrypt your credit card data using a new credit card encryption key. However, because this file is used to receive virtual card numbers from an external system, you need to run the Encrypt Virtual Card File periodic function after you receive new records in the Virtual Card Number file.

Encrypting the Virtual Card Number File

Delete sensitive authentication data

Card security value: The system automatically removes the card security value (CID, CVV2, CVC2) from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing.

If the card security value and card security presence are passed for an e-commerce order, the system clears the values and does not pass them to the order.

Bill Me Later: If a Bill Me Later account is approved, the system stores the account number in the encrypted credit card number field. Regardless if a Bill Me Later account is approved or declined, the system removes the customer’s social security number and date of birth.

Credit Card Security Service (CID, CVV2, CVC2)

Logging: Turn off logging in any CWIntegrate site that passes customer credit card information; see below.

Troubleshooting: When troubleshooting a problem dealing with sensitive data, collect only the minimum data required to solve the problem. If you need to store this information, store it in a secure location with limited access. Once the problem has been resolved, immediately delete the sensitive data.

Note: CWDirect does not process PIN numbers.

If you perform online authorizations using a leased line point-to-point integration, turn off logging to the Communication Trace file.

To turn off the Communication Trace file, enter the following command at a command line:

CHGDTAARA ONLINETRC ’0’

You should only log online transactions in the Communication Trace file if there are problems with processing that need to be researched. Once research is complete, turn off the Communication Trace file.

Note: Access to the ONLINETRC data area is controlled by security settings on the iSeries.

See Working with Socket Server Jobs (SOCK).

If you process authorization transactions to a Paymentech test environment using the Paymentech socket programs (AAR0173 and AAR0174), remove any test data stored in the PMTDTAF file once testing is complete.

The setting of the Production system field for the Paymentech service bureau in Work with Authorization Services (WASV) indicates whether you are sending authorization transactions to a test environment. Once testing is complete, select the Production system field to send transactions to Paymentech’s production environment; in this situation, the system does not create records in the PMTDTAF file.

Purge sensitive customer data after a defined retention period

Use the Purging Orders menu option to purge old orders.

Use the Merge/Purge Sold To Names menu option to merge duplicate sold to customers.

Use the Prevent Storing the Customer’s Last CC# and Exp Date (J86) system control value to prevent the storing of the customer’s credit card number and expiration date that was most recently used on an order in the Customer Sold To and Customer Ship To Order History file.

Purging Orders (MPOR, FORP, VORP, DORP)

Working with Merge/Purge Sold-to Names (MMCS)Prevent Storing the Customer’s Last CC# and Exp Date (J86)

Delete encryption key material that is no longer used

Once the entire encryption key switch process has been completed, you should securely delete old key switch files so that the files are not recoverable.

Credit Card Encryption Key Switch in the Data Security and Encryption Reference

Restrict access to the IFS portion of the iSeries to specific users. These users should not have access to CWDirect.

Access to the IFS portion of the iSeries is controlled by the WRKLNK command.

IBM documentation

Use the Generic Order Interface (Order API) rather than the phone interface to load remote orders.

If you continue to use the phone interface, set the Clear Phone Interface Files (J14) to Y to clear the files after processing orders.

Clear Phone Interface Files (J14)

Configure WebSphereMQ to use SSL when sending credit card data.

IBM documentation

Use TCP/IP over VPN to send credit card data from CWDirect to an authorization service

Use the password settings available on the iSeries to enhance security. To adhere to security best practices, it is recommended that you use the highest security settings available on the iSeries.

Summary of iSeries Password Options

Disable user accounts that have not been used for over 180 days.

Delete user accounts that have not been used for over 270 days (90 days after the user account has been disabled).

Query the User file to determine the last time a user account was used in CWDirect. To disable a user account, change the user’s authority to *EXCLUDE.

Working with User Records (WUSR)

Keep the CWDirect default user account at a low level of privilege (no system security, system administration, or fast path access) since it is used to create user accounts.

If you create a user account based on the default user account, you should review the necessary security for that individual user.

When setting up a user in CWDirect, access should be limited to the functions the user needs to successfully perform his or her job duties.

Working with User Records (WUSR)

Restrict MICROS from access to the Work with Users menu option and provide as little overall system authority as necessary to support your environment. If higher security needs to be granted to resolve a problem, reduce the security as soon as the problem has been resolved.

Work with Menu Option Authority Screen

Restrict MICROS from update authority to the Work with System Values/Features option.

MICROS should have *DISPLAY authority to system control values.

Work with Menu Option Authority Screen

Restrict MICROS from access to the IFS portion of the iSeries.

IBM documentation

Configure communications with MICROS so that communication is initiated by you, rather than MICROS. In addition, prevent MICROS from access to your servers until connection is granted by you over a secure connection.

Any passwords required to connect to a server should be different from the passwords used to access CWDirect.

Reset the password as need for support purposes.

Configure MICROS's user ID and password on the VPN to be different than the password for the CWDirect application.

Reset the password as need for support purposes.

Configure MICROS’s user ID and password to expire or be disabled daily.

Reset the password as needed for support purposes.

Summary of iSeries Password Options

Use a firewall configuration to secure data on the iSeries.

Recommended Firewall Configuration for E-Commerce

Apply software fixes and updates provided by MICROS.

Refer to the PCI Security Standards for all other security guidelines related to networks, wireless devices, etc.

http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html

QMAXSGNACN

Action to take for failed signon attempts

1=Disable device, 2=Disable profile, 3=Disable device and profile

3=Disable device and profile

QMAXSIGN

Maximum signon attempts allowed

1-*NOMAX

3 attempts

QPWDEXPITV

Password expiration interval

1 day - *NOMAX

30 days

QPWDLMTAJC

Limit adjacent digits in password

0=Allowed, 1=Not allowed

1=Not Allowed

QPWDLMTCHR

Limit characters in password

Allow user to have any character including special characters in password.

QPWDLMTREP

Limit repeating characters in password

0=Can be repeated, 1=Cannot be repeated, 2=Cannot be repeated consecutively

1=Cannot be repeated. Option 2 is acceptable also and may be more acceptable to the user community since it allows the use of words as passwords.

QPWDLVL

Password level

0=User profile passwords with a length of 1-10 characters

are supported. 1=User profile passwords with a length of 1-10 characters are supported. AS/400 NetServer passwords for Windows 95/98/ME clients will be removed from the system. 3=User profile passwords with a length of 1-128 characters are supported. 4=User profile passwords with a length of 1-128 characters are supported. AS/400 NetServer passwords for Windows 95/98/ME clients will be removed from the system.

1 is recommended because CWDirect only supports passwords up to length 10.

QPWDMAXLEN

Maximum password length

1-128

10

QPWDMINLEN

Minimum password length

1-128

8

QPWDPOSDIF

Limit password character positions

0=Can be the same, 1=Cannot be the same

1=Cannot be the same

QPWDRQDDGT

Require digit in password

0=Not Required, 1=Required

1=Required

QPWDRQDDIF

Duplicate password control

0=Can be the same as old passwords, 1=Cannot be the same as last 32, 2=Cannot be the same as last 24, 3=Cannot be the same as last 18, 4=Cannot be the same as last 12, 5=Cannot be the same as last 10, 6=Cannot be the same as last 8, 7=Cannot be the same as last 6, 8=Cannot be the same as the last 4

1=Cannot be the same as last 32

1.1.4 Delete sensitive authentication data stored by previous payment application versions.

Historical data must be removed (magnetic stripe data, card validation codes, PINs, or PIN blocks stored by previous versions of the payment application).

How to remove historical data. Such removal is absolutely necessary for PCI DSS compliance.

CWDirect does not store any authentication data in the database.

The system stores the credit card number and expiration date as encrypted data and if you use tokenization, the encrypted credit card number is replaced with a token from the authorization service.

Card security value: The system automatically removes the card security value (CID, CVV2, CVC2) from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing.

If the card security value and card security presence are passed for an e-commerce order, the system clears the values and does not pass them to the order.

1.1.5 Delete any sensitive authentication data (pre-authorization) gathered as a result of troubleshooting the payment application.

Sensitive authentication data (pre-authorization) must only be collected when needed to solve a specific problem.

Such data must be stored only in specific, known locations with limited access.

Only collect a limited amount of such data as needed to solve a specific problem.

Sensitive authentication data must be encrypted while stored.

Such data must be securely deleted immediately after use.

Bill Me Later: If a Bill Me Later account is approved, the system stores the account number in the encrypted credit card number field. Regardless if a Bill Me Later account is approved or declined, the system removes the customer’s social security number and date of birth.

Logging: Turn off logging in any CWIntegrate site that passes customer credit card information.

Troubleshooting: When troubleshooting a problem dealing with sensitive data, collect only the minimum data required to solve the problem. If you need to store this information, store it in a secure location with limited access. Once the problem has been resolved, immediately delete the sensitive data.

CWDirect does not process PIN numbers.

See Guidelines for Data Security.

2.1 Purge cardholder data after customer-defined retention period.

Cardholder data must be purged after it exceeds the customer-defined retention period.

All locations where payment application stores cardholder data.

Use the Purging Orders menu option to purge old orders.

Use the Merge/Purge Sold To Names menu option to merge duplicate sold to customers.

Use the Prevent Storing the Customer’s Last CC# and Exp Date (J86) system control value to prevent the storing of the customer’s credit card number and expiration date that was most recently used on an order in the Customer Sold To Order History file.

See Guidelines for Data Security, Purging Orders (MPOR, FORP, VORP, DORP)

Working with Merge/Purge Sold-to Names (MMCS)Prevent Storing the Customer’s Last CC# and Exp Date (J86)

2.7 Delete cryptographic key material or cryptograms stored by previous payment application versions.

Cryptographic material must be removed.

How to remove cryptographic material. Such removal is absolutely necessary for PCI Compliance.

How to re-encrypt historic data with new keys.

Once the entire encryption key switch process has been completed, you should securely delete old key switch files so that the files are not recoverable.

See Guidelines for Data Security and Encryption Key Switch Process in the Data Security and Encryption Reference.

3.1 Use unique user IDs and secure authentication for administrative access and access to cardholder data.

Do not use default administrative accounts for payment application logins.

Assign secure authentication to default accounts (even if not used), and disable or do not use the accounts.

Use secure authentication for the payment application and system whenever possible.

How to create secure authentication to access the payment application, per PCI DSS Requirements 8.5.8 through 8.5.15.

See Guidelines for Data Security and Summary of iSeries Password Options.

3.2 Use unique user IDs and secure authentication for access to PCs, servers, and databases with payment applications.

Use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data, per PCI DSS Requirements 8.5.8 through 8.5.15.

4.2 Implement automated audit trails.

Set PCI DSS-compliant log settings, per PCI DSS Requirement 10.

Logs must be enabled, and disabling the logs will result in non-compliance with PCI DSS.

See Guidelines for Data Security and Logging Credit Card Data Access.

6.1 Securely implement wireless technology.

If wireless is used within payment environment, install a firewall per PCI DSS Requirement 1.3.8.

See Guidelines for Data Security and Recommended Firewall Configuration for E-Commerce.

6.2 Secure transmissions of cardholder data over wireless networks.

If payment application is implemented into a wireless environment, use PCI DSS-compliant wireless settings, per PCI DSS Requirement 4.1.1.

See Guidelines for Data Security.

9.1 Store cardholder data only on servers not connected to the Internet.

Do not store cardholder data on Internet-accessible systems (for example, web server and database server must not be on same server).

See Guidelines for Data Security.

10.1 Securely deliver remote payment application updates.

Receive remote payment application updates via secure modems, per PCI DSS Requirement 12.3.

If computer is connected via VPN or other high-speed connection, receive remote payment application updates via a firewall or a personal firewall per PCI DSS Requirement 1 or 1.3.9.

Use the customer secure web site or a secure FTP site to receive updates.

See Guidelines for Data Security.

11.2 Implement two-factor authentication for remote access to payment application.

Use two-factor authentication (user ID and password and an additional authentication item such as a token) if the payment application may be accessed remotely.

Configure communications so that communication is initiated by you. In addition, prevent users from access to your servers until connection is granted by you over a secure connection.

Any passwords required to connect to a server should be different from the passwords used to access CWDirect.

See Guidelines for Data Security.

11.3 Securely implement remote access software.

Implement and use remote access software security features if remote access software is used to remotely access the payment application or payment environment.

12.1 Secure transmissions of cardholder data over public networks.

Implement and use SSL for secure cardholder data transmission over public networks, in accordance with PCI DSS Requirement 4.1.

Configure WebSphereMQ to use SSL when sending credit card data.

See Guidelines for Data Security.

12.2 Encrypt cardholder data sent over end-user messaging technologies.

Implement and use an encryption solution if PANs can be sent with end-user messaging technologies.

See Guidelines for Data Security.

13.1 Encrypt non-console administrative access.

Implement and use SSH, VPN, or SSL/TLS for encryption of any non-console administrative access to payment application or servers in cardholder data environment.

See Guidelines for Data Security.

Customer Sold To BML (OECSBM)

Account #

Customer Sold To Ord Hist (CSTOOH)

Last CC#

Customer Membership (OECSMP)

Credit card number

Customer Ship To Ord Hist (CSHORH)

Last CC#

Pay Type Extended (OEPAYE)

BML default account #

Billing SVC Data Queue (FLSVDQ)

Card #

A/R Payment Detail (ARPAY)

CBT account #

Miscellaneous Fraud (MSCFRD)

Code

(for C type records only)

Order Payment Method (OEPAYM)

Credit card number

Order Payment History (OEPAYH)

OPH note

Note: The message CC# change from 4788250000121443 to CC# 4788250000131225 now displays as CC# changed.

Invoice Payment Method (CSINVP)

Credit card #

Authorization Hist Print (AUTHPT)

Credit card number

CC Deposit History (CCDPHI)

Credit card #

On Line Authorization (CCOLAT)

Credit card #

Order Ship To Data Queue (OESTDQ)

Credit card number

Store Pickup Payment (MLPSBP)

Credit card number

Pick Stored Value Card (FLPSVC)

PSV Card #

SVC Remote Fulfill Error (FLSRFE)

SVC Card #

RA Exch Payment Method (CSRAPM)

Credit card number

Stored Value Card (OESVCD)

SVC Card #

A/R Batch Payment Detail (ACARBD)

Account #

CC Authorization Trans (CCAT00)

Credit card #

CC Deposit Transaction (CCDP00)

Credit card #

JC Penney Invoice (FLJCPI)

Credit card#

Spiegel Invoice (FLSPIN)

Credit card#

Sending authorization requests to a service bureau, including stored value card activations, balance inquiries, and authorization reversals.

See:

• Processing Authorizations and Deposits using CWIntegrate

• Authorization/Deposit Setup

Tokenization: If you use Credit Card Tokenization and the Require Credit Card Token (L40) system control value is set to N, the ccAccountNumber in the CWAuthorizationRequest may contain a token or an actual credit card number. The Tokenized tag in the message indicates whether the authorization service should replace the credit card number with a token.

Authorization Request XML Message (CWAuthorizationRequest)

ccAccountNumber

CC Auth Trans Data file

Credit card number

CC Trans Data - Amex file

Credit card number

Sending deposit requests to a service bureau.

See:

• Processing Authorizations and Deposits using CWIntegrate

• Processing Auto Deposits (SDEP)

Deposit Request XML Message (CWDepositRequest)

ccAccountNumber

Sending deposit requests for foreign currency using the Prestige process. See Multi-Currency, Alternate Currency, and Prestige Process.

CC Deposit Prestige file

Credit card number

Extracting invoice information to the Financial Sales Download file. See Using the Financial Data Interface.

Financial Sales Download File (IXSLDL)

Credit card number

Downloading sold to customers to CWData. See Working with the Data Warehouse Integration in CWDirect.

Note: If the Suppress Customer Credit Card Information in Data Warehouse (I49) system control value is set to Y, the system does not download credit card information to CWData.

DW Customer Sold To file

Last credit card

Generating a CWEmailOut XML message for order, shipment, return, or stored value card notifications. See Outbound Email API.

Note:

• For order, shipment, and return notices, all but the last four positions of the credit card number are replaced with asterisks (*), regardless of the credit card number formats defined.

• For stored value card notices, the stored value card number displays unencrypted and unformatted since the customer needs to read the stored value card number for future purchases.

Outbound Email XML Message (CWEmailOut)

opm_credit_card

svc_card_nbr

Generating a CWInvoiceOut XML message. See Generic Invoice Download API.

Invoice Download XML Message (CWINVOICEOUT)

ipm_credit_card_

nbr

Generating a CWOrderOut XML message.

See:

• Generic Order Interface (Order API)

• Generic Customer History API

Detailed Order XML Response (CWORDEROUT)

credit_card_nbr

Generating a StoreFulfillmentRequest XML message. See Merchandise Locator and Store Fulfillment API through .NET.

Store Fulfillment Request XML Message (StoreFulfillmentRequest) (.NET)

cc_number

Receiving orders from an external system.

See:

• E-Commerce Order Creation

• Generic Order Interface (Order API)

• Using the Phone Interface

• Transferring Remote Orders (TPHO)

E-Commerce New Order Message (CWCreateOrder)

XML and name/value pair

cc_number

E-Commerce Payment Message (CWPayment)

XML and name/value pair

cc_number

Inbound Order XML Message (CWORDERIN)

cc_number

Phone Orders (PHORDS) File

Credit card number

Phone Order Expanded (PHORDE) file

Credit card number

NeoData Order Header (IXNDOH) file

Credit card nbr

Receiving an authorization response from a service bureau during authorization processing, including stored value card activation, balance inquiry, and authorization reversal. See Processing Authorizations and Deposits using CWIntegrate.

Authorization Response XML Message (CWAuthorizationResponse)

ccAccountNumber

Receiving a deposit response from a service bureau during deposit processing. See Processing Authorizations and Deposits using CWIntegrate.

Deposit Response XML Message (CWDepositResponse)

ccAccountNumber

Receiving virtual stored value card numbers from your service bureau to assign to a virtual stored value card during activation.

Note: Once you receive virtual card numbers from your service bureau, you can run the Encrypt Virtual Card File Periodic Function (program name CCR0046) to encrypt unencrypted virtual card numbers in the file for companies that have enabled credit card encryption. See Encrypting the Virtual Card Number File for more information.

Virtual Card Number File (FLSVCA)

Card #

Receiving a stored value card remote fulfillment confirmation from a gift card fulfillment system indicating a stored value card item has been activated and fulfilled by the system. See Stored Value Card Remote Fulfillment.

Stored Value Card Remote Fulfillment Confirmation (CWSVCRemoteIn)

card_number

Receiving credit card data from a tape provided by GECC. See Loading the Credit Card Account File (LCCA).

Credit Card Account file

Account number

Receiving electronic gift certificate numbers from the Electronic Gift Certificate FTP file. See Populate Electronic Gift Certificate File Screen (PEGC).

Electronic Gift Certificate file

Gift cert number

Receiving credit card data from Paymentech for level II discounting. See Level II and III Discounting.

CC Deposit Level II Bin file

CC bin low range

CC bin high range

Receiving A/R payments from an external system. See High Speed A/R Payment Entry and Batch Processing (WABP)

Inbound A/R Payment XML Message (ARPayment)

account_nbr

Function

ENCVIRT

Description

ENCRYPT VIRTUAL CARD FILE

Company parameter

Y

Note: In order to run the Encrypt Virtual Card File periodic function without errors, you must enter Y in the Company parameter. However, this periodic function runs for each company whose Use Credit Card Encryption (I97) system control value is set to Y.

Appl area

ALL

Program name

CCR0046

cc_number

E-Commerce New Order Message (CWCreateOrder)

E-Commerce Payment Message (CWPayment)

Inbound Order XML Message (CWORDERIN)

Store Fulfillment Request XML Message (StoreFulfillmentRequest) (.NET)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

MQJAVALOGS

cc_sec_value

E-Commerce New Order Message (CWCreateOrder)

E-Commerce Payment Message (CWPayment)

Inbound Order XML Message (CWORDERIN)

Store Fulfillment Request XML Message (StoreFulfillmentRequest) (.NET)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

MQJAVALOGS

ccAccountNumber

Authorization Request XML Message (CWAuthorizationRequest)

Authorization Response XML Message (CWAuthorizationResponse)

Deposit Request XML Message (CWDepositRequest)

Deposit Response XML Message (CWDepositResponse)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

credit_card_nbr

Detailed Order XML Response (CWORDEROUT)

Detailed Customer History Response XML Message (CWORDEROUT)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

ipm_credit_card_nbr

Invoice Download XML Message (CWINVOICEOUT)

MQJAVALOGS

opm_credit_card

CWEmailOut

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

CIDNumber

Authorization Request XML Message (CWAuthorizationRequest)

Deposit Request XML Message (CWDepositRequest)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

account_nbr

Inbound A/R Payment XML Message (ARPayment)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)

card_number

Stored Value Card Remote Fulfillment Confirmation (CWSVCRemoteIn)

daily ECLG (such as ECLG080421 for the April 21, 2008 log file)