Customer device application site accessible via merchant management identifier

Abstract

A customer device application site (e.g., content presented via a progressive web application) is described that is accessible via a merchant-controlled identifier (e.g., an identification code). An identification of a physical location associated with the merchant may be associated with the identification code. The identification code may be received from a customer's computing device, and merchant data associated with the merchant may be presented via a web browser on the customer's computing device based at least in part on receiving the identification code. In one example, the merchant data may be presented via a web browser by a progressive web application downloaded onto the customer's computing device. An indication of an input received via the progressive web application may be received by the customer's computing device, and an action based at least in part on the input may be performed.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 16 / 998,921, filed August 20, 2020, entitled "CUSTOMER-DEVICE APPLICATION SITES ACCESSIBLE VIA MERCHANT-MANAGED IDENTIFIERS," the entire contents of which are incorporated herein by reference.

[0002] Physical store transactions can be high-friction transactions, requiring customers and merchants to interact with each other and other physical items (e.g., menus, writing implements, payment terminals, etc.) to effectuate such transactions. There are scenarios in which customers and / or merchants aim to facilitate transactions and / or minimize the friction associated with such transactions. Existing techniques are not user-friendly and / or accessible to small merchants due to development complexity and cost. Furthermore, existing techniques can be slow due to the time required for downloading and / or registration, and are limited in use due to network connectivity. There is also a need to provide a more computationally efficient alternative to existing techniques, having lower bandwidth usage and reduced storage requirements. [Brief explanation of the drawings]

[0003] The features of the present disclosure, its nature and various advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0004] [Figure 1] FIG. 1 illustrates an exemplary environment for a customer device application site (e.g., content presented via a progressive web application) accessible via a merchant-controlled identifier (e.g., an identification code) as described herein.

[0005] [Figure 2A]FIG. 2A illustrates an exemplary graphical user interface (GUI) that may be presented by a progressive web application via a web browser on a customer computing device.

[0006] [Figure 2B] FIG. 2B illustrates another exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0007] [Figure 2C] FIG. 2C illustrates yet another exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0008] [Figure 2D] FIG. 2D illustrates another exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0009] [Figure 3A] FIG. 3A illustrates an exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0010] [Figure 3B] FIG. 3B illustrates another exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0011] [Figure 3C] FIG. 3C illustrates yet another exemplary GUI that may be presented by a progressive web application via a web browser on a customer computing device.

[0012] [Figure 4]FIG. 4 illustrates an exemplary GUI that may be presented via a merchant computing device for managing orders as described herein.

[0013] [Figure 5] FIG. 5 illustrates an exemplary GUI that may be presented via a merchant computing device for managing tickets as described herein.

[0014] [Figure 6] FIG. 6 illustrates an exemplary GUI that may be presented via a merchant computing device for generating and / or managing identification codes as described herein.

[0015] [Figure 7] FIG. 7 illustrates an example process for receiving input via a progressive web application and performing an action based at least in part on the input, as described herein.

[0016] [Figure 8] FIG. 8 illustrates an example process for processing a payment associated with an open ticket as described herein.

[0017] [Figure 9] FIG. 9 illustrates an example process for generating an order queue based at least in part on orders received via different commerce channels.

[0018] [Figure 10] FIG. 10 illustrates an exemplary process for outputting merchant data, such as an online menu, by a progressive web application and via a customer's web browser, where the merchant data and / or its presentation may be modified based at least in part on data associated with the customer, as described herein.

[0019] [Figure 11] FIG. 11 illustrates an example process for modifying a menu presented via a first commerce channel for presentation on a second commerce channel, as described herein.

[0020] [Figure 12] FIG. 12 illustrates, among other things, an exemplary merchant ecosystem for facilitating the techniques described herein.

[0021] [Figure 13] FIG. 13 provides additional details relating to the individual components of the merchant ecosystem described above in FIG.

[0022] In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Use of the same reference number in different figures indicates similar or identical items or features. The figures are not to scale. DETAILED DESCRIPTION OF THE INVENTION

[0023] The techniques described herein are directed, among other things, to customer device application sites (e.g., content presented via a progressive web application) accessible via a merchant-managed identifier (e.g., an identification code). In one example, a merchant can utilize the services of a service provider to generate or otherwise associate an identification code with a particular location associated with the merchant's physical store or facility. Such an identification code, which may be, for example, a quick response (QR) code, a barcode, a radio frequency identification (RFID) device ID, or the like, can be associated with a restaurant table, a movie theater seat, a parking spot in a parking lot, a hotel room, or the like. When a customer is at the physical store or other facility, the customer can scan the identification code using a computing device (e.g., their mobile device). The computing device can provide the scanned identification code to a server associated with the service provider, which can cause merchant data associated with the merchant to be presented via the customer's computing device. In some examples, such merchant data can include a menu of items offered for sale, a layout of the physical store or facility, etc. The customer can interact with a user interface to provide input related to the transaction. In some examples, the input can be ordering from an online menu, reserving a table, a seat, a parking spot, a hotel room, etc. In some examples, customers can interact with merchant data via a user interface to provide payment data, tips, feedback, etc. Thus, customers can transact with merchants without touching or otherwise interacting with physical items (e.g., menus, writing implements, etc.), the merchant's payment terminal and / or computing device, etc. This can allow customers to provide input via their own computing devices, thus reducing the friction associated with brick-and-mortar transactions.

[0024] In some examples, merchant data may be presented via a customer's computing device via progressive web application technology. A progressive web application is a type of application software delivered over a network (e.g., the web) that can be built using web technologies (e.g., HTML, CSS, JavaScript, etc.). Progressive web applications may be used to provide a user experience similar to that of a native application on a computing device, but with fewer development resources. In other words, the functionality of a native application may be provided in a much more computationally efficient manner, reducing bandwidth usage and storage requirements because the native application does not need to be downloaded to the customer's computing device. In at least one example, a progressive web application may be provided to (e.g., downloaded by) the customer's computing device in response to scanning an identification code associated with a designated seating area and / or a brick-and-mortar store. Thus, merchant data may be presented via a web browser on the computing device by the progressive web application. Downloading a progressive web application is more computationally efficient and requires less bandwidth and storage capacity than downloading a native application.

[0025] In at least one example, a customer may enter a merchant's physical store. The customer may have an identification code (e.g., a QR code, a barcode, an RFID device, etc.) associated with it and may select a table at which to sit. The customer may use their mobile device to scan the identification code. The identification code may identify a table (e.g., a location number, a seat number, etc.), and in some examples, if the merchant has multiple physical stores, the scanned identification code may indicate the particular physical store where the customer is located. In some examples, an indication of the scanned identification code may be associated with data indicating a date, time, customer, etc. In at least one example, a server computing device (“server”) associated with a service provider may receive the indication of the scanned identification code and cause a progressive web application (which may present content via an “app site”) to be downloaded onto the customer's mobile device. The progressive web application may cause an online menu to be presented via a web browser on the mobile device. Progressive Web Applications can provide experiences similar to native applications, such as presenting content similar to that presented in native applications, and can provide push notifications via an "app site" with high computational efficiency and low bandwidth and memory usage. In at least one example, a customer can interact with their mobile device to place an order because they have already scanned an identification code, which can be associated with an indication of where the customer is located within the brick-and-mortar store. Such information can be provided to front-of-house computing systems, back-of-house computing systems, kitchen display systems, etc., to enable fulfillment of orders and / or service to the customer. Thus, using Progressive Web Application technology, customers can have an in-seat dining experience using their mobile devices.Thus, customers can have an in-seat dining experience using their mobile devices using Progressive Web Application technology. The techniques are similarly applicable to "in-store" experiences at theaters, sports fields or arenas, hotels, parking lots, retail stores, etc.

[0026] As discussed above, brick-and-mortar transactions can be high-friction transactions, as customers and merchants may be required to interact with each other and other physical items (e.g., menus, writing implements, payment terminals, etc.) to effectuate such transactions. There are scenarios in which customers and / or merchants aim to facilitate transactions and / or minimize the friction associated with such transactions. Existing techniques are not user-friendly and / or accessible to small merchants due to development complexity and cost. Furthermore, existing techniques can be slow due to the time required for downloading and / or registration and have limited use due to network connectivity.

[0027] In some instances, merchants may choose to develop and deploy native applications (or hybrid applications) to enable customers to interact with the merchant through their devices. Such development can be complex and expensive, often making native application development impractical for small merchants. Furthermore, in order for customers to use such native applications, they often must install the native application on their computing devices and accept terms and conditions before using the native application. Downloading a native application can consume bandwidth, require time, and storage space, which in some instances may limit the availability of the native application to customers. In a restaurant dining experience, customers may not want to spend the time downloading a native application, registering to use the native application, reserving the necessary memory, etc. Native applications also need to be configured to run on any particular platform, which means that different versions of the native application need to be made available for download for each platform.

[0028] In some instances, merchants may choose to deploy web applications. Web applications are software applications accessed via a web browser. Web applications can be slow and heavy (consuming bandwidth and processing resources), making the associated user experience frustrating and unpleasant. Web applications require an Internet connection (or another network), and therefore, content presented via the web application may be unavailable when there is a poor connection associated with such a web application or when the computing device is offline. Furthermore, web applications can be complex and difficult to use, especially on small form factors such as mobile computing devices.

[0029] Progressive web applications provide solutions to the above-mentioned problems with native and / or web applications. For example, progressive web applications use resources from web browsers and present an experience similar to that of native applications. Progressive web applications can offer more features, use fewer processing resources and bandwidth, and execute much faster than web applications. Furthermore, progressive web applications can be portable across different types of platforms (e.g., desktop, mobile, etc.) and, in some instances, can adapt to various display sizes (e.g., of computing devices such as desktop, mobile, and tablet), thereby making progressive web applications accessible, user-friendly, usable across various platforms without the need for reconfiguration, more computationally efficient, and less of a drain on bandwidth and device memory. That is, progressive web applications can be responsive in that they can adapt to different form factors and / or screen sizes. Progressive web applications can be more user-friendly than native and / or web applications. For example, progressive web applications may be accessible when the internet connection is poor and / or the computing device is offline, up-to-date (eg, updates to content may be performed in the background), etc.

[0030] Progressive web applications can provide security by utilizing the HTTPS protocol to protect the privacy and integrity of data associated with the progressive web application. Progressive web applications can be "progressive" in that they can function for a variety of users regardless of which web browser is being used. Furthermore, progressive web applications that can use an application shell model can provide a user experience similar to that of a native application. That is, customers can access the progressive web application via a shortcut icon that can be installed on a web browser and / or the desktop or home screen of a computing device operable by such customers. In some examples, progressive web applications can use push notifications to maintain customer engagement. Furthermore, progressive web applications can be easily shared via a uniform resource locator (URL) and do not require complex installation. That is, a progressive web application may use a URL to indicate the current state of the progressive web application, allowing the progressive web application to preserve or reload its state when a user bookmarks or shares a URL associated with the progressive web application (e.g., to which the progressive web application is linkable).

[0031] Thus, the techniques described herein leverage progressive web applications that provide a similar user experience to native and / or web applications, allowing customers to have faster access to merchant data through technologies that use less bandwidth, fewer processing resources, less memory, can be used across a variety of platforms without requiring any reconfiguration, and provide an improved user experience over traditional alternatives such as native and / or web applications. Such technologies can thus streamline transactions and other interactions between customers and merchants at such merchants' brick-and-mortar stores or other facilities. Further details are provided below.

[0032] FIG. 1 illustrates an exemplary environment 100 for a customer device application site (e.g., content presented via a progressive web application) accessible via a merchant-controlled identifier (e.g., an identification code) as described herein.

[0033] In at least one embodiment, a merchant 102 may offer items (e.g., goods or services) for sale or other acquisition. In at least one example, the merchant 102 may operate a computing device (i.e., merchant computing device 104). The merchant computing device 104 may comprise one or more components capable of communicating with one or more remotely located computers associated with a service provider (e.g., server 106) via one or more networks 108. As shown in FIG. 1 , the merchant computing device 104 comprises merchant-facing components and customer-facing components. In such examples, the merchant-facing components and / or customer-facing components may have applications installed thereon that enable the merchant 102 to conduct transactions with customers, such as customer 110, and perform other merchant operations (e.g., order management, reservation management, identification code generation, etc.). In some examples, applications are provided by a service provider to specifically equip the merchant computing device 104 (and / or its associated components) as a payment terminal. Although applications are described herein, in some instances, the merchant 102 may interact with the merchant computing device 104 through a user interface presented by additional or alternative mechanisms, such as a web browser.

[0034] In at least one example, the merchant-facing component may have a reader device integrated therewith. In at least one example, the merchant-facing component may be coupled to a customer-facing component and may have a reader device integrated therewith. In some examples, the merchant-facing component and the customer-facing component may be associated with their own displays. In some examples, the merchant computing device 104 may be a single computing device that is rotatable or otherwise movable to allow the merchant and / or customer to interact with the merchant computing device 104. Additional details related to the merchant computing device 104 are described below.

[0035] In at least one example, a merchant 102 may offer items for sale through different commerce channels. For example, a merchant 102 may offer items for sale through an online commerce channel (or “e-commerce channel”), which may allow customers fulfillment options to obtain the items via pickup, delivery, shipping, etc. Additionally, in some examples, a merchant 102 may offer items through a brick-and-mortar commerce channel (or “in-store commerce channel”), where the merchant 102 fulfills orders by delivering the items to customers at the merchant's 102 brick-and-mortar store. In some examples, a brick-and-mortar store may include one or more designated seating areas, such as tables, chairs, etc. A top-down view 112 of the layout of a merchant's 102 brick-and-mortar store, including multiple designated seating areas, is shown in FIG. 1 .

[0036] In at least one example, the merchant 102 can interact with the merchant computing device 104 to generate identification codes that can be associated with each of the designated seating areas. For example, a designated seating area (e.g., a table) 114 can be associated with an identification code 116. In FIG. 1 , the seating area is shown as a table and chairs (i.e., bar stools). However, the designated seating area may also be a theater seat, a parking lot, a hotel room, etc. In FIG. 1 , the identification code 116 is shown as a QR code. However, the identification code may also be a barcode, an ID associated with an RFID device, etc. In some examples, the identification code may be predetermined, and the merchant 102 can interact with the merchant computing device 104 to associate the predetermined identification code with the designated seating area and / or the physical store's ID. The identification code, whether generated by the merchant 102 and / or associated with the designated seating area and / or physical store's ID(s), can indicate the merchant's 102's designated seating area and / or physical store.

[0037] In at least one example, the customer 110 can operate a computing device (i.e., the customer computing device 118) to scan or otherwise read the identification code 116. In some examples, the customer computing device 118 can include a reader device capable of reading the identification code 116. In at least one example, the customer computing device 118 can transmit an indication of the identification code 116 to the server(s) 106 over the network(s) 108. In some examples, the indication of the identification code 116 can be associated with data such as a date, time, a customer ID, a device ID, a cookie, etc. In at least one example, the server 106 can receive the identification code 116 and transmit a progressive web application (PWA) 120 to the customer computing device 118. That is, the customer computing device 118 can download the progressive web application 120 via a web browser on the customer computing device 118. In some examples, the customer computing device 118 may have previously downloaded the progressive web application 120, for example, by entering a URL associated with the progressive web application 120 into a web browser associated with the customer computing device 118. In such examples, the indication in the identification code 116 may be associated with a cookie or other indicator that the progressive web application 120 was previously downloaded on the customer computing device 118.

[0038] As described above, a progressive web application 120 may be a type of application software delivered over a network (e.g., the web) that may be built using web technologies (e.g., HTML, CSS, JavaScript, etc.). A progressive web application 120 may be used to provide a user experience similar to a native application on a computing device, such as the customer computing device 118, with fewer development resources. The progressive web application 120 may use resources from web browser(s) to present an experience similar to a native application. In at least one example, the progressive web application 120 may utilize the HTTPS protocol to protect the privacy and integrity of data associated with the progressive web application 120 (e.g., data provided via the progressive web application 120 and / or transmitted over the network 108). The progressive web application 120 may be configured to function for a variety of users regardless of which web browser is used. Thus, the progressive web application 120 may be progressive (built using progressive enhancement patterns). However, features available via the progressive web application 120 may be dependent on web browser support, including, for example, connection independence, home screen or desktop installation, push messaging, etc.

[0039] As described above, progressive web applications 120 may be more user-friendly than native applications and / or web applications. For example, progressive web applications 120 may be adaptable to a variety of display sizes (e.g., desktop, mobile, tablet, etc., computing devices), may be accessible when the internet connection is low quality and / or the computing device is offline, may be up-to-date (e.g., updates to content may be performed in the background), etc. Furthermore, progressive web applications 120 that can use an application shell model may provide a user experience similar to that of native applications. That is, customers 110 may access the progressive web application 120 via a shortcut icon that may be installed on a web browser and / or the desktop or home screen of a computing device operable by such customers. In some examples, progressive web applications 120 may use push notifications to maintain engagement with customers 110. Furthermore, progressive web applications 120 may be easily shared via a uniform resource locator (URL) and do not require complex installation.

[0040] In at least one example, a progressive web application 120 may be associated with a manifest that provides a developer with a centralized location for storing metadata associated with the progressive web application 120. Such metadata may include, but is not limited to, the name of the progressive web application 120, a link to an icon or image object for the progressive web application 120, a preferred URL for launching or opening the progressive web application 120, configuration data for the progressive web application 120, a default orientation for the progressive web application 120, display mode options, etc.

[0041] In at least one example, the progressive web application 120 may be associated with an object (e.g., a “service worker”) configured to execute client-side code in a background thread separate from the web browser's main thread and provide a scriptable network proxy to the web browser to programmatically manage communications between the progressive web application 120 and the server(s) 106. In at least one example, the object may be independent of the progressive web application 120 with which it is associated. In some examples, portions of the progressive web application 120 and / or content associated therewith may be cached by the object for future interactions with the progressive web application 120. That is, in some examples, after an initial load of the content, the same content and / or page elements do not need to be re-downloaded and / or re-rendered each time the progressive web application 120 is subsequently accessed. In some examples, the object may utilize one or more application programming interfaces (APIs) to enable the progressive web application 120 to operate offline. Such an API can provide a mechanism for retrieving content over networks 108 and for persistent content storage for application data. Caching resources allows content to load faster under varying network conditions.

[0042] In at least one example, the object can help keep content associated with the progressive web application 120 up to date. In some examples, the object can be a file (e.g., a JavaScript file) that acts as a type of web worker. The object can operate separately from the main thread of the web browser to handle push notifications, synchronize data in the background, cache or retrieve resource requests, intercept network requests, receive centralized updates, and / or the like. Such objects can enable the progressive web application 120 to provide the high-performance, rich user experience of a native application with the low storage space, real-time updates, and improved search engine visibility of a traditional web application (e.g., a progressive web application as a website can be discovered in search engines).

