PayScan Bill Payment Retailer Software Architecture & Design

Transcription

1 PayScan Bill Payment Retailer Software Architecture & Design INTRODUCTION The following diagram (not illustrated here) depicts the software components of PayScan bill payment system within a Retailer Point of Sale (POS) Application or Kiosk Application environment. Also shown is the general relationship and connection of any attached realtime communication network(s) that instantly validates and activates all varieties of thirdparty gift cards, phone cards and cash cards including credit and debit cards already presiding at the retailer checkout. This document discusses the various issues of integrating and incorporating the PayScan Bill Payment Service Application into any Point of Sale application environment, or transparently using any other existing network, for processing customer bill payments. The bold outlined elements in this diagram are the various components that comprise the Application. This document describes the major details of each component and how each is designed to operate within the Retailer POS environment, whether it is a PayScan network or other high-speed communication network. These bill payments are processed in the current manner similar to gift cards with an alternate bar code data format. Bill payment bar codes are scanned by the cashier from customer presented biller invoices DESCRIPTION The Retailer POS Application operates within a computer operating system framework, such as an IBM Flex O/S or a Microsoft Windows NT O/S. The checkout aisle bar code scanners, Retailer POS Application and UPC data base(s) already interoperate so that customer selected items can be identified, priced and totaled for customer payment at the checkout aisle. At the same time, these items are also subtracted from the current inventory stock of the retail store. In addition to the standard complement of grocery items that are identified by their industry standard 12 digit UPC-A/E bar codes, there may be other retail items available for purchase (third party gift cards and local commercial services) that are identified with alternate bar code data formats. These items may not have a companion retail UPC-A/E bar code. Third party gift cards are activated only when scanned through the checkout counter by their reverse side printed 30 digit Code-128 bar code. The bar code format of these gift cards is recognized as a special data class that should be diverted to the real-time network for validation and activation. For products I services, using other bar code data formats (variants that are detected, identified, decoded and check digit proofed (automatically) by the hardware firmware), a multi-level sieve routing process within the Retail POS Application is employed to divert these different bar code types to their respective reference product data bases. If an unrecognized bar code type is scanned, it drops completely through the multi-level 1

2 sieve checks, is discarded and an error indication returned to the checkout aisle operator. It is a PayScan recommendation that the bar code check for the PayScan bill payment signature be placed as the very last check in this series of bar code checks, immediately prior to discarding an unknown bar code read. It is assumed that this bar code check placement would cause the least amount of perturbation to the Retail POS Application code. There are a sufficient number of validation cross checks built into the PayScan bill payment signature bar code that it would not be confused with any other existing industry standard bar code format. If the gift card network is used to process bill payments, then the POS detection process by which gift card transactions are recognized and diverted would have to be modified to include the PayScan bill payment signature bar code format as well. The PayScan bill payment signature bar code is formulated from a standard Code-128 bar code sequence that starts out with a START C character immediately followed by an FNC1 control character (Application Identifier), then followed by either a 91 or 92 value. These values are designated by the Uniform Code Council UCC I EAN-128 Application Identifier Standard (1/93, revised 7/95) as Intra-Company (internal) reserved codes. As stated in the Code-128 Standard (Page 20), scanners detecting this START C / FNC1 character combination sequence should prefix the detected bar code string with a ]C1 character string. However, there are some commercially available scanners that, while they properly detect and decode this introductory character sequence properly, their internal firmware does not prefix the detected output bar code sequence with the ]C1 character string. The detection arid validation of the bill payment signature bar code does not solely depend on the bar code scanner outputting this prefix character string. However, if the bar scanner firmware is capable of outputting this prefix string, the Retail POS Application code (or gift card network modifications within the POS application) will have a unique character string identifier sequence by which to unconditionally detect and discern PayScan bill payment bar codes. If a gift card network is not used to process bill payments, a stand alone PayScan Bill Payment Service Application is expected to exist within the Retail Host as a system service application that is accessible to the Retailer POS Application through a choice of a Named Pipe, a Remote Procedure Call (RPC) or a TCP / UDP / IP network connection. This design approach was selected because it would require the least amount of code modification to the Retailer POS Application to incorporate the Bill Payment Application. The Bill Payment Service Application is a simple C program that requires I uses only basic file input / output capabilities and basic Windows Sockets Network program calls to interface with the external Bill Payment Controller Application through an Ethernet connection. The Bill Payment Service Application operates as a service application with a very low system overhead to communicate with the Bill Payment Controller Application. The primary function of the Bill Payment Service Application is to route detected bar code strings to the controller for validation and to return biller identification and transaction information. When operating in a debug code laced environment, the Bill Payment Controller Application is capable of processing a sustained rate of 10+ transactions per second for extended durations. When the overhead debug ASSERTion code is taken out, this 2

