Credit Card Processing User Guide Release 5.4

(1)

Credit Card Processing

User Guide

(2)

(3)

Business Property

All rights reserved. Vormittag Associates, Inc. is the sole owner of this manual. Information in this manual is subject to change without notice. No part of this publication may be reproduced in any form, by any means, electronic or mechanical, including photocopying, recording or by any other information storage and retrieval system, or distributed without prior written authorization of an executive officer of Vormittag Associates, Inc. While every precaution has been taken in the preparation of this manual, Vormittag Associates, Inc. assumes no responsibility for errors or omissions.

This software is designed for use with the IBM i family operating system and the IBM Power SystemsTM _{server. IBM i family operating}

system and IBM Power SystemsTM _{are registered trademarks of International Business Machines Corporation (IBM®).}

Authorized Possession and Use

1. Who May Use - Only licensees and current employees of Vormittag Associates, Inc. may possess and use this manual.

2. Purpose of Use - This manual may only be used in connection with or in support of Vormittag Associates, Inc. licensees, authorized users, or the company's internal use.

Penalties for Unauthorized Possession, Copying or Use

Any person or organization possessing, copying, or using this manual in violation of the authorized possession and use provision above will be subject to civil and criminal prosecution.

Credits

Editor

Elaine Cereola, Director of Documentation Services Technical Writers

Elaine Cereola, Director of Documentation Services Al Sheremeta, Technical Writer

Susan Licata, Technical Writer

Richard Schreiber, Director of Quality/Training Manager

Additional technical information provided by Larry Murphy – Vice President of Research & Development, Gary Unger – Development Engineer, Kevin Dick – Development Engineer, Purnadip Mukherjee – Programmer/Analyst (3rd_{Party Integration), Rajeev Naidu –}

Programmer/Analyst, Beth Steadman – Administrations Manager: Help Desk Support, Richard Schreiber – Director of Quality/Training Manager, Bob Moloney – Programmer/Analyst (EDI Segment) and the Programming Staff of VAI.

The Organization

Robert Vormittag, President Russ Cereola, Vice President

Robert Giustino, Vice President of Operations

Larry Murphy, Vice President of Research & Development Joe Scioscia, Vice President of Marketing

(4)

Vormittag Associates, Inc. S2K Enterprise user guides have been designed to provide the user with a quick look at some of the important features of the S2K Enterprise Management solution. Geared to the end user, they provide the information needed to perform the day-to-day operational tasks of an organization. Our goal in creating user guides is to take the user, step by step, through the processes that will make them successful S2K Enterprise users.

S2K Enterprise documentation, including but not limited to, manuals, user guides, workbooks, online help text, and documentation posted at www.vai.net is written in accordance with the S2K Enterprise Software base package. Custom modifications required for individual S2K Enterprise users will not be reflected in S2K Enterprise documentation unless the modification has been incorporated into the S2K Enterprise Software base package.

Illustrations, screen captures, flowcharts, report samples, worksheets, etc. are for illustrative purposes only and may not reflect the software version currently in use by individual users.

If you are unable to find the answers you need from this manual, feel free to call VAIs technical support hotline at 1.888.824.4435 or 1.888.VAI.4HELP.

(5)

Overview

S2K Enterprise permits credit card processing for several third party processors. S2K Enterprise integrates with either PAYware Connect, PayFlowPro or RiTA Direct. This integration permits the processing of credit card transactions through the Customer Order and Retail Point of Sale modules with real time authorization capabilities. With proper set up, the credit card process is a fully integrated process that handles backorders, declined authorizations, credit card swiping, and buffer reservations.

Process

Credit card processing takes place in the Customer Order, Accounts Receivable, and Retail Point of Sale applications. In the Customer Orders and Retail Point of Sale applications the credit card information is captured on the summary window by selecting the credit card payment type. The payment type holds the specifications for each credit card, i.e., credit card length, is authorization required, days to keep authorization, etc. In the Accounts Receivable application credit card information is captured during cash receipt entry on the Credit Card window by selecting the CREDIT CARD function on the Cash Receipt Entry/Update window.

If authorization is required the system will perform real time authorization at the point of entering and accepting the credit card information and will capture and display the authorization number on the summary window. The authorization will be for the order amount and any additional dollar or percentage amount entered in the ‘Reservation Buffer’ fields via the Cross Application Customer Orders – Credit Card Interface window.

Authorization Information

The system will hold the authorization as valid based on the number of days entered in the ‘Days to keep Authorization’ field in the Payment Type Master File. The End of Day process will go through the authorization log file and determine if any

authorizations have expired. If any authorizations meet the expiration criteria, the system will change the authorization status from an ‘A’ to an ‘X’, delete the record in the Accounts Receivable Deposits File, reduce the YTD deposit amount in the Order Header File, and print an expired authorization report for all expired authorizations. If the authorization had failed for other reasons, in addition to but not necessarily contingent on the expiration date, the order may be placed on hold depending on interface settings.

Note: To review any expired authorizations that need to be re-authorized, a Credit Card Authorization Expiration Report

can be run from the S2K Enterprise Customer Orders Reports menu.

Re-Authorizing

Re-authorizing orders can be done from the Order Entry/Update summary window. Select the order from the Order

Entry/Update window. Continue through the order until you have reached the Order Entry/Update summary window. From the summary window click on the CREDIT CARD button, this will display the Order Entry/Update window. On this window position your cursor on the desired transaction and click on the POS TO SELECT button. This will pass deposit amount, card type, card number and card expiration date back into the order. The user can now change any of the captured data and then re-submit for authorization.

Pick Ticket Process

Pick tickets will have no effect on credit card order processing unless the order is split out by locations. If a credit card was taken for an order with merchandise being picked and sent from several locations, the system will need to recalculate the authorization dollars. When the pick ticket process is run the system will split the order out by location creating individual orders. At this point the system will reverse the original authorization and split out the amount taken on the card based on the individual order totals and re-authorize them for the new split amounts.

(8)

Vormittag Associates, Inc. 2

Invoicing

The invoicing cycle does several functions that will affect credit card orders. When invoicing, the system will check to see if the order has been completely shipped. If an order has been split due to backorder conditions the system will re-authorize the remaining balance on backorders during the invoice cycle. The invoicing cycle will also mark all authorized orders for settlement.

The settlement process occurs during the End of Day process.

Split Order Processing

Suppose you have taken a credit card deposit on an order with merchandise from different locations. During the printing of Pick-ticket process the order gets split into three different orders. In that case we reverse out the original authorization done to the base order and split the amount taken as deposit in the ratio of their new order totals (calculation given later) and re-authorize them for the new split deposit amount. A report gets printed for any declined authorizations.

Calculation for Split Order Processing Amount

Say for example the base order (123-00) total is $1000 & the deposit taken on the order is $500. During the Pick Ticket printer process suppose the order gets split 3 ways (123-00, 123-10 & 123-20) with order totals of $500, $200 & $300 respectively. Then split order processing does 4 new transactions