[0043] In some examples, objects may utilize one or more other APIs to enable the progressive web application 120 to function like a native application. For example, an object may use a notification API to display and interact with notifications using the native notification system of the operating system of the customer computing device 118. A push API may enable the progressive web application 120 to subscribe to a push service and receive push messages, for example, from the server(s) 106. Push messages may be delivered to the object, which can use the information in the message to update local state or display a notification to the customer 110. Because objects run independently of the progressive web application 120, they can receive and display notifications even when the web browser is not running. In some examples, a background synchronization API may defer actions until the customer computing device 118 has stable connectivity. This may be useful to ensure that what the customer 110 wants to send is actually sent. This API can also allow the server 106 to push periodic updates to the progressive web application 120 so that the progressive web application 120 can update the next time it is online. In some examples, a channel messaging API can allow objects to communicate with other objects and the progressive web application 120. Examples of this API can include new content notifications (e.g., making new content available via the progressive web application 120) and updates that utilize user interaction. The progressive web application 120 can utilize additional or alternative APIs or additional or alternative functional components to perform the operations described herein.

[0044] In at least one example, an object can go through a three-stage lifecycle: registration, installation, and activation. Registration can include communicating the object's location to a web browser in preparation for installation. Installation can occur when the web browser has no installed object or when there is an object update (e.g., a byte difference between a new object and a previously installed object). Activation can occur when all of the web pages of the progressive web application 120 are closed, so that there are no conflicts between the previous version and the updated one. The lifecycle also helps maintain consistency when switching between versions of an object, since, in some examples, only a single object may be active for a region.

[0045] In at least one example, the progressive web application 120 may cause merchant data to be presented via a web browser on the customer computing device 118. In some examples, such merchant data may be a menu of items, a layout of the merchant's 102 physical store, etc. In at least one example, the server 106 and / or the merchant computing device 104 may perform actions based on such input. Examples are provided below.

[0046] In some examples, the progressive web application 120 can submit a request for payment for the transaction. In such examples, the customer 110 can enter payment data, provide a payment instrument (e.g., that can be read by a reader device associated with the customer computing device 118), or the like, to facilitate payment for the transaction with the merchant 102. In some examples, the customer 110 can provide the payment data to the merchant 102, for example, via a reader device associated with the merchant computing device 104 or via a card-on-file transaction (e.g., using stored payment data) accessible by the service provider and / or the merchant 102. Regardless of whether the payment data is provided via the customer computing device 118 or the merchant computing device 104, the server 106 can receive the payment data and attempt to process payment for the cost of the transaction.

[0047] In some examples, the progressive web application 120 may be associated with an instant application. An instant application may be a portion of an application, such as the progressive web application 120, that can be quickly executed on a user computing device without requiring the user to download the entire progressive web application 120. That is, a portion of the progressive web application 120 may include instructions (e.g., code) to enable a particular function (e.g., a single task, several tasks, etc.) that can be performed by a user computing device, such as the customer computing device 118, without the user having to download the entire progressive web application 120. Such a portion may be downloaded to the customer computing device 118 and quickly opened, even if it is not already on the customer computing device 118. That is, such an instant application may provide a means for executing application code “on-demand” on the customer computing device 118 and may act as a representation of a complete application (e.g., the progressive web application 120) before the user commits to downloading the complete application. In some examples, information input into an instant application can persist so that such information can be integrated into the complete application when the rest of the application is downloaded onto the customer computing device 118. In one example, an instant application is a portion of a complete application, and therefore, the instant application can have a smaller set of features than the set of features in the complete application. That is, an instant application can include a portion of a full progressive web application 120, and therefore, can provide a smaller set of features than the full progressive web application 120.In some examples, the remainder of the progressive web application 120 may be downloaded at a time after the instant application is downloaded and / or executed.

[0048] Instant applications are discoverable. In some examples, a user may scan or otherwise read an identification code or other interactive element associated with a particular application (or portion thereof). Such an identification code or other interactive element may be associated with a quick response (QR) code, a radio frequency identification (RFID) tag, a barcode, a near field communication (NFC) tag, a uniform resource identifier (URI), an image, etc. In some examples, an identification code may be affixed to or otherwise associated with a physical object, such as a table, a designated seating area, a receipt, a bicycle, a scooter, a vehicle, a door, an item offered for sale, etc. In some examples, an identification code may be presented via an electronic device (e.g., a customer-facing display at a point of sale). In some examples, interaction with the identification code or other interactive element may activate an instant application on a user computing device. In some examples, a user may tap a card reader or another NFC device to activate the instant application on the user computing device. In some examples, an instant application may be discoverable via a banner associated with a webpage, a link in a message, a maps user interface, a library of recently used instant applications, etc. In some examples, instant applications may be discovered based at least in part on the geolocation of the user computing device, a time, a date, an event, or any other context.

[0049] Once discovered, a portion of the application (e.g., an instant application) is downloaded onto the customer computing device 118 and thus executable thereby, and a user interface may be presented to allow the user to interact with the portion of the application executable by the customer computing device 118. That is, the instant application may be discovered at a time or place where the user can use it and focus on a particular task (e.g., making a reservation, ordering, paying, etc.). In some examples, the user may start and finish the experience for seconds, minutes, or other periods, after which the user may be presented with an opportunity to download the full application (or additional portions thereof). In at least one example, the user may interact with the instant application without downloading the corresponding application. In some examples, if a user launches an instant application periodically (without downloading the full application), the instant application may remember data from previous usage and leverage intelligence to learn about the user and / or their interactions with the instant application. Such intelligence may be used to present recommendations, expedite order processing, facilitate checkout flows, etc. In some examples, if the user decides to download the full instant application, data previously provided to the instant application may be used by the full application to streamline the handoff. In some examples, permissions provided for access to the camera, microphone, Bluetooth, etc., already requested by the instant application may be provided to the full application to further streamline the handoff.

[0050] Thus, the techniques described herein may be performed by the progressive web application 120 and / or portions thereof (e.g., as an instant application). In examples where the functionality described herein is performed by an instant application, additional or alternative functionality available through other portions of the progressive web application 120 may be accessed later, for example, via another instant application or the full progressive web application 120.

[0051] 2A-2D and 3A-3C illustrate exemplary graphical user interfaces (GUIs) that may be presented by the progressive web application 120 via a web browser on the customer computing device 118. The exemplary GUIs are for illustrative purposes and should not be construed as limiting. For example, the techniques described herein may present additional or alternative content via the GUI and / or additional or alternative configurations of content via the GUI. In some examples, content may be presented via additional or alternative user interfaces (e.g., speakers, etc.).

[0052] As described above, the progressive web application 120 can cause merchant data to be presented via a web browser. In some examples, such merchant data can be presented in response to the customer computing device 118 reading the identification code 116 and transmitting instructions thereto to the server 106. In some examples, such merchant data can include a menu of items for sale by the merchant 102. That is, in at least one example, the identification code 116 can link to an order page for a particular physical location (e.g., a table / seat in a brick-and-mortar store). In some examples, items can be added to an order without the customer 110 signing up. In FIGS. 2A and 2B, the exemplary GUI 200 includes user interface elements 204 that represent items offered for sale by the merchant 102. That is, in FIGS. 2A and 2B, the GUI 200 can represent an order page. In some examples, the user interface elements 204 can be text elements, graphical elements, pictures, icons, selectable elements, or any other object that can be presented via a GUI. In some examples, the menu of items may include one or more items that may be identified in the merchant's 102 inventory as being available for sale by the merchant 102 .

[0053] In at least one example, a customer 110 can interact with a customer computing device 118 to select an item to order. In such an example, the progressive web application 120 can detect input indicating the selection and can send an indication of the selection to the server 106. In some examples, the server 106 can generate a data structure with which the indication of the item can be associated. In some examples, the data structure can represent a ticket. In some examples, the data structure can be stored, at least temporarily, so that indications of one or more additional items can be added to the data structure over time. In such an example, the data structure can represent an “open ticket” and can persist until the customer 110 and / or the merchant 102 provide an indication to close the open ticket and / or until an event occurs (e.g., time passes, a threshold is met, etc.) that causes the open ticket to be automatically closed.

[0054] As a non-limiting example, in FIG. 2A , which may be associated with an initial time, the customer 110 can interact with the GUI 200 to order a burger (e.g., provide input indicating a burger selection). The progressive web application 120 can send input instructions to the server 106. The server 106 can associate the burger instructions with a data structure. In FIG. 2B , which may be associated with a second time after the first time, the customer 110 can interact with the GUI 200 to order a beer (e.g., provide input indicating a beer selection). The progressive web application 120 can send input instructions to the server 106. The server 106 can associate the beer instructions with a data structure. In examples where the customer 110 interacts with the customer computing device 118 at different times, the web browser associated with the progressive web application 120 can remain open. That is, the customer 110 can interact with the GUI 200 as long as the web browser associated with the progressive web application 120 remains open. In some examples, content presented via the GUI 200 may be updated while the web browser associated with the progressive web application 120 remains open, so that the content is current and does not need to be re-cached. In some examples, notifications and / or other content may be pushed from the merchant computing device 104 and / or server 106 to the customer computing device 118 as long as the web browser associated with the progressive web application 120 remains open.

[0055] In some examples, customer information can be saved based on web browser / cookie session parameters, thereby keeping such customer information attached. If the customer provides identification (e.g., customer ID, phone number, email address, etc.), payment data, etc., such information can be saved. In some examples, the customer can provide confirmation authentication using a code or other means for authentication. Thus, as long as the web browser remains open, content associated with the progressive web application 120 can be accessible to the customer 110. For example, the customer 110 can view / use previously created presets (e.g., location, previous orders / reorders, account subscriptions, addresses, payments, etc.) and / or continue to interact with content provided by the progressive web application 120.

[0056] In at least one example, when a customer 110 accesses a menu of items in connection with scanning or otherwise reading an identification code (e.g., identification code 116) associated with the designated seating area and / or physical store of the merchant 102, the input may be associated with a display of the designated seating area and / or physical store of the merchant 102. In some examples, such information may be used by the merchant 102 (or an employee, agent, etc. associated therewith) to determine how to fulfill an order for the items (e.g., where to deliver the items). In some examples, such information may be used by the merchant 102 (or an employee, agent, etc. associated therewith) to determine how to fulfill an order for the items (e.g., where to deliver the items). In some examples, such orders may be provided by the server 106 to the merchant computing device 104 (e.g., an application associated therewith), a kitchen display system of the merchant 102, and / or another computing device of the merchant 102 (e.g., a front-of-house and / or back-of-house computing system). In some examples, an order may be added to a queue with one or more other orders (i.e., "order queues") that may be received via the same commerce channel and / or additional or alternative commerce channels (e.g., online or in-store). That is, in some examples, a queue may be associated with orders received from other progressive web applications, online stores, applications associated with the merchant computing device (e.g., in-store orders), etc., and may be consolidated into a single queue of orders to be fulfilled by the merchant 102.

[0057] In at least one example, at a third time, subsequent to the first and second times, the customer 110 and / or merchant 102 can close the open ticket and / or provide instructions for processing the transaction via payment. In such an example, the progressive web application 120 can cause a payment user interface to be presented via GUI 200, as shown in FIG. 2C . In some examples, the payment user interface may be presented via GUI 200 instead of a menu of items, as described above. In some examples, the payment user interface may be presented via a pop-up, overlay, or the like. In at least one example, the customer 110 can interact with GUI 200 to provide payment data. For example, the customer 110 can select a selectable control 204 to provide such payment data. In some examples, the customer 110 can provide payment data via a secure portal (e.g., via manual entry), which may be presented in response to selecting the selectable control 204. In such an example, the payment data can be securely transmitted to the server 106 for payment processing. In some examples, the customer computing device 118 can include a reader device (e.g., a near field communication (NFC) reader), and the customer 110 can initiate an interaction between the payment instrument and the customer computing device 118 such that the customer computing device 118 (e.g., via the reader device) can obtain payment data from the payment instrument (e.g., the reader device). In some examples, the customer 110 can access stored payment data (e.g., stored in a wallet application associated with the customer computing device 118), which can be provided to the server 106. In some examples, the customer 110 can utilize a third-party payment mechanism (e.g., Apple Pay, Google Pay, etc.) to provide payment data to the server 106 for payment processing.

[0058] In some examples, during the payment flow (i.e., checkout), the customer 110 may choose to store their payment data in order to make a purchase and / or place an order. In such examples, the payment data may be stored locally by the progressive web application 120 and / or the server 106.

[0059] In some examples, the customer 110 may provide payment data to the merchant 102 via the merchant computing device 104. For example, the customer 110 may initiate an interaction between a payment instrument and a reader device associated with the merchant computing device 104. In such examples, the merchant computing device 104 may transmit the payment data to the server 106 for payment processing. In some examples, the customer 110 may store payment data with the merchant 102 and / or a service provider. In such examples, the customer 110 may provide an ID to identify itself, and the server 106 may access stored payment data corresponding to the ID. Such a transaction may be referred to as a “card-on-file” transaction.

[0060] Although described above as being associated with a third time after the first and second times, the payment data may be obtained by the server 106 at any time. For example, the server(s) 106 may receive the payment data at various times, such as before the customer 110 arrives at the merchant's 102's physical store, when the customer 110 orders a first item (i.e., at a first time), after the customer 110 orders the first item, when the customer 110 orders a second item (i.e., at a second time), after the customer 110 orders the second item, after the customer 110 leaves the merchant's 102's physical store, etc.

[0061] FIG. 2D illustrates an example of a tip and / or feedback user interface that may be presented via GUI 200. In at least one example, at a fourth time, subsequent to the first, second, and third times, the progressive web application 120 may cause the tip and / or feedback user interface to be presented via GUI 200 as shown in FIG. 2D. In some examples, the tip and / or feedback user interface may be presented via GUI 200 in place of a menu of items, a payment user interface, etc., as described above. In some examples, the tip and / or feedback user interface may be presented via a pop-up, an overlay, etc. In at least one example, the tip and / or feedback user interface may include one or more selectable controls 206 (e.g., tip), 208 (e.g., feedback) that, when selected, enable the customer 110 to provide a tip and / or feedback associated with the transaction. In some examples, based at least in part on detecting a selection of one of the selectable controls 206, 208, the progressive web application 120 may send an indication of the selection to the server 106. The server 106 may cause additional or alternative user interfaces, pop-ups, overlays, etc. to be presented to allow the customer 110 to provide tips and / or feedback.

[0062] 3A-3C illustrate an exemplary GUI 300 that may be presented in association with a progressive web application 120 on a customer computing device 118. In at least one example, after the progressive web application 120 is downloaded to the customer computing device 118, the customer 110 can continue to interact with the progressive web application 120 via the GUI 300 as long as the web browser associated with the progressive web application 120 remains open. As described above, in some examples, content presented via the GUI 300 may be updated while the web browser associated with the progressive web application 120 remains open, so that the content is current and does not need to be re-cached. For example, updates to inventory and / or items available via a menu can be updated via the progressive web application 120. In some examples, notifications and / or other content may be pushed from the merchant computing device 104 and / or the server 106 to the customer computing device 118 as long as the web browser associated with the progressive web application 120 remains open. As an example, recommendations and / or notifications may be pushed to the customer computing device 118 as long as the web browser remains open.

[0063] In at least one example, a progressive web application 120, which may use an application shell model, may be accessed via a web browser and / or shortcut icon that may be installed on a home screen of a customer computing device 118. That is, in at least one example, a customer 110 may choose to save and / or otherwise install the progressive web application 120 to a home screen of the customer computing device 118 (e.g., which may be an option associated with a web browser), and a shortcut icon may be associated therewith. Subsequent interaction with the shortcut icon may cause the web browser to load the same URL associated with the progressive web application 120. As shown in FIG. 3A , the home screen of the customer computing device 118 may include one or more user interface elements 302 representing different applications (e.g., native applications, web applications, progressive web applications, etc.). In at least one example, one or more of the user interface elements 302 may be shortcut icons that, when activated, allow the customer 110 to access the corresponding application. In at least one example, if the merchant 102 is "Merchant A," as shown in FIG. 3A, the customer 110 can interact with a shortcut icon associated with the progressive web application 120 to access merchant data associated with the aforementioned merchant 102. That is, by detecting the activation of a user interface element associated with "Merchant A," the web browser can load a URL associated with the progressive web application 120, thereby allowing the customer 110 to access content associated therewith.

[0064] In at least one example, the progressive web application 120 may cause merchant data to be presented via a web browser on the customer computing device 118, as shown in FIG. 3B. For example, the progressive web application 120 may cause a layout of the merchant's 102 physical store to be presented. In one example, the customer 110 may interact with a designated seating area depicted in the layout, for example, to make a reservation for the designated seating area. In such an example, a separate GUI, pop-up, overlay, etc. may be presented to allow the customer 110 to enter details related to the reservation, such as date, time, number of guests, etc.

[0065] In at least one example, so long as the web browser associated with the progressive web application 120 remains open, the customer 110 can access the same or different merchant data at a later time, as shown in Figure 3C. For example, when the customer 110 arrives at the merchant's 102 brick-and-mortar store at their appointment time, the customer 110 can interact with the customer computing device 118 to access a list of items (e.g., a menu) via the GUI 300. In at least one example, the customer 110 can interact with the GUI 300 to order the items, as described above.

[0066] 4-6 illustrate exemplary GUIs that may be presented via a user interface of a merchant computing device 104. In some examples, the user interface may be utilized via an application (e.g., which may be provided by a service provider). In some examples, the user interface may be utilized via a web browser. The exemplary GUIs are for illustrative purposes and should not be construed as limiting. For example, the techniques described herein may present additional or alternative content via the GUI and / or additional or alternative configurations of content via the GUI. In some examples, content may be presented via additional or alternative user interfaces (e.g., speakers, etc.).

[0067] In at least one example, the merchant 102 (or an employee, agent, etc. associated therewith) can interact with the merchant computing device 104 to manage the merchant 102's operations. In at least one example, the merchant computing device 104 can present a GUI 400, shown in FIG. 4 , that allows the merchant 102 to manage orders. As described above, in some examples, the merchant 102 can receive orders from one or more customers via one or more commerce channels. In some examples, the merchant 102 can receive orders from the merchant's 102's online store, a progressive web application associated with the merchant 102, input via the GUI 400, etc. In some examples, an application associated with the merchant computing device 104 (which may be provided, for example, by a service provider) allows the merchant 102 to manage orders. In at least one example, the GUI 400 can present an order queue 402 that includes orders from one or more commerce channels. In some examples, the order queue 402 may indicate which commerce channel each order is associated with, the location associated with the order (which in some examples may be provided by an identification code), the fulfillment method associated with the order, the approximate time until the order will be ready, etc.