3 transaction rate is expected to increase. However in a typical retail environment, a more realistic transient peak transaction rate encountered for a 20-aisle checkout is anticipated to be no more than 1 transaction per second with no discernible Retailer Host CPU overhead (less than 1%). The Bill Payment Controller is a 386 based single board computer that has an Ethernet interface to communicate with the Bill Payment Service Application and a network interface for high-speed communication to the data center. The Bill Payment Controller is a solid state device with non-volatile memory to store scanned bill payment information. Alternatively, a gift card network would host the PayScan software that would eliminate a separate device from the retailer s environment. In either case, periodically throughout the day, based on threshold time intervals, accumulated transaction counts I dollar volumes and events, the Bill Payment Controller transmits all accumulated customer payment data, stored in non-volatile memory, to the central site data center. From a data security point of view, the Bill Payment Service Application does not access ANY directories outside of its base directory where the program.exe file is stored and the Bill Payment Controller has no means to direct the Bill Payment Service Application to fetch host data outside of this locus. The RETAIL_API routine within the Bill Payment Service Application is expected to be modified accordingly to interface with the Retail POS Application program. Currently, it operates as a transaction generator and receiver in a demonstration I test environment. Operationally, the RETAIL_API routine will be modified to accept bar code validation transactions when a bill payment is taken at the checkout counter. If successful, the cashier would then ask the customer two questions and enter the answers - partial or full payments are equally possible and are treated the same in any case. At this point, this bill payment transaction information is then held in abeyance or off to the side until the customer payment is presented and confirmed. After the customer payment instrument (cash, check, debit or credit, debit or cash card) has been authorized, each held bill payment transaction is then consummated with the Bill Payment Controller and each customer bill payment receipt is subsequently printed on the store cash register tape. As the checkout aisle cashier is scanning retail products, such as a UPC bar coded can of soup, the general operational Retail POS Application process follows this general logic track. The bar code is detected, identified and decoded by the scanner firmware. The returned bar code string is then compared against the primary database of product items. If the lookup is successful, then a product description and price is returned for receipt printing. If the primary lookup is unsuccessful, the bar code string may then be submitted to a multi-level sieve routing process to alternate set(s) of reference data base lookups (or diverted to an external real-time validation network) for a possible match. If the multi-level sieve process yields no matches, then the bar code string is discarded and a sour note or error tone is sounded at the checkout register to indicate an invalid or unrecognized bar code scan. In the case of a bill payment, before the unknown bar code string is discarded, that bar code string should be diverted to the Bill Payment Service Application via a 3

4 Named Pipe, a Remote Procedure Call (RPC) or TCP I UDP / IP network connection as a VALIDATION REQUEST. The following information is sent to the Bill Payment Controller as fields in a C record structure 1. Transaction bar code string to identify 2. Transaction Type VALIDATION REQUEST 3. Optional user defined API transaction tag match character (0x20 0x7E) The VALIDATION REQUEST will return a VALIDATION RESPONSE in the same C record structure consisting of the following information within 20 milliseconds 1. Transaction Error Code Non-zero if any sort of error 2. Transaction Type VALIDATION RESPONSE 3. Biller Limits I Restrictions (Biller Not Active, No Express Service) 4. Customer Limits / Restrictions (Cash Only) 5. Fee (Wholesale Fee) 6. Recommended Store Retail Price (can be overridden before payment confirmation) 7. Payment Amount (encoded if biller customer account number is less than 17 digits) If there is no returned Transaction Error Code, then this bar code string is a valid bill payment signature and the cashier should then solicit the type of bill payment and the amount to be paid if less than the full payment amount. If a premium Express delivery service is requested and were available, a second validation transaction would have to be resubmitted and processed to update the Fee and the Recommended Store Retail Price for that premium transaction type. The VALIDATION RESPONSE should then be put aside and held in an intermediate buffer area while the cashier goes on to scan the next customer checkout item. When the whole checkout scanning process is complete and totaled, payment for these purchases is requested from the customer in the form of cash, check, debit card, cash card or credit card. When the payment is confirmed and reconciled with any biller imposed customer restriction limits, each held bill payment is then confirmed by reprocessing the held VALIDATION RESPONSE transactions with updated transaction information in the same C record structure - 1. Transaction bar code string to identify 2. Transaction Type PAYMENT REQUEST 3. Optional user defined API transaction tag match character (0x20 0x7E) 4. Transaction Error Code Should be zero from last response (input error if not) 5. Biller Limits / Restrictions (Biller Not Active, No Express Service) (unchanged) 6. Customer Limits I Restrictions (Cash Only) (unchanged) 7. Fee (Wholesale Fee) (unchanged) 8. Recommended Store Retail Price (can be overridden before payment confirmation) 9. Payment Method (cash, check, debit card, credit card) 10. Customer MICR Check Information if captured 11. Payment Amount 4