First we reverse the initial deposit of $500 taken on order 123-00 & then we re-authorize the $500 deposit split in ratio of the order totals for the orders 123-00, 123-10 & 123-20

So the deposit for respective orders will be $250 (123-00) = ($500/$1000) * $500 $100 (123-10) = ($500/$1000) * $200 $150 (123-20) = ($500/$1000) * $300

Calculation for Backorder Re-Authorization Amount

Consider a base order (123-00) with order total of $1000 & the deposit taken on the order $800. Suppose we have only half of the merchandise available to ship, when the order gets invoiced, we have an invoice total of $500 for the base order (123-00). That’s the amount that gets settled for the base order & the remaining deposit amount $300 ($800 - $500), is re-authorized for the backorder (123-01).

Credit Card Data Purge

It is VAIs recommendation to run XADLDTAQ program during IPL to purge credit card queues. While running, make sure the Credit Card Engine is not active. Make sure the library list is correct by executing the EDITCL command prior to running the XADLDTAQ program. Additionally, the user should have proper authority to DLTDTAQ.

(9)

Cross Applications Interface Set Up

Setup for ‘PAYware Connect’, ‘PayflowPro’ (VeriSign) or ‘RiTA Direct’ takes place in the Cross Application Customer Order Credit Card Interface. Select Customer Orders from the S2K Enterprise Cross Applications Interface menu (Figure 1).

Figure 1 S2K Enterprise Cross Applications Interfaces Menu Select Customer Orders

from the S2K Enterprise Cross Applications Interfaces menu.

(10)

Customer Orders Interface

Selecting Customer Orders prompts the display of the following Customer Order Interface window.

Figure 2 Customer Orders Interface Window

Clicking on the CREDIT CARD button from the Customer Order Interface window prompts the display the following Customer Orders Credit Card Interface window.

Click on the CREDIT CARD button.

(11)

Credit Card Interface

Clicking on the CREDIT CARD button, from the Customer Orders Interface Setup window, prompts the display of the Customer Orders Interface Setup - Credit Card Interface window, allowing the user to set all parameters that will be used by the credit card processor. When processing credit card transactions throughout the system the credit card number is encrypted in the system as required by CISP (Cardholder Information Security Program) standards.

FIGURE 3 CUSTOMER ORDERS INTERFACE SETUP CREDIT CARD INTERFACE WINDOW

On the Customer Order Interface Credit Card Interface window the user will set all parameters that will be used by the credit card processor. Information regarding these parameters is as follows.

Field Descriptions and Specifications

Company Display Field

Display field representing the company to which these Credit Card Processing settings will be applied. The value in this field defaults from selection on the Company Search window.

Are you using Credit Card Processing Check Box

Are you using credit card processing? If yes, select (check) the ‘Are you using Credit Card Processing’ check box to provide the capability of using either the ‘PayflowPro’ (VeriSign), ‘RiTA Direct’, or ‘PAYware Connect’ credit card processing systems and reply to the following questions. If no, leave this check box unselected (blank) for NO and bypass all other entries on this window.

If – Y – Product Drop Down Selection Box

Select the product to be used if you are using credit card processing. Select ‘PayflowPro’ (VeriSign), ‘RiTA Direct’, or ‘PAYware Connect’ from the ‘If – YES – Product’ drop down selection box to define which technology partner credit card processing software will be used. In order to select RiTA Direct the user must have QSECOFR authority.

(12)

If – Y – Enter Hold Reason Code for Credit Card Decline 4 Alphanumeric

What default hold code should be used if the current credit card order is declined? Enter the default hold reason code that will automatically default to the ‘Hold Reason Code’ field on the Order Entry/Update header 1 window upon credit card

authorization decline. This code needs to be setup in the Hold Reason Code Master File. If the Hold Reason Code is NOT known, it can be located in the Hold Reason Search window by clicking on the 'SEARCH' icon. Additionally, with proper authority, the user may ADD, EDIT, mark INACTIVE or REACTIVATE a Hold Reason Code record, by clicking on the ‘SEARCH’ icon.

If – Y – Do you want to De-Allocate Inventory Check Box

Will inventory for orders on shipping hold be de-allocated? Select (check) the ‘De-Allocate Inventory’ check box for YES, to un-commit all order quantities, and place the quantity on backorder when the code is assigned to an order and placed on hold.

Reservation Buffer: Whichever is Greater

Dollar Amount Over Sale 9.2 Numeric

At what dollar amount, over the sale, will the reservation buffer be set for freight? Enter the amount at which the reservation buffer will be set. This amount, added to the sale amount will become the reserved amount for credit card processing.

Percentage Over Sale 8.3 Numeric

At what percentage over the sale will the reservation buffer be set for freight? Enter the percentage at which the reservation buffer will be set. This amount added to the sale amount will become the reserved amount for credit card processing. Enter the discount percentage in decimal format, i.e., a discount of 10% would be entered as ‘10.00’.

Note: The reservation buffer will be whichever is greater, the dollar amount over sale or the percentage over sale as

entered on this window.

For an Expired Authorization does the Order go On Hold Check Box

Select (check) the ‘For an Expired Authorization does the Order go On Hold’ check box for YES to place orders on hold if the order’s credit card authorization has expired.

If – Y – Specify the Hold Reason Code 4 Alphanumeric

If the order was placed on Hold due to an expired credit card authorization, a valid Hold Reason Code is required in this field. If the ‘Expired authorization causes order to go on hold’ check box is selected (checked) for YES, enter a valid Hold Reason Code in this field. If the Hold Reason code is NOT known, it can be located in the Hold Reason Search window by clicking on the ‘SEARCH’ icon.

If – Y – Do you want to De-Allocate Inventory Check Box

If an order was placed on Hold due to an expired credit card authorization should inventory that had been allocated to these orders be de-allocated? If the ‘Expired authorization causes order to go on hold’ check box was selected (checked) for YES, the user may select to de-allocate the inventory. The default setting for this box is unselected (blank) for NO. Select the ‘If – Y – De-Allocate Inventory’ check box for YES to de-allocate inventory for orders placed on Hold for expired credit card

authorizations.

Do you need Automatic Re-Authorization for Backorders Check Box

The default setting in the ‘Automatic Re-Authorization for Backorders’ check box is unselected (blank) for NO. Selecting (checking) this check box for YES instructs the system to automatically perform credit card re-authorization for backorders when these backorders become available for shipment.

Address Verification (AVS) Check Box

The default setting in the ‘Address Verification (AVS)’ check box is unselected (blank) for NO. Selecting (checking) this check box for YES instructs the system to verify ‘Address Line 1’ and ‘Zip Code’ against the address on file at the bank.

(13)

CVV2 Check Box

Do you require a Card Verification Value when processing credit card transactions? If yes, select (check) the ‘CVV2’ check box for YES. A credit card security code is a 3 or 4 digit number (not part of the credit card number) that is printed on the credit card. Because the card security code appears only on the credit card and not on receipts or statements, the card security code provides some assurance that the physical card is in the possession of the buyer.

