In some implementations, the session data and/or the uniform resource locator described above can be transmitted by the fuel dispenser via near field communication (NFC) to the client device. In such an implementation, the user can position the client device in proximity to an NFC transceiver of the fuel dispenser that is configured to transmit the session data (including unique identifier, the site unique identifier, and/or the fueling point unique identifier), and/or the uniform resource locator, and the client device can then acquire the unique identifier, the site unique identifier, the fueling point unique identifier, and/or the uniform resource locator from the NFC transceiver once it is positioned within range of the NFC transceiver.

At 120, a fuel dispensing parameter can be received. The fuel dispensing parameter can characterize an operational parameter of the fuel dispenser to configure operation of the fuel dispenser during a session in which fuel is to be dispensed from the fuel dispenser. For example, the fuel dispensing parameter can include at least one of a desired type of fuel (e.g., gasoline, diesel, etc.), a desired grade of fuel, a desired amount of payment for the fuel, a desired amount of fuel to be dispensed from the fuel dispenser, a desired fuel additive, a desired product/service for sale, and data characterizing a loyalty program. In some implementations, the fuel dispensing parameter can be received as an input from the user to the client device that is associated with the user. The input can be provided by the user by interacting with a graphical interface presented on a display of the client device, such as one or more of the graphical interfaces described above.

In some implementations, the content that is presented in the graphical interface via the display of the client device can be determined based on the received session data. For example, the unique identifier that is characterized by the session data can be used to initiate the process of generating the graphical interface. The input can include at least one of a numerical value characterizing the desired amount of payment for the fuel, a numerical value characterizing desired amount of fuel to be dispensed from the fuel dispenser, a selection of an available fuel additive, a selection of an available product/service for sale, and a string associated with a user's loyalty program account. In some implementations, the graphical interface can include a field for receiving the input and a prompt to instruct the user to provide the input to the field.

As mentioned above, in some implementations, the client device can include a vehicle head unit that is integrated into the user's vehicle and that includes a display configured to present a graphical interface and that permits the user to operate a web browser on the vehicle head unit via the graphical interface. The vehicle head unit can also be configured to receive input from the user that is responsive to or otherwise based on content provided in the graphical interface. In some implementations, a wireless connection, such as a wireless connection that is configured to transmit data via the Bluetooth protocol, can be established between the vehicle head unit and the fuel dispenser. Once the wireless connection is established, the fuel dispenser can transmit the session data (including unique identifier, the site unique identifier, and/or the fueling point unique identifier) and/or the uniform resource locator to the vehicle head unit via the wireless connection.

After the client device has received and/or decoded the session and the uniform resource locator, the client device can generate an instruction to launch the uniform resource locator in the web browser of the client device and to provide the unique identifier to a web server configured to interface with the web browser of the client device once the uniform resource locator is launched. The web server can be further configured to generate data characterizing content to be presented on the client device (via the web browser of the client device) and to provide the content to the client device for presentation on the display of the client device via the graphical interface. The data characterizing the content can be generated by the web server based on data received via an application programming interface (“API”) from other servers/components described herein.

The unique identifier can be provided by the web server to a transaction server, which can pass the unique identifier to a control server. In some implementations, the control server can be configured to authorize a transaction at an individual fueling point (such as a fuel dispenser) by directly communicating with the individual fueling point. In some implementations, the control server can be configured to authorize a transaction at an individual fueling point by interacting with a fueling station forecourt controller that is in operable communication with the individual fueling point and the control server. In some implementations, the control server can also be configured to provide data characterizing a message for display on a display of the fuel dispenser to inform the customer of the actions required in order to execute the fuel transaction (e.g., to lift the fuel dispenser nozzle from the fuel dispenser, to select a fuel grade for dispensing from the fuel dispenser, etc.).

In some implementations, the transaction server can be configured to identify and authorize a transaction with servers affiliated with acquiring merchants. In some implementations, the transaction server can identify a fuel transaction and request a fuel transaction authorization from the control server for use in authorizing the fuel transaction.