5 The PAYMENT REQUEST process performs a complete validation of the submitted payment information within the Bill Payment Controller Application and should return a Transaction Error Code of zero if there are no errors encountered with the old returned information (which should not be altered) or any of the new valid italicized field entries. The PAYMENT RESPONSE returns the following information in the same C record structure along with a Transaction ID string specifically formatted for customer receipt printing - 1. Transaction Error Code should be zero, or the transaction is not confirmed 2. Transaction ID string 3. Customer Payment Amount 4. Biller Name 5. Customer Biller Account Number 6. Service Delivery Express I Normal 7. Time / Date of Customer Payment for Biller 8. Payment Method 9. Payment Fee Charged By Store The above returned information is sufficient to print a customer receipt. PENDING ISSUES There are a few pending technical issues that should be resolved on a chain store policy basis dealing with customer submitted checks as a form of payment instrument. When cash is presented by a customer and accepted by the cashier as a payment for goods and services, the transaction is considered to be complete and can not be repudiated by the customer. When debit cards and credit cards are presented by a customer and accepted by the cashier, after receiving the appropriate owning organization authorization confirmation number, the transaction is considered to be complete and also can not be arbitrarily repudiated by the customer without pursuing the required mediation resolution procedures. Checks, on the other hand, are different. Customer checks can be validated (for a per item service fee) when they are presented as payment but can, later, go bad if there are not sufficient funds in the customer account when that check is presented for payment to the customer s bank. In that case, the customer check is returned to the retail establishment to which it was originally presented. Now it is up to the retail establishment to go after the customer at a later point in time to collect the funds owed by that customer for his bounced check. A PayScan design philosophy is not to collect personal customer financial information regarding a bill payment transaction. However, this design philosophy may have to be reconsidered to accommodate the special case of customer check transaction. If the customer check MICR information is captured along with the bill payment transaction information, then these bill payments can be completely reversed at a later time when the customer check is found to be bad so that the customer does not receive credit for his fraudulent check payment and the retailer is not out any money as well. 5

6 An alternate solution to this problem would be for the retailer to print an absolute identifying transaction number on the customer check when it is presented and to provide that transaction number in lieu of the check MICR information. Then, if the customer check is later returned to the retailer for the reason of insufficient funds, the retailer printed transaction number can then be used as the data base link to reverse all the bill payments made with that check to refund the retailer. Another pending issue under discussion concerns credit card payments and the discount that is associated with them. In the past year or so, developments within the credit card industry indicate that credit card issuers are offering a fixed fee (-$0.75), rather than a scale of individual retailer negotiated discount rates based on transaction value, for customer utility bill payments in order to expand their market base. This issue should be discussed and a process agreed to between the retailer and PayScan, and the participating utilities. NEW BAR CODED BILLER INVOICE The PayScan bill payment signature bar code can appear on either the front of the bill invoice or on the reverse side where there is likely to be more empty real estate to print a bar code. In the case of one particular biller, the reverse side of this invoice is completely blank. A second companion document obtainable from PayScan outlines and describes the issues and specifications for printing a production bill payment signature bar code using the Code-128 industry standard. Depending on the empirical study referenced, the Code-128 bar code has a demonstrated error rate of 1:2 million scans whereas the fortified bill payment signature bar code, using the industry standard Code-128 as its foundation, has a calculated error rate of 1:30 billion scans. 6