The credit card security code has various names, depending on the payment network. Visa calls it CVV2, Master Card calls it

CVC2, and American Express and Discover call it CID.

Credit card CVV2/CVC2/CID data (the verification number that appears on the front or back of the credit card) is NOT stored by RiTA/VeriSign and MAY NOT be stored in the integrated application.

The following outlines CVV2 for RiTA: RiTA CVV2-based Auto-Decline Support:

CVV2-based auto-decline support is available for merchants processing MOTO and e-Commerce Pre-authorization transactions. Enabling this feature allows RiTA to automatically decline pre-authorization transaction requests based on certain CVV2 responses.

The auto-decline feature is configurable at the MERCH_SITE level. There is a field in each MERCH_SITE record for configuring which CVV2 response codes will be accepted: CVV2_ACCPT_LVL.

Configuration:

To enable the CVV2 auto-decline feature, assign a value to the CVV2_ACCPT_LVL fields of the merchant's

MERCH_SITE record. This value will be interpreted by RiTA to determine which CVV2 responses will not auto-decline a transaction.

To assign a value for CVV2 auto-decline, use the following table to determine which value to assign in the CVV2_ACCPT_LVL field:

CVV2

Code Description Value

All response values accepted 0

Non-response accepted 1

U Issuer not certified and/or has not provided encryption

keys 2

S Merchant indicated that CVV2 was not present on card 4

P Not processed 8

N CVV2 No Match 16

M CVV2 Match 32

As the table shows, to disable the CVV2 auto-decline feature for a MERCH_SITE, leave the value of

CVV2_ACCPT_LVL for the MERCH_SITE record unassigned (null), or assign the fields the value of 0. If the feature is disabled, any approved pre-authorization transaction, regardless of the CVV2 response, will be available for completion.

To enable the auto-decline feature, choose which CVV2 responses are acceptable and add the values associated with each response. The sum of these values will be placed in the appropriate CVV2_ACCPT_LVL field.

(14)

Example:

To accept transactions only when the following CVV2 responses are returned by the processor: • S-Merchant indicated that CVV2 was not present on card (4)

• M-CVV2 Match (32)

Assign 36 (4 + 32 = 36) as the CVV2_ACCPT_LVL value.

Since the system does not store the CVV2 and RiTA does not support a Reference Transaction; therefore, during the back order re-authorization or the split process the system will be unable to pass the CVV2 code, which is why we have to keep 4 along with 32.

The following outlines CVV2 for VeriSign: VeriSign CVV2-based Auto-decline Support:

CVV2-based auto-decline can be set in the Fraud Protection filter (it may not work in the Test Mode). There is a filter named Card Security Code Failure that performs the action after the transaction is processed. This means that, if set to reject, the filter rejects the transaction after the transaction is authorized by the processor.

Settlement success Response Codes for ROI 2 Alphanumeric/2 Alphanumeric

Settlement Success Response Codes are supplied by the Authorization Network. Please refer to the corresponding addendum, for response codes, provided by VeriFone for further information. The system will look for these codes to

determine the settlement status of the batch. If a response code, other than the 2 codes identified in this field, is returned then the batch was not settled.

Credit Card Swipe Device Configuration (‘ ‘/1,2) 1 Alphanumeric

What is the Credit Card Swipe Device Configuration? The Credit Card Swipe Device Configuration determines how many carriage returns are present in the swipe data.

(15)

Verisign Interface

In the year 2005, VeriSign® Payment Services was acquired by PayPal.

VeriSign's suite of products provides the ideal payment transaction platform for merchants who want to conduct business on the Internet. VeriSign's portfolio of products provides merchants with a high-speed, secure, and dependable way of processing transactions online, in real-time.