In some implementations, the control server can compare the unique identifier with a copy of the unique identifier received by the control server from the fuel dispenser in a separate transmission and thereby validate the unique identifier. The control server can generate data characterizing a request to reserve the fuel dispenser for the session, and the control server can provide the request to a point-of-sale device. In response to receiving the request to reserve the fuel dispenser, the point-of-sale device can reserve the fuel dispenser for the session and transmit data characterizing the fuel dispenser reservation to the control server. The control server can provide the fuel dispenser reservation data to the transaction server, which can pass the fuel dispenser reservation data to the web server. In response to receiving the fuel dispenser reservation data, the web server can generate the content for presenting on the display of the client device via the graphical interface, including the aforementioned fields. The web server can provide the content to the web browser of the client device, which can display the content on the display of the client device via the graphical interface.

At 130, a token characterizing a credential associated with the user for initializing the dispensing of the fuel during the session can be determined. In some implementations, after providing the aforementioned input(s) to the graphical interface, the user can interact with the graphical interface to select a method of payment for the fuel to be dispensed during the session. In response to receiving the payment method selection from the user, the web browser can request the token from the digital payment database of the client device. In order to issue the token to the web browser, the digital payment database must authenticate the request, and can do so by requesting a security credential from the user (e.g., biometric fingerprint, passcode, etc.). In response to receiving an acceptable security credential from the user, the digital payment database can provide the token to the web browser, which can provide the token to the web server for further processing, as explained in further detail below.

In some implementations, the token can include a string of randomly-generated numbers. In some implementations, the string of randomly-generated numbers can be encrypted using, for example, 128-bit encryption. The string of randomly-generated numbers can be associated with a primary account number that characterizes payment information of the user. In some implementations, the payment information of the user can be stored in a digital payment database that is stored in a memory of the client device. For example, the digital payment database can include a digital wallet that securely stores the payment information on the client device.

At 140, the initialization of the dispensing of the fuel from the fuel dispenser can be authorized. The authorization can include at least providing the token and the fuel dispensing parameter received from the client device to a routing processor separate from the fuel dispenser and the client device. For example, in some implementations, in response to receiving the token from the browser of the client device, the web server can provide a payment authorization request that that includes the token and the fuel dispensing parameter to the transaction server, which can in turn pass the payment authorization request to an external processor for further processing, such as the routing processor. In some implementations, the routing processor can include a payment switch configured to interact with payment-issuing and merchant banks and thereby manage payment to a merchant bank affiliated with the fueling station for the fuel/additives/products/services/etc. purchased during the session. For example, in some implementations, the payment switch can be configured to ascertain an authorization, from a payment-issuing bank holding an account of the user that corresponds to the token provided by the client device, indicating that the account has sufficient funds to pay for the fuel to be dispensed and/or any additional products/services selected by the user when using the graphical interface.

The authorization can include at least receiving a confirmation instruction from the routing processor based on at least the provided token and the provided fuel dispensing parameter. In some implementations, the confirmation instruction can be generated by the routing processor in response to determining that the account associated with the provided token at the payment-issuing bank has sufficient funds to pay for the desired fuel/additives/products/services/etc. requested for purchase during the session and that are characterized by the provided fuel dispensing parameter. In some implementations, as a result of this determination, the confirmation instruction can indicate that the initialization of the dispensing of the fuel by the fuel dispenser is authorized. The routing processor can provide the confirmation instruction to the transaction server.

The authorization can include at least determining an initialization instruction in response to receiving the confirmation instruction. For example, in some implementations, the transaction server can determine an initialization instruction for sending to the fuel dispenser in response to receiving the confirmation instruction, and the initialization instruction can include data characterizing commands for configuring the fuel dispenser for the dispensing of the fuel and to cause the fuel dispenser to be configured according to the fuel dispensing parameter.