[0068] In some examples, the GUI 400 may include one or more selectable controls to enable the merchant 102 to access other functionality available through applications installed thereon. For example, the GUI 400 may include a first control 404 that may be activated to enable the merchant 102 to create a new order, a second control 406 that may be activated to enable the merchant 102 to view completed orders, a third control 408 that may be activated to enable the merchant 102 to manage reservations, a fourth control 410 that may be activated to enable the merchant 102 to manage identities, etc. In some examples, activation of one of the controls may cause the application to send an instruction to the server 106, which may cause additional or alternative data to be presented via the GUI 400 to facilitate the requested action.

[0069] 5 illustrates an example of a GUI 500 that may be presented to enable a merchant 102 to manage open tickets. As described above, in some examples, when a customer 110 orders an item, a representation of the item may be associated with a data structure that may be at least temporarily stored by the server 106. Additional items may be added to the order over time, and the data structure may persist until the customer 110 and / or merchant 102 provides instructions to close the open ticket and / or until an event occurs (e.g., the passage of time, a threshold being met, etc.) that causes the open ticket to be automatically closed.

[0070] The merchant 102 can access the GUI 500 to view open tickets. In some examples, a portion of the GUI 500 can include user interface elements 502 that represent individual open tickets. In some examples, each user interface element can correspond to an individual open ticket and can be selectable, such that data related to the open ticket can be presented via the GUI 500 when a user interface element associated with the open ticket is selected. In some examples, the merchant 102 can add items to the open ticket by selecting its associated user interface element. Additionally, in some examples, the merchant 102 can select an individual user interface element to initiate a payment flow or otherwise process the associated payment.

[0071] In some examples, the GUI 500 may include one or more selectable controls to enable the merchant 102 to access other functionality available through the application installed thereon. For example, the GUI 500 may include a first control 504 that may be activated to enable the merchant 102 to return to an order user interface, a second control 506 that may be activated to enable the merchant 102 to manage reservations, a third control 508 that may be activated to enable the merchant 102 to manage IDs, etc. In some examples, activation of one of the controls may cause the application to send an indication of activation to the server 106, which may cause additional or alternative data to be presented via the GUI 500 to facilitate the requested action.

[0072] FIG. 6 illustrates an example of a GUI 600 that may be presented to enable the merchant 102 to manage IDs. As described above, the merchant 102 can interact with the merchant computing device 104 to generate an identification code or otherwise associate an identification of a designated seating area and / or physical store with an identification code. In one example, a graphical representation 602 of the layout of the merchant's 102's physical store may be presented via the user interface 600. In some examples, the merchant 102 can interact with the GUI 600 to identify a designated seating area (e.g., a table, bar stool, etc.) associated with the physical store. In at least one example, by selecting a designated seating area, the ID associated with the designated seating area (i.e., table ID) and, in some examples, the physical store (i.e., store ID) may be stored in a section 604 of the GUI 600, enabling the merchant 102 to generate an identification code (ID code) for the designated seating area. In some examples, the merchant 102 can manually enter identification information associated with the designated seating area and / or physical store via section 604 of the GUI 600. In at least one example, once the identification information is entered, the merchant 102 can activate the first control 606 to generate an identification code. In one example, the application can send instructions for activating the first control 606 to a server 106 that can generate the identification code. That is, the server 106 can generate an identification code that is unique to the provided ID. In some examples, the merchant computing device 104 can generate an identification code that is unique to the ID without a relationship with the server 106. The identification code can be associated with the ID in a data store, for example, as described below.

[0073] In some examples, the merchant computing device 104 may receive the identification code and print the identification code, so that the identification code may be associated with the designated seating area and / or the physical store (e.g., as shown in FIG. 1). In some examples, the identification code may be printed on a piece of paper, a sticker, a magnet, a placard, or other physical item to be located in proximity to the designated seating area and / or the physical store. In some examples, the identification code may be made available via an electronic device located in proximity to the designated seating area and / or the physical store.

[0074] In some examples, the identification code may be associated with an identification device, such as an RFID device. In such examples, the server 106 and / or the merchant computing device 104 may not generate the identification code but instead associate the identity of the designated seating area and / or the physical store with the identification code associated with the identification device. In such examples, the identification device may be located in proximity to the designated seating area and / or the physical store.

[0075] As described above, in some examples, in response to scanning or otherwise reading an identification code at a physical location with which the customer computing device 118 is associated, the server 106 may cause the progressive web application 120 to be downloaded onto the customer computing device 118. In some examples, in response to scanning or otherwise reading an identification code at a physical location with which the customer computing device 118 is associated, the server 106 may transmit merchant data to the customer computing device 118. In some examples, the merchant may include a menu of items such that an order page is presented (by the progressive web application 120) via a web browser on the customer computing device 118. In some examples, the merchant data may include a layout of a physical store such that a reservation page is presented (by the progressive web application 120) via a web browser on the customer computing device 118. In such an example, the customer computing device 118 may, in response to scanning or otherwise reading an identification code at a physical location with which it is associated, cause the server 106 to render an order page, reservation page, etc. on the customer computing device 118 (e.g., via the progressive web application 120).

[0076] In some examples, the service provider may leverage merchant data associated with the merchant 102 to prompt the merchant 102 to generate a new identification code and / or to automatically generate a new identification code for the merchant 102. For example, if the merchant 102 adds a new designated seating area to the physical store, the server 106 may detect that the new designated seating area has been added and may prompt the merchant 102 to generate a new identification code for the new designated seating area and / or to automatically generate a new identification code for the merchant 102.

[0077] 4 and 5, GUI 600 may include one or more selectable controls to enable the merchant 102 to access other functionality available through applications installed thereon. For example, GUI 600 may include a second control 608 that can be activated to enable the merchant 102 to return to an order user interface, as described above in FIG. 4, a third control 610 that can be activated to enable the merchant 102 to manage tickets, as described above in FIG. 5, a fourth control 612 that can be activated to enable the merchant 102 to manage reservations, etc. In some examples, activation of one of the controls may cause the application to send an instruction to actuate to the server 106, which may cause additional or alternative data to be presented via GUI 600 to facilitate the requested action.

[0078] 2-6 illustrate various GUIs that may be presented in connection with the techniques described herein. In at least one example, a user (e.g., a customer 110 and / or a merchant 102) can interact with the GUI to provide input that can be detected by its associated computing component and transmitted to the server 106 via the network 108. In some examples, a user can select, activate, or otherwise interact with user interface elements presented via the GUI. Such selection, activation, or other interaction may be provided via touch input, voice input, mouse input, keyboard control, etc. For purposes of this description, a user interface element may comprise a textual element, a graphical element, a picture, an icon, a selectable element, or any other object that may be presented via a GUI.

[0079] 7-11 are flowcharts illustrating exemplary processes that include the techniques described herein. The processes illustrated in FIGS. 7-11 are described with reference to FIG. 1 for convenience and ease of understanding. FIGS. 12 and 13 provide additional details related to the components of FIG. 1 described above. The processes illustrated in FIGS. 7-11 are not limited to being performed using the components illustrated in FIG. 1, and these components are not limited to performing the processes illustrated in FIGS. 7-11.

[0080] Processes 700-1100 are illustrated as a collection of blocks in a logical flow graph, which represent sequences of operations that may be implemented in hardware, software, or a combination thereof. In a software context, the blocks represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by a processor, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as limiting, and any number of the described blocks may be combined in any order and / or in parallel to perform a process. In some embodiments, one or more blocks of a process may be omitted entirely. Additionally, processes 700-1100 may be combined, in whole or in part, with each other or with other processes.

[0081] FIG. 7 illustrates an example process 700 for receiving input via a progressive web application and performing an action based at least in part on the input, as described herein.

[0082] Block 702 depicts receiving identification information associated with a merchant. In at least one example, the server 106 may receive identification information associated with a merchant, such as the merchant 102. In at least one example, the identification information may identify a physical location (e.g., a designated seating area and / or a physical store) associated with the merchant 102. For example, individual tables, bar stools, etc. may be associated with the identification information. If the merchant 102 has multiple physical stores (i.e., in different locations), each of the physical stores may be associated with the identification information. In some examples, the merchant 102 may manually enter the identification information, for example, via a GUI such as the GUI shown in FIG. 6 above. In some examples, the server(s) 106 may receive information that a new designated seating area and / or physical store is associated with the merchant 102 and may determine the identification information without such information entered by the merchant 102.

[0083] Block 704 depicts associating an identification of a physical location associated with the merchant with the identification code. In at least one example, the server 106 may associate the identification of the physical location (e.g., the designated seating area and / or the physical store) with the identification code. In some examples, the identification code may be associated with an identification device, such as an RFID device. In such examples, the server 106 may associate the identification of the designated seating area and / or the physical store with the identification code associated with the identification device. In at least one example, the identification device may be located proximate to the designated seating area and / or the physical store.

[0084] In some examples, the server 106 can generate an identification code based at least in part on the identification information associated with the designated seating area and / or the physical store. In at least one example, the server 106 can generate an identification code unique to the identification information. In some examples, the identification code can be a QR code, a barcode, a string of characters and / or numbers, etc. In some examples, the server 106 can transmit the identification code to the merchant computing device 104. The merchant computing device 104 can receive the identification code and, in some examples, can print or cause to be printed the identification code so that it can be associated with the designated seating area and / or the physical store (e.g., as shown in FIG. 1 ). In some examples, the identification code can be printed on a piece of paper, a sticker, a magnet, a placard, or other physical item to be located in proximity to the designated seating area and / or the physical store. In some examples, the identification code can be made available via an electronic device located in proximity to the designated seating area and / or the physical store.

[0085] Block 706 depicts receiving an identification code from a customer's computing device. In at least one example, the customer 110 may operate the computing device (i.e., the customer computing device 118) to scan or otherwise read the identification code. In some examples, the customer computing device 118 may include a reader device capable of reading the identification code. In some examples, the identification code may be manually entered via a user interface presented on the customer computing device 118. In at least one example, the customer computing device 118 may transmit an indication of the identification code to the server 106 via the network 108. In at least one example, the server 106 may receive the identification code.

[0086] Block 708 depicts determining whether the computing device is associated with an open progressive web application. In at least one example, the server 106 may determine whether the computing device (e.g., the customer computing device 118) to which the identification code was sent has a web browser associated with the progressive web application open. In some examples, if the customer computing device 118 is associated with the open progressive web application, the indication of the identification code may be associated with a cookie, etc., previously provided by the server 106, indicating that the customer computing device 118 is associated with the open progressive web application. If the customer computing device 118 does not have a web browser associated with the progressive web application open (and thus the customer computing device 118 is not associated with the open progressive web application), the server 106 may cause the progressive web application to be downloaded onto the customer computing device 118, as depicted in operation 710. In some examples, a URL associated with the progressive web application 120 may be provided to the customer computing device 118 that may be activated by the customer 110, and / or the customer 110 may manually enter the URL into a web browser to download the progressive web application 120. Details related to progressive web applications are described above.

[0087] Block 712 depicts causing (by the progressive web application) the merchant data to be presented via a web browser of the computing device. In at least one example, based at least in part on determining that the customer computing device 118 has downloaded the progressive web application 120 and has its associated web browser open, the server 106 can transmit the merchant data to the progressive web application 120 for presentation via the web browser of the customer computing device 118. That is, in at least one example, the progressive web application 120 can cause the merchant data to be presented via the web browser of the customer computing device 118. In some examples, such merchant data can be a menu of items, a layout of the merchant's 102 physical store, etc.

[0088] As mentioned above, in some examples, customer information may be stored based on web browser / cookie session parameters, thereby allowing such customer information to remain attached. If the customer provides identification (e.g., customer ID, phone number, email address, etc.), payment data, etc., such information may be stored. In some examples, the customer may provide confirmation authentication using a code or other means for authentication. Thus, as long as the web browser remains open, content associated with the progressive web application 120 may be accessible to the customer 110. For example, the customer 110 may be able to view / use previously created presets (e.g., location, previous orders / reorders, account enrollment, address, payment, etc.) and / or continue to interact with content provided by the progressive web application 120.

[0089] Block 714 illustrates receiving input via the progressive web application. In at least one example, the customer 110 can interact with the customer computing device 118 (e.g., a user interface associated therewith) to provide input. The instructions may be transmitted to the server 106. As described above with reference to FIGS. 2A-2D and 3A-3E, in some examples, such input may be associated with ordering an item from a menu of items offered for sale by the merchant 102, reserving a designated seating area, tipping, feedback, etc. In at least one example, the server 106 can receive the input instructions, as shown in block 716, and can perform an action based on such input. For example, if the input is associated with ordering an item, the server 106 can associate the item with a data structure, which in some examples may be an open ticket data structure. In some examples, the server 106 can transmit the order instructions to the merchant computing device 104, a kitchen display system, etc. to enable the merchant 102 to fulfill the order. In another example, if the input is associated with a reservation, the server 106 can schedule the reservation. Additionally, if the input is associated with payment data, the server 106 may process the payment using the payment data. In at least one example, if the input is feedback, the feedback may be stored in a data store associated with the server 106 and, in some examples, may be provided to the merchant 102 via the merchant computing device 104.

[0090] FIG. 8 shows an example process 800 for processing a payment associated with an open ticket, as described herein.

[0091] Block 802 depicts receiving an order associated with an item from a customer's computing device in association with an input to the progressive web application. As described above, the progressive web application 120 may cause merchant data to be presented via a web browser. In some examples, such merchant data may include a menu of items for sale by the merchant 102. FIGS. 2A and 2B above illustrate an exemplary GUI 200 including user interface elements 204 representing items offered for sale by the merchant 102. In at least one example, the customer 110 may interact with the customer computing device 118 to select an item to order. In such an example, the progressive web application 120 may detect the input indicating the selection and may send an indication of the selection to the server 106. The server 106 may receive the order or an indication thereof from the customer computing device 118. In at least one example, if the order is received via an order page presented in response to the customer 110 scanning or otherwise reading an identification code associated with a physical location (e.g., a designated seating area and / or a brick-and-mortar store), the order may be associated with the ID(s) associated with the physical location so that the merchant 102 knows where to deliver the items associated with the order.

[0092] Block 804 depicts determining whether the customer is associated with an existing open ticket data structure. In some examples, the server 106 may generate a data structure with which item instructions can be associated. In some examples, the data structure may represent an order or a ticket. In some examples, the data structure may be stored at least temporarily so that instructions for one or more additional items may be added to the data structure over time. In such examples, the data structure may represent an “open ticket,” which may persist until the customer 110 and / or the merchant 102 provide instructions to close the open ticket and / or until an event occurs (e.g., time passes, a threshold is met, etc.) that causes the open ticket to be automatically closed.

[0093] In at least one example, the server 106 can determine whether the customer is associated with an existing open ticket data structure. In some examples, the order or an instruction therefor may be associated with an ID associated with the customer computing device 118, the customer 110, the customer's 110's physical location (e.g., table number, table identifier, etc.), and / or the like. In at least one example, the server 106 can determine whether the identifier is associated with an existing open ticket data structure. If the customer 110 is not associated with an existing open ticket data structure, the server 106 can generate a new open ticket data structure and associate the item with the new open ticket data structure, as shown in block 806. The new open ticket data structure can persist until the customer 110 and / or merchant 102 provide instructions to close the open ticket and / or until an event occurs that causes the open ticket to be automatically closed (e.g., a period of time has elapsed, a threshold has been met, etc.). In some examples, the server 106 may request or otherwise access payment data from the customer 110, and the server 106 may send an authorization request to authorize the payment data for at least a portion of the cost of items associated with the order.

[0094] If the customer 110 is associated with an existing open ticket data structure, the server 106 may associate the items with the existing open ticket data structure, as shown in block 808. In some examples, if the existing open ticket data structure is associated with payment data and / or an authorization request, in some examples, the server 106 may send another authorization request to approve the payment data for at least a portion of the cost of the items associated with the order. In some examples, if the existing open ticket data structure is not associated with payment data, the server 106 may request or otherwise access payment data from the customer 110, and the server 106 may send an authorization request to approve the payment data for at least a portion of the cost of the items associated with the order.

[0095] Block 810 depicts determining whether a request to complete the transaction has been received. As described above, the open ticket data structure may persist until the customer 110 and / or merchant 102 provides instructions to close the open ticket and / or until an event occurs that causes the open ticket to be automatically closed (e.g., time has passed, a threshold has been met, etc.). In at least one example, the server 106 may determine whether an instruction to close the open ticket has been received from either the customer computing device 118 or the merchant computing device 104. If no request is received, the server 106 may store the open ticket data structure until a request to complete the transaction is received and / or until an event occurs (e.g., time has passed, a threshold has been met, etc.), as depicted in block 812.

[0096] Block 814 indicates requesting payment data to process payment for the total of items associated with the open ticket data structure. In at least one example, when a request to complete a transaction is received, the server 106 can determine the total cost of the transaction associated with the open ticket data structure (e.g., the total cost of the items associated with the open ticket) and can send a request for payment data to the customer computing device 118 (e.g., via the progressive web application 120) and / or to the merchant computing device 104 (e.g., via an application, via a web browser, etc.).

[0097] In at least one example, as described above with reference to FIG. 2C , the progressive web application 120 may cause a payment user interface to be presented via a GUI 200. In at least one example, the customer 110 may interact with the GUI 200 to provide payment data. For example, the customer 110 may select a selectable control 204 to provide such payment data. In some examples, the customer 110 may provide payment data via a secure portal (e.g., via manual entry), which may be presented in response to selecting the selectable control 204. In such examples, the payment data may be securely transmitted to the server 106 for payment processing. In some examples, the customer computing device 118 may include a reader device (e.g., a near-field communication (NFC) reader), and the customer 110 may initiate an interaction between the payment instrument and the customer computing device 118 such that the customer computing device 118 can obtain payment data from the payment instrument. In some examples, the customer 110 may access stored payment data (e.g., stored in a wallet associated with the customer computing device 118), which may be provided to the server 106. In some examples, the customer 110 may utilize a third-party payment mechanism (e.g., Apple Pay, Google Pay, etc.) to provide payment data to the server 106 for payment processing.

[0098] In some examples, the customer 110 may provide payment data to the merchant 102 via the merchant computing device 104. For example, the customer 110 may initiate an interaction between a payment instrument and a reader device associated with the merchant computing device 104. In such examples, the merchant computing device 104 may transmit the payment data to the server 106 for payment processing. In some examples, the customer 110 may store payment data with the merchant 102 and / or a service provider. In such examples, the customer 110 may provide an identifier to identify itself, and the server 106 may access stored payment data corresponding to the identifier. This may be referred to as a "card-on-file" transaction.

[0099] The server 106 can receive the payment data and can process payment for the transaction using the payment data. In at least one example, the server 106 can send an authorization and / or capture request to a payment service associated with the payment data to determine whether the payment data (e.g., a payment instrument associated therewith) is authorized for the transaction. Additional details related to payment processing are described below.

[0100] 8 illustrates payment data requested after a request to complete a transaction is received, but as noted above, the server 106 may receive payment data at various times, such as before the customer 110 arrives at the merchant's 102's physical store, when the customer 110 orders the item, after the customer 110 orders the item, after the customer 110 leaves the merchant's 102's physical store, etc. Additionally, open tickets may be associated with orders received from the customer computing device 118 and / or the merchant computing device 104. That is, when a new order is received, the server 106 may associate the new order with an existing open ticket if the new order is associated with a customer identifier, a customer device identifier, a physical location associated with the merchant 102, etc., associated with the existing open ticket.

[0101] FIG. 9 illustrates an example process 900 for generating an order queue based at least in part on orders received via different commerce channels.

[0102] Block 902 illustrates receiving a first order associated with a first item from a customer's computing device in association with input to the progressive web application. As described above, the progressive web application 120 can cause merchant data to be presented via a web browser. In some examples, such merchant data can include a menu of items for sale by the merchant 102. FIGS. 2A and 2B above illustrate an exemplary GUI 200 including user interface elements 204 representing items offered for sale by the merchant 102. In at least one example, the customer 110 can interact with the customer computing device 118 to select an item to order. In such an example, the progressive web application 120 can detect the input indicating the selection and can transmit an indication of the selection to the server 106. The server 106 can receive the order or an indication thereof from the customer computing device 118.

[0103] Block 904 indicates associating the first order with an order queue. In at least one example, the server 106 may add the first order to a queue (e.g., an “order queue”) with one or more other orders that may be received via the same commerce channel (e.g., via the progressive web application 120 on the customer computing device 128) and / or via additional and / or alternative commerce channels (e.g., online or in-store). That is, in some examples, queues may be associated with orders received from a progressive web application, an online store, an application associated with a merchant computing device, etc., and may be consolidated into a single queue of orders fulfilled by the merchant 102. Non-limiting examples of order queues are described above with reference to FIG. 4.

[0104] Block 906 depicts receiving a second order associated with the second item. In at least one example, the server 106 can receive the second order. In some examples, the second order can be from a customer computing device 118 (e.g., via the progressive web application 120). In some examples, the second order can be from a different customer, a different commerce channel, etc. In at least one example, the second order can be associated with a different fulfillment method than the first order. In at least one example, the server 106 can associate the second order with an order queue.

[0105] Block 910 illustrates causing at least a portion of the order queue to be presented via a customer computing device or a merchant computing device. In at least one example, the server 106 may cause at least a portion of the order queue to be presented via a customer computing device 118 or a merchant computing device 104. For example, the portion of the order queue may be presented to the customer 110 to inform the customer 110 where their order is in the queue, the expected time before their order will be fulfilled, etc. In at least one example, the portion of the order queue may be presented to the merchant 102 to enable the merchant 102 to track orders, manage orders, or otherwise understand which orders are being prepared, which orders have been fulfilled, etc. In some examples, the portion of the order queue may be presented via a kitchen display system, a front-of-house computing device, a back-of-house computing device, etc. In at least one example, if the order is received via an order page presented in response to the customer 110 scanning or otherwise reading an identification code associated with a physical location (e.g., a designated seating area and / or a brick-and-mortar store), the order may be associated with the identification(s) associated with the physical location so that the merchant 102 knows where to deliver the items associated with the order.

[0106] FIG. 10 illustrates an exemplary process 1000 for outputting merchant data, such as an online menu, by a progressive web application and via a customer's web browser, where the merchant data and / or its presentation may be modified based at least in part on data associated with the customer, as described herein.

[0107] Block 1002 depicts receiving an input indication to the progressive web application from a customer's computing device. As described above, the customer 110 can interact with a user interface of the customer computing device 118 to provide input that can be detected by the progressive web application 120. In at least one example, the input indication can be sent by the progressive web application 120 to the server 106. In some examples, the indication can be associated with an identifier of the customer 110 (e.g., a customer identifier, a phone number, an email address, etc.), the customer computing device 118, etc. In some examples, the indication can be associated with a cookie previously provided by the server 106. That is, customer information can be saved based on web browser / cookie session parameters, thereby keeping customer information (e.g., identification information, payment information, etc.) attached. The server 106 can receive the input indication from the customer computing device 118.

[0108] Block 1004 depicts determining whether the customer is associated with a customer profile. In at least one example, the server 106 can receive an indication of an input associated with an identifier, cookie, etc., and can determine whether the identifier, cookie, etc. is associated with the customer profile. That is, the server 106 can access a customer profile data store to determine whether the identifier, cookie, etc. is associated with the customer profile. If the identifier, cookie, etc. is not associated with the customer profile, the server 106 can cause an online menu to be presented via the customer computing device 118, as shown in block 1006. That is, if the identifier, cookie, etc. is not associated with the customer profile, the server 106 can cause a default or standard online menu to be presented via the customer computing device 118.

[0109] Block 1008 depicts accessing customer data associated with the customer profile. In at least one example, if an identifier, cookie, etc. is associated with the customer profile, server 106 may access data associated with the customer profile (i.e., customer data). Additional details related to the customer profile and / or customer data are described below.

[0110] Block 1010 depicts accessing data related to an online menu. In at least one example, data associated with the online menu may be stored in a data store. For example, inventory may indicate which items offered for sale by the merchant 102 should be presented via the online menu. That is, such items may be associated with indicators, etc., so that when an online menu is requested, the server 106 can access such data to generate the online menu for presentation. In at least one example, the server 106 can access data associated with the online menu.

[0111] Block 1012 indicates generating a customized online menu based at least in part on the customer data and data associated with the online menu. In at least one example, the server 106 can generate a customized online menu for the customer based at least in part on the customer data. That is, if the customer data indicates that the customer does not like fish (e.g., previous transactions indicate that the customer 110 has not purchased fish, explicitly indicating that the customer 110 does not like fish, etc.), the server 106 can omit offering fish from the online menu. Or, if the customer data indicates that the customer 110 generally spends within a price range, the server 106 can include items within the price range and exclude items outside the price range. In some examples, the ordering of items presented via the menu can be determined at least in part on the customer data, the configuration of the online menu can be determined at least in part on the customer data, etc.

[0112] Block 1014 illustrates causing the customized online menu to be presented via the customer's computing device. In at least one example, the server 106 can transmit the customized online menu to the customer computing device 118 so that the online menu can be presented via a web browser associated with the customer computing device 118 (e.g., by the progressive web application 120).

[0113] 10 references a menu, similar techniques may be implemented in some examples to customize other types of data provided to the customer computing device 118. Additionally, by determining the identity of the customer 110, the server 106 may provide personalized recommendations to the customer 110 (e.g., based at least in part on merchant data, etc.), may present recommendations specific to the customer 110 to the merchant 102, may send marketing to the customer 110 via the progressive web application 120, etc.

[0114] FIG. 11 shows an example process 1100 for modifying a menu presented via a first commerce channel for presentation on a second commerce channel, as described herein.

[0115] Block 1102 illustrates storing data related to a merchant's menu to be presented via a first commerce channel. In at least one example, data related to a menu of items offered for sale by the merchant 102 may be stored in a data store. In at least one example, individual items may be associated with an indicator indicating the commerce channel(s) through which such items should be offered. In one example, inventory may indicate which items offered for sale by the merchant 102 should be presented via an online menu. That is, such items may be associated with an indicator, etc., so that when an online menu is requested, the server 106 can access such data to generate the online menu for presentation. In one example, the inventory may indicate which items are not available online and are only available in a brick-and-mortar store. In some examples, the menu may include fulfillment options (e.g., pickup, shipping, delivery, etc.). In at least one example, the server 106 may access data associated with a menu of items associated with an indicator indicating availability via the first commerce channel. In at least one example, the first commerce channel can be an e-commerce channel in which each of the items is associated with a different fulfillment option (e.g., pickup, shipping, delivery, etc.).

[0116] Block 1104 illustrates receiving a request to access a menu from a customer's computing device. In at least one example, the customer 110 can interact with a user interface of the customer computing device 118 to provide input that can be detected by functional components of the customer computing device 118. In some examples, the input may be received through an interface associated with a first commerce channel (e.g., an e-commerce user interface). In some examples, the input may be received through the progressive web application 120 or another source that indicates the request is associated with a different commerce channel (e.g., in-store).

[0117] Block 1106 depicts determining whether the request is associated with a first commerce channel. In at least one example, the server 106 may determine the origin of the request. That is, the server 106 may determine whether the request was sent from an e-commerce user interface (e.g., associated with the first commerce channel), a progressive web application 120 (e.g., associated with a different commerce channel), etc. In at least one example, as shown in block 1108, if the request is received from the first commerce channel, the server 106 may access a menu associated with the first commerce channel and cause the menu to be presented via the customer computing device 118. That is, if the request is received from the e-commerce channel, the server 106 may access (e.g., via the e-commerce user interface) an online menu associated with the e-commerce channel for presentation by the customer computing device 118.

[0118] Block 1110 depicts modifying the menu for the second commerce channel. In at least one example, if the request is submitted from a source such as the progressive web application 120, in association with an indication that the request is associated with a designated seating area and / or a brick-and-mortar store, the server 106 can modify the online menu so that it is tailored to the dine-in experience. That is, fulfillment information, etc., may not be relevant to the dine-in customer, and thus the server 106 can remove such information from the menu that would be presented via the first commerce channel. This can result in a simpler menu that can download faster and can provide a better user experience for the customer 110 (e.g., because the customer 110 is in the brick-and-mortar store, there is no need to provide options for fulfillment, brick-and-mortar store location, etc.). The server 106 can then cause the modified menu to be presented via the customer computing device 118, e.g., via the progressive web application 120 or via another user interface, as shown in block 1112.

[0119] 12 illustrates an example environment 1200. The environment 1200 includes a server 1202 that can communicate with user devices 1206 (which in some examples may be merchant devices 1208 (individually, 1208(A)-1208(N)) and / or a server 1210 associated with a third-party service provider) via a network 1204. The server 1202 may be associated with a service provider 1212 that can provide one or more services for the benefit of a user 1214, as described below. Actions attributed to the service provider 1212 can be executed by the server 1202.

[0120] In at least one example, server 1202 may correspond to server 106 in Figure 1, network 1204 may correspond to network 108 in Figure 1, user device 1206 may correspond to merchant computing device 104 and / or customer computing device 118, and user 1214 may correspond to merchant 102 and / or customer 110 in Figure 1. Merchant computing device 104 in Figure 1 may correspond to one of merchant devices 1208(A)-1208(N).

[0121] As mentioned above, the techniques described herein are directed, among other things, to customer device application sites accessible via merchant-managed identifiers. Environment 1200 can facilitate such techniques. As mentioned above, brick-and-mortar transactions can be high-friction transactions, such that customers and merchants may be required to interact with each other and other physical items (e.g., menus, writing implements, payment terminals, etc.) to effectuate such transactions. As mentioned above, brick-and-mortar transactions can be high-friction transactions, such that customers and merchants may be required to interact with each other and other physical items (e.g., menus, writing implements, payment terminals, etc.) to effectuate such transactions. There are scenarios in which customers and / or merchants may facilitate transactions and / or minimize friction associated with such transactions. Existing techniques (e.g., native applications, web applications, etc.) are not user-friendly and / or accessible to small merchants due to development complexity and cost.

[0122] As described above, the service provider 1212 can enable merchants to offer progressive web applications to streamline transactions at brick-and-mortar stores. Progressive web applications provide solutions to the problems identified above with native and / or web applications. For example, progressive web applications use resources from modern web browsers to present an experience similar to that of native applications. Progressive web applications can offer more functionality and function much faster than web applications. Furthermore, progressive web applications can be portable across different types of platforms (e.g., desktop, mobile, etc.) and, in some examples, can adapt to various display sizes (e.g., desktop, mobile, tablet, etc. computing devices), thereby making the progressive web application accessible and user-friendly. That is, progressive web applications can be responsive in that they can adapt to different form factors and / or screen sizes. Progressive web applications can be more user-friendly than native and / or web applications. For example, a progressive web application may be accessible when the internet connection is poor and / or when the computing device is offline, when it is up to date (e.g., when updates to the content may be performed in the background), etc.

[0123] Progressive web applications can provide security by utilizing the HTTPS protocol to protect the privacy and integrity of data associated with the progressive web application. Progressive web applications can be "progressive" in that they can function for a variety of users regardless of which web browser is being used. Furthermore, progressive web applications that can use an application shell model provide a user experience similar to that of native applications. That is, customers can access the progressive web application via a shortcut icon that can be installed on a web browser and / or the desktop or home screen of a computing device operable by such customers. In some instances, progressive web applications can use push notifications to maintain customer engagement. Furthermore, progressive web applications can be easily shared via a uniform resource locator (URL) and do not require complex installation.

[0124] Thus, the techniques described herein leverage progressive web applications to enable customers to have faster access to merchant data via technologies that provide an improved user experience over traditional alternatives, such as native and / or web applications. Such technologies can thus streamline transactions and other interactions between customers and merchants at such merchants' brick-and-mortar stores or other facilities.

[0125] The environment 1200 may include a plurality of user devices 1206, as described above. Each of the plurality of user devices 1206 may be any type of computing device, such as a tablet computing device, a smartphone or mobile communication device, a laptop, netbook or other portable or semi-portable computer, a desktop computing device, a terminal computing device or other semi-stationary or stationary computing device, a dedicated device, a wearable or other body-worn computing device, an augmented reality device, a virtual reality device, an Internet of Things (IoT) device, etc. In some examples, individual ones of the user devices may be operable by a user 1214. The user 1214 may be referred to as a customer, buyer, merchant, seller, borrower, employee, employer, payer, recipient, courier, etc. The user 1214 may interact with the user device 1206 via a user interface presented via the user device 1206. In at least one example, the user interface may be presented via a web browser or the like. In other examples, the user interface may be presented via an application, such as a mobile or desktop application, which may be provided by the service provider 1212 or may be another dedicated application. In some examples, each of the user devices 1206 may have an instance or versioned instance of an application, downloadable from, for example, an application store, that can present the user interface described herein. In at least one example, the user 1214 may interact with the user interface via touch input, voice input, or any other type of input.

[0126] As mentioned above, in at least one example, the user 1214 can include merchants 1216 (individually, 1216(A) through 1216(N)). In one example, the merchants 1216 can operate respective merchant devices 1208, which can be user devices 1206 configured for use by the merchant 1216. For purposes of this discussion, a “merchant” can be any entity that offers items (e.g., goods or services) for purchase or other means of acquisition (e.g., rent, borrow, negotiate, etc.). The merchants 1216 can offer items for purchase or other means of acquisition via a brick-and-mortar store, a mobile store (e.g., pop-up store, food truck, etc.), an online store, a combination of the foregoing, etc. In some examples, at least some of the merchants 1216 can be associated with the same entity but can have different merchant locations and / or can have franchise / franchisee relationships. In additional or alternative examples, the merchants 1216 can be different merchants. That is, in at least one example, merchant 1216(A) is a different merchant than merchant 1216(B) and / or merchant 1216(C).

[0127] For purposes of this description, "different merchants" can refer to two or more unrelated merchants. Thus, "different merchants" can refer to two or more merchants that are different legal entities (e.g., natural and / or corporate persons) that do not share accounting, employees, branding, etc. As used herein, "different merchants" have different names, employer identification numbers (EINs), lines of business (in some instances), inventory (or at least a portion thereof), etc. Thus, use of the term "different merchants" does not refer to merchants with different merchant locations or franchise / franchisee relationships. Such merchants with different merchant locations or franchise / franchisee relationships can be referred to as merchants with different merchant locations and / or different commerce channels.

[0128] Each merchant device 1208 may have an instance of a POS application 1218 stored thereon. The POS application 1218 may configure the merchant device 1208 as a POS terminal, allowing a merchant 1216(A) to interact with one or more customers 1220. As described above, the user 1214 may include a customer, such as customer 1220 shown interacting with merchant 1216(A). For purposes of this discussion, a "customer" may be any entity that obtains items from a merchant. While only two customers 1220 are shown in FIG. 12, any number of customers 1220 may interact with the merchant 1216. Additionally, although FIG. 12 shows customer 1220 interacting with merchant 1216(A), the customer 1220 may interact with any of the merchants 1216.

[0129] An interaction between the customer 1220 and the merchant 1216, which in at least one example involves the exchange of funds (from the customer 1220) for items (from the merchant 1216), may be referred to as a "transaction." In at least one example, the POS application 1218 may determine transaction data associated with the transaction. The transaction data may include payment information, user authentication data, purchase amount information, point-of-purchase information (e.g., items purchased, purchase date, purchase time, etc.), which may be obtained from a reader device 1222 associated with the merchant device 1208(A). The POS application 1218 may transmit the transaction data to the server 1202. Additionally, the POS application 1218 may present a UI to enable the merchant 1216(A) to interact with the POS application 1218 and / or the service provider 1212 via the POS application 1218.

[0130] In at least one example, the merchant device 1208(A) may be a dedicated computing device configured as a POS terminal (via execution of the POS application 1218). In at least one example, the POS terminal may be connected to a reader device 1222 capable of accepting various payment instruments, such as credit cards, debit cards, gift cards, near-field communication-based payment instruments, etc., as described below. In at least one example, the reader device 1222 may plug into a port within the merchant device 1208(A), such as a microphone port, headphone port, audio jack, data port, or other suitable port. In additional or alternative examples, the reader device 1222 may be coupled to the merchant device 1208(A) via another wired or wireless connection, such as via Bluetooth, BLE, etc. Additional details are described below with reference to FIG. 13. In some examples, the reader device 1222 may read information from alternative payment instruments, including, but not limited to, wristbands, etc.

[0131] In some examples, the reader device 1222 may physically interact with a payment instrument, such as a magnetic stripe payment card, an EMV payment card, and / or a near-field communication (e.g., near field communication (NFC), radio frequency identification (RFID), Bluetooth, Bluetooth low energy (BLE), etc.) payment instrument (e.g., a card or device configured for tapping). The POS terminal provides a rich user interface, communicates with the reader device 1222, and can communicate with the server 1202, which can provide payment processing services, among other services. The server 1202, associated with the service provider 1212, can communicate with the server 1210, as described below. In this manner, the POS terminal and the reader device 1222 can collectively process transactions between the merchant 1216 and the customer 1220. In some examples, the POS terminal and the reader device can be configured in a one-to-one pairing. In other examples, POS terminals and reader devices may be configured in a many-to-one pairing (e.g., one POS terminal coupled to multiple reader devices or multiple POS terminals coupled to one reader device). In some examples, there may be multiple POS terminals connected to several other devices, such as "secondary" terminals, e.g., back-of-the-house systems, printers, line buster devices, POS readers, etc., to allow information from the secondary terminals to be shared between the primary POS terminal and the secondary terminals, e.g., via near-field communications technology. This type of configuration may also allow one device (e.g., the secondary terminal) to continue accepting user input in an offline-online scenario and function to synchronize data with another device (e.g., the primary terminal) when the primary or secondary terminal switches to online mode. In other examples, such data synchronization may occur periodically or at randomly selected time intervals.

[0132] Although the POS terminal and reader device 1222 of POS system 1224 are shown as separate devices, in additional or alternative examples, the POS terminal and reader device 1222 may be part of a single device. In some examples, the reader device 1222 may have a display integrated therein for presenting information to the customer 1220. In additional or alternative examples, the POS terminal may have a display integrated therein for presenting information to the customer 1220. POS systems, such as POS system 1224, may be mobile, such that the POS terminal and reader device may process transactions in different locations around the world. POS systems may be used to process card-present and card-not-present (CNP) transactions, as described below.

[0133] A card-present transaction is one in which both the customer 1220 and their payment instrument are physically present at the time of the transaction. Card-present transactions may be processed by swiping, dipping, tapping, or any other interaction between a physical payment instrument (e.g., a card) or other present payment instrument and the reader device 1222, whereby the reader device 1222 can obtain payment data from the payment instrument. A swipe is a card-present transaction in which the customer 1220 slides a card or other payment instrument having a magnetic strip through the reader device 1222, which captures the payment data contained on the magnetic strip. A dip is a card-present transaction in which the customer 1220 first inserts a payment instrument having an embedded microchip (i.e., chip) into the reader device 1222. A dipped payment instrument remains in the payment reader until the reader device 1222 prompts the customer 1220 to remove the card or other payment instrument. While the payment instrument is within the reader device 1222, the microchip can create a one-time code that is sent from the POS system 1224 to the server 1210 (which may be associated with an acquirer bank, an issuer, and / or a third-party service provider offering payment services, including but not limited to a card payment network (e.g., Mastercard®, VISA®, etc.)) to be matched against an identical one-time code. A tap is a card-present transaction in which a customer 1220 can tap or hover their payment instrument (e.g., a card, an electronic device such as a smartphone running a payment application) over the reader device 1222 to complete the transaction via short-range communication (e.g., NFC, RFID, Bluetooth®, BLE, etc.). The short-range communication allows the payment instrument to exchange information with the reader device 1222. A tap is sometimes referred to as a contactless payment.

[0134] A CNP transaction is one in which the card or other payment instrument is not physically present at the POS, and as a result, payment data must be manually keyed in (e.g., by the merchant, customer, etc.) or the payment data must be recalled from a card-on-file data store to complete the transaction.

[0135] POS system 1224, server 1202, and / or server 1210 can exchange payment information and transaction data to determine whether the transaction is authorized. For example, POS system 1224 can provide encrypted payment data, user authentication data, purchase amount information, point-of-purchase information, etc. (collectively, transaction data) to server 1202 over network 1204. Server 1202 can transmit the transaction data to server 1210. As mentioned above, in at least one example, server 1210 can be associated with a third-party service provider that provides payment services, including, but not limited to, an acquiring bank, an issuer, and / or a card payment network (e.g., Mastercard®, VISA®, etc.).

[0136] For purposes of this discussion, a "payment service provider" may be an acquiring bank ("acquirer"), an issuing bank ("issuer"), a card payment network, etc. In one example, an acquirer is a bank or financial institution that processes payments (e.g., credit or debit card payments) and can assume risk on behalf of the merchant. An acquirer may be a registered member of a card association (e.g., Visa®, MasterCard®) and may be part of a card payment network. The acquirer (e.g., its associated server 1210) can send a funds transfer request to a server computing device of the card payment network (e.g., Mastercard®, VISA®, etc.) to determine whether the transaction is authorized or delinquent. In at least one example, service provider 1212 may act as an acquirer and connect directly to the card payment network.

[0137] The card payment network (e.g., its associated server 1210) can forward the funds transfer request to an issuing bank (e.g., an “issuer”). An issuer is a bank or financial institution that provides a financial account (e.g., a credit or debit card account) to a user. The issuer can issue a payment card to a user and can pay an acquirer for purchases made by the cardholder to whom the issuing bank issued the payment card. The issuer (e.g., its associated server 1210) can make a determination as to whether the customer has the ability to incur associated fees associated with the payment transaction. In at least one example, the service provider 1212 can act as the issuer and / or partner with the issuer. The transaction is approved or denied by the issuer and / or the card payment network (e.g., its associated server 1210), and a payment authorization message is communicated from the issuer to the POS device via the reverse path described above or via an alternative path.

[0138] As described above, server 1210, which may be associated with a payment service provider, can determine whether a transaction is authorized based on the transaction data and information about the parties to the transaction (e.g., customer 1220 and / or merchant 1216(A)). Server 1210 can send an authorization notification over network 1204 to server 1202, which can send an authorization notification over network 1204 to POS system 1224 to indicate whether the transaction is authorized. Server 1202 can also send additional information, such as a transaction identifier, to POS system 1224. In one example, server 1202 can include merchant applications and / or other functional components for communicating with POS system 1224 and / or server 1210 to authorize or deny the transaction.

[0139] Based on the authorization notification received by the POS system 1224 from the server 1202, the merchant 1216(A) can indicate to the customer 1220 whether the transaction was approved. In some examples, the authorization may be indicated at the POS system 1224, such as on a display of the POS system 1224. In other examples, information regarding the approved transaction may be provided to a near-field communication payment device, such as a smartphone or watch operating as a near-field communication payment device, for presentation via the smartphone or watch display. In some examples, additional or alternative information may be further presented along with the approved transaction notification, including, but not limited to, a receipt, special offers, coupons, or loyalty program information.

[0140] As mentioned above, the service provider 1212 may offer, among other services, payment processing services, inventory management services, catalog management services, business banking services, financial services, lending services, reservation management services, web development services, payroll services, employee management services, reservation services, loyalty tracking services, restaurant management services, order management services, fulfillment services, peer-to-peer payment services, onboarding services, identity verification (IDV) services, etc. In some examples, the user 1214 may have access to all of the service provider's 1212 services. In other examples, the user 1214 may have tiered access to services that may be based on risk tolerance, IDV output, subscription, etc. In at least one example, access to such services may be available to the merchant 1216 via the POS application 1218. In additional or alternative examples, each service may be associated with its own access point (e.g., an application, a web browser, etc.).

[0141] The service provider 1212 may provide payment processing services to process payments on behalf of the merchant 1216, as described above. For example, the service provider 1212 may provide payment processing software, payment processing hardware, and / or payment processing services to the merchant 1216, as described above, to enable the merchant 1216 to receive payments from the customer 1220 when conducting a transaction with the customer 1220. For example, the service provider 1212 may enable the merchant 1216 to receive cash payments, payment card payments, and / or electronic payments from the customer 1220 for a transaction, and the service provider 1212 may process the transaction on behalf of the merchant 1216.

[0142] Because the service provider 1212 processes transactions on behalf of the merchant 1216, the service provider 1212 may maintain an account or balance for the merchant 1216 in one or more ledgers. For example, the service provider 1212 may analyze transaction data received for a transaction to determine the amount of funds to be paid to the merchant 1216(A) for the transaction. In at least one example, such amount may be the total purchase price less fees charged by the service provider 1212 for providing payment processing services. Based on determining the amount of funds to be paid to the merchant 1216(A), the service provider 1212 may deposit the funds into the merchant 1216(A)'s account. The account may have a stored balance, which may be managed by the service provider 1212. The account may differ from a traditional bank account at least because the stored balance is managed by the service provider's 1212 ledger and the associated funds are accessible via various withdrawal channels, including, but not limited to, scheduled deposits, same-day deposits, immediate deposits, and linked payment instruments.

[0143] A scheduled deposit can occur when the service provider 1212 transfers funds associated with the merchant's 1216(A) stored balance to the merchant's 1216(A) bank account held at a bank or other financial institution (e.g., associated with server 1210). The scheduled deposit can occur at a scheduled time after the transaction is funded, i.e., the business day after the transaction occurs, or earlier or later. In some examples, the merchant 1216(A) can access the funds before the scheduled deposit. For example, the merchant 1216(A) can access a same-day deposit (e.g., the service provider 1212 deposits funds from a stored balance to the merchant's linked bank account on the same day as the transaction, in some embodiments before the transaction is funded) or an immediate deposit (e.g., the service provider 1212 deposits funds from a stored balance to the merchant's linked bank account on demand, such as upon request). Additionally, in at least one example, the merchant 1216(A) may have a payment instrument linked to the stored balance that allows the merchant to access funds without first transferring the funds from an account managed by the service provider 1212 to the merchant's 1216(A) bank account.

[0144] In at least one example, the service provider 1212 may provide inventory management services. That is, the service provider 1212 may provide inventory tracking and reporting. The inventory management services may enable the merchant 1216(A) to access and manage a database that stores data related to the quantity of each item available to the merchant 1216(A) (i.e., inventory). Additionally, in at least one example, the service provider 1212 may provide a catalog management service to enable the merchant 1216(A) to maintain a catalog, which may be a database that stores data related to items available for acquisition by the merchant 1216(A) (i.e., a catalog management service). In at least one example, the catalog may include multiple data items, and a data item among the multiple data items may represent an item available for acquisition by the merchant 1261(A). The service provider 1212 may provide suggestions related to item pricing, item placement on the catalog, and multi-party fulfillment of inventory.

[0145] In at least one example, the service provider 1212 may offer business banking services that enable the merchant 1216(A) to track deposits (from payment processing and / or other funding sources) to the merchant's 1216(A) account, payroll payments from the account (e.g., payments to the merchant's 1216(A) employees), payments to other merchants (e.g., business-to-business) from the account directly or from a linked debit card, withdrawals made via scheduled and / or immediate deposits, etc. Additionally, the business banking services enable the merchant 1216(A) to obtain customized payment instruments (e.g., credit cards), check how much money they are earning (e.g., via presentation of available earned balances), understand where their money is going (e.g., via deposit reports (which may include a breakdown of fees), expenditure reports, etc.), access / spend the money they have earned (e.g., via scheduled deposits, immediate deposits, linked payment instruments, etc.), and feel in control of their money (e.g., via managing deposit schedules, deposit speeds, linked products, etc.). Additionally, business banking services allow merchants 1216 to visualize their cash flow to track their financial health, set aside money for upcoming obligations (e.g., savings), organize money according to goals, etc.

[0146] In at least one example, the service provider 1212 may offer financial services and products via business loans, consumer loans, fixed term loans, variable term loans, etc. In at least one example, the service provider 1212 may utilize one or more risk signals to determine whether to extend funding and / or terms associated with such funding.

[0147] In at least one example, the service provider 1212 may provide finance services to provide and / or lend loans to borrowers, which in some examples may be used to fund the borrower's short-term operational needs (e.g., capital loans). For example, a potential borrower who is a merchant may obtain a capital loan via a capital loan product to finance various operational costs (e.g., rent, payroll, inventory, etc.). In at least one example, the service provider 1212 may offer different types of capital loan products. For example, in at least one example, the service provider 1212 may offer a daily repayment loan product, where the capital loan is repaid daily from, for example, a portion of transactions processed by the payment processing service on the borrower's behalf. Additionally and / or alternatively, the service provider 1212 may offer a monthly repayment loan product, where the capital loan is repaid monthly, for example, via debit from a bank account linked to the payment processing service. The credit risk of a merchant may be assessed using a risk model that considers factors such as payment volume, the credit risk of the similarly situated merchant, past transaction history, seasonality, credit history, etc.

[0148] Additionally or alternatively, the service provider 1212 may provide financing services to provide and / or lend loans to borrowers, which in some examples are used to finance the borrower's consumer purchases (e.g., consumer loans). In at least one example, a borrower may submit a loan request to enable the borrower to purchase an item from a merchant, which may be one of the merchants 1216. The service provider 1212 may generate the loan based, at least in part, on the borrower determining that they have purchased or intend to purchase an item from the merchant. The loan may be associated with a balance based on the actual purchase price of the item, and the borrower may repay the loan over time. In some examples, the borrower may repay the loan through installments, which may be paid via funds managed and / or maintained by the service provider 1212 (e.g., from payments processed on behalf of the merchant, from payments made to the merchant, from funds transferred to the merchant, etc.). The service provider 1212 may offer specific financial products, such as payment instruments, specifically tied to loan products. For example, in one implementation, the service provider 1212 associates capital with a merchant's or customer's debit card, and the use of the debit card is defined by the terms of the loan. In some examples, a merchant may only use the debit card to make certain purchases. In other examples, "installments" associated with a loan product are credited directly via the payment instrument. Thus, the payment instrument is customized to the loan and / or the parties associated with the loan.

[0149] The service provider 1212 can provide web development services that enable users 1214 who are not familiar with HTML, XML, Javascript, CSS, or other web design tools to create and maintain professional, aesthetically pleasing websites. Some of these web page editing applications allow users to build web pages and / or modify web pages (e.g., change, add, or remove content associated with a web page). Furthermore, the web development services can create and maintain other online omni-channel presences in addition to websites, such as social media posts. In some examples, the resulting web pages and / or other content items can be used to offer items for sale via an online / e-commerce platform. That is, the resulting web pages and / or other content items can be associated with online stores or offerings by one or more merchants 1216. In at least one example, the service provider 1212 can recommend and / or generate content items to complement the merchant's 1216 omni-channel presence. That is, if a merchant of merchants 1216 has a web page, service provider 1212 may, through web development or other services, recommend and / or generate additional content items to be presented via other channels, such as social media, email, etc.

[0150] Additionally, service provider 1212 may provide payroll services that enable employers to pay employees for work performed on behalf of the employer. In at least one example, service provider 1212 may receive data including hours worked by employees (e.g., through imported time cards and / or POS interactions), sales made by employees, tips received by employees, etc. Based on such data, service provider 1212 may issue payroll payments to employees on behalf of the employer via payroll services. For example, service provider 1212 may facilitate the transfer of a sum due for an employee's payroll from the employer's bank to service provider 1212's bank, which is to be used to issue the payroll payment. In at least one example, when funds are received at service provider 1212's bank, service provider 1212 may pay the employee via check, direct deposit, or the like, often one day, one week, or more after the work was actually performed by the employee. In an additional or alternative example, the service provider 1212 may enable employees to receive payment via same-day or instant deposit based at least in part on a risk and / or reliability analysis performed by the service provider 1212.

[0151] Additionally, in at least one example, service provider 1212 may provide employee management services for managing employee schedules. Additionally, service provider 1212 may provide schedules for users 1214 to schedule appointments and / or provide appointment services for enabling users 1214 to schedule appointments.

[0152] In some examples, the service provider 1212 may provide restaurant management services to enable the user 1214 to make and / or manage reservations, monitor front-of-house and / or back-of-house operations, etc. In such examples, the merchant device 1208 and / or the server 1202 may be configured to communicate with one or more other computing devices that may be located at the front-of-house (e.g., a POS device) and / or the back-of-house (e.g., a kitchen display system (KDS)). In at least one example, the service provider 1212 may provide order management services and / or fulfillment services to enable the restaurant to manage open tickets, split tickets, etc., and / or manage fulfillment services. In some examples, such services may be associated with a restaurant merchant, as described above. In additional or alternative examples, such services may be any type of merchant.

[0153] In at least one example, the service provider 1212 can provide a fulfillment service that can use couriers for deliveries, and the couriers can travel between multiple locations to provide delivery services, photography services, etc. A courier can be a user 1214 that can travel between locations to perform a service (e.g., deliver an item, capture an image, etc.) for a requesting user 1214. In some examples, the courier can receive compensation from the service provider 1212. A courier can use one or more vehicles, such as a car, bicycle, scooter, motorcycle, bus, airplane, helicopter, boat, skateboard, etc. However, in other examples, a courier can travel on foot or in another manner without a vehicle. Some examples discussed herein enable people to participate in a type of crowdsourced service economy as couriers, where essentially anyone with a mobile device can quickly become or cease to be a courier in a courier network providing the services described herein. In at least one example, the courier may be an unmanned aerial vehicle (e.g., a drone), an autonomous vehicle, or any other type of vehicle capable of receiving instructions to travel between locations. In some examples, the service provider 1212 may receive a request for courier services via a user interface (e.g., an application, a web browser, or other access point) presented via the respective device 1206, automatically assign the request to an active courier, and communicate delivery instructions to the courier.

[0154] In some examples, service provider 1212 may offer omni-channel fulfillment services. For example, if a customer places an order with a merchant and the merchant is unable to fulfill the order because one or more items are out of stock or otherwise unavailable, service provider 1212 may leverage other merchants and / or sales channels that are part of service provider 1212's platform to fulfill the customer's order. That is, another merchant may provide one or more items to fulfill the customer's order. Additionally, in some examples, another sales channel (e.g., online, brick-and-mortar store, etc.) may be used to fulfill the customer's order.

[0155] In some examples, the service provider 1212 can enable conversational commerce via a conversational commerce service, which can use one or more machine learning mechanisms to analyze messages exchanged between two or more users 1214, voice input to a virtual assistant, etc., to determine the intent of the users 1214. In some examples, the service provider 1212 can utilize the determined intent to automate customer service, offer promotions, provide recommendations, or otherwise interact with the customer in real time. In at least one example, the service provider 1212 can integrate products and services and payment mechanisms into a communication platform (e.g., messaging, etc.) to allow the customer to make a purchase or other transaction without having to call, email, or visit a merchant's web page or other channel. That is, conversational commerce alleviates the need for the customer to switch back and forth between a conversation and a web page to gather information and make a purchase.

[0156] In at least one example, the service provider 1212 can provide a peer-to-peer payment service that enables peer-to-peer payments between two or more users 1214. In at least one example, the service provider 1212 can communicate with an instance of a payment application (or other access point) installed on a device 1206 configured for operation by the user 1214. In one example, an instance of the payment application running on a first device operated by the payer can send a request to the service provider 1212 to transfer an amount of funds (e.g., fiat currency or non-fiat currency such as cryptocurrency, securities, and related assets) from the payer's account to the payee's account (e.g., a peer-to-peer payment). The service provider 1212 can facilitate the transfer and can send a notification to the instance of the payment application running on a second mobile device operated by the payee that the transfer is in process (or has been completed). In some examples, the service provider 1212 can send additional or alternative information to the instance of the payment application (e.g., a low balance to the payer, current balances to the payer or payee, etc.). In some embodiments, the payer and / or payee may be automatically identified based on, for example, context, proximity, prior transaction history, etc. In other examples, the payee may send a request for funds to the payer before the payer initiates the transfer of funds. The funds to be transferred may be associated with any digital currency type, including, but not limited to, cash, cryptocurrency, etc. In some embodiments, the service provider 1212 funds the request to the payee on behalf of the payer to speed up the transfer process and compensate for any delays that may be due to the payer's financial network.

[0157] In some embodiments, the service provider 1212 can initiate a peer-to-peer payment transaction through the identification of a “payment proxy” having a specific syntax. For example, the syntax includes a currency indicator prefixed with one or more alphanumeric characters (e.g., $Cash). The currency indicator acts as a tagging mechanism that indicates to the computer system that the input is to be treated as a request from the sender to transfer cash, and detection of the syntax (including one or more alphanumeric characters tagged with the currency indicator) triggers the transfer of cash. The currency indicator can correspond to various currencies, including, but not limited to, dollars ($), euros (EUR), pounds (£), rupees (Rs), renminbi (￥), etc. While the use of the dollar currency indicator ($) is used herein, it should be understood that any currency symbol could equally be used. The peer-to-peer transaction can be initiated through a specific application running on the user device 1206.

[0158] In some embodiments, peer-to-peer processing may be implemented within a forum context. The term “forum,” as used herein, refers to a content provider's media channel (e.g., a social networking platform, microblogging, blog, video sharing platform, music sharing platform, etc.) that enables user interaction and engagement via comments, posts, messages on electronic bulletin boards, messages on social networking platforms, and / or any other type of message. A forum may be employed by a content provider to enable users of the forum to interact with one another (e.g., through creating messages, posting comments, etc.). In some embodiments, a “forum” may also refer to an application or web page of an e-commerce or retail organization offering products and / or services. Such websites may provide online “forms” to be completed before or after a product or service is added to a virtual cart. The online form may include one or more fields for receiving user interaction and engagement. Specific examples include the user's name and other identifying information, the user's shipping address, etc. Some of these fields may be configured to receive payment information, such as a payment proxy, in lieu of other types of payment mechanisms, such as credit cards, debit cards, prepaid cards, gift cards, virtual wallets, etc.

[0159] In some embodiments, peer-to-peer processing may be implemented within a communications application context, such as a messaging application context. The term “messaging application,” as used herein, refers to any messaging application that enables communication between users (e.g., senders and recipients of messages) over a wired or wireless communication network through the use of communication messages. The messaging application may be utilized by the service provider 1212. For example, the service provider 1212 may offer a messaging service that provides communication services to users via the messaging application (e.g., chat or messaging capabilities). The messaging application may include, for example, a text messaging application for communication between phones (e.g., traditional mobile phones or smartphones) or a cross-platform instant messaging application for smartphones and phones that use the Internet for communication. The messaging application may execute on the user device 1206 (e.g., a mobile terminal or a traditional personal computer (PC)) based on instructions transmitted to or from the server 1202 (which may be referred to as a “messaging server” in such examples). In some examples, the messaging application may include a payment application with messaging capabilities that enables users of the payment application to communicate with each other. In such an example, a payment application may be executed on the user device 1206 based on instructions transmitted to or from the server 1202 (e.g., a payment service discussed herein or another payment service that supports payment transactions).

[0160] In at least some embodiments, peer-to-peer processing may be implemented within a landing page context. The term “landing page,” as used herein, refers to a virtual location identified by a personalized location address that is dedicated to collecting payments on behalf of a recipient associated with the personalized location address. The personalized location address that identifies the landing page may include the payment proxy described above. The service provider 1212 may generate the landing page to enable a recipient to conveniently receive one or more payments from one or more senders. In some embodiments, the personalized location address that identifies the landing page is a uniform resource locator (URL) that incorporates the payment proxy. In such embodiments, the landing page is a web page, such as www.cash.me / $cash.

[0161] In at least one example, the user 1214 may be new to the service provider 1212, such as an unregistered user 1214 (e.g., who has not subscribed to receive access to one or more services offered by the service provider). The service provider 1212 may offer onboarding services to register the potential user 1214 with the service provider 1212. In some examples, onboarding may involve presenting the potential user 1214 with various questions, prompts, etc. to obtain information that may be used to generate a profile for the potential user 1214. In at least one example, the service provider 1212 may provide limited or short-term access to its services before or during onboarding (e.g., a user of a peer-to-peer payment service may transfer and / or receive funds before being fully onboarded, a merchant may process payments before being fully onboarded, etc.). In at least one example, in response to the potential user 1214 providing all the necessary information, the potential user 1214 may be onboarded to the service provider 1212. In such an example, any limited or short-term access to the services of the service provider 1212 may be transitioned to more permissive (e.g., less limited) or longer-term access to such services.

[0162] The service provider 1212 may be associated with an IDV service that may be used by the service provider 1212 for compliance purposes and / or may be offered as a service to, for example, a third-party service provider (e.g., associated with the server 1210). That is, the service provider 1212 may offer an IDV service to verify the identity of a user 1214 who uses or attempts to use their services. Identity verification requires a customer (or potential customer) to provide information that is used by a compliance department to prove that the information is associated with the identity of a real person or entity. In at least one example, the service provider 1212 may perform a service to determine whether the identifying information provided by the user 1214 accurately identifies the customer (or potential customer) (i.e., is the customer who they say they are?).

[0163] Service provider 1212 may offer additional or alternative services, and the services described above are provided as a sampling of services. In at least one example, service provider 1212 may exchange data with server 1210 associated with a third-party service provider. Such third-party service provider may provide information that enables service provider 1212 to provide services such as those described above. In additional or alternative examples, such third-party service provider may access the services of service provider 1212. That is, in some examples, the third-party service provider may be a subscriber or otherwise have access to the services of service provider 1212.

[0164] The techniques described herein may be configured to operate in both real-time / online and offline modes. “Online” mode refers to a mode when the device is able to communicate with the service provider 1212 (e.g., server 1202) and / or server 1210 over the network 1204. In some examples, the merchant device 1208 is unable to connect with the service provider 1212 (e.g., server 1202) and / or server 1210, e.g., due to network connectivity issues. In additional or alternative examples, the server 1202 is unable to communicate with the server 1210, e.g., due to network connectivity issues. In such examples, the device may operate in “offline” mode, where at least some payment data is stored on (e.g., merchant device 1208) and / or server 1202 until connectivity is restored and the payment data can be transmitted to the server 1202 and / or server 1210 for processing.

[0165] In at least one example, service provider 1212 may be associated with a hub, such as an order hub, inventory hub, fulfillment hub, etc., that may enable integration with one or more additional service providers (e.g., associated with additional servers 1210). In some examples, such additional service providers may offer additional or alternative services, and service provider 1212 may provide interfaces or other computer-readable instructions for integrating the functionality of service provider 1212 with the one or more additional service providers.

[0166] The techniques described herein are directed to services provided via a distributed system of user devices 1206 in communication with one or more server computing devices (i.e., servers 1202) of a service provider 1212. That is, the techniques described herein are directed to particular implementations, or practical applications, that utilize a distributed system of user devices 1206 in communication with servers 1202 of a service provider 1212 to perform various services, as described above. The non-traditional configuration of the distributed system described herein enables servers 1202, located remotely from end users (e.g., users 1214), to intelligently provide services, in near real time, in some examples, based on aggregated data associated with end users, such as users 1214 (e.g., data associated with multiple, different merchants and / or multiple, different purchasers). Thus, the techniques described herein are directed to particular configurations of elements that offer technological improvements over traditional techniques for performing payment processing services and the like. Particularly for small business owners, the business environment is typically fragmented and relies on unrelated tools and programs, making it difficult for owners to manually consolidate and view such data. The techniques described herein constantly or periodically monitor disparate and separate merchant accounts, e.g., accounts within the control of the service provider(s) 1212 and accounts outside the control of the service provider(s) 1212, to track the state of the merchant's business (e.g., payables, receivables, payroll, invoices, reservations, capital, etc.). The techniques herein provide a consolidated view of the merchant's cash flow, predict needs, preemptively provide recommendations or services such as capital, coupons, and / or enable money transfers between disparate accounts (merchant, another merchant, or payment service) in a frictionless and transparent manner.

[0167] In at least one example, an individual one of the customers 1220 can interact with a customer computing device 1226, which can be one of the user devices 1226 and can correspond to the customer computing device 1226 described above with reference to FIG. 1. As described herein, in some examples, the customer computing device 1226 can download a progressive web application (PWA) 1228. As described above with reference to FIG. 1, in at least one example, the server 1202 can receive an identification code and send the progressive web application 1228 to the customer computing device 1226. That is, the customer computing device 1226 can download the progressive web application 1228 via a web browser 1230 of the customer computing device 1226. In some examples, the customer computing device 1226 may have previously downloaded the progressive web application 1228, for example, by entering a URL associated with the progressive web application 1228 into the web browser 1230 associated with the customer computing device 1226. In such an example, the indication of the identification code may be associated with a cookie or other indicator that the progressive web application 1228 was previously downloaded on the customer computing device 1226 .

[0168] As described above, progressive web application 1228 may be a type of application software delivered over a network (e.g., the web) that may be built using web technologies (e.g., HTML, CSS, JavaScript, etc.). Progressive web application 1228 may be used to provide a user experience similar to a native application on a computing device, such as customer computing device 1226, with fewer development resources. Progressive web application 1228 may use resources from a web browser, such as web browser 1230, to present an experience similar to a native application. In at least one example, progressive web application 1228 may utilize the HTTPS protocol to protect the privacy and integrity of data associated with progressive web application 1228 (e.g., data provided via progressive web application 1228 and / or transmitted over network 1204). Progressive web application 1228 may be configured to function for a variety of users regardless of which web browser is used. Thus, the progressive web application 1228 can be progressive (built using a progressive expansion pattern) such that the progressive web application 1228 can run on any device and expand progressively, utilizing any functionality available on the customer computing device 1226 and web browser 1230. In some examples, functionality available via the progressive web application 1228 can depend on web browser support. For example, features including connectivity independence, installation to a home screen or desktop, push messaging, etc. can depend on web browser support.

[0169] As described above, progressive web applications 1228 may be more user-friendly than native applications and / or web applications. For example, progressive web applications 1228 may fit a variety of display sizes (e.g., desktop, mobile, tablet, etc. computing devices), may be accessible when the internet connection is low quality and / or the computing device is offline, and may be up-to-date (e.g., updates to content may be performed in the background). Furthermore, progressive web applications 1228 may be associated with a shell 1232, which may use an application shell model to provide a user experience similar to that of a native application. That is, customers may access the progressive web application 1228 via a web browser and / or a shortcut icon, which may be installed on the desktop or home screen of a computing device operable by such customers. In some examples, progressive web applications 1228 may use push notifications to maintain customer engagement. Furthermore, progressive web applications 1228 may be easily shared via a uniform resource locator (URL) and do not require complex installation. That is, a progressive web application may use a URL to indicate the current state of the progressive web application, which may allow the progressive web application to preserve or reload its state when a user bookmarks or shares a URL associated with the progressive web application (e.g., the progressive web application may link to).

[0170] In at least one example, the progressive web application 1228 may be associated with a manifest 1234 that provides a developer with a centralized location for storing metadata associated with the progressive web application 1228. Such metadata may include, but is not limited to, the name of the progressive web application 1228, a link to an icon or image object for the progressive web application 1228, a preferred URL for launching or opening the progressive web application 1228, configuration data for the progressive web application 1228, a default orientation for the progressive web application 1228, display mode options, etc.

[0171] In at least one example, the progressive web application 1228 may be associated with an object 1236 (e.g., a “service worker”) configured to execute client-side code in a background thread separate from the main thread of the web browser 1230, provide a scriptable network proxy to the web browser 1230, and programmatically manage communications between the progressive web application 1228 and the server 1202. In at least one example, the object may be independent of the progressive web application 1228 with which it is associated. In some examples, portions of the progressive web application 1228 and / or content associated therewith may be cached by the object 1236 (e.g., in cache memory 1238) for future interactions with the progressive web application 1228. That is, in some examples, after an initial load of content, the same content and / or page elements do not need to be re-downloaded and / or re-rendered each time the progressive web application 1228 is subsequently accessed. In some examples, the object 1236 may utilize one or more application programming interfaces (APIs) to operate the progressive web application 1228 offline. Such APIs may provide mechanisms for retrieving content over the network 1204 and for persistent content storage for application data. Caching resources allows content to load faster under various network conditions.

[0172] In at least one example, the objects 1236 can help keep content associated with the progressive web application 1228 up to date. In some examples, the objects 1236 can be files (e.g., JavaScript files) that act as a type of web worker. The objects 1236 can operate separately from the main thread of the web browser 1230 to handle push notifications, synchronize data in the background, cache or retrieve resource requests, intercept network requests, receive centralized updates, and / or the like. Such objects 1230 can enable the progressive web application 1228 to provide the high-performance, rich user experience of a native application with the low storage space, real-time updates, and improved search engine visibility of a traditional web application (e.g., a progressive web application as a website may be discoverable in search engines).

[0173] In some examples, the object 1230 can utilize one or more other APIs 1240 to enable the progressive web application 1228 to function like a native application. For example, the object can use a notification API to display and interact with notifications using the native notification system of the operating system of the customer computing device 1226. A push API can enable the progressive web application 1228 to subscribe to a push service and receive push messages, for example, from the server 106. The push messages can be delivered to the object 1236, which can use the information in the message to update local state or display notifications to the customer. Because the object 1236 operates independently of the progressive web application 1228, it can receive and display notifications even if the web browser is not running. In some examples, a background synchronization API can postpone actions until the customer computing device 1226 has stable connectivity. This can be useful to ensure that what the customer wants to send is actually sent. This API can also allow the server 1202 to push periodic updates to the progressive web application 1228 so that the progressive web application 1228 can update the next time it is online. In some examples, a channel messaging API can allow the object 1236 to communicate with other objects and the progressive web application 1228. Examples of this API can include new content notifications (e.g., making new content available via the progressive web application 1228) and updates that utilize user interaction. The progressive web application 1228 can utilize additional or alternative APIs or additional or alternative functional components to perform the operations described herein.

[0174] In at least one example, an object 1236 can go through a three-step lifecycle: registration, installation, and activation. Registration can include communicating the location of the object 1236 to the web browser 1230 in preparation for installation. Installation can occur when the web browser 1230 has no installed object or when there is an update to the object 1236 (e.g., a byte difference between the new object and the previously installed object). Activation can occur when all of the web pages of the progressive web application 1228 are closed, so that there are no conflicts between the previous version and the updated one. The lifecycle also helps maintain consistency when switching between versions of the object 1236, since, in some examples, only a single object may be active for a region.

[0175] In at least one example, the progressive web application 1228 may cause merchant data to be presented via the web browser 1230 of the customer computing device 1226. In some examples, such merchant data may be a menu of items, a layout of the merchant's physical store, etc. In some examples, a customer may interact with the customer computing device 1226 (e.g., a user interface associated therewith) to provide input, which instructions may be transmitted to a merchant computing device, such as the server 1202 and / or the merchant computing device 1208(A). In at least one example, the server 1202 and / or the merchant computing device 1208(A) may perform an action based on such input. Examples are provided above.

[0176] The merchant computing device 1208(A) and the customer computing device 1226 may be associated with additional or alternative components, as described below with reference to Figure 13. The components shown in Figure 12 are for illustration purposes, and components described below with reference to Figure 13 are omitted for clarity of Figure 12.

[0177] FIG. 13 shows an exemplary block diagram illustrating a system 1300 for performing the techniques described herein. The system 1300 includes a user device 1302 that communicates with a server computing device (e.g., a server 1304) via a network 1306 (e.g., the Internet, a cable network, a cellular network, a cloud network, a wireless network (e.g., Wi-Fi), and a wired network) and near-field communications such as Bluetooth®, Bluetooth® Low Energy (BLE), etc. Although a single user device 1302 is shown, in additional or alternative examples, the system 1300 can have multiple user devices, as described above with reference to FIG. 12. For example, in the environment 100 described above, the merchant computing device 104 and the customer computing device 118 can each represent a user device 1302.

[0178] As mentioned above, in at least one example, the user device 1302 may correspond to the merchant computing device 104 or the customer computing device 118 of Figure 1. In at least one example, the server 1304 may correspond to the server 106 of Figure 1, and the network 1306 may correspond to the network 108 of Figure 1.

[0179] As mentioned above, the techniques described herein are directed, among other things, to customer device application sites accessible via merchant-managed identifiers. System 1300 can facilitate such techniques. As mentioned above, brick-and-mortar transactions can be high-friction transactions, and as a result, customers and merchants may be required to interact with each other and other physical items (e.g., menus, writing implements, payment terminals, etc.) to effectuate such transactions. There are scenarios in which customers and / or merchants aim to expedite transactions and / or minimize friction associated with such transactions. Existing techniques (e.g., native applications, web applications, etc.) are not user-friendly and / or accessible to small merchants due to development complexity and cost.

[0180] As mentioned above, the service provider 1212 described above with reference to FIG. 12 can enable merchants to offer progressive web applications to streamline transactions in brick-and-mortar stores. Progressive web applications provide solutions to the problems identified above with native and / or web applications. For example, progressive web applications use resources from modern web browsers to present an experience similar to that of native applications. Progressive web applications can offer more functionality and run much faster than web applications. Furthermore, progressive web applications can be portable across different types of platforms (e.g., desktop, mobile, etc.) and, in some instances, can adapt to various display sizes of computing devices (e.g., desktop, mobile, tablet, etc.), thereby making the progressive web application accessible and user-friendly. That is, progressive web applications can be responsive in that they can adapt to different form factors and / or screen sizes. Progressive web applications can be more user-friendly than native and / or web applications. For example, a progressive web application may be accessible and up-to-date (e.g., updates to content may be performed in the background) when the internet connection is poor and / or when the computing device is offline.

[0181] Progressive web applications can provide security by utilizing the HTTPS protocol to protect the privacy and integrity of data associated with the progressive web application. Progressive web applications can be "progressive" in that they can function for a variety of users regardless of which web browser is being used. Furthermore, progressive web applications that can use an application shell model provide a user experience similar to that of native applications. That is, customers can access the progressive web application via a shortcut icon that can be installed on a web browser and / or the desktop or home screen of a computing device operable by such customers. In some examples, progressive web applications can use push notifications to maintain customer engagement. Furthermore, progressive web applications can be easily shared via a uniform resource locator (URL) and do not require complex installation.

[0182] Thus, the techniques described herein leverage progressive web applications to enable customers to have faster access to merchant data via technologies that provide an improved user experience over traditional alternatives, such as native applications and / or web applications. Such technologies can thus streamline transactions and other interactions between customers and merchants at brick-and-mortar stores or other premises of such merchants.

[0183] In at least one example, the user device 1302 may be any suitable type of computing device, e.g., portable, semi-portable, semi-stationary, or stationary. Some examples of the user device 1302 may include, but are not limited to, a tablet computing device, a smartphone or mobile communication device, a laptop, netbook, or other portable or semi-portable computer, a desktop computing device, a terminal computing device, or other semi-stationary or stationary computing device, a dedicated device, a wearable or other body-worn computing device, an augmented reality device, a virtual reality device, an Internet of Things (IoT) device, etc. That is, the user device 1302 may be any computing device capable of transmitting communications and performing functions in accordance with the techniques described herein. The user device 1302 may include devices such as a payment card reader or component capable of accepting payments, as described below.

[0184] In the illustrated example, the user device 1302 includes one or more processors 1308, one or more computer-readable media 1310, one or more communication interfaces 1312, one or more input / output (I / O) devices 1314, a display 1316, and sensors 1318.

[0185] In at least one example, each processor 1308 may itself comprise one or more processors or processing cores. For example, processor 1308 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any devices that manipulate signals based on operational instructions. In some examples, processor 1308 may be one or more hardware processors and / or logic circuits of any suitable type that are specifically programmed or configured to execute the algorithms and processes described herein. Processor 1308 may be configured to fetch and execute computer-readable, processor-executable instructions stored on computer-readable medium 1310.

[0186] Depending on the configuration of the user device 1302, the computer-readable medium 1310 may be an example of a tangible, non-transitory computer storage medium and may include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable, processor-executable instructions, data structures, program modules, or other data. The computer-readable medium 1310 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable medium technology. Furthermore, in some examples, the user device 1302 may have access to external storage devices such as a RAID storage system, a storage array, network-attached storage, a storage area network, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor 1308 directly or through another computing device or network. Thus, the computer-readable medium 1310 may be a computer storage medium capable of storing instructions, modules, or components that can be executed by the processor 1308. Additionally, when referred to, non-transitory computer-readable media excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0187] The computer-readable medium 1310 may be used to store and maintain any number of functional components executable by the processor 1308. In some embodiments, these functional components comprise instructions or programs executable by the processor 1308 that, when executed, implement operational logic for performing actions and services attributed to the user device 1302. The functional components stored on the computer-readable medium 1310 may enable a user interface 1320 to be presented so that a user can interact with the user device 1302 and, therefore, the server 1304 and / or other networked devices. In at least one example, the user interface 1320 may be presented via a web browser or the like. In other examples, the user interface 1320 may be presented via an application, such as a mobile or desktop application, which may be provided by the service provider 1212 associated with the server 1304, or may be other dedicated application. In some examples, the user interface 1320 may be presented via a web browser associated with a progressive web application, such as the progressive web application 120 described above with reference to FIG. 1 and the progressive web application described above with reference to FIG. 12. In at least one example, a user may interact with the user interface via touch input, voice input, gestures, or any other type of input. The word “input” is also used to describe “contextual” input that may not be directly provided by the user via the user interface 1320. For example, a user's interaction with the user interface 1320 may be analyzed, e.g., using natural language processing techniques, to determine the user's context or intent, which may be processed in a manner similar to “direct” user input.

[0188] In some examples, where the user device 1302 represents the merchant computing device 104 of FIG. 1 , the user interface 1320 may be presented via an application provided by the service provider 1212 of FIG. 12 . An application referred to as the POS application 1218 in FIG. 12 may configure the user device 1302 as a point-of-sale terminal. Such an application may additionally or alternatively enable the merchant to view and / or manage an order queue, view and / or manage reservations, generate and / or manage identification codes, etc. That is, such an application may configure the user device 1302 to perform the functions described herein (e.g., in FIGS. 1 and 4-6 above). In some examples, at least some of the functionality may be utilized via a web browser that presents the user interface 1320. In examples where the user device 1302 represents the customer computing device 118 of FIG. 1 , the user interface 1320 may be presented via a web browser associated with the progressive web application 120. Further details related to such web browsers and progressive web applications are described above with reference to FIG. 12 .

[0189] Depending on the type of user device 1302, the computer-readable medium 1310 may also optionally include other modules and data 1322, which may include programs, drivers, etc., as well as other functional components and data, such as data used or generated by the functional components. Additionally, the computer-readable medium 1310 may also store data, data structures, etc. used by the functional components. Additionally, the user device 1302 may include many other logical, program, and physical components, of which those described are merely examples relevant to the discussion herein.

[0190] In at least one example, the computer-readable medium 1310 can include additional functional components, such as an operating system 1324, for controlling and managing various functions of the user device 1302 and enabling basic user interaction.

[0191] The communication interface 1312 may include one or more interfaces and hardware components for enabling communication with various other devices, such as via the network 1306 or directly. For example, the communication interface 1312 may enable communication over one or more networks 1306, which may include any type of network known in the art, such as, but not limited to, a local area network or a wide area network such as the Internet, a wireless network such as a cellular network, a cloud network, a local wireless network such as Wi-Fi, and / or a near field communication such as Bluetooth®, BLE, NFC, RFID, or any other such network, a wired network, or any other such network, or any combination thereof. Thus, the network 1306 may include both wired and / or wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as wired or fiber optic technologies. The components used for such communication may depend at least in part on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0192] Embodiments of the present disclosure may be provided to users through a cloud computing infrastructure. Cloud computing refers to the provision of scalable computing resources as a service over a network, enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be quickly provisioned and released with minimal management effort or service provider interaction. Cloud computing thus enables users to access virtual computing resources (e.g., storage, data, applications, and complete virtualized computing systems) in the "cloud" regardless of the underlying physical systems used to provide the computing resources (or the location of those systems).

[0193] The user device 1302 may further include one or more input / output (I / O) devices 1314. The I / O devices 1314 may include speakers, microphones, cameras, and various user controls (e.g., buttons, joysticks, keyboards, keypads, etc.), tactile output devices, etc. The I / O devices 1314 may also include attachments that utilize accessories (e.g., audio jacks, USB-C, Bluetooth, etc.) to connect with the user device 1302.

[0194] In at least one example, user device 1302 may include a display 1316. Depending on the type of computing device used as user device 1302, display 1316 may use any suitable display technology. For example, display 1316 may be a liquid crystal display, a plasma display, a light-emitting diode display, an OLED (organic light-emitting diode) display, an electronic paper display, or any other suitable type of display capable of presenting digital content thereon. In at least one example, display 1316 may be an augmented reality display, a virtual reality display, or any other display capable of presenting and / or projecting digital content. In some examples, display 1316 may have a touch sensor associated with it to provide a touchscreen display configured to receive touch input to enable interaction with a graphical interface presented on display 1316. Thus, implementations herein are not limited to any particular display technology. Alternatively, in some examples, user device 1302 may not include a display 1316, and information may be presented by other means, such as auditory or tactile.

[0195] Additionally, the user device 1302 may include sensors 1318. The sensors 1318 may include a GPS device capable of indicating location information. Further, the sensors 1318 may include, but are not limited to, an accelerometer, a gyroscope, a compass, a proximity sensor, a camera, a microphone, and / or a switch.

[0196] In some examples, a GPS device may be used to identify a user's location. In at least one example, the user's location may be used by the aforementioned service provider 1212 to provide one or more services. That is, in some examples, the service provider 1212 may implement geofencing to provide specific services to a user. As an example, with a lending service, location may be used to verify that the stated purpose of the loan corresponds to evidence of use (e.g., does the user using the loan match what they said they would use the loan?). Additionally, in some examples, location may be used for payroll purposes. As an example, when a contractor completes a project, the contractor may provide geotagged images (e.g., tagged based on location information available by a GPS device). In some examples, location may be used to facilitate peer-to-peer payments between nearby users 1214 and / or to send notifications to the user 1214 regarding available appointments with merchant(s) located in proximity to the user 1214. In at least one example, the location may be used to accept payment from a nearby customer upon exiting a geofence, or the location may be used to initiate an action in response to the user 1214 entering a merchant's brick-and-mortar store. The location may also be used in additional or alternative ways.

[0197] In addition, the user device 1302 may include various other components not shown, examples of which include removable storage, a power source such as a battery and power control unit, a barcode scanner, a printer, a cash drawer, etc.

[0198] Additionally, in some examples, the user device 1302 may include, be connectable to, or otherwise coupled to a reader device 1326 to read payment instruments and / or identifiers associated with other objects. In some examples, as described above, the reader device 1326 may plug into a port on the user device 1302, such as a microphone port, a headphone port, an audio jack, a data port, or other suitable port. In additional or alternative examples, the reader device 1326 may be coupled to the user device 1302 via another wired or wireless connection, such as via Bluetooth, BLE, or the like. The reader device 1326 may include a read head for reading the magnetic strip of a payment card and may further include encryption technology for encrypting information read from the magnetic strip. Additionally or alternatively, the reader device 1326 may be an EMV payment reader, which in some examples may be embedded in the user device 1302. Furthermore, depending on the type and configuration of the user device 1302, numerous other types of readers may be used in conjunction with the user device 1302 herein.

[0199] The reader device 1326 may be a portable magnetic stripe card reader, an optical scanner, a smart card (a card with an embedded IC chip) reader (e.g., an EMV-compliant card reader or a near field communication enabled reader), an RFID reader, etc. configured to detect and acquire data from any payment instrument. Thus, the reader device 1326 may include hardware implementations such as slots, magnetic tracks, and rails with one or more sensors or electrical contacts to facilitate detection and acceptance of a payment instrument. That is, the reader device 1326 may include a hardware implementation that enables the reader device 1326 to interact with a payment instrument via a swipe (i.e., a card-present transaction in which a customer slides a card having a magnetic strip through a payment reader that captures the payment data contained on the magnetic strip), a dip (i.e., a card-present transaction in which a customer first inserts a card having an embedded microchip (i.e., chip) into the payment reader until the payment reader prompts the customer to remove the card), or a tap (i.e., a card-present transaction in which a customer taps or hovers their electronic device, such as a smartphone running a payment application, to complete the transaction via short-range communication) to obtain payment data associated with the customer. Additionally or optionally, the reader device 1326 may also include a biometric sensor to receive and process biometric characteristics and process them as a payment instrument, provided the biometric characteristics are registered with the service provider and connected to a financial account using a bank server.

[0200] The reader device 1326 may include a processing unit, computer-readable media, a reading chip, a transaction chip, a timer, a clock, a network interface, a power supply, etc. The processing unit of the reader device 1326 may execute one or more modules and / or processes that cause the reader device 1326 to perform various functions, as described above and in further detail in the disclosure that follows. In some examples, the processing unit may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU, or other processing units or components known in the art. Additionally, each of the processing units may possess its own local memory, which may also store program modules, program data, and / or one or more operating systems. Depending on the exact configuration and type of the reader device 1326, the computer-readable media may include volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, mini-hard drives, memory cards, etc.), or some combination thereof. In at least one example, the computer-readable media of the reader device 1326 may include at least one module for performing the various functions described herein.

[0201] The reading chip can perform functions to control the operation and processing of the reader device 1326. That is, the reading chip can perform functions to control a payment interface (e.g., a contactless interface, a contact interface, etc.), a wireless communication interface, a wired interface, a user interface (e.g., a signal state device (FPGA)), etc. Additionally, the reading chip can perform functions to control a timer, which can provide a timer signal indicating an amount of time that has elapsed following a particular event (e.g., an interaction, a power-down event, etc.). Additionally, the reading chip can perform functions to control a clock 136, which can provide a clock signal indicating time. Additionally, the reading chip can perform functions to control a network interface, which can interact with the network 1306 as described below.

[0202] Additionally, the reader chip can perform functions for controlling a power source. The power supply can include one or more power sources, such as a physical connection to AC power or a battery. The power supply can include power conversion circuitry for converting AC power and generating multiple DC voltages for use by components of the reader device 1326. When the power supply includes a battery, the battery can be charged via a physical power connection, via inductive charging, or any other suitable method.

[0203] The transaction chip can perform functions related to processing payment transactions, interfacing with payment instruments, encryption, and other payment-specific functions. That is, the transaction chip can access payment data associated with the payment instrument and provide the payment data to the POS terminal, as described above. The payment data can include, but is not limited to, the customer's name, the customer's address, the type of payment instrument (e.g., credit, debit, etc.), the number associated with the payment instrument, a verification value associated with the payment instrument (e.g., PIN Verification Key Indicator (PVKI), PIN Verification Value (PVV), Card Verification Value (CVV), Card Verification Code (CVC), etc.), expiration date data associated with the payment instrument, the primary account number (PAN) corresponding to the customer (which may or may not match the number associated with the payment instrument), restrictions on what types of charges / debits may be made, etc. Additionally, the transaction chip can encrypt the payment data upon receiving it.

[0204] It should be understood that in some examples, the reading chip may have its own central processing unit(s) and computer-readable media, and / or the transaction chip may have its own central processing unit(s) and computer-readable media. In other examples, the functionality of the reading chip and transaction chip may be embodied in a single chip or multiple chips, each including any suitable combination of central processing unit(s) and computer-readable media for collectively performing the functions of the reading chip and transaction chip described herein.

[0205] While the user device 1302, which may be a POS terminal, and the reader device 1326 are shown as separate devices, in additional or alternative examples, the user device 1302 and the reader device 1326 may be part of a single device, which may be a battery-operated device. In such examples, components of both the user device 1302 and the reader device 1326 may be associated with a single device. In some examples, the reader device 1326 may have a display integrated therewith, which may be in addition to (or instead of) the display 1316 associated with the user device 1302.

[0206] Server(s) 1304 may include one or more servers or other types of computing devices, which may be embodied in any number of ways. For example, in the server example, the modules, other functional components, and data may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud-hosted computing service, a cloud-hosted storage service, etc., although other computer architectures may additionally or alternatively be used.

[0207] Additionally, while the diagram depicts the components and data of server 1304 as residing in a single location, these components and data may alternatively be distributed in any manner across different computing devices and different locations. Thus, functionality may be implemented by one or more server computing devices, and the various functions described above may be distributed in various ways across the various computing devices. Multiple servers 1304 may be located together or separately and may be organized, for example, as virtual servers, server banks, and / or server farms. The described functionality may be provided by a single merchant or business server, or by multiple different customer or business servers and / or services.

[0208] In the depicted example, server 1304 may include one or more processors 1328, one or more computer-readable media 1330, one or more I / O devices 1332, and one or more communication interfaces 1334. Each processor 1328 may be a single processing unit or several processing units and may include single or multiple computing units or multiple processing cores. Processor 1328 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operational instructions. For example, processor 1328 may be one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. Processor 1328 may be configured to fetch and execute computer-readable instructions stored on computer-readable medium 1330, which may program processor 1328 to perform the functions described herein.

[0209] The computer-readable medium 1330 may include volatile and nonvolatile memory and / or removable and non-removable media implemented in any type of technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Such computer-readable medium 1330 may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid-state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network-attached storage, storage area networks, cloud storage, or any other medium that can be used to store desired information and that can be accessed by a computing device. Depending on the configuration of the server 1304, the computer-readable medium 1330 may be a type of computer-readable storage medium and / or may be a tangible non-transitory medium, to the extent that, when referred to, non-transitory computer-readable medium excludes media such as energy, carrier signals, electromagnetic waves, and the signal itself.

[0210] The computer-readable medium 1330 may be used to store any number of functional components executable by the processor(s) 1328. In many implementations, these functional components comprise instructions or programs executable by the processor(s) 1328 that, when executed, specifically configure the one or more processors 1328 to perform the operations described above for the service provider 1212 and / or the payment processing service. The functional components stored on the computer-readable medium 1330 may optionally include a merchant component 1336, an identification component 1338, a training component 1340, and one or more other components and data 1342.

[0211] The merchant component 1336 can be configured to receive transaction data from a POS system, such as the POS system 1224 described above with reference to FIG. 12. The merchant component 1336 can send requests (e.g., authorization, capture, settlement, etc.) to a payment services server computing device to facilitate a transaction between a merchant and a customer. The merchant component 1336 can communicate transaction success or failure to the POS system and / or customer computing device. In some examples, the merchant component 1336 can receive orders, generate open tickets, manage open tickets, etc. In at least one example, the merchant component 1336 can manage orders, for example, by managing the order queues described above and / or sending communications related to such orders to customer computing devices, merchant computing devices, kitchen display systems, front-of-house computing systems, back-of-house computing systems, etc. The merchant component 1336 can provide functionality for managing reservations, feedback, and / or any other server-side merchant-related functionality described above with reference to FIGS. 2A-2D, 3A-3C, 4, 5, and 7-11.

[0212] The identification component 1338 can facilitate the generation of an identification code as described herein. That is, the identification component 1338 can receive an identifier associated with a physical location (e.g., a designated seating area, a brick-and-mortar store, etc.) and can generate an identification code based at least in part on such identifier. In some examples, the identification component 1338 can facilitate the association of an existing identification code with a physical location. That is, the identification component 1338 can perform, for example, the server-side operations described above with reference to FIG. 6.

[0213] The training component 1340 may be configured to train the model using a machine learning mechanism. For example, the machine learning mechanism may analyze the training data to train a data model that generates an output, which may be a suggestion, a score, and / or another indicator. The machine learning mechanism may include, but is not limited to, supervised learning algorithms (e.g., artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbors, etc.), unsupervised learning algorithms (e.g., artificial neural networks, association rule learning, hierarchical clustering, cluster analysis, etc.), semi-supervised learning algorithms, deep learning algorithms, statistical models, etc. In at least one example, the machine-trained data model may be stored in a data store associated with the user device 1302 and / or the server 1304 for use once (e.g., at runtime) after the data model has been trained.

[0214] The one or more other components and data 1342 may include programs, drivers, etc., as well as data used or generated by the functional components. Additionally, the server 1304 may include many other logical, programmatic, and physical components, of which the above-described are merely examples relevant to the discussion herein.

[0215] One or more “components” referenced herein may be implemented as more or fewer components, and the functionality described for a component may be redistributed depending on implementation details. As used herein, the term “component” broadly refers to software stored on a non-transitory storage medium (e.g., volatile or non-volatile memory for a computing device), hardware, or firmware (or any combination thereof) component. A component is typically functional such that it can use specified input to generate useful data or other output. A component may be self-contained or not. An application program (also referred to as an “application”) may include one or more components, or the components may include one or more application programs that can be accessed over a network or downloaded onto a device as software (e.g., executable code that causes a device to perform operations). Additionally and / or alternatively, a component may be implemented as computer-readable instructions, various data structures, etc., via at least one processing unit to execute the instructions and configure a computing device described herein to perform the operations described herein.

[0216] In some examples, a module may include one or more application programming interfaces (APIs) to perform some or all of its functions (e.g., operations). In at least one example, a software developer kit (SDK) may be provided by the service provider to enable third-party developers to include service provider functionality and / or utilize service provider services associated with their third-party applications. Additionally or alternatively, in some examples, the service provider may utilize the SDK to integrate third-party service provider functionality into its applications. That is, the APIs and / or SDKs may enable third-party developers to customize how their respective third-party applications interact with the service provider, or vice versa.

[0217] The computer-readable medium 1330 may further include an operating system 1344 for controlling and managing various functions of the server 1304 .

[0218] The communication interface 1334 may include one or more interfaces and hardware components for enabling communication with various other devices, such as via the network 1306 or directly. For example, the communication interface 1334 may enable communication over one or more networks 1306, which may include any type of network known in the art, such as, but not limited to, a local area network or a wide area network such as the Internet, a wireless network such as a cellular network, a local wireless network such as Wi-Fi, and / or a near field communication such as Bluetooth®, BLE, NFC, RFID, or any other such network, a wired network, or any other such network, or any combination thereof. Thus, the network 1306 may include both wired and / or wireless communication technologies, including Bluetooth®, BLE, Wi-Fi, and cellular communication technologies, as well as wired or fiber optic technologies. The components used for such communication may depend at least in part on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and will not be described in detail herein.

[0219] The server 1304 may further comprise various I / O devices 1332. Such I / O devices 1332 may include a display, various user interface controls (e.g., buttons, joysticks, keyboards, mice, touch screens, biometric or sensor input devices, etc.), audio speakers, connection ports, etc.

[0220] In at least one example, the system 1300 can include a data store 1346 that can be configured to store accessible, manageable, and updatable data. In some examples, the data store 1346 can be integrated with the user device 1302 and / or the server 1304. In other examples, as shown in Figure 13, the data store 1346 can be located remotely from and accessible to the server 1304. The data store 1346 can comprise multiple databases and / or servers connected locally and / or remotely via the network 1306.

[0221] In at least one example, the data store 1346 can store user profiles, which can include merchant profiles, customer profiles, and the like.

[0222] A merchant profile may store or otherwise associate data related to a merchant. For example, a merchant profile may store or otherwise be associated with information about the merchant (e.g., merchant name, merchant geographic location, merchant operating hours, employee information, etc.), merchant category classification (MCC), items offered for sale by the merchant, hardware used by the merchant (e.g., device type), transaction data associated with the merchant (e.g., transactions made by the merchant, payment data associated with the transaction, items associated with the transaction, a description of the items associated with the transaction, each item and / or total spend of the transaction, parties to the transaction, date, time, and / or location associated with the transaction, etc.), loan information associated with the merchant (e.g., previous loans made to the merchant, previous defaults on said loans, etc.), risk information associated with the merchant (e.g., indications of risk, instances of fraud, chargebacks, etc.), reservation information (e.g., previous reservations, upcoming (scheduled) reservations, timing of reservations, length of reservations, etc.), payroll information (e.g., employee, pay frequency, pay amount, etc.), employee information, reservation data (e.g., previous reservations, upcoming (scheduled) reservations, interactions related to such reservations, etc.), inventory data, customer service data, etc. The merchant profile may securely store bank account information provided by the merchant. Additionally, the merchant profile may store payment information associated with payment instruments linked to the merchant's stored balances, such as stored balances maintained in a ledger by the service provider 1212.

[0223] A customer profile may store customer data including, but not limited to, customer information (e.g., name, phone number, address, banking information, etc.), customer preferences (e.g., learned or customer-specified), purchase history data (e.g., identifying one or more items purchased (and respective item information)), one or more items, returns associated with one or more orders, the status of one or more orders (e.g., in preparation, in packing, in transit, delivered, etc.), appointment data (e.g., last appointment, next (scheduled) appointment, appointment timing, appointment length, etc.), payroll data (e.g., employer, payroll frequency, pay amount, etc.), reservation data (e.g., last appointment, next (scheduled) appointment, appointment duration, interactions related to such appointments, etc.), inventory data, customer service data, etc.

[0224] Additionally, in at least one example, the data store 1346 may store an inventory database and / or a catalog database. As described above, the inventory may store data related to the quantity of each item that a merchant has available to the merchant. Additionally, the catalog may store data related to the items that a merchant has available for acquisition. The data store 1346 may store additional or alternative types of data as described herein.

[0225] The phrases "in some examples," "according to various examples," "in the illustrated example," "in one example," "in other examples, various examples," "some examples," etc. generally mean that the particular feature, structure, or characteristic that follows the phrase is included in at least one example of the invention and may be included in more than one example of the invention. Additionally, such phrases do not necessarily refer to the same or different examples.

[0226] If the specification describes a component or feature as including or having a feature with "can," "could," "may," or "might," it does not require that the particular component or feature include or have that feature.

[0227] Furthermore, the above description is directed to devices and applications related to payment technology. However, it will be understood that the technology can be extended to any device and application. Furthermore, the techniques described herein can be configured to operate regardless of the type of payment object reader, POS terminal, web application, mobile application, POS topology, payment card, computer network, and environment.

[0228] Various figures included herein are flow charts illustrating example methods incorporating the techniques described herein. The methods described are explained for convenience and ease of understanding with reference to Figures 1, 12, and 13. However, the illustrated methods are not limited to being performed using the components set forth in Figures 1, 12, and 13, and such components are not limited to performing the methods illustrated herein.

[0229] Furthermore, the methods described above are illustrated as a collection of blocks in a logical flow graph, which represent sequences of operations that may be implemented in hardware, software, or a combination thereof. In the software context, the blocks represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by a processor, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as limiting, and any number of the described blocks may be combined in any order and / or in parallel to perform processing. In some embodiments, one or more blocks of processing may be omitted entirely. Furthermore, the methods may be combined, in whole or in part, with each other or with other methods.

[0230] A. A method implemented by at least one server computing device of a service provider, the method comprising: accessing identification information associated with (i) a physical store of a merchant associated with the service provider and (ii) a designated seating area within the physical store; generating an identification code based at least in part on the identification information, the identification code being configured to be located proximate to the designated seating area at the physical store; receiving an indication of the identification code from a computing device of a customer within the designated seating area at the physical store; downloading a progressive web application onto the computing device of the customer via a web browser on the computing device of the customer; the progressive web application being configured to (i) execute client-side code in a background thread separate from a main thread of the web browser on the computing device of the customer; (ii) providing a scriptable network proxy to a web browser for programmatically managing communications between a progressive web application and at least one server computing device of a service provider, wherein at least a portion of the progressive web application is cached by the object for future interactions with the progressive web application, wherein the progressive web application causes a menu of items offered for sale by a merchant to be presented via the web browser; receiving from the computing device of the customer an order for items from the menu of items via input received by the progressive web application, the order being associated with the identification of the physical store and the identification of the designated seating area; receiving payment data associated with a payment instrument of the customer; and processing payment for at least the order based at least in part on the payment data.

[0231] B. The method of paragraph A, wherein the indication of the identification code is associated with a customer identifier, and the method further includes accessing customer data associated with the customer identifier and generating the menu of items based at least in part on the customer data.

[0232] C. The method of claim A or B, wherein payment data is received while the customer is at the physical store or after the customer has left the physical store.

[0233] D. The method of any of paragraphs A-C, wherein the order is a first order, the item is a first item, the first order is associated with a first time, and the method further includes receiving, via another input received by the progressive web application, a second order for a second item in the menu of items at a second time after the first time, and the web browser remains open between the first time and the second time.

[0234] E. The method of any of paragraphs A-D, wherein the order is associated with a first time, and the method further includes receiving at least one of a tip or feedback associated with the order at a second time after the first time via another input received by the progressive web application, and wherein the web browser remains open between the first time and the second time.

[0235] F. The method of any of paragraphs A-E, further including receiving an indication from the merchant's computing device that the designated seating area has been added to the physical store prior to generating the identification information, and generating the identification code is further based at least in part on receiving the indication.

[0236] G. A system comprising: one or more processors; and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the system to: associate an identification of a physical location associated with a merchant with an identification code; receive the identification code from a customer's computing device; cause merchant data associated with the merchant to be presented via a web browser of the customer's computing device based at least in part on receiving the identification code, the merchant data being presented via the web browser by a progressive web application downloaded onto the customer's computing device; receive an indication of input received via the progressive web application from the customer's computing device; and perform an action based at least in part on the input.

[0237] H. The system of paragraph G, wherein the identification code includes at least one of a barcode, a quick response (QR) code, or a unique ID of a radio frequency identification (RFID) device.

[0238] I. The system described in paragraphs G or H, wherein the physical location includes at least one of the merchant's physical store or a designated seating area at the physical store, and wherein the instructions, when executed by the one or more processors, further configure the system to generate the identification code based at least in part on at least one of (i) an identification of the physical store or (ii) an identification of the designated seating area, and wherein the identification code is located proximate to the designated seating area at the physical store.

[0239] J. The system of any of paragraphs G-I, wherein the input is associated with a transaction, and the instructions, when executed by the one or more processors, further cause the system to receive payment data associated with the customer's payment instrument, the payment data being received before, at the beginning, during, at the end, or after the transaction, the payment data being received from (i) the customer's computing device via the progressive web application, (ii) the merchant's computing device via a merchant application installed thereon, or (iii) a data store storing the payment data; and process payment for the transaction based at least in part on the payment data.

[0240] K. The system of paragraph J, wherein at least a portion of the merchant data is presented via an instant application before the merchant data is presented via the web browser by the progressive web application.

[0241] L. The system of any of paragraphs G-K, wherein the instructions of the identification code are associated with a customer ID, and the instructions, when executed by the one or more processors, further cause the system to access customer data associated with the customer ID and determine at least one of the merchant data or offers associated with the merchant data based at least in part on the customer data.

[0242] M. The system of any of paragraphs G-L, wherein the merchant data includes a menu of items available for sale by the merchant and the input includes an order for the item.

[0243] N. The system of paragraph M, wherein the input is associated with a first time, and the instructions, when executed by the one or more processors, further cause the system to receive from the computing device of the customer another indication of another input received by the progressive web application at a second time, the another input including at least one of another order, reservation, tip, or feedback for another item, and the web browser remains open between the first time and the second time.

[0244] O. The system of any of clauses G-N, wherein the merchant data includes a layout of the merchant's physical store and the input includes a request for a designated seating area associated with the physical store.

[0245] P. The system described in any of paragraphs G to O, wherein the progressive web application (i) is configured to execute client-side code in a background thread separate from the main thread of the web browser of the customer's computing device, and (ii) is associated with an object that provides the web browser with a scriptable network proxy for programmatically managing communications between the progressive web application and at least one server computing device of a service provider, and at least a portion of the progressive web application is cached by the object for future interactions with the progressive web application.

[0246] Q. One or more computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including associating an identification of a physical location associated with a merchant with an identification code of an identification device; receiving the identification code of the identification device from a customer's computing device; causing a menu of items for sale by the merchant to be presented via a web browser of the customer's computing device based at least in part on receiving the identification code of the identification device, the menu of items being presented via the web browser by a progressive web application downloaded onto the customer's computing device; receiving a first order for a first item from the menu of items via a first input instruction received by the progressive web application at a first time from the customer's computing device; receiving payment data associated with the customer's payment device; and processing payment for at least the first item based at least in part on the payment data.

[0247] R. The one or more computer-readable media described in paragraph Q, wherein the operations further include associating the first item with a data structure representing an open ticket; receiving a second order for a second item from the menu of items via a second input received by the progressive web application from the computing device of the customer at a second time, the second time being after the first time; associating the second item with the data structure; and processing payment for the first item and the second item at a third time after the first and second times.

[0248] S. The one or more computer-readable media described in paragraphs Q or R, wherein the operations further include receiving a second order associated with a different customer from the merchant's computing device, the second order being received via (i) an online ordering user interface or (ii) an application associated with the merchant's computing device; adding the second order to a queue containing the first order; and causing at least a portion of the queue to be presented via at least one of the customer's computing device or the merchant's computing device.

[0249] T. The one or more computer-readable media described in any of paragraphs Q-S, wherein the operations further include: accessing, based at least in part on receiving the identification code, data associated with an online menu to be presented via an online ordering user interface; and modifying the data associated with the online menu to generate a menu of the items to be presented via the web browser by the progressive web application.

[0250] Although the exemplary sections above are described with respect to one particular implementation, it should be understood that in the context of this document, the content of the exemplary sections may also be implemented via a method, a device, a system, a computer-readable medium, and / or another implementation. Furthermore, any of Examples A-T may be implemented alone or in combination with any other one or more of Examples A-T.

[0251] Having described one or more examples of the techniques described herein, various modifications, additions, permutations, and equivalents thereof fall within the scope of the techniques described herein.

[0252] In the description of the embodiments, reference is made to the accompanying drawings, which form a part of this specification, and which show, by way of example, specific embodiments of the claimed invention. It is understood that other embodiments may be used and that changes or modifications, such as structural changes, may be made. Such examples, modifications, or modifications do not necessarily depart from the intended scope of the claimed invention. While steps herein may be presented in a particular order, in some cases the order can be changed so that certain inputs are provided at different times or in a different order without changing the functionality of the systems and methods described. The disclosed procedures may also be performed in a different order. Furthermore, the various operations need not be performed in the order disclosed herein; other examples using alternative orders of operations can be readily implemented. In addition to being reordered, computations may also be decomposed into subcomputations that have the same result.

Claims

1. 1. A system comprising: one or more processors; One or more computer-readable media, When executed by the one or more processors, the system: Associating an identification of a physical location associated with the merchant with the identification code; receiving said identification code from the customer's computing device; and based at least in part on receiving the identification code, causing merchant data associated with the merchant to be presented via a web browser on the customer's computing device, wherein the merchant data is presented via the web browser by a progressive web application downloaded onto the customer's computing device via the web browser; receiving an indication of input received via the progressive web application from the computing device of the customer; performing an action based at least in part on said input; content presented via the progressive web application is updated while the web browser associated with the progressive web application remains open; one or more computer-readable media that store instructions; system.

2. the identification code comprises at least one of a barcode, a quick response (QR) code, or a unique ID of a radio frequency identification (RFID) device; The system of claim 1 .

3. the physical location includes at least one of the merchant's physical store or a designated seating area at the physical store, and the instructions, when executed by the one or more processors, further cause the system to generate the identification code based at least in part on at least one of (i) an identification of the physical store or (ii) an identification of the designated seating area, and the identification code is configured to be located proximate to the designated seating area at the physical store. The system of claim 1 .

4. The input is associated with a transaction, and the instructions, when executed by the one or more processors, further cause the system to: receiving payment data associated with the customer's payment instrument, the payment data being received before, at the beginning, during, at the end, or after the transaction, the payment data being received from (i) the customer's computing device via the Progressive Web Application, (ii) the merchant's computing device via a merchant application installed on the merchant's computing device, or (iii) a data store storing the payment data; processing payment for the transaction based at least in part on the payment data; The system of claim 1 .

5. at least a portion of the merchant data is presented via an instant application before the merchant data is presented via the web browser by the progressive web application; The system of claim 4.

6. The indication of the identification code is associated with a customer ID, and the instructions, when executed by the one or more processors, further cause the system to: accessing customer data associated with said customer ID; determining at least one of the merchant data or offers associated with the merchant data based at least in part on the customer data; The system of claim 1 .

7. the merchant data includes a menu of items available for sale by the merchant, and the input includes an order for the item; The system of claim 1 .

8. the input is associated with a first time, and the instructions, when executed by the one or more processors, further cause the system to receive from the computing device of the customer another indication of another input received by the progressive web application at a second time, the another input including at least one of another order, reservation, tip, or feedback for another item, and the web browser remains open between the first time and the second time. The system of claim 7.

9. the merchant data includes a layout of the merchant's physical store, and the input includes a request for a designated seating area associated with the physical store; The system of claim 1 .

10. The progressive web application (i) is configured to execute client-side code in a background thread separate from the main thread of the web browser of the customer's computing device; and (ii) is associated with an object that provides the web browser with a scriptable network proxy for programmatically managing communications between the progressive web application and at least one server computing device of a service provider, wherein at least a portion of the progressive web application is cached by the object for future interactions with the progressive web application. The system of claim 1 .

11. one or more computer programs, When executed by one or more processors, the one or more processors: associating an identification of a physical location associated with the merchant with an identification code of the identification device; receiving the identification code of the identification device from a customer computing device; causing, based at least in part on receiving the identification code of the identification device, to present a menu of items for sale by the merchant via a web browser on the customer's computing device, the menu of items being presented via the web browser by a progressive web application downloaded onto the customer's computing device via the web browser; receiving a first order for a first item from the menu of items via a first input indication received by the progressive web application at a first time from the computing device of the customer; receiving payment data associated with the customer's payment instrument; processing payment for at least the first item based at least in part on the payment data; updating content presented via the progressive web application while the web browser associated with the progressive web application remains open; One or more computer programs.

12. The operation is Associating the first item with a data structure representing an open ticket; receiving a second order for a second item from the menu of items via a second input received by the progressive web application from the computing device of the customer at a second time, the second time being after the first time; Associating the second item with the data structure; processing payment for the first item and the second item at a third time after the first time and the second time. One or more computer programs according to claim 11.

13. The operation is receiving a second order associated with a different customer from the merchant's computing device, the second order being received via (i) an online ordering user interface or (ii) an application associated with the merchant's computing device; adding the second order to a queue containing the first order; causing at least a portion of the queue to be presented via at least one of the customer's computing device or the merchant's computing device. One or more computer programs according to claim 11.

14. The operation is accessing data associated with an online menu presented via an online ordering user interface based at least in part on receiving the identification code; modifying the data associated with the online menu to generate a menu of the items to be presented by the progressive web application via the web browser. One or more computer programs according to claim 11.

15. 1. A method performed by at least one server computing device of a service provider, the method comprising: accessing an identification associated with (i) a merchant physical store associated with the service provider, and (ii) a designated seating area within the physical store; generating an identification code based at least in part on the identification, the identification code configured to be placed proximate to the designated seating area at the physical store; receiving an indication of the identification code from a computing device of a customer at the designated seating area at the physical store; causing a progressive web application to be downloaded onto the customer's computing device via a web browser on the customer's computing device, the progressive web application causing a menu of items offered for sale by the merchant to be presented via the web browser; receiving an order for an item from the menu of items via input received by the progressive web application from the computing device of the customer, the order associated with an identification of the physical store and an identification of the designated seating area; receiving payment data associated with the customer's payment instrument; processing payment for at least the order based at least in part on the payment data; updating content presented via the progressive web application while the web browser associated with the progressive web application remains open; method.

16. The progressive web application is associated with an object that (i) is configured to execute client-side code in a background thread separate from a main thread of the web browser of the customer's computing device, and (ii) provides the web browser with a scriptable network proxy to programmatically manage communications between the progressive web application and the at least one server computing device of the service provider; at least a portion of the progressive web application is cached by the object for future interactions with the progressive web application; 16. The method of claim 15.

17. The indication of the identification code is associated with a customer ID, and the method further comprises: accessing customer data associated with the customer ID; generating the menu of items based at least in part on the customer data.

16. The method of claim 15.

18. The payment data is received while the customer is at the physical store or after the customer has left the physical store.

16. The method of claim 15.

19. the order is a first order, the item is a first item, the first order is associated with a first time, the method further includes receiving, via another input received by the progressive web application, a second order for a second item in the menu of items at a second time after the first time, wherein the web browser remains open between the first time and the second time.

16. The method of claim 15.

20. The order is associated with a first time, the method further including receiving at least one of a tip or feedback associated with the order at a second time after the first time via another input received by the progressive web application, the web browser remaining open between the first time and the second time.

16. The method of claim 15.

21. and further including receiving, from the merchant's computing device, an indication that the designated seating area has been added to the physical store prior to generating the identification, and generating the identification code is further based at least in part on receiving the indication.

16. The method of claim 15.

Images