The PayFlow Pro is the TCP/IP solution. Customer would be required to download the VeriSign SDK (Software Developers' Kit - VeriSign API) onto their web server. It is designed for merchants requiring a high performance solution to process a high volume of transactions. In conjunction with Pro, customer must use SSL (purchased separately) to encrypt the transmission of data between customer's servers and VeriSign.

This is the link to the (Verisign, now PayPal) Payflow Pro product that S2K Enterprise software integrates with:

https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-gateway-overview-outside

Sign up Payflow Pro and make a note of the Partner, User Id and Password. Payflow Pro Datasheet:

https://www.paypal.com/en_US/pdf/PP_PayFlowPro_Datasheet.pdf

PayPal Manager User Guide:

https://www.paypal.com/en_US/pdf/GettingStarted.pdf

IBM Power SystemsTM_{server System Requirements:}

 TCP/IP Connection (Internet)

 JDK (Power Systems Developer Kit for Java)

VeriSign Java SDK V3.05 requires JDK 1.1 through 1.4. VeriSign Java SDK V3.06 and up requires JDK 1.4 only.

 Power Systems Toolbox for Java

 Qshell Interpreter

Please contact VAI with the following Payflow Pro Sign up information for VeriSign (now PayPal) setup:

 Partner

 User Id

 Password

A VAI technician will setup the VeriSign SDK on your IBM Power SystemsTM_{server IFS, do the necessary setup on the test}

environment and test a few transactions before handing it over to your organization for more testing. This setup performed by VAI is billable, estimated to take approximately 8 hours.

The information gathered from Payflow Pro is used to populate the following VeriSign Interface window. If ‘PayFlowPro’ is selected from the ‘If -Y- Select Product’ drop down selection box on the Customer Order Credit Card Interface window, clicking on the ‘ENTER’ icon will prompt the display of the following VeriSign Interface window.

(16)

Enter the following information:

Host Addr 30 Alphanumeric

What is the Host Address or website at which authorization will take place? Enter the URL of the website at which the authorization will take place. The URL for live is live-payflow.verisign.com.

Partner 15 Alphanumeric

What is the Partner ID? The Partner ID is provided by the authorized VeriSign re-seller who registered your organization for the pay flow pro service. If your organization signed up on its own (downloaded the Partner ID password from internet) use VeriSign.

Note: This field is case sensitive

VeriSign work Library 10 Alphanumeric

What is the designated VeriSign Work Library? This is the working library created by VAI.

User ID 64 Alphanumeric

The User ID and Password were created during the registration process. These fields are used to access the website and are validated by the website.

Password 32 Alphanumeric

The User ID and Password were created during the registration process. These fields are used to access the website and are validated by the website.

AVS Check on Street Address Check Box

Is Address Verification Service (AVS) required on the Street Address? The default setting in the ‘AVS Check on Street Address’ check box is unselected (blank) for NO. Select (check) this check box for YES to verify the ‘Address Line 1’ against the address on file at the bank.

On Zip Check Box

Is Address Verification Service (AVS) required on the Zip Code? The default setting in the ‘On Zip’ check box is unselected (blank) for NO. Select (check) this check box for YES to verify the ‘Zip Code’ against the address on file at the bank.

Native Optimizations Path 60 Alphanumeric

What is the designated Native Optimizations Path? Enter the native optimizer for JDK (Java Developer Kit). Valid entries are: For IBM i5/OS® V4R5 JDK 1.2/1.3 - :/QIBM®/ProdData/Java400/jt400ntv.jar

(17)

S2K Enterprise Cross Applications Interfaces RiTA Server Menu

RiTA Overview

RiTA (Rapid Internet Transaction Authority), a product of VeriFone, is a Javabased engine that is operating system, database, and machine independent. Designed to enable a variety of hosting and merchant capabilities, RiTA Server is a highly scalable transaction switch that supports high-volume, multi-threaded transaction processing. RiTA Server is e-transaction middleware for businesses that process large volumes of payment transactions.

RiTA Server provides TCP/IP or dial connectivity directly to processing companies. With the S2K Enterprise client application RiTA is integrated to the IBM Power SystemsTM_{server using the Data Queue Integration Method (name/value pair API).}

RiTA includes the following credit card processing features and fraud protections:

 Accept all major credit cards - Visa, MasterCard, American Express, Discover, etc. Additionally, this product supports Debit Card with PIN and Check Processing.

 Customer database with recurring & installment billing allows you to schedule payment processing according to your specific business requirements.

 Real time or batch transaction processing.

 Highly scaleable and flexible to accommodate high levels of growth and activity.  Support Level I & II Purchase Cards.

 Internet connectivity using SSL.

 Smart Settlement, automatically detect errors, quarantines those errors and resubmits until successfully transmitted.  No transaction fee charged by VeriFone.

 Electronic Commerce certified (ECI Compliant).

 Meets up to date compliance standards for Visa and MasterCard.

Fraud Protection Features



Address Verification Service (AVS) is an industry standard known for its effectiveness in reducing loss.



Data file encryption allows you to encrypt and protect credit card account numbers.

(18)

Select RiTA Server from the S2K Enterprise Cross Applications Interfaces menu, the following S2K Enterprise Cross Applications Interfaces RiTA Server menu will display.

Figure 5 S2K Enterprise Cross Applications Interfaces RiTA Server Menu

1. Client ID Maintenance ... 13 2. Pre Settlement Report... 15 3. Settlement Manager ... 16

(19)

Client ID Maintenance

The Client ID Maintenance option provides for the setup of a link between the S2K Enterprise Merchant ID and the Client ID supplied by RiTA.

Select Client ID Maintenance from the S2K Enterprise RiTA Server menu, the Merchant Search window will display.

Figure 6 Merchant Search Window Program Functions

Clicking on the ‘ADD’ icon allows the user to add a new message to the Message File.

Clicking on the ‘EDIT’ icon, with the cursor positioned on a Message detail line on the VAI Message File Maintenance selection window, prompts the display of the VAI Message File Maintenance window and allows the user to edit the selected message.

Clicking on the ‘DELETE’ icon, with the cursor positioned on a Merchant detail line on the Merchant Search window, prompts the display of the Confirm Delete window prompting the user to confirm the deletion of the selected record. Click on the CONFIRM button to confirm the deletion. Clicking on the CANCEL button terminates the delete request.

Figure 7 Confirm Delete Window

Click on the ‘ADD’ icon to add a new Client ID to the master file. The following RiTA Client ID Maintenance window will display in the ADD mode.

(20)

Merchant ID 4 Alphanumeric

Enter the Merchant ID. To edit an existing Merchant ID record, click on the ‘PREVIOUS’ icon, the display will return to the Merchant Search window where the record to be edited may be selected.

The Merchant ID is utilized by the credit card processing system to track credit card purchases through Customer Orders. If RiTA Direct, PayflowPro, or PAYware Connect is selected from the ‘If – YES – Product’ drop down selection box, in the Cross Applications Customer Orders Interface via the CREDIT CARD button, this number is user-defined. The S2K Enterprise Merchant ID (4 Alphanumeric) is established in the Cross Applications Company Setup Interface via the INTERFACES button and will be used here to cross reference to the Bank Merchant ID (12 Alphanumeric). However, if a Land Merchant ID was entered in the Store Master File via the ADDITIONAL DEFAULTS button that number will need to be entered here as the cross reference to the Bank Merchant ID.

Client ID 16 Alphanumeric

Required field used for entering the Client ID supplied by RiTA. Entry in this field links the Merchant ID for your organization to the Client ID supplied by RiTA. If the Client ID number is NOT known, it can be located in the RiTA Client ID Search window by clicking on the ‘SEARCH’ icon.

Manager Password 16 Alphanumeric

When mapping between the merchant number and the client ID a data element of ‘password’ will be required. PABP (Payment Applications Best Practices) regulations require complex passwords. Additionally, passwords must be changed every 90 days.

Program Functions

Clicking on the ‘RECORD INFO’ icon prompts the display of the Record Information window which provides the user with details on the date and time the record was created as well as the user ID of the person that created the record.

Additionally, this window displays the date and time a change was made to the selected record and the user ID of the person that made the change. This function is only active when accessing the selected record in ‘Change’ mode.

(21)

Pre Settlement Report

Selecting Pre Settlement Report from the RiTA Server menu prompts the display of the RiTA Client ID Search window. Select a client ID, and click on the ‘ENTER’ icon, to print a list of all transactions that will be settled during the next settlement process.

(22)

Settlement Manager

Selecting Settlement Manager from the RiTA Server menu prompts the display of the RiTA Settlement Manager window. This inquiry lets the user know the status of the settlements, i.e., whether they were accepted, rejected, etc. Additionally, report details can be displayed or printed by selecting from the available program functions. To display batch details select the DISPLAY BATCH DETAILS button.

Figure 11 RiTA Settlement Manager Window

The RiTA Settlement Manager window displays the Client ID, Batch Status, Batch Date and Batch Amount for all transactions displayed. The batch status shows whether or not the debit and credit card transactions were accepted or rejected. Rejection codes displayed in this window are system-generated by RiTA. For additional information on RiTA rejection codes, contact VeriFone, or consult your RiTA documentation.

The display can be sorted to display transactions for a specific Client ID and beginning and ending date by entering sort criteria in the fields provided. Additional information for sort fields is as follows.

Client ID 16 Alphanumeric

Optional field that may be used to sort the transactions displayed in the RiTA Settlement Manager window. If the Client ID is NOT known, it can be located in the RiTA Client ID Search window by clicking on the ‘SEARCH’ icon.

Beginning Date 8.0 Numeric

Optional field that may be used to sort the transactions displayed in the RiTA Settlement Manager window by beginning date. Entry in this field is in YYYYMMDD (year, month, date format).

End Date 8.0 Numeric

Optional field that may be used to sort the transactions displayed in the RiTA Settlement Manager window by ending date. Entry in this field is in YYYYMMDD (year, month, date format).

(23)

Clicking on the DISPLAY DETAIL REPORT button, with the cursor positioned on a transaction detail line, prompts the display of the Post Settlement Report spool file. See Detail Report on page 18 for additional information.

Clicking on the PRINT DETAIL REPORT button, with the cursor positioned on a transaction detail line, prints the Post Settlement Report to the default printer for the current user.

Clicking on the DISPLAY BATCH DETAILS button, with the cursor positioned on a transaction detail line, prompts the display of the Batch Details window showing the Client ID, batch number, batch amount, status (accepted, rejection code, etc.), batch count and amount for debit card transactions, credit card transactions and voids. See Batch Details on page 19 for additional information.

(24)

Detail Report

Clicking on the DISPLAY DETAIL REPORT button, with the cursor positioned on a transaction detail line on the RiTA Settlement Manager window, prompts the display of the Post Settlement Report spool file.

Figure 12 Display Spooled File Window

The Post Settlement Report provides transaction detail information including the Client ID, TROUTD (transaction identifier) Command (Sale = Debit Card Transaction, Credit = Credit issued on a credit card and Completion = Settlement has been completed on transaction), account number (credit or debit card number) and transaction amount.

(25)

Batch Details

Clicking on the DISPLAY BATCH DETAILS button, with the cursor positioned on a transaction detail line on the RiTA Settlement Manager window, prompts the display of the following Batch Details window.

Figure 13 Batch Details Window Field Descriptions and Specifications

Client ID Display Field

Display field identifying the Client ID for which this batch was processed.

Batch Number Display Field

Display field identifying the batch number associated with the transaction selected from the RiTA Settlement Manager window.

Batch Amount Display Field

Display field identifying the batch amount (amount of the transaction) associated with the transaction selected from the RiTA Settlement Manager window.

Batch Status Display Field

Display field identifying the status of the batch. If the transaction was rejected, the rejection code displayed is system-generated by RiTA. For additional information on RiTA rejection codes contact RiTA or consult your RiTA documentation.

Count Display Field

Display field identifying the number of debit card, credit card and void transactions included in the selected batch.

Amount Display Field

Display field identifying the total amount (value) of the debit card, credit card and void transactions included in the selected batch.

Date/Time Display Fields

(26)

VeriSign Merchant Specific User Profile

Selecting VeriSign Merchant Specific User Profile from the S2K Enterprise Cross Applications Interfaces menu prompts the display of the VeriSign Merchant Specific User Profile prompt window. This option provides for the setup of a link between the S2K Enterprise Merchant ID and the partner information supplied by VeriSign/Payflow Pro. Information entered here will override information entered on the VeriSign Interface window via the Cross Applications Customer Orders Interface using the CREDIT CARD button.

Figure 14 VeriSign Merchant Specific User Profile Prompt Window Field Descriptions and Specifications

Merchant ID 4 Alphanumeric

Enter the Merchant ID. The Merchant ID is utilized by the credit card processing system to track credit card purchases through Customer Orders. If Verisign or RiTA are selected from the ‘If – Y – Type of Processing’ drop down selection box, in the Cross Applications Customer Orders Interface via the CREDIT CARD button, this number is user-defined.

The S2K Enterprise Merchant ID (4 Alphanumeric) is established in the Cross Applications Company Setup Interface via the INTERFACES button. However, if a Land Merchant ID was entered in the Store Master File via the ADDITIONAL DEFAULTS button that number will need to be entered here.

The Merchant ID number entered here is used to establish specific VeriSign partner information. Additionally, the Information entered here will override information entered on the VeriSign Interface window via the Cross Applications Customer Orders Interface using the CREDIT CARD button.

Click on the ‘ENTER’ icon to continue. The following VeriSign Merchant Specific User Profile detail window will display.

Figure 15 VeriSign Merchant Specific User Profile Detail Window Field Descriptions and Specifications

Merchant ID Display Field

Defaults from entry on the VeriSign Merchant Specific User Profile prompt window.

Partner ID 15 Alphanumeric

The Partner ID is provided by the authorized VeriSign re-seller who registered your organization for the Payflow Pro service. If your organization signed up on its own (downloaded the Partner ID password from internet) use VeriSign (now PayPal).

(27)

User ID 65 Alphanumeric

The User ID was created during the registration process. This field is used to access the website and is validated by the website.

Note: This field is case sensitive.

Password 32 Alphanumeric

The Password was created during the registration process. This field is used to access the website and is validated by the website.

Note: This field is case sensitive. Program Functions

Clicking on the ‘DELETE’ icon prompts the display of the Confirm Delete window prompting the user to confirm the deletion of the selected record. Click on the CONFIRM button to confirm the deletion. Clicking on the CANCEL button terminates the delete request.

Figure 16 Confirm Delete Window

Clicking on the ‘RECORD INFO’ icon prompts the display of the Record Information window which provides the user with details on the date and time the record was created as well as the user ID of the person that created the record.

Additionally, this window displays the date and time a change was made to the selected record and the user ID of the person that made the change. This function is only active when accessing the selected record in CHANGE mode.

(28)

File Maintenance Tables

The following File Maintenance table from the S2K Enterprise Customer Orders File Maintenance menu must be maintained for Credit Card Processing to function.

Payment Types

The Payment Type Master File maintains information for deposit type codes used during the Order Entry process. For clarification purposes, different payment type records should be established for each payment method accepted at retail stores, i.e. Visa, Discover, American Express, Gift Certificates, etc.

To add a record to the file, select Payment Types from the S2K Enterprise Customer Orders File Maintenance menu, the Payment Type Search window will display (not shown). Click on the ‘ADD’ icon to add a new Payment Type code to the master file. The following Payment Type File Maintenance window will display.

Figure 18 Payment Type File Maintenance Window Field Descriptions and Specifications

Company Display Field

The company number defaults from the Payment Type Search window and is based on the current user’s S2K Enterprise User Profile.

Payment Type 6 Alphanumeric

To create a new payment type code, enter a code that uniquely identifies the Payment Type record being created. Click on the ‘ENTER’ icon to continue. Additional entry fields are activated. To edit an existing payment type record, click on the

(29)

Once the company and payment type have been entered, click on the ‘ENTER’ icon to continue. Additional entry fields are activated.

Figure 19 Payment Type File Maintenance Window Field Descriptions and Specifications

Description 30 Alphanumeric

Required field used for entering free-form text to describing the Payment Type code. Try to use a description that accurately describes the code. For example, do not use ‘credit card’ when this code is for a ‘Master Card’ credit card.

Allow Refund of Cash Check Box

If this check box is selected (checked) for YES, users will be permitted to refund cash, to the customer, when processing ‘Returns with a Receipt’ during the order entry process, if the original order payment type, selected at the time of Order Entry, is the Payment Type selected here. Leave this check box unselected (blank) for NO to prohibit cash refunds for the payment type selected here.

Wait Days for Cash Refund 3.0 Numeric

If the preceding ‘Allow Refund of Cash’ check box is selected (checked) for YES, enter the number of days that must transpire before cash refunds are permitted. Typically, this field would be used for a Payment Type of CHECK and the number entered here would represent an amount of time in excess of the number of days if takes for a check to clear, this will assure your organization that funds have been collected before a cash refund is made to the customer.

Authorization Required Check Box

Entry in this field is required. If this check box is selected (checked) for YES, users will be required to enter an authorization number on the Order Entry/Update summary window during the order entry process when using this payment type code. Orders using payment types that require an authorization cannot be processed until an authorization code is entered.

(30)

Validate Expiration Date Check Box

Selecting (checking) this check box for YES instructs the system to determine whether or not the expiration date of a credit card is a valid date.

Days to Keep Authorization 7.0 Numeric

The value entered in this field refers to credit card authorizations only. ‘Days to Keep Authorization’ is an optional field that can be used to record the number of days in which the system will consider the Credit Card Authorization to be valid. The system will use the number of days entered here and begin the calculation from the date of the transaction. During the end of day process authorizations that have become eligible to expire will receive a status code of ‘X’. Additionally, the end of day process will delete the deposit record in the Deposits Master File and reduce the year to date deposit amount in the Order Header File.

Bank Number (debit) 2.0 Numeric

Required field validated against the Bank Master File. Represents the bank account deposits received during Customer Order Entry (not used for Retail Point of Sale transactions) will be deposited to. If the bank number is NOT known, it can be located in the Bank Master File by clicking on the 'SEARCH' icon. Additionally, with proper authority, the user may ADD, EDIT mark INACTIVE or REACTIVATE a Bank code, by clicking on the ‘SEARCH’ icon.

General Ledger (credit) 23 Numeric

Required field validated against the Chart of Accounts Master File. Represents the general ledger account, deposits received during Customer Order Entry (not used for Retail Point of Sale transactions) should be credited to. This is typically the general ledger account number for the deposits payable liability account. Amounts credited to this account will appear on the Daily Deposit Register printed during end-of-day processing. If the general ledger account number is NOT known, it can be located in the Chart of Accounts Master File by clicking on the 'SEARCH' icon. Additionally, with proper authority, the user may ADD, EDIT mark INACTIVE or REACTIVATE a General Ledger number, by clicking on the ‘SEARCH’ icon.

Validate Credit Card Check Box

Entry in this field is required. If this check box is selected (checked) for YES credit card payment types will be validated during the order entry process. If this check box is unselected (blank) for NO credit card payment types will not be validated during the order entry process

Note: For Customer Order Entry, this field indicates to the credit card processing system that this Payment Type

record is for a credit card.

Credit Card Lengths 2.0/2.0/2.0 Numeric

Entry in this field is required. Enter the number of digits on this credit card payment type. Space has been provided for two additional entries for the length of the credit card number in the event that the number of digits on this credit card changes. If ‘Validate Credit Card’ is selected (checked) for YES, in the preceding field, entry in this field is required.

Note: This field only applies to Retail Order Entry and not Customer Order Entry.

Mandatory CC#/CK# Check Box

If this check box selected (checked) for YES the system is instructed to require that the user enter a Credit Card Number or Check Number when accepting deposits on an order in the third window of Order Entry/Update. If this check box is unselected (blank) for NO the user will have authority to enter deposits without requiring a Credit Card or Check number on the Order Entry/Update summary window.

Print Signature Receipt Check Box

If this check box selected (checked) for YES the system is instructed to print a register receipt and a signature receipt when the Payment Type created here is selected on the Retail Sales Entry summary window. If this check box is unselected (blank) for NO the system is instructed to print a register receipt only.

Exclude from Internet Check Box

If this check box is selected (checked) for YES the system is instructed to exclude this Payment Type as an option for Internet orders. If this check box is unselected (blank) for NO this Payment Type will be available for Internet orders and an entry will be required in the ‘Thumbnail Image’ field.

(31)

Thumbnail Image 30 Alphanumeric

Conditional field, entry in this field will be required if the ‘Exclude from Internet’ check box is unselected (blank) for NO. Enter the path and filename of the thumbnail image to display for this payment type. Payment type images reside in the IBM Power SystemsTM_{server Integrated File System (IFS).}

Valid AVS Response Code 1 Alphanumeric Each

This field will display provided the ‘Address Verification Service (AVS)’ check box is selected (checked for YES in the Cross Applications Customer Orders Interface via the CREDIT CARD button. AVS codes are one character response codes used to validate a cardholder's given address against the issuer's records, to determine accuracy and deter fraud. Please refer to the corresponding addendum, for response codes, provided by VeriFone for further information.

Payment Type Class Drop Down Selection Box

Valid Payment Type codes are CASH, CHECK, CREDIT CARD, IN HOUSE, DEBIT CARD, or MISCELLANEOUS. Payment Type Class is a system-generated table representing the classification that this Payment Type is categorized by. For instance, Payment Types of AMEX, MC, VISA, or Discover may all be classified as CREDIT CARD. The following example Payment Types should be setup with the Payment Type Class shown:

Payment Types Payment Type Class

Credit Cards CREDIT CARD

Payouts, Traveler’s checks MISCELLANEOUS In House Charges, Gift Card, Store Credit IN HOUSE

Cash CASH

Check (Bank Checks) CHECK

Debit Card DEBIT CARD

Note: When processing an order, in the Retail Point of Sale application, authorization will not be required, regardless of

the setting in the ‘Authorization Required’ check box, if a payment type is selected that has been designated with a ‘Payment Type Class’ of CASH or MISCELLANEOUS.

Note: Within Customer Order Entry a payment type coded with a payment class of IN HOUSE is prohibited, IN HOUSE

payment classes are restricted to the Retail Point of Sale module.

Open Cash Drawer Check Box

If this check box is selected (checked) for YES the system is instructed to open the cash drawer when the Payment Type Class in the preceding field is tendered during order entry. If this check box is unselected (blank) for NO the cash drawer will not open during order entry when tendering the Payment Type Class selected in the preceding field.

Clicking on the RECORD INFO button prompts the display of the Record Information window which provides the user with details on the date and time the record was created as well as the user ID of the person that created the record.

Additionally, this window displays the date and time a change was made to the selected record and the user ID of the person that made the change. This function is only active when accessing the selected record in CHANGE mode.

(32)

Clicking on the RETAIL button prompts the display of the Retail Store Payment Type window, allowing the user to set up individual stores, by company, by payment type, with separate bank accounts. See Retail on page 28 for additional information.

Clicking on the ‘REACTIVATE’ icon reactivates records previously marked as inactive. This function is only active if an inactive record was selected from the search window.

(33)

Credit Card Type

Clicking on the ‘ENTER’ icon, from the Payment Type File Maintenance window, will display the following Credit Card Type Selection window provided CREDIT CARD was selected from the ‘Payment Type Class’ drop down selection box. The Credit Card Type Selection window is used to select the appropriate credit card type for the credit card entered on the Payment Type File Maintenance window, e.g., Master Card, Visa, American Express, etc. S2K Enterprise will use the selection made here during credit card processing in the Retail Point of Sale module to validate that the card swiped matches the credit card tender selected on the Retail Entry summary window.

Figure 21 Credit Card Type Window

Credit Card Types in the Credit Card Type Selection window are predefined in S2K Enterprise. Select (check) the appropriate type and click on the ‘ENTER’ icon to continue.

The following credit card numeric prefixes are predefined in S2K Enterprise: 51, 55, 36 Master Card 4 Visa 34, 37 American Express 300, 305, 38 Diners Club 6011, 65 Discover Card 2014, 2149 enRoute/Diners Club 3, 2131, 1800 JCB

(34)

Retail

Clicking on the RETAIL button, from the Payment Type File Maintenance window, prompts the display of the Retail Store Payment Type window. This function allows the user to set up individual stores, by company, by payment type, with separate bank accounts. Therefore, stores residing in different geographic locations have the ability to bank in a location that is convenient. For instance, a payment type of American Express may be used by one company with 8 different store locations, with each individual store being responsible for their own daily deposits.

Figure 22 Retail Store Payment Type Window

Company number and payment type default based on the current user profile and entry on the Payment Type File Maintenance window. Additional field descriptions are as follows.

Del 1 Alphanumeric

Entry in this field is optional. Valid entry is ‘D’ for DELETE. Enter a ‘D’ for DELETE for each store to be deleted from the Retail Store Payment Type window.

Store 4.0 Numeric

Enter the Store Number(s) for which this Payment Type record will be available. If the Store code is NOT known it can be located in the Retail Store Search window by clicking on the 'SEARCH' icon.

Debit Bank 2.0 Numeric

Required field validated against the Bank Master File. Represents the bank account deposits received during order entry will be deposited to. If the Bank number is NOT known, it can be located in the Bank Search window by clicking on the 'SEARCH' icon. Additionally, with proper authority the user may ADD, EDIT mark INACTIVE or REACTIVATE a Bank code, by clicking on the ‘SEARCH’ icon.

General Ledger Credit 23 Numeric

Required field validated against the General Ledger Master File. Represents the general ledger account, deposits received during order entry should be credited to. This is typically the general ledger account number for the deposits payable liability account. Amounts credited to this account will appear on the Daily Deposit Register printed during end-of-day processing. If the General Ledger Account Number is NOT known, it can be located in the General Ledger Account Search window by clicking the ‘SEARCH’ icon. Additionally, with proper authority, the user may ADD, EDIT mark INACTIVE or REACTIVATE a G/L Number, by clicking on the ‘SEARCH’ icon.

(35)

(36)

Systems Requirement

 TCP/IP Connection (Internet)

 JDK (AS/400 Developer Kit for Java) 1.1.8, 1.2. Check with java *version command  AS/400 Toolbox for Java. Should be in /QIBM/ProdData/HTTP/Public/jt400  Qshell Interpreter

 VeriSign SDK API (Download from Internet)

 Internet Merchant Account – An account with a financial institution that accept payments over the Internet.

Configuration Management

 In the integrated file system create the following directory structure in the root file system (/). VeriSign

certs com

 Make all the directory shared  Copy f73e89fd.0 into /VeriSign/certs  Copy VeriSign.jar into /VeriSign/com

 Copy PFProJava.java (our version with Java Toolbox) into /VeriSign. Use SAV (Save) and RST (Restore) command.  Compile PFProJava.java and create PFProJava.class in /VeriSign

- SET CLASSPATH (wrkenvvar) environment variable as:

‘:/VeriSign/com/VeriSign.jar:/QIBM/ProdData/HTTP/Public/jt400/lib/jt400.zip :/QIBM/ProdData/HTTP/Public/jt400/utilities:.’

- Start Qshell interpreter (STRQSH) - cd /VeriSign

- javac PFProJava.java

 Create a Data area ‘@VERISIGN’ length 128 chr. in QGPL

(37)

VeriSign Interface (VERSGNINT)

 Parameter List: Trxtype 1 A/D I Company 2,0 I Order# 9 I Credit card# 16 I Expdt 4 yymm I Amount 11,2 I Address 30 I Zip 9 I Swipe data 117 I Payment type 6 I Auth code 6 O Trans Ref 15 O Resp. Msg 30 O Fatal 1 O Valid 1 O

 If the Trxtype = ‘A’ (Authorization) then for credit (Amount < 0), do not issue any transaction, instead treat it as valid, get the Routing id from VXACONT.XANO01 with key ‘VERISIGN’ and pass back the OK status and go out.

 Call ‘VERSETUP’ to create the DTAQ (@CR+Job#)

 If the Trxtype = ‘A’ (Authorization) then for regular order issue Authorization transaction (A)

 If the Trxtype = ‘D’ (Delayed Capture) for regular order issue Delayed Captured transaction (D) when the amount is > 0  If the Trxtype = ‘D’ (Delayed Capture) for credit (Amount < 0), issue credit transaction.

 If the Trxtype = ‘D’ (Delayed Capture) for regular order issue Void transaction (V) when the amount is 0  Send data queue entry to @VERISIGN1

 Receive response from DTAQ (@CR+job#)

VeriSign Setup (VERSETUP)

 Create the DTAQ @VERISIGN1, @VERISIGN2 if it is not present  Create the DTAQ (@CR+job#) if it is not present.

 Check whether the batch engine (VERSGNENG) is active, if not submit it in VAINEP JOBQ.

VeriSign Batch Engine (VERSGNENG)

 Receive entry from DTAQ @VERISIGN1  Call Java Servlet PFProJava

 Get the response from DTAQ @VERISIGN2mailto:DTAQ@VERISIGN2

 Send response to DTAQ (@CR+job#)

PFProJava (Java Servlet)

 Connect to the VeriSign web server  Send the credit card request

(38)

VeriSign Settlement (VERSPORT)

Same as USRPORT, except call VERSPO1 instead of USRPO1.

End VeriSign (VERSENDGEN)

 Delete the DTAQ @VERISIGN1 which will send a MONMSG to the VeriSign batch engine (VERSGNENG) that will delete the @VERISIGN2 DTAQ and end the engine.

VeriSign Settlement (VERSPO1)

Same logic as USRPO1 with the following exception:

 Select records based on LF VCOAPP6 (Select TQSTAT=T )  Call ‘VERSGNINT’ with the following parameters:

Trxtype 1 ‘D’ I

Company 2,0 I

Order# 9 I

Credit card# 16 I

Expdt 4 yymm I

Amount 11,2 TQRQSM I (Amount to be settled)

Address 30 I Zip 9 I Swipe data 117 I Payment type 6 I Auth code 6 O Trans Ref 15 I Resp. Msg 30 O Fatal 1 O Valid 1 O

 Process only if the Valid parameter is Y (Successful)  Update VCOAPPV with the TQSTAT= ‘S’

 Update Trans ref. In VCOAPPV and VARDEPS for credit

(39)

DTAQ @VERISIGN1 Layout

Job number Char 6 1-6

Host Website Char 30 7-36 Order number Num 9,0 37-45

User Char 64 46-109

Password Char 32 110-141

Transaction Type Char 1 142-142 (A-Authorization, D-Delayed Captured, C-Credit) Tender Type Char 1 143-143 (Always C-Credit card)

Credit card number Char 19 144-162

Expiration date Num 4,0 163-166 (MMYY) Transaction Amount Num 11,2 167-177

VeriSign reference Id Char 12 178-189 (Required with transaction type D-Delayed captured)

Address Char 30 190-219

Zip Char 9 220-228

Partner Char 15 229-243

Response DTAQ (@CR+job#) Layout

Return code Char 1 1-1 (A-Approved, D-Declined)

Result Char 4 2-5 (RESULT)

Transaction reference Char 12 6-17 (PNREF) Authorization code Char 6 18-23 (AUTHCODE) AVS Address match Char 1 24-24 (AVSADDR) AVS Zip match Char 1 25-25 (AVSZIP) Response Text Char 231 26-256 (RESPMSG)

(40)

Regular Order Flow

Order Entry

 VERISIGN

Issue Authorization transaction (A) [PGM:VERSGNINT called from COAUCR]  VCOAPPV

TQADCD ‘A’/’D’

TQ$AMOUNT Approval Amount (including buffer) TQDAMOUNT Deposit Amount (excluding buffer)

TQRQSM 0

TQSAMOUNT 0 TQSTAT blank  VARDEPS

TDDEL ‘R’

TDAMOUNT Deposit Amount (excluding buffer) TDDC ‘D’ TDTYPE ‘A’  ROI ‘AU’

Invoicing

 VCOAPPV TQADCD ‘A’/’D’

TQRQSM Required Settlement Amount (invoice amount)

TQSAMOUNT 0

TQSTAT ‘T’

 ROI ‘AT’

Final Settlement

 VERISIGN

Issue Delayed captured transaction (D) with the settlement amount (TQRQSM) [PGM:VERSPO1 called from VERSPORT which is called from COSETLCL]  VCOAPPV

TQADCD ‘S’

TQRQSM Required Settlement Amount (invoice amount)

TQSAMOUNT Settlement amount

TQSTAT ‘S’

 VARDEPS

TDDEL ‘A’

TDAMOUNT Actual Settlement Amount

TDDC ‘D’ TDTYPE ‘A’

(41)

Credit Flow

Credit Entry

 VERISIGN No action  VCOAPPV TQADCD ‘A’/’D’

TQ$AMOUNT Approval Amount (-ve) TQDAMOUNT Deposit Amount (-ve)

TQRQSM 0

TQSAMOUNT 0 TQSTAT blank  VARDEPS

TDDEL ‘R’

TDAMOUNT Deposit Amount (excluding buffer) TDDC ‘C’ TDTYPE ‘S’  ROI ‘RC’

Invoicing

 VCOAPPV TQADCD ‘A’/’D’

TQRQSM Required credit TQSAMOUNT 0 TQSTAT ‘T’  ROI ‘CT’

Final Settlement

 VERISIGN

Issue Credit (C) with the credit amount (TQRQSM)

[PGM:VERSPO1 called from VERSPORT which is called from COSETLCL]  VCOAPPV

TQADCD ‘S’

TQRQSM Required settlement Amount (invoice amount)

TQSAMOUNT Settlement amount

TQSTAT ‘S’

 VARDEPS

TDDEL ‘A’

TDAMOUNT Actual Settlement Amount

TDDC ‘C’ TDTYPE ‘S’

(42)

ROI Setup

 On the command line, type ADDLIBLE ASCCOM1.  On the command line type CCMENU.

The following Verifone JCharge menu will display:

Figure 23 Verifone JCharge Menu

Select Option 1 to Start JCharge processing or 2 to End JCharge processing. After selecting Option 1 to Start JCharge, it may take a few minutes before the Credit Card authorization process is fully functional.

(43)

S2K Enterprise Interface Setup

Order Entry

If credit card payment is entered the API COAUCR is called to authorize the credit card entered. COAUCR works in 2 phases. In the first phase it validates the credit card and its expiration date. If either is not valid an error is displayed during order entry. If the credit card is valid then COAUCR actually dials out to get an approval. If for some reason, payment is not approved the order goes on hold and the hold reason code is displayed. If the payment is approved an ‘AU’ type of record is written to the ROI Transaction File CCFP9000 with the authorized amount. An ‘AU’ record is written for a positive amount (not a credit). An ‘RC’ type of record is written to CCFP9000 for a credit.

A record is written to VARDEPS with a status code of ‘R’ for each authorized payment or credit. You could have multiple credit card payment records in VARDEPS for the same order and each record has a unique identification number generated by ROI. Although ROI supports multiple credit cards to be used on the same order, at this time, this feature is not being utilized, therefore, for any order, the same credit card will have to be used, but it can be used a multiple number of times. A record is written to VCOAPPV for each payment/credit with the authorized amount and the unique identification number returned by ROI CCS.

When an order is cancelled an API COCNCR is called that marks all the payment records for settlement with the field ‘amount to settle (TSETAM)’ set to a 0. When the program COSETLCL is run, these marked records are settled.

Invoicing Procedure

A new program COUPML is called during the invoicing procedure to mark credit card payment records for settlement. This program reads through VCOBILL, for orders with credit card payments, it calls an API COSTMT to mark authorized records for settlement. COUPML passes as parameter to COSTMT for the amount that has to be marked for settlement. For credits, the amounts are always settled in full. After the invoicing cycle is run all the ‘AU’ records are changed to ‘AT’ and ‘RC’ records are changed to ‘CT’ in the file CCFP9000.

Settlement Procedure

A new program COSETLCL has been written that actually starts the settlement process for all credit card payments that have been marked for settlement during the invoicing cycle.

COSETLCL loops through the Company Master File, for each company found with a Merchant ID it calls program COSTPT with the Merchant ID as the parameter. COSTPT is an interface program between S2K Enterprise and ROI processing. If the batch is successful then a ‘JG’ type of record is written to CCFP9000 with the batch number and the amount settled. All AT records are changed to AS type and all CT type records are changed to CS type records in CCFP9000. These records are updated with the batch number, settlement date and time.

COSETLCL then calls USRPORT with the batch number as the parameter. USRPORT calls the programs:

USRPO1 to change the status of credit card payment records from R to A in VARDEPS, update deposit amount in VARDEPS with the actual amount settled and update the YTD deposit field OAYTTD in VCOHEAD. For each settled record, this program also writes a record to file VCORESV to be used later by COUPGL2. VCOAPPV is also updated with the amount settled and the date and time.

COUPSA2 to write payment records to the Open A/R File for credit card deposits that where settled. ARUPDPCL to process deposit records settled.

(44)

If the settlement has not completed successfully the program (USRPORT2) will be run to issue a message stating that the settlement was unsuccessful.

Credit card transactions that have completed the settlement process are purged from the Credit Card Approval Tracking File (VCOAPPV) during the Customer Orders End of Month Procedure.

Credit Card Processing User Guide Release 5.4