At 150, the initialization instruction and the fuel dispensing parameter can be provided to the fuel dispenser, which causes the fuel dispenser to be configured according to the fuel dispensing parameter and enables the fuel dispenser to dispense the fuel. In some implementations, the initialization instruction can be provided to the control server. The control server can provide the initialization instruction to the client device and to the point-of-sale device to facilitate activation of the fuel dispenser for fueling.

In some implementations, when the dispensing of the fuel is complete, the point-of-sale device can generate a request to finalize the session and provide the finalization request to the control server. The control server can pass the finalization request to the transaction server, which can interact with the routing processor to finalize payment to the merchant bank for the fuel dispensed during the session. Once the routing processor has settled payment to the merchant bank associated with the fueling station, the routing processor can generate a finalization instruction that indicates the settling of the payment and provide the finalization instruction to the transaction server, which can pass the finalization instruction to the point-of-sale device. In response to receiving the finalization instruction, the point-of-sale device can indicate to an operator of the fueling station that the session has been completed and that payment has been settled.

In some implementations, a receipt characterizing the session can be generated and provided to the client device. For example, the point-of-sale device can provide session data characterizing the completed session to the control server, which can use the session data to generate receipt data that characterizes a record of the completed session. The control server can provide the receipt data to the transaction server, which can provide the receipt data to the web server. The web server can generate a graphical depiction of the receipt data and provide the graphical depiction to the web browser of the client device for display, via the graphical interface, on the display of the client device. In some implementations, the control server can provide the receipt data to a receipt database for storage therein. The receipt database can determine a path that characterizes a location of the receipt data stored in the receipt database and provide the path to the control server. The control server can provide the path to the transaction server, which can pass the path to the web server. The web server can provide the path to the client device for depiction in the graphical interface and viewing by the user on the display of the client device.

In some implementations, wherein the user has purchased a product/service available at the fueling station in addition to fuel, a retrieval three-dimensional barcode can be determined. The retrieval three-dimensional barcode can encode instructions to cause an authorization of retrieval of the product/service. The retrieval three-dimensional barcode can be provided to the client device, and the client device can display the retrieval three-dimensional barcode such that the retrieval three-dimensional barcode can be presented to a three-dimensional barcode reader in operable communication with a terminal used to provide the product/service. For example, when the product/service is a car wash visit at a car wash facility at or near the fueling station, the retrieval three-dimensional barcode can encode instructions that permit the activation of the car wash facility in accordance with the car wash services previously purchased by the user. The user can present the client device, having the retrieval three-dimensional barcode displayed on the display of the client device, to a three-dimensional barcode reader communicatively coupled to the car wash, which can activate the car wash after scanning the retrieval three-dimensional barcode.

In another example, when the product/service is a convenience store item that is available for purchase at a convenience store at/near the fueling station, the retrieval three-dimensional barcode can encode information that characterizes a proof of purchase of the convenience store item that was previously purchased by the user. The user can present the client device, having the retrieval three-dimensional barcode displayed on the display of the client device, to a three-dimensional barcode reader communicatively coupled to a convenience store point-of-sale device at the convenience store at which the convenience store item is located, which can scan the retrieval three-dimensional barcode and decode the proof of purchase information. The decoded proof of purchase information can be provided to the point-of-sale device by the three-dimensional barcode reader, which can generate a notification, for presentation on a display of the point-of-sale device, that indicates the user is authorized to retrieve the convenience store item.

In some implementations, the generated receipt data can be provided to a user's email address. For example, the graphical interface can include a field for the user to input their email address and a prompt that instructs the user to input their email address into the field. After receiving the email address at the field, the web browser can provide the email address to the web server, which can provide the email address to a notification service in operable communication with the web server. The notification service can provide the receipt data to the email address once the email address is received from the web server.

In some implementations, the receipt data, and additional receipt data previously stored in the receipt database, can be used in the generation of a receipt report that aggregates the receipt data corresponding to the session with historical receipt data from historical sessions. The receipt report can be provided to the point-of-sale device for presentation on the display of the point-of-sale device for review by fueling station attendants and/or management.

In some implementations, the current subject matter can be implemented in a system 200, as shown in FIG. 2. The system 200 can include one or more of a fuel dispenser 210, a client device 220, a remote management service 230, a routing processor 240, an on-site store 250, and a fuel controller 260.

In some implementations, the fuel dispenser 210 can be configured to dispense fuel and can include at least one data processor, memory, and an input/output device, and each can be configured to perform one or more aspects of the fuel dispenser functionality described herein. As shown and described herein, the fuel dispenser 210 can include components and programming that enable the fuel dispenser to provide fuel to a user and to facilitate payment for the fuel dispensed. In some implementations, the fuel dispenser can include components and programming that enable the fuel dispenser to provide the fuel, and the fuel dispenser can operate in conjunction with a payment terminal that includes components and programming configured to perform the payment and transaction functionalities described herein.

In some implementations, the client device 220 can be in operable communication with the fuel dispenser 210 and can include at least one data processor, memory, and an input/output device, and each can be configured to perform one or more aspects of the client device functionality described herein. As shown in FIG. 2, the client device 220 can include a receiver 221, such as a three-dimensional barcode scanner (e.g., a camera or image sensor), a near-field communication transceiver, and/or a wireless communications transceiver (e.g., a Bluetooth transceiver) that is configured to acquire data from the fuel dispenser 210 (such as a three-dimensional barcode encoding the above-described session data and/or the above-described session data). The client device 220 can also include a browser 222 that is configured to provide data characterizing the operation of the fuel dispenser 210 and other data types as shown and described herein to a graphical interface (GUI) 223, and to receive user inputs for selecting fuel dispenser operation parameters that are made by the user via the graphical interface (GUI) 223. The graphical interface 223 can be displayed on a display 224 of the client device 220. The client device 220 can also include a digital wallet 225 that is configured to store payment information of the user and to provide at least one token characterizing the payment information to the browser upon receiving a request from the browser and after an authentication of the user.

In some implementations, the remote management service 230 can be in operable communication with the fuel dispenser 210 and the client device 220 and can include one or more servers configured to perform one or more aspects of the server and database functionality described herein. As shown in FIG. 2, the remote management service 230 can include a web server 231, a transaction server 232, a control server 233, a loyalty server 234, a receipt database 235, and a notification server 236. The web server 231 can be configured to generate web content for presentation on the client device 220. The transaction server 232 can be configured to process the token received from the client device 220 in accordance with the functionality and operations described herein. The control server 233 can be configured to manage the operation of the processes and operations as described elsewhere herein. The loyalty server 234 can be configured to store loyalty program account information associated with the user and to provide data characterizing available promotions/discounts that are available to the user in accordance with any applicable loyalty programs. The receipt database 235 can be configured to receive receipt data that characterizes records of fuel dispenser sessions and to generate aggregate reports that include aggregated data characterizing fuel dispenser sessions. The notification server 236 can be configured to receive the receipt data and to provide the receipt data to an external address (e.g., an email address) based on inputs (e.g., an email address) provided via graphical interface 223 of the client device 220.

Although these servers and databases are shown as separate components within the remote management service 230, the functionalities performed by these separate servers and databases can be performed by a single server or database, or by any combination of servers and/or databases as required to ensure compatibility with existing/legacy components at fueling points/fueling stations, to maintain operational capacity in the event of service outages, and to improve the reliability of the systems and components described herein.

As mentioned above, the system 200 can include a routing processor 240 that is in operable communication with the remote management service 230. In some implementations, the routing processor can be a payment switch that is configured to manage the completion of payment for the fuel, products, and/or services purchased by the user during the session. As shown in FIG. 2, the routing processor 240 can be an external processor that is separate from the remote management service 230. However, in some implementations, the routing processor 240 can be incorporated into the remote management service 230.

In addition, as mentioned above, in some implementations the system 200 can include an on-site store 250 that is located at or near the fueling station at which the fuel dispenser 210 is located. The on-site store 250 can include products and/or services that are offered for sale by the fueling station in addition to fuel, such as convenience store items, restaurant service, and car wash services. As shown in FIG. 2, the on-site store 250 can include a point-of sale (“POS”) device 251 that includes at least one data processor that is configured to manage payment for the items in the on-site store 250 and to facilitate the dispensing of fuel from the fuel dispenser 210 in accordance with the functionality described herein. In addition, the on-site store 250 can include a forecourt controller 252 that includes at least one data processor configured to facilitate the management of the fuel dispenser 210 in accordance with the functionality described herein. Finally, the on-site store 250 can also include a car wash controller 253 that includes at least one data processor that is configured to operate a car wash in accordance with the functionality described herein. In some implementations, the POS 251, the forecourt controller 252, and/or the car wash controller 253 can be in operable communication with the remote management service 230 and can be configured to receive and transmit data characterizing operating instructions for various components of the system 200 in accordance with the functionality described herein.

In addition, as mentioned above, in some implementations, the system 200 can include a fuel controller 260 that can be incorporated into the fuel dispenser 210 and that can include at least one data processor configured to manage the dispensing of the fuel from the fuel dispenser 210 in accordance with the functionality described herein. In some implementations, the fuel controller 260 is configured to manage the operation of components of the fuel dispenser 210 (e.g., hydraulic components) and to measure the amount of fuel that is dispensed from the fuel dispenser 210. In some implementations, the fuel controller 260 can be in operable communication with one or more of the POS device 251 and the forecourt controller 252 of the on-site store 250, and can be configured to receive data from the POS device 251 and/or the forecourt controller 252 that characterizes instructions for controlling the dispensing of fuel from the fuel dispenser 210. In some implementations, the forecourt controller 252 is configured to interface with the fuel controller 260 and the POS device 251 and to provide an interface between the fuel controller 260 and the POS device 251. In operation, the forecourt controller can receive a request to authorize a fuel amount (or, in some implementations, a dollar amount equal to a desired fuel amount) at a particular fueling point/fuel dispenser and can translate the requested amount into commands which the fuel controller can accept to enable the dispensing of fuel. In some implementations, the POS device 251 can authorize a sales transaction based on a pre-authorization amount that the customer indicates via their interactions with the browser 222 of the client device or that the merchant sets as a maximum.

FIG. 3A is a data flow diagram 300 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram illustrates the transfer of data when the system 200 is initialized to begin operations. Referring to FIGS. 2 and 3A, in order to initialize the system 200, at 301, the POS device 251 can transmit a site initialization signal to the control server 233. The site initialization signal can include data that characterizes an indication, for use by one or more of the aforementioned components of system 200, that the components of the fueling station at which the fuel dispenser 210 and the POS device 251 is located (such as the components of the on-site store 250) are operational and ready to begin a session. At 302, the fuel dispenser 210 can transmit a fueling point initialization signal to the control server 233. Similar to the site initialization signal, the fueling point initialization signal can include data that characterizes an indication, for use by one or more of the aforementioned components of system 200, that the fuel dispenser 210 is operational and ready to begin a session.

FIG. 3B is a data flow diagram 310 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 310 illustrates the flow of data after the system 200 has been initialized and during the period time in which the system 200 is waiting for the fuel dispenser user to engage the fuel dispenser 210 to begin a session. Referring to FIGS. 2 and 3B, after the fuel dispenser 210 has generated a unique identifier that identifies the session to be initiated, and after the fuel dispenser 210 has generated a three-dimensional barcode characterizing the unique identifier, a fueling point identifier that identifies the fuel dispenser 210 relative to the fueling station, a site identifier that identifies the fueling station, and a uniform resource locator (URL) characterizing the web server 231, at 311, the fuel dispenser 210 can transmit data characterizing the unique identifier to the control server 233.

FIG. 3C is a data flow diagram 320 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 320 illustrates the transfer of data during the initialization of the session. Referring to FIGS. 2 and 3C, at 321, the receiver 221 of the client device 220 can acquire the aforementioned three-dimensional barcode from the fuel dispenser 210, for example, by acquiring an image of the three-dimensional barcode when depicted on the display of the fuel dispenser 210. At 322, the receiver 221 can decode the URL and the unique identifier from the three-dimensional barcode and provide the URL and the unique identifier to the browser 222 of the client device 210. At 323, the browser 222 can connect to the web server 231 using the URL received from the receiver 221 and provide the unique identifier to the web server 231. At 324, the unique identifier can be provided from the web server 231 to the transaction server 232. The transaction server 232 can temporarily store the unique identifier for the duration of the session. At 325, the transaction server 232 can provide the unique identifier to the control server 233 for comparison with the copy of the unique identifier that was previously provided to the control server 233 by the fuel dispenser 210. If the control server 233 determines that the unique identifier received from the transaction server 232 matches the copy of the unique identifier provided to the control server 233 by the fuel dispenser 210, at 326, the control server 233 transmits a request to reserve the fuel dispenser 210 for the session to the POS device 251. If the fuel dispenser 210 is available to be reserved for the session, at 327, the POS device 251 transmits a response indicating that the fuel dispenser 210 has been reserved for the session to the control server 233. The control server 233 then generates data indicating that the fuel dispenser 210 has been reserved for the session and, at 328, can transmit the generated data to the transaction server 232. The transaction server 232 can then populate a content template with data characterizing the fuel dispenser 210, the session, and fuel dispensing parameters. At 329, the transaction server 232 can provide the populated content template to the web server 231. In response to receiving the populated content template, the web server 231 can, at 330 provide the populated content template to the browser 222 for presentation in graphical interface 223. The user can then interact with graphical interface 223 to select and/or input their desired fuel dispensing parameters (including their desired payment amount and/or amount of fuel), desired products and/or services available for sale at the on-site store 250, and/or desired fuel additives.

FIG. 3D is a data flow diagram 340 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 340 illustrates the transfer of data during the authorization of the transaction that occurs during the session. Referring to FIGS. 2 and 3D, after the user has provided the aforementioned inputs/selections to the graphical interface via browser 222, and after the user has selected a method of payment for the transaction by interacting with the graphical interface, the browser 222, at 341, can request a token from the digital wallet 225 that characterizes the method of payment stored on the client device 220. After the wallet 225 has requested and received authentication (in the form of a security credential, such as those described elsewhere herein) from the user to provide the token, at 342, the wallet 225 can provide the token to the browser 222. In response to receiving the payment token, the browser 222 can, at 343, provide the payment token, the fuel dispensing parameters, the desired products and/or services, and the desired fuel additives to the web server 231. At 344, the web server 231 can provide the payment token, the fuel dispensing parameters, the desired products and/or services, and the desired fuel additives to transaction server 232, which can generate a payment authorization request using the received payment token and that includes an authorized purchase amount that corresponds to the cost of the desired fuel, the desired products and/or services, and the desired fuel additives.

In some implementations, wherein the customer has provided, as an input to the graphical interface provided by the browser 222, a desired volume of fuel, the transaction server 232 can also query the control server 233 to determine the price of the highest grade of fuel available at the fuel dispenser 210. In response to receiving the price of the highest grade of fuel available at the fuel dispenser 210 from the control server 233, the transaction server 232 can calculate a maximum monetary value of the fuel portion of the transaction that is based on the received price of the highest grade of fuel. The transaction server 232 can use the maximum monetary value in determining the authorized purchase amount included in the payment authorization request.

At 345, the transaction server 232 provides the payment authorization request to the routing processor 240. After the routing processor 240 determines that the account of the user that is associated with the payment token at the payment-issuing bank has sufficient funds available to cover the authorized purchase amount, which includes the cost of the desired fuel, additives, products, and/or services, the routing processor 240 can generate a confirmation instruction that includes data characterizing the authorized purchase amount and indicating that sufficient funds are available and that the transaction can proceed. And, at 346, the routing processor 240 can transmit the confirmation instruction to the transaction server 232.

In some implementations, wherein the user has provided, as an input to the graphical interface provided by the browser 222, loyalty program information characterizing the user's participation in a loyalty program, the transaction server 232 can query the routing processor 240 to ascertain whether the provided loyalty program information matches an existing loyalty rewards account and whether there are any promotional offers/discounts on the products/services being purchased during the session that are available to the user based on the schema of the loyalty program. If the provided loyalty program information matches an existing loyalty rewards account, and/or if promotional offers/discounts are available to the user, the routing processor 240 can generate and transmit data that characterizes the loyalty rewards account and/or the available promotional offers/discounts to the transaction server 232. Similarly, in some implementations, wherein the loyalty program is maintained on the loyalty server 234, the transaction server 232 can query the loyalty server 234 to ascertain whether the provided loyalty program information matches an existing loyalty rewards account and whether there are any promotional offers/discounts on the products/services being purchased during the session that are available to the user based on the schema of the loyalty program. If the provided loyalty program information matches an existing loyalty rewards account, and/or if promotional offers/discounts are available to the user, the loyalty server 234 can generate and transmit data that characterizes the loyalty rewards account and/or the promotional offers/discounts to the transaction server 232.

FIG. 3E is a data flow diagram 350 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 350 illustrates the transfer of data during the authorization of the fuel dispensing operation that occurs during the session. Referring to FIGS. 2 and 3E, after the confirmation instruction has been provided to the transaction server 232 from the routing processor 240, the transaction server 232 can generate an initialization instruction that includes data characterizing the authorized purchase amount and instructions to initialize the fuel dispenser 210 for delivery of fuel. In some implementations, wherein the transaction server 232 has received data from the routing processor 240 and/or loyalty server 234 pertaining to available promotional offers/discounts associated with the products and/or services being purchased, the initialization instruction can include any changes to the standard pricing of the products and/or services being purchased. Such changes can be determined by the transaction server 232 based on the aforementioned data received from the routing processor 240 and/or the loyalty server 234.

In some implementations, the user can order products and/or services, such as convenience store items, by interacting with the web server 231 via the browser 222 after the confirmation instruction has been received from the routing processor 240 and after the initialization instruction has been generated by the transaction server 232. In such an occurrence, an additional authorization of a secondary transaction for the additional products and/or services can be made. In some implementations, the initialization instruction can be modified by reducing the authorized purchase amount that is included in the initialization instruction in order to account for the additional cost of the additional products and/or services, thereby obviating the need to obtain an additional authorization for the additional products and/or services.

At 351, initialization instruction can be provided to the control server 233, which can generate a fuel authorization instruction based on the received initialization instruction. The fuel authorization instruction can include data characterizing instructions for the fuel controller 260 to activate the fuel dispenser 210 for fuel delivery and data characterizing the aforementioned changes to the standard pricing of the products and/or services being purchased. At 352, the fuel authorization instruction can be transmitted to the POS device 251, which can transmit the fuel authorization instruction to the forecourt controller 252 at 353. At 354, the forecourt controller 252 can transmit the fuel authorization instruction to the fuel controller 260, which can cause the fuel controller 260 to activate the fuel dispenser 210 for fuel delivery by generating and sending initialization instructions to the fuel delivery components of the fuel dispenser 210 at 355. When the fuel authorization instruction is transmitted to the POS device 251, the POS device 251 can update an operational status of the fuel dispenser 210 that is stored on the POS device 251 to indicate that the fuel dispenser 210 is engaged in a fuel transaction. As a result, any other systems at the fueling station that are configured to initialize fuel transactions at the fuel dispenser 210, and that are in operable communication with the POS device 251, are prevented from successfully initializing a transaction at the fuel dispenser 210. Similarly, when the fuel authorization instruction is transmitted to the forecourt controller 252, the forecourt controller 252 can update an operational status of the fuel dispenser 210 that is stored on the forecourt controller 252 to indicate that the fuel dispenser 210 is engaged in a fuel transaction. As a result, any other systems at the fueling station that are configured to initialize fuel transactions at the fuel dispenser 210, and that are in operable communication with the forecourt controller 252, are prevented from successfully initializing a transaction at the fuel dispenser 210. However, in some implementations, wherein the fueling station lacks any additional systems for initializing fuel transactions at the fuel dispenser 210, the control server 233 can transmit the fuel authorization instruction directly to the fuel controller 260.

Once the fuel controller 260 has activated the fuel dispenser 210 for fuel delivery, the fuel controller 260 can generate signal data that indicates that the fuel dispenser 210 has been activated, and the fuel controller 260 can transmit the signal data to the POS device 251 at 356. At 357, the POS device 251 can transmit the signal data to the control server 233, which can generate a display command characterizing a prompt to instruct the user to proceed with fueling (e.g., lift nozzle, select grade, begin fueling, etc.). At 358, the control server 233 can provide the display command to the fuel dispenser 210, which can generate a graphical representation of the prompt and display the graphical representation of the prompt on the display of the fuel dispenser 210. In some implementations, the control server 233 can, at 359, provide the display command to the transaction server 232, which can provide the display command to the web server 231 at 360. The web server 231 can generate a graphical representation of the prompt and provide the graphical representation of the prompt for presentation in the browser 222 of the client device 220 at 361.

FIG. 3F is a data flow diagram 365 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 365 illustrates the transfer of data after fueling has been completed. Referring to FIGS. 2 and 3F, once fueling has been completed in accordance with the fuel authorization instruction, the fuel controller 260 generates finalization data characterizing a notification that fueling has been completed, the volume of fuel dispensed by the fuel dispenser 210, and a price per unit volume of the fuel dispensed. At 366, the fuel controller 260 transmits the finalization data to the forecourt controller 252. At 367, the forecourt controller 252 can transmit the finalization data to the POS device 251. The POS device 251 can generate data characterizing a request to finalize the transaction and provide the generated request, at 368, to the control server 233. However, in some implementations, the fuel controller 260 may provide the finalization data directly to the control server 233, which can generate the data characterizing the request to finalize the transaction. The control server 233 can, at 369, provide the generated request to the transaction server 232, which can apply any promotional offers/discounts that are applicable in accordance with the aforementioned loyalty program data and provide the generated request to the routing processor 240 at 370. The routing processor 240 can finalize the transaction to effect payment for the dispensed fuel to the merchant bank associated with the fueling station. The routing processor 240 can generate a notification that the transaction has been finalized, and, at 371, the routing processor 240 can provide the notification to the transaction server 232. The transaction server can, at 372, provide the notification to the control server 233. The control server 233 can, at 373, provide the notification to the POS device 251. The POS device 251 can then finalize the transaction and end the session.

FIG. 3G is a data flow diagram 375 that illustrates the transfer of one or more of the types of data described herein between system components described in FIG. 2 and in accordance with some implementations of the current subject matter. In particular, data flow diagram 375 illustrates the transfer of data when a receipt characterizing the transaction that occurred during the session is provided to the client device. Referring to FIGS. 2 and 3G, after the transaction has been finalized, the POS 251 can, at 376, transmit receipt data characterizing a record of the completed session to the control server 233. The control server 233 can, at 377, transmit the receipt data to the receipt database 235, which can store the receipt data. In response to receiving the receipt data from the control server, the receipt database 235 can generate a path that characterizes a location of the receipt data in the receipt database 235 and transmit the path to the control server