The present invention relates to a system and method for coordinating pre-payment and post-payment of fuel and/or goods/services (FGS) between a fuel dispenser (FD) and an automated attendant (AA) within a retail fueling environment.
Retail fueling environments are often associated with convenience stores and fast food restaurants where customers may purchase goods or services in addition to purchasing fuel. Within these retail fueling environments, a single person, often called an attendant, is typically hired to run the cash register to complete transactions for the purchase of fuel and/or goods/services (FGS). The attendant is also responsible for managing the pre-payment and post-payment of fuel for fueling transactions and for selling goods or services at a retail counter within the retail fueling environment.
Theft of FGS within a retail fueling environment is of concern. A co-pending application, entitled “Security system and method for determining, preventing, and/or tracking theft of the use of goods and/or services, particularly fuel at retail fueling stations,” Ser. No. 11/125,682, is incorporated hereby by reference in its entirety
Given that retail fueling environments typically have multiple fuel pumps that must be managed to complete purchase transactions, the attendant running the register is often exceptionally busy managing fuel dispensing transactions. A pump select/authorization sequence requires multiple interactions between the attendant and the system for certain transactions.
As such, customers that are attempting to make counter purchases may have to wait in lines, thereby, making the convenience store environment much less convenient. Additionally, because the attendant running the register is often so busy managing fuel dispensing transactions and customers at the retail counter, more opportunity exists for shoplifters to steal goods from the retail convenience store that is associated with the retail fueling environment.
Accordingly, there exists a need to provide an automated attendant (AA) to manage pre-payment and post-payment of FGS transactions in a retail fueling environment including a user interface that allows customers to provide their own attendant-less payment for these transactions within the retail fueling environment.
The present invention is an automated attendant (AA) located apart from the fuel dispenser(s) (FD) in a retail fueling environment to allow a customer to make their own attendant-less payment for fuel and/or goods/services (FGS) ordered at either a FD or at the AA. This allows a customer to settle payment when not using or not able to use “pay-at-the-pump” features without having to interface with a human station operator.
The AA is used by a customer to either self pre-pay or self post-pay for FGS. The customer presents a form of identifying indicium at the AA when presenting payment for FGS. When the customer orders or receives FGS at a FD, the indicium is presented at the FD to link payment provided or to be provided at the AA for the transaction. In this manner, a customer desiring to pay for the FGS can do so either before or after fulfillment and on his or her own without interaction with or assistance from a human operator or attendant. The AA automatically links and settles the charges for FGS at the correct FD. Settlement times are lessened, thereby resulting in increased station throughput and an improved customer satisfaction.
As such, a customer can start their own transaction and pay it out with cash or credit at the AA without intervention of the attendant. Additionally, by recalling the transaction with a bar code, key tag, credit card, fingerprint scan, or other indicia, easier transaction processing for the customer is provided. For example, it is often difficult for customers to remember what pump they used when they show up to pay for the transaction. The present invention alleviates this problem by providing a transaction processing approach that automatically recalls a transaction at an AA without intervention of the attendant. Alternatively, the customer may request the attendant to recall the transaction and complete the transaction at a point-of-sale (POS) terminal operated by the attendant.
Those skilled in the art will appreciate the scope of the present invention and realize additional aspects thereof after reading the following detailed description of the preferred embodiments in association with the accompanying drawing figures.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention.
The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
The present invention is an automated attendant (AA) located apart from the fuel dispenser(s) (FD) in a retail fueling environment to allow a customer to make their own attendant-less payment for fuel and/or goods/services (FGS) ordered at either a FD or at the AA. This allows a customer to settle payment when not using or not able to use “pay-at-the-pump” features without having to interface with a human station operator.
The AA is used by a customer to either self pre-pay or self post-pay for FGS. The customer presents a form of identifying indicium at the AA when presenting payment for FGS. When the customer orders or receives FGS at a FD, the indicium is presented at the FD to link payment provided or to be provided at the AA for the transaction. In this manner, a customer desiring to pay for the FGS can do so either before or after fulfillment and on his or her own without interaction with or assistance from a human operator or attendant. The AA automatically links and settles the charges for FGS at the correct FD. Settlement times are lessened, thereby resulting in increased station throughput and an improved customer satisfaction.
As such, a customer can start their own transaction and pay it out with cash or credit at the AA without intervention of the attendant. Additionally, by recalling the transaction with a bar code, key tag, credit card, fingerprint scan, or other indicia, easier transaction processing for the customer is provided. For example, it is often difficult for customers to remember what pump they used when they show up to pay for the transaction. The present invention alleviates this problem by providing a transaction processing approach that automatically recalls a transaction at an AA without intervention of the attendant. Alternatively, the customer may request the attendant to recall the transaction and complete the transaction at a point-of-sale (POS) terminal operated by the attendant.
The central building 12 need not be centrally located within the retail fueling environment 10, but rather is the focus of the retail fueling environment 10, and may house a convenience store 22 and/or a quick serve restaurant (QSR) 24 therein. Both the convenience store 22 and the QSR 24 may include point-of-sale (POS) terminals 26 and 28, respectively.
One or more AAs are provided within the retail fueling environment 10. Referring to
The AAs 30 provide convenient and automated user interaction capabilities both inside and outside of the central building 12 and within the convenience store 22 and the QSR 24. As will be described in more detail below, the AAs 30 allow customers to manage the purchase of fuel and/or goods/services (FGS) without needing to interact with an operator or attendant at the various locations.
The central building 12 further includes a site controller (SC) 32, which in an exemplary embodiment may be the G-SITE® sold by Gilbarco Inc. of Greensboro, N.C. The SC 32 may control the authorization of fueling transactions and other conventional activities, as is well understood. The SC 32 may be incorporated into a POS, such as the POS 26 and 28, if needed or desired, such that the SC 32 also acts as a POS device. Alternatively, the SC 32 may be incorporated into one of the AAs 30 and, accordingly, may act as an automated attendant. Additionally, as will be described in more detail below, the FDs 16 may also include the functionality of the AA's 30 to allow a customer to initiate or complete a FGS transaction at one of the FDs 16.
The SC 32 may perform any of the functions, as will be described in detail below beginning with
Further, the SC 32 may have an off-site communication link 34 allowing communication with a remote location for credit/debit card authorization via a host processing system 36, an identification database 38, and/or a remote system 40. The remote system 40 represents another computer, system, or device that can be used to access identification information, such as credit card and/or fingerprint data. The off-site communication link 34 may be routed through the Public Switched Telephone Network (PSTN), the Internet, both, or the like, as needed or desired.
The car wash 20 may have a POS 42 associated therewith that communicates with the SC 32 for inventory and/or sales purposes. The car wash 20 alternatively may be a stand alone unit. U.S. patent application Ser. No. 10/430,689 entitled “Service Station Car Wash,” filed on May 6, 2003, is hereby incorporated by reference as if fully set forth herein as an example of such a car wash that includes a POS terminal.
It should be noted that the car wash 20, the convenience store 22, and the QSR 24 are all optional and need not be present in a given retail fueling environment.
As described above, the plurality of fueling islands 14 may have one or more FDs 16 positioned thereon. The FDs 16 are in electronic communication with the SC 32 through a Local Area Network (LAN), pump communication loop, or other communication channel or line, or the like.
The retail fueling environment 10 also has one or more underground storage tanks (USTs) 44 adapted to hold fuel therein. As such, the USTs 44 may be a double-walled tank. Further, each USTs 44 may include a liquid level sensor or other sensor (not shown) positioned therein. The sensors may report to a tank monitor (TM) 46 associated therewith. The TM 46 may communicate with the FDs 16 (either through the SC 32 or directly, as needed or desired) to determine amounts of fuel dispensed, and compare fuel dispensed to current levels of fuel within the USTs 44 to determine if the USTs 44 are leaking. In a typical installation, the TM 46 is also positioned in the central building 12, and may be proximate to the SC 32. The TM 46 may communicate with the SC 32 for leak detection reporting, inventory reporting, or the like.
The AA 30 may include a control system 66 for controlling a pre-paid or post-paid purchase transaction within the retail fueling environment 10. The control system 66 may interface with one or more input devices for payment of FGS at the retail fueling environment 10. The AA 30 may include a keypad 68. The keypad 68 may be used for selection of different types of purchase transactions available to the customer or to enter an authentication code. The types of purchase transactions include pre-paid and post-paid fueling transactions and can also include the purchase of other goods/services from the retail fueling environment 10. The keypad 68 may also be used for entry of a personal identification number (PIN) if the customer is using a debit card for payment of FGS.
When purchase transactions are created, the purchase transaction is identified with a transaction identifier. This transaction identifier may include customer identification indicia, such as a customer name, a customer account number, or other customer identification indicium. The transaction identifier may further include or be associated with a text-based designation in either an alpha-based format, a numeric format, or an alphanumeric format. This text-based designator may be used by the customer to recall the purchase transaction at another terminal within the retail fueling environment. Further, a coded sequence, such as a bar code sequence may be associated with the transaction identifier to allow a transaction receipt to be printed at one terminal and scanned at another terminal to recall and complete the purchase transaction.
The AA 30 may also contain a magnetic strip card reader 70 for insertion of credit, debit or other magnetic strip cards for payment. Additionally, the magnetic strip card reader 70 may accept loyalty or program-specific cards that entitle the customer to a fixed credit or percentage discount or other favorable pricing on gasoline or other goods/services.
The AA 30 may also contain an input device known as a radio-frequency (RF) antenna 72. The RF antenna 72 is coupled to an RF interrogator (not shown). If the customer is tendering a radio frequency identifier (RFID) for payment of a car wash, the RF antenna 72 as controlled by the RF interrogator, will generate a field to interrogate the customer's RFID. The RFID and the RF antenna 72 will communicate using RF communications to identify the customer's account or other payment information. For more information on RFID payments and interaction at a FD, see U.S. Pat. No. 6,073,840, entitled “Fuel Dispensing and Retail System Providing for Transponder Prepayment,” issued Jun. 13, 2000, incorporated herein by reference in its entirety.
The AA 30 may also include other payment or transactional type devices to receive payment information for transaction processing associated with transactions such as a pre-paid and post-paid FGS transactions, including a bill acceptor 74, an optical reader 76, a smart card reader 78, and a biometric reader 80. The AA 30 also includes a receipt printer 82 so that a receipt with a recording of the FGS transaction carried out at the AA 30 may be generated and presented to the customer.
A change delivery device 84 may also be used to deliver change for overpayment to a customer. The overpayment could also be applied as a credit towards other purchasing within the retail fueling environment 10, such as goods and/or services from the convenience store 22.
A display 86 is used to provide information, such as transaction related prompts and advertising, to the customer. Soft keys 88 are used by the customer to respond to information requests presented to the user via the display 86. An intercom 90 is provided to generate audible cues for the customer and to allow the customer to interact with an operator or attendant in the event that the customer has a question that is not answered by the AA 30.
The FD 16 is subdivided into multiple compartments. A hydraulic area 104 is used to enclose hydraulic components and an electronic area 106 is used to enclose electronic components. A vapor barrier (not shown) may be used to separate the hydraulic area 104 from the electronic area 106.
Several components used to control fuel flow may be housed within the hydraulic area 104. Fuel from USTs 44 (not shown) is pumped through a piping network into inlet or fuel dispensing pipes. An inlet pipe 108 provides a piping network from an UST.
When fuel is dispensed, fuel begins to travel through a meter 110, which is responsive to flow rate or volume. A pulser 112 is employed to generate a signal in response to fuel movement through the meter 110. Control/data lines 114 provide a signaling path from the pulser 112 to a control system 116. The control/data lines 114 provide signals to the control system 116 indicative of the flow rate or volume of fuel being dispensed within the meter 110. The control/data lines 114 may provide control signaling to a valve 118 that may be opened and closed to dispense and terminate dispensing of fuel, respectively.
The control system 116 includes a controller and control circuitry for transaction-level and functional processing within the FD 16. Additionally, the control system 116 uses control/data lines 120 to interact with the user interface 18 for transactional processing at the FD 16. As described above and in more detail below, the FD 16, via the user interface 18, acts in conjunction with the AA 30 to allow a customer to perform pre-paid and post-paid FGS transactions within the retail fueling environment 10.
The user interface 18 is functionally similar to and includes elements with like reference numerals that are representative of the elements described above in association with the AA 30. In addition, the FD 16 includes a transaction price total display 122 that may be used to present the customer with the price to be charged to the customer for fuel that is dispensed. A transaction gallon total display 124 may be used to present the customer with the measurement of fuel dispensed in units of gallons or liters as a volume of fuel dispensed from the FD 16. Octane selection buttons 126 are provided for the customer to select which grade of fuel is to be dispensed before dispensing is initiated.
As fuel is dispensed from the FD 16, the control system 116 receives signaling from the pulser 112 associated with the meter 110 described above during the dispensing transaction. In response to receipt of signaling from the pulser 112, the control system 116 provides transaction-level functionality within FD 16. The control system 116 collects, either directly or indirectly, meter flow measurements associated with the meter 110.
As a dispensing transaction progresses, fuel is then delivered to a hose 128 and through a nozzle 130 into the customer's vehicle (not shown). FD 16 includes a nozzle boot 132, which may be used to hold and retain the nozzle 130 when not in use. The nozzle boot 132 may include a mechanical or electronic switch (not shown) to indicate when the nozzle 130 has been removed for a fuel dispensing request and when the nozzle 130 has been replaced, signifying the end of a fueling transaction. A control line (not shown) provides a signaling path from the electronic switch to the control system 116. The control system 116 uses signaling received via the control line in order to make a determination as to when a transaction has been initiated or completed.
The common elements of the user interactive elements (e.g., soft keys 88, RF antenna 72, etc.) of the AA 30 and the FDs 16 are illustrated vertically along the right side of
A memory 142 is connected to the system controller 140. The memory 142 may be used to store user transaction information that is associated with automated pre-paid and post-paid transactions within the retail fueling environment 10, such as identification card data and/or fingerprint identification data associated with an active transaction. The memory 142 may also include a read only memory (ROM) 144, a random access memory (RAM) 146, and a non-volatile memory 148. Transactions that are created at a node may be stored within either the RAM 146 or the non-volatile memory 148, or may be stored at the SC 32, as will be described in more detail below.
Regarding transactions within the retail fueling environment 10, any node, such as the FD 16 and the AA 30, may create a transaction for pre-payment or post-payment of FGS. Further, any node may complete a transaction once it is created. Accordingly, the processes that are executed on the nodes within the retail fueling environment 10 provide for the creation of new transactions, monitoring of active transactions, and recalling of active transactions in order to complete transaction processing. Recalling an active transaction may be performed from any node within the retail fueling environment 10. The ordering of these three exemplary initial activities may be altered without departure from the scope of the subject matter described herein.
As described above, the AA 30 may be located apart from the fuel dispenser(s) (FD) in a retail fueling environment to allow a customer to make their own attendant-less payment for FGS ordered at either a FD or at the AA. This allows a customer to settle payment when not using or not able to use “pay-at-the-pump” features without having to interface with a human station operator.
The process illustrated within
Regarding
Because monitoring of active transactions will help to prevent customers from requesting a post-payment of FGS and avoiding payment, monitoring of active FGS transactions will be described before the creation of a new transaction is described. Once a transaction is created, the node upon which the transaction is created can monitor the active transaction or may transfer the transaction to another node for monitoring. Alternatively, the SC 32 may monitor all active transactions from a central point without departure from the scope of the subject matter described herein. For purposes of illustration, it will be assumed that the node at which a transaction is created will monitor a transaction that is created until another node requests a transfer of the transaction. Once a transfer is completed, the receiving node will then monitor any active transactions associated with it.
Accordingly, when an active transaction exists to be monitored (decision point 502), the process determines whether a transaction transfer request has been received from another node within the retail fueling environment 10 (decision point 508). When a transaction transfer request has been received, the process transfers the active transaction to the requesting node (step 510) and removes the transaction from its monitored queue of active transactions (step 512).
When a transaction transfer request has not been received (decision point 508), the process determines whether a transaction timeout has occurred (decision point 514). A timeout mechanism will help prevent customers from initiating a post-payment transaction without later paying for the FGS. When the process determines that a transaction timeout has occurred (decision point 514), the process generates an alarm and stores indicia for the unpaid transaction (step 516). This alarm may be generated and forwarded to the SC 32. The SC 32 may then take action, such as reporting the unpaid transaction via the off-site communication link 34 so that authorities may be alerted about the unpaid transaction.
When either a transaction timeout has not occurred (decision point 514) or the alarm has been generated and the indicia for the unpaid transaction have been stored (step 516), the process returns to the main loop where the process determines whether a transaction recall request has been received (decision point 504).
When a transaction recall request has been received, the process receives transaction indicia from the user (step 518). The transaction indicia may be received by any of the interface components described above in association with
After receipt of the transaction indicia from the customer, the process searches its local database of monitored transactions (not illustrated) and requests the transaction from the originating node or from the SC 32 if it is not a local transaction (step 520). The process may also add the transaction to its queue of monitored transactions if payment for the transaction is not received during the transaction recall processing (not illustrated).
For the case of a pre-paid transaction, the process determines whether there has been an overpayment associated with the transaction (decision point 522). For example, if the transaction is a pre-paid fueling transaction, the customer may not have dispensed fuel sufficient to consume the entire amount of payment authorized. As well, the customer may have authorized payment and intend to purchase goods and/or services with the overpayment.
When there has been an overpayment, the process determines whether the customer has made a refund request (decision point 524) and if the customer has made a refund request, the process refunds the overpayment (step 526). The refund may be performed by dispensing change via the change delivery device 84. The process can then complete (e.g., settle) the transaction (step 528). The process may also remove the transaction from a monitored transaction queue if it was added to one previously (not illustrated).
When a refund request has not been issued by the customer (decision point 524) or there is no overpayment (decision point 522), the process may determine whether the customer has requested to add goods and/or services to the transaction (decision point 530). If the customer has not requested to add goods and/or services to the transaction, the process may complete the transaction (step 528), as described above. If the customer has requested to add goods and/or services to the transaction, the process scans a product code or receives a customer selection from an interface component, such as soft keys 88 (step 532).
The process determines whether the customer has requested that the transaction be completed (decision point 534) and may iteratively add new goods and/or services to the transaction (step 532) until the transaction completion request is received. When the customer has requested that the transaction be completed, the process completes the transaction (step 528).
The process may optionally request the user to authorize additional payment if the pre-payment authorization is not sufficient to cover the additional goods and/or services, but for ease of illustration, it will be assumed that the payment was sufficient and that all pre-payment authorization was used to complete the transaction. Additionally, if there were an overpayment after additional goods and/or services are purchased, the process may optionally store a credit for the customer (not illustrated) or may inquire whether the customer would like a refund (steps 524 and 526).
After the transaction is completed, the process returns to the main loop. When a new transaction has been requested (decision point 506), the process progresses to
When the customer has requested that the goods and/or services portion of the transaction be completed (decision point 540) or when there has not been a request to add goods and/or services (decision point 536), the process determines whether fuel pre-payment has been requested (decision point 542). When fuel pre-payment has been requested, the process sets a fuel pre-pay transaction flag (step 544). When fuel pre-payment has not been requested, the process determines whether to complete the transaction (decision point 546).
For the case where goods and/or services were not added, there will not be an active transaction to complete and the process can return to the main loop illustrated in
The process waits for payment indicia to be received (decision point 550) and determines whether the transaction is authorized (decision point 552) upon receipt of the payment indicia. The payment indicia may be in the form of a customer swiping a credit card at the magnetic strip card reader 70 and may include any other form of payment via any of the other payment interfaces available on the AA 30. The payment indicia may also include customer identification indicia that may then be associated with the transaction in the form of a transaction identifier, as described above and in more detail below.
It should be noted that appropriate error handling procedures may be employed at any stage within the process, for example, when a user does not enter payment indicia, to manage either a non-payment situation or general timeout procedures. These error-handling procedures are not addressed herein for ease of illustration.
When the transaction is not authorized, the process generates an alert or alarm to the operator and stores indicia for the unpaid transaction (step 554). Unlike the situation where a timeout occurs relative to an active monitored transaction, this situation may not imply that a customer has failed to pay for FGS. This situation may imply that the card is over its limit or some other problem may have occurred. In this case, the customer may be instructed to go to the POS to complete the transaction with the attendant. Additionally, the process may optionally prompt the customer for another form of payment and/or complete the transaction (step 556), as described above, and then returns to the main loop in
When the transaction is not authorized, the process determines whether the fuel pre-payment flag is set (decision point 558). If the fuel pre-payment flag is not set, the process completes (e.g., settles) the transaction (step 560), as described above. If the fuel pre-payment flag is set, the process creates and stores a transaction for later recall at a FD and clears the fuel pre-payment flag (step 562). As part of the transaction creation, the transaction may be placed in the monitored transaction queue, as described above. As well, the creation process includes associating a transaction identifier with the transaction that may be used by a customer to recall the transaction at another terminal within the retail fueling environment. As described above, the transaction identifier may include customer identification indicia, a text-based designation including alpha and/or numeric characters, and/or a bar coded sequence. The customer is provided with the transaction identifier, for example, via the display 86 or the receipt printer 82, so that the transaction may be recalled at another terminal within the retail fueling environment. When the receipt printer is used to provide the transaction identifier to the customer, the printed transaction identifier may be in the form of a bar code or a combination of alpha and/or numeric characters.
The process then publishes (e.g., distributes) the transaction information (step 564) so that another AA 30 or a FD 16 can complete the transaction and returns to the main loop illustrated in
If a distributed repository is preferred, distributing the transaction indicia may include monitoring a communication buss for a transaction recall requests from another node or nodes and fulfilling those requests, such that each node acts as a part of a distributed repository for transactions created at the node. A distributed repository may also include broadcasting the transaction identifier and/or transaction indicia to all nodes within the retail fueling environment 10 so that any node may request a recall directly from the creating node.
Because monitoring of active transactions will help to prevent customers from requesting a post-payment of FGS and avoiding payment, monitoring of active FGS transactions will be described before the creation of a new transaction is described. Once a transaction is created, the node upon which the transaction is created can monitor the active transaction or may transfer the transaction to another node for monitoring. Alternatively, the SC 32 may monitor all active transactions from a central point without departure from the scope of the subject matter described herein. As described above in association with
Accordingly, when an active transaction exists to be monitored (decision point 602), the process determines whether a transaction transfer request has been received from another node within the retail fueling environment 10 (decision point 608). When a transaction transfer request has been received, the process transfers the active transaction to the requesting node (step 610) and removes the transaction from its monitored queue of active transactions (step 612).
When a transaction transfer request has not been received (decision point 608), the process determines whether a transaction timeout has occurred (decision point 614). A timeout mechanism will help prevent customers from initiating a post-payment transaction without later paying for the FGS. When the process determines that a transaction timeout has occurred (decision point 614), the process generates an alarm and stores indicia for the unpaid transaction (step 616). This alarm may be generated and forwarded to the SC 32. The SC 32 may then take action, such as reporting the unpaid transaction via the off-site communication link 34 so that authorities may be alerted about the unpaid transaction.
When either a transaction timeout has not occurred (decision point 614) or the alarm has been generated and the indicia for the unpaid transaction have been stored (step 616), the process returns to the main loop where the process determines whether a transaction recall request has been received (decision point 604).
When a transaction recall request has been received, the process receives transaction indicia from the user (step 618). The transaction indicia may be received by any of the interface components described above in association with
After receipt of the transaction indicia from the customer, the process searches its local database of monitored transactions (not illustrated) and requests the transaction from the originating node or from the SC 32 if it is not a local transaction (step 620). The process may also add the transaction to its queue of monitored transactions if payment for the transaction is not received during the transaction recall processing (not illustrated).
Upon receipt of the transaction from the requesting node, the process allows dispensing of fuel (step 622) by performing various operations, such as unlocking the dispenser if a lock is present, opening valves, and any other activities that enable fuel to be dispensed from the FD 16. As fuel is dispensed, the process monitors a pre-payment shutdown threshold (decision point 624). When the pre-payment shutdown threshold has not been reached, the process determines whether fueling has been stopped prior to reaching the pre-paid amount (decision point 626), which would indicate that a refund or credit is due to the customer. The process iteratively checks the pre-payment threshold and for termination of the fueling transaction by the customer until either the pre-payment threshold has been reached or fueling has been stopped prior to reaching the pre-payment threshold.
When the pre-payment threshold has been reached (decision point 624), the process slows fuel delivery by beginning to close dispensing valves and stops dispensing fuel at the pre-paid amount (step 628). The FD is then locked if a lock is present and the valve(s) closed (step 630). The transaction is then completed (e.g., settled) (step 632), as described above.
When fueling has been stopped by the customer prior to reaching the pre-payment threshold (decision point 626), a refund or credit for the customer will be due. The process determines whether the customer wants a change from the pre-paid transaction or a credit (decision point 634). When the customer selects a credit, the credit is stored with customer identification indicium for future use (step 636). This credit may be recalled during a future transaction recall request, as described above. When the customer selects refund of the difference between the dispensed fuel and the pre-paid amount, change is provided to the customer (step 638). The change may be provided to the customer via the change delivery device 84.
When either the credit has been stored or change has been dispensed, the process locks the FD and completes the transaction (step 632), as described above. After the transaction is completed, the process returns to the main loop.
When a new transaction has been requested (decision point 606), the process progresses to
When post-payment is not allowed at the FD 16 (decision point 640), an alert/error message is displayed to the customer indicating that the customer must either pre-pay with the operator or pre-pay at the FD 16 (step 642). The customer is prompted for payment indicia (step 644).
The process then waits for the customer to present payment indicia (decision point 646). For example, the customer may present a smart card at the smart card reader 78 for payment purposes. The payment indicia may also include customer identification indicia that may then be associated with the transaction in the form of a transaction identifier, as described above and in more detail below.
Though not illustrated in
When the customer has presented a payment indicia to either the FD 16 or to the operator, the process may determine whether the transaction has been authorized (decision point 648). When the transaction has been authorized by either method, the process allows dispensing of fuel (step 650) by performing various operations, such as unlocking the dispenser if a lock is present, opening valves, and any other activities that enable fuel to be dispensed from the FD 16.
The process waits for the customer to finish dispensing fuel (decision point 652). When the customer has finished dispensing fuel, the FD is then locked if a lock is present and the valve(s) are closed (step 654).
The process then determines whether the customer desires to add goods and/or services to the transaction (decision point 656). When the customer does not desire additional goods and/or services, the process completes (e.g., settles) the transaction (step 658) and returns to the main loop of
Referring back to a situation where the transaction has not been authorized (decision point 648), the customer is prompted for another form of payment (step 664) and a determination is made as to whether a retry limit has been exceeded (decision point 666). The retry limit may be set to a reasonable number, such as three retries, to allow a customer to provide new payment and to avoid congestion at the FD 16 that may occur if the retry limit were set too high. When the retry limit has not been exceeded, the process iterates through decision point 646 to receive payment indicia, as described above. When the retry limit has been exceeded, the process terminates the transaction (step 668) and returns to the main loop of
Reference is now made to the situation where post-payment is allowed at the FD (decision point 640). The process then determines whether a request for post-payment has been received from the customer at the FD 16 (decision point 670). When a post-payment request has not been received, payment is to be made at the FD 16 and the process proceeds to prompt the customer for payment indicia (step 644), as described above.
When the customer chooses post-payment, the process initiates a post-payment transaction by determining whether customer identification indicium is required for the transaction (decision point 672). If customer identification indicium is not required, the process allows dispensing of fuel (step 650), as described above. When customer identification indicium is required for the transaction, the process waits for the customer identification indicium to be received (decision point 674). Again, appropriate timeout and error handling procedures may be implemented at any appropriate stage within the process described.
When customer identification indicium is received, a determination is made as to whether the customer is authorized to perform a post-paid transaction (decision point 676). Customer authorization may be performed in a variety of ways. For example, a check of an external database associated with fraudulent FGS transactions may be maintained by the SC 32. Additionally, the SC 32 may perform a check using the identification database 38 over the off-site communication link 34.
If the customer is determined not to be authorized to perform a post-paid transaction, the process terminates the transaction (step 668), as described above. Optionally, the attendant may authorize the transaction and allow indicia to be used to pay for fuel at an AA. If the customer is determined to be authorized to perform a post-paid transaction, the process creates a transaction (step 678). The transaction creation process includes associating a transaction identifier with the transaction that may be used by a customer to recall the transaction at another terminal within the retail fueling environment. As described above, the transaction identifier may include customer identification indicia, a text-based designation including alpha and/or numeric characters, and/or a bar coded sequence. The customer is provided with the transaction identifier, for example, via the display 86 or the receipt printer 82, so that the transaction may be recalled at another terminal within the retail fueling environment. When the receipt printer is used to provide the transaction identifier to the customer, the printed transaction identifier may be in the form of a bar code or a combination of alpha and/or numeric characters.
The process then allows fuel to be dispensed (step 650), as described above. Upon completion of the fueling process (either at step 658 or at step 662), the process returns to the main loop of
Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.