System and method for e-commerce checkout with delayed loading of checkout options

Abstract

Systems and methods are provided for progressively presenting checkout options during a checkout transaction. During the course of the transaction, a user interface is presented having option categories, where each option category has a set of checkout options. Requests associated with the checkout options are transmitted, where at least one of the transmitted requests is transmitted to a remote third party. One or more of the checkout options are identified as a first set of options and the other checkout options are identified as a second set of options. The user interface is updated to display the first set of options and a selectable UI element before the second set of options are displayed, where the second set of options are all hidden and not displayed until the selectable UI element is selected. The checkout transaction can be completed using one of the options in the first set of options while the second set of options are not displayed.

Description

Technical Field

[0001] This disclosure relates to systems and methods for completing checkout transactions. In particular, this disclosure relates to systems and methods for enabling checkout transactions to be completed even when not all possible checkout options have been loaded, such as when checkout options may be loaded late. Background Art

[0002] Customers who wish to purchase products using an online service (e.g., an online e-commerce platform or a dedicated online checkout service) may need to complete a checkout transaction to finalize the purchase. During a checkout transaction (or simply checkout), customers are typically presented with selectable options for different components or aspects of the transaction that cannot be determined in advance. These components / aspects can include services that involve operations provided by third-party service providers, such as shipping. Since third-party services and rates often change, many of these selectable options often require an external call (such as an application programming interface (API) call) from the online platform to an external remote server of the third-party service provider to determine their current rates.

[0003] External calls made during checkout typically require round-trip requests and responses from third-party applications hosted on remote servers. The speed of such external calls can depend on the level of technical infrastructure provided by the third party and / or connectivity providers, server speed, and network connection speed. Therefore, the latency of such external calls can be largely caused by latencies beyond the control of the online service providing the checkout.

[0004] When such latency is encountered, a loading cursor (e.g., a spinner) is presented to the customer in the checkout user interface (UI) to indicate that checkout options are being loaded. The customer then has to wait for all options to be loaded and displayed before being able to proceed with the checkout transaction. Summary of the Invention

[0005] In existing online checkout systems, all checkout options need to be loaded and available for the user to select before a checkout transaction can be completed. If some checkout options require a response from a remote third-party server, waiting for the response can cause delays in the checkout transaction.

[0006] However, requiring all external calls (i.e., receiving responses from remote servers) to be completed before the checkout transaction itself is completed may be an inefficient use of computer resources. Loading and displaying all third-party checkout options for multiple option categories can be both time-consuming and consume the computer resources (e.g., including computer processing power, memory resources, etc.) of the online service providing the checkout process, especially since the customer may only need to select one checkout option from each option category to complete the transaction. Further, the responses to external calls consume network resources (e.g., network bandwidth, network ports, etc.), even if these responses may be for options that are ultimately not selected by the customer (which means the information and data carried in these responses are wasted). Thus, ultimately, for unselected checkout options, computer resources (including the processing power, memory storage, and bandwidth used to make all third-party calls and to load and display all checkout options for all option categories) are essentially "wasted".

[0007] Further, the delays that occur during checkout may cause confusion for the customer, as the customer may feel or perceive the UI as unresponsive. This may cause the customer to cancel their transaction, leave / reload the page, or the transaction to be interrupted, etc., all of which also further waste computer resources (e.g., reloading the checkout page wastes processing power and memory resources). Even if the customer does not reload the checkout page, there is still a waste of computer resources because the memory resources required to execute the checkout transaction are occupied (and not available for other processes) until the checkout transaction is completed or abandoned. It should be understood that this waste is greatly amplified by the fact that a large number of customers may be trying to complete checkout using the online service simultaneously. Thus, delays in the checkout transaction not only cause inconvenience to the customer, but may also result in a significant consumption of computer resources.

[0008] Accordingly, the present disclosure relates to methods and systems for enabling a checkout transaction to be completed even when not all possible checkout options have been loaded. In particular, one or more of the possible checkout options may be loaded lazily. The example provided by the present disclosure has the technical improvement that the checkout options can be automatically classified into a first group of options and a second group of options (such as fast-loading or slow-loading). The second group / slow-loading options (also known as lazy-loading options) are hidden and not displayed until the customer selects a UI element (e.g., an expander), while at least one option in the first group / fast-loading options is immediately displayed (e.g., as soon as the information of this at least one option to be displayed becomes available). The second group of options can be loaded lazily (e.g., loaded and available for display only after a certain amount of time). Even if the second group of options has not been loaded or is not available, the customer can use at least one option in the first group of options to complete the checkout transaction. The technical advantage provided by this is that the checkout transaction can be completed without wasting time and / or computer resources in loading all possible checkout options (including third-party checkout options that require an external call to a remote server).

[0009] In some examples, the present disclosure describes a system that includes: at least one processor and at least one memory storing instructions executable by the at least one processor to cause the system to: provide, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including option categories associated with the checkout transaction, the option categories having an associated set of checkout options; transmit, via the network, requests associated with respective ones of the checkout options, at least one of the transmitted queries being transmitted to a remote third-party server, where selecting one of the checkout options is required to complete the checkout transaction; identify one or more of the checkout options as a first group of options and the other checkout options as a second group of options; after receiving responses to one or more of the requests and before displaying the second group of options, send an indication to the remote client device to update the user interface to display at least one of the checkout options in the first group of options; send an indication to the remote client device to display a selectable user interface element, where all of the second group of options are hidden and not displayed until the selectable user interface element is selected; and use one of the checkout options in the first group of options displayed on the user interface to enable the checkout transaction to be completed before receiving responses to the respective queries for all of the options in the second group of options.

[0010] In the above example, the first group of options can be fast-loading options, and the second group of options can be slow-loading options, where the fast-loading options are loaded faster than the slow-loading options.

[0011] In any of the above examples, one of the first set of options shown can be automatically selected as the default option, and the at least one processor can be further configured to execute the instructions to cause the system to: in response to selecting the option to complete the checkout transaction, trigger the completion of the checkout transaction using the default option.

[0012] In any of the above examples, the at least one processor can be further configured to execute the instructions to cause the system to: in response to selecting the selectable user interface element at the remote client device, send an indication to the remote user device to update the user interface such that: any remaining fast load options are displayed, and a load indicator for the slow load options is displayed when all responses to the corresponding queries for the slow load options have not been received; or the slow load options are displayed when all responses to the corresponding queries for the slow load options have been received.

[0013] In any of the above examples, the at least one processor can be further configured to execute the instructions to cause the system to transmit the queries for the checkout options in response to detecting a trigger event.

[0014] In any of the above examples, the option category can be related to shipping, and the trigger event can be receipt of a delivery address.

[0015] In any of the above examples, the at least one processor can be further configured to execute the instructions to cause the system to determine, based on any response to the queries, whether each of the checkout options belongs to the first set of options or the second set of options.

[0016] In any of the above examples, determining whether each of the checkout options is the first set of options or the second set of options can be made based on at least one of the following: a threshold cutoff time for receiving a response; a historical measurement of responses to receiving similar queries; an analysis of network communications and / or fulfillment network configuration associated with each query; and merchant configuration.

[0017] In any of the above examples, the available checkout options can be determined to be fast load or slow load based on the threshold cutoff time, which is dynamically determined for the customer based on the customer's historical response time.

[0018] In any of the above examples, the at least one processor may further be configured to execute the instructions to cause the system to: identify faster and slower loading options among the slow loading options, where the slower slow loading options take more time to receive a response to a corresponding query than the faster slow loading options; and in response to selection of the selectable user interface element: display any remaining fast loading options; and display the faster slow loading options after receiving a response to the corresponding query for the faster slow loading options and before displaying the slower slow loading options.

[0019] In some example aspects, the present disclosure describes a method that includes: providing, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options having an associated set of checkout options; transmitting, via the network, requests associated with respective ones of the checkout options, at least one of the transmitted queries being transmitted to a remote third-party server, where selection of one of the checkout options is required to complete the checkout transaction; identifying one or more of the checkout options as a first set of options and identifying the other checkout options of the checkout options as a second set of options; after receiving a response to one or more of the requests and before displaying the second set of options, sending an indication to the remote client device to update the user interface to display at least one option of the first set of options; sending an indication to the remote client device to display a selectable user interface element on the user interface, where, before selection of the selectable user interface element, all of the second set of options are hidden from view; and enabling the checkout transaction to be completed using at least one of the at least one option of the first set of options displayed on the user interface before receiving a response to the corresponding queries for all of the options of the second set of options.

[0020] In some examples, the method may include any steps performed by a processor described herein.

[0021] In some example aspects, the present disclosure describes a computer-readable medium storing instructions that, when executed by a processor of a system, cause the system to: provide, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options having an associated set of checkout options; transmit, via the network, requests associated with respective ones of the checkout options, at least one of the transmitted requests being transmitted to a remote third-party server, wherein selecting one of the checkout options is required to complete the checkout transaction; identify one or more of the checkout options as fast-load options and identify other ones of the checkout options as slow-load options; after receiving a response to one or more of the requests and before displaying the slow-load options, send an indication to the remote client device to update the user interface to display at least one of the fast-load options; send an indication to the remote client device to display selectable user interface elements on the user interface, wherein, before the selectable user interface elements are selected, all of the slow-load options are hidden from view; and

[0022] Before receiving responses to respective requests for all of the slow-load options, use one of the at least one of the fast-load options displayed on the user interface to enable the checkout transaction to be completed.

[0023] In some examples, the computer-readable medium, when executed by a processor, may cause the system to perform any of the methods described herein.

[0024] Accordingly, a method, a system, a computer program, and a computer-readable medium are provided as detailed in the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Reference will now be made, by way of example, to the accompanying drawings, which show example embodiments of the present application, in which:

[0026] Figure 1 is a block diagram of an example e-commerce platform in which the examples described herein may be implemented;

[0027] Figure 2 is an example home page for an administrator that may be accessed via Figure 1 the e-commerce platform;

[0028] Figure 3 is Figure 1 another block diagram of the e-commerce platform showing some details related to application development;

[0029] Figure 4 is a display ofFigure 1 Block diagram of an example implementation of an e - commerce platform;

[0030] Figure 5 is Figure 1 Another block diagram of the e - commerce platform, showing some details related to the progressive loading of checkout options;

[0031] Figure 6 is a signaling diagram showing an example communication between a user device and a conventional e - commerce platform during a typical checkout transaction;

[0032] Figure 7 is a signaling diagram showing an example communication between a user device and a checkout option manager for implementing progressive loading of checkout options according to an example of the present disclosure during a checkout transaction;

[0033] Figure 8 is a flowchart showing an example method for progressive loading of checkout options according to an example of the present disclosure, which can be implemented using a checkout option manager; and

[0034] Figures 9A to 9D Shows some example presentation formats for progressive loading of checkout options.

[0035] Similar reference numerals may be used in different figures to represent similar components. Detailed Description

[0036] The present disclosure will be described in the context of an e - commerce platform discussed below. However, it should be understood that this discussion is for illustrative purposes only and is not intended to be limiting. Further, it should be understood that the present disclosure may be implemented in other contexts and is not necessarily limited to implementation in an e - commerce platform. For example, a checkout transaction for completing an online purchase may be provided by an online checkout service, which is not necessarily part of an e - commerce platform. In another example, an online store that is not hosted by an e - commerce platform (i.e., the online store is an independent online store) may provide an online checkout service. Other such possibilities are contemplated within the scope of the present disclosure.

[0037] Example E - commerce Platform

[0038] Although integration with a commerce platform is not required, in some embodiments, the methods disclosed herein may be performed on or associated with a commerce platform such as an e - commerce platform. Accordingly, an example of a commerce platform will be described.

[0039] Figure 1Shows an example e-commerce platform 100 according to an embodiment. The e-commerce platform 100 can be used to provide products and services of merchants to customers. Although this disclosure contemplates using devices, systems, and processes to purchase products and services, for simplicity, the description herein will refer to products. All references to products in this disclosure should also be understood as references to products and / or services, including, for example, physical products, digital content (e.g., music, video, and games), software, tickets, subscriptions, services to be provided, etc.

[0040] Although this disclosure contemplates throughout that'merchants' and 'customers' can be more than just individuals, for simplicity, the description herein generally refers to merchants and customers themselves. All references to merchants and customers in this disclosure should also be understood as references to groups of individuals, companies, enterprises, computing entities, etc., and can represent for-profit or non-profit product exchanges. Further, although this disclosure refers throughout to'merchants' and 'customers' and describes their roles themselves, the e-commerce platform 100 should be understood as more generally supporting users in an e-commerce environment, and all references to merchants and customers in this disclosure should also be understood as references to users, such as, for example, merchant users (e.g., sellers, retailers, wholesalers, or product providers), customer users (e.g., buyers, purchasing agents, consumers, or product users), potential users (e.g., users who are browsing but have not committed to a purchase, users evaluating the e-commerce platform 100 for potential use in marketing and selling products, etc.), service provider users (e.g., shipping provider 112, financial providers, etc.), corporate or enterprise users (e.g., company representatives who purchase, sell, or use products; enterprise users; customer relationship or customer management agents, etc.), information technology users, computing entity users (e.g., computer robots used to purchase, sell, or use products), etc. In addition, it can be recognized that although in one context a given user can play a given role (e.g., as a merchant) and their associated device can be referred to accordingly (e.g., as a merchant device), in another context the same person can play a different role (e.g., as a customer) and the same or another associated device can be referred to accordingly (e.g., as a customer device). For example, a person can be a merchant of one type of product (e.g., shoes) and a customer / consumer of other types of products (e.g., groceries). In another example, a person can be both a consumer and a merchant of the same type of product. In a specific example, a merchant engaged in trading a particular category of goods can act as a customer for the same category of goods when ordering from a wholesaler (where the wholesaler acts as a merchant).

[0041] The e-commerce platform 100 provides online services / facilities for merchants to manage their businesses. The facilities described herein are shown as part of the platform 100, but may also be configured, in whole or in part, separately from the platform 100 as a stand-alone service. Additionally, in some embodiments, such facilities may alternatively or additionally be provided by one or more providers / entities.

[0042] In Figure 1 the example, the facilities are deployed by a machine, service, or engine that executes computer software, modules, program code, and / or instructions on one or more processors, which may be part of the platform 100 or external to the platform as described above. Merchants can use the e-commerce platform 100 to implement or manage commerce with customers, such as through an online store 138, applications 142A-B, channels 110A-B, and / or through a point-of-sale (POS) device 152 at a physical location (e.g., a brick-and-mortar store or other location, such as through a kiosk, terminal, reader, printer, 3D printer, etc.) to implement an e-commerce experience with customers. A merchant can use the e-commerce platform 100 as the sole commerce presence with customers or in combination with other merchant commerce facilities, such as through a physical store (e.g., a 'brick-and-mortar' retail store), a merchant off-platform website 104 (e.g., a commercial Internet website or other Internet or network property or asset supported by or on behalf of the merchant and separate from the e-commerce platform 100), an application 142B, etc. However, even these 'other' merchant commerce facilities can be combined with or communicate with the e-commerce platform 100. For example, the POS device 152 in a merchant's physical store is linked to the e-commerce platform 100, and the merchant off-platform website 104 is bound to the e-commerce platform 100, such as by linking the content of the off-platform merchant website 104 to the 'buy button' of the online store 138.

[0043] The online store 138 can represent a multi-tenant facility that includes multiple virtual storefronts. In an embodiment, a merchant can configure and / or manage one or more storefronts in the online store 138, for example, via a merchant device 102 (such as a computer, laptop, mobile computing device, etc.), and offer products to customers through a variety of different channels 110A-B (such as the online store 138; the applications 142A-B; a physical storefront, via a POS device 152; an e-marketplace, such as via an e-purchase button integrated into a website or a social media channel, such as on a social network, a social media page, a social media messaging system). A merchant can sell across the channels 110A-B and then manage their sales through the e-commerce platform 100, where the channel 110A can be provided as a facility or service either internal or external to the e-commerce platform 100. Additionally or alternatively, a merchant can sell at their physical retail store, at a pop-up store, through wholesale, over the phone, etc., and then manage their sales through the e-commerce platform 100. A merchant can adopt all or any combination of these operating modes. It is noted that it is possible that by adopting multiple and / or specific combinations of these modes, a merchant can increase the probability of sales and / or the volume of sales. In this disclosure, the terms "online store 138" and "storefront" can be used synonymously to refer to the online e-commerce service provided by a merchant through the e-commerce platform 100, where the online store 138 can refer to a collection of storefronts supported by the e-commerce platform 100 (for example, for one or more merchants), or refer to the storefront of a single merchant (such as the merchant's online store).

[0044] In some embodiments, a customer can interact with the platform 100 via a customer device 150 (such as a computer, laptop, mobile computing device, etc.), a POS device 152 (such as a retail device, a self-service kiosk, an automated (self-checkout) checkout system, etc.), and / or any other commercial interface device known in the art. The e-commerce platform 100 can enable a merchant to contact a customer through the online store 138, through the applications 142A-B, through the POS device 152 at a physical location (such as the merchant's storefront or other location), communicate with the customer via the electronic communication facility 129, etc., in order to provide a system for contacting a customer and facilitating merchant services for a real or virtual path that can be used to contact and interact with the customer.

[0045] In some embodiments, and as further described herein, the e - commerce platform 100 may be implemented via a processing facility. Such a processing facility may include a processor and a memory. The processor may be a hardware processor. The memory may be and / or may include a non - transitory computer - readable medium. The memory may be and / or may include random access memory (RAM) and / or a persistent storage device (e.g., a magnetic storage device). The processing facility may store (e.g., in the memory) a set of instructions that, when executed, cause the e - commerce platform 100 to perform the e - commerce functions and support functions described herein. The processing facility may be one or more or may be part of a server, a client, a network infrastructure, a mobile computing platform, a cloud computing platform, a fixed computing platform, and / or other computing platforms, and may provide an electronic connection and communication between components of the e - commerce platform 100, merchant devices 102, payment gateways 106, applications 142A - B, channels 110A - B, shipping providers 112, customer devices 150, point - of - sale devices 152, etc. In some implementations, the processing facility may be or may include one or more such computing devices working in concert. For example, multiple collaborative computing devices may act as / provide the processing facility. The e - commerce platform 100 may be implemented as one or more of the following or used to implement them: cloud computing services, software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS), desktop as a service (DaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), information technology management as a service (ITMaaS), etc. For example, the underlying software (e.g., the online store 138) implementing the facilities described herein may be provided as a service and centrally hosted (e.g., and then accessed by a user via a web browser or other application, and / or via a customer device 150, a POS device 152, etc.). In some embodiments, elements of the e - commerce platform 100 may be implemented to operate and / or integrate with various other platforms and operating systems.

[0046] In some embodiments, facilities of the e - commerce platform 100 (e.g., the online store 138) may provide content to the customer device 150, for example, via a network (using data 134) connected to the e - commerce platform 100. For example, the online store 138 may provide or send content in response to a request for data 134 from the customer device 150, where a browser (or other application) is connected to the online store 138 via a network connection using a network communication protocol (e.g., the Internet protocol). The content may be written in a machine - readable language and may include hypertext markup language (HTML), a templating language, JavaScript, etc. and / or any combination thereof.

[0047] In some embodiments, the online store 138 may be or may include a service instance that provides content to customer devices and allows customers to browse and purchase various available products (e.g., add products to a shopping cart, purchase via a buy button, etc.). Merchants can also customize the look and feel of their websites through a theme system, such as a theme system in which merchants can select and change the look and feel of their online store 138 by changing their theme while showing the same underlying product and business data within the product information of the online store. It is possible to further customize the theme through a theme editor (i.e., a design interface that enables users to flexibly customize the design of their websites). Additionally or alternatively, it is possible to use theme-specific settings to customize the theme, such settings being able to change aspects of a given theme (e.g., specific colors, fonts, and pre-built layout schemes). In some implementations, the online store may implement a content management system for website content. Merchants can employ such a content management system when creating blog posts or static pages and publishing them to their online store 138 (such as via blogs, articles, landing pages, etc.), as well as when configuring navigation menus. Merchants can upload images (e.g., products), videos, content, data, etc. to the e-commerce platform 100, such as for storage by the system (e.g., stored as data 134). In some embodiments, the e-commerce platform 100 may provide functions for manipulating such images and content, such as functions for resizing images, associating images with products, adding text and associating the text with images, adding images for new product variants, protecting images, etc.

[0048] As described herein, the e-commerce platform 100 can provide sales and marketing services for products to merchants through a variety of different channels 110A - B, which include, for example, the online store 138, the applications 142A - B, and through the physical POS device 152 described herein. The e-commerce platform 100 may additionally or alternatively include business support services 116, an administrator 114, a warehouse management system, etc. associated with operating an online business (such as providing one or more of a domain registration service 118 associated with their online store, a payment service 120 for facilitating transactions with customers, a shipping service 122 for providing customer shipping options for purchased products, a fulfillment service for managing inventory, a risk and insurance service 124 associated with product protection and liability, merchant billing, etc.). The services 116 may be provided via the e-commerce platform 100 or in association with external facilities, such as provided through a payment gateway 106 for payment processing, a shipping provider 112 for expediting product shipping, etc.

[0049] In some embodiments, the e-commerce platform 100 may be configured with a shipping service 122 (e.g., via an e-commerce platform shipping facility or via a third-party carrier) to provide various shipping-related information to merchants and / or their customers, such as shipping labels or freight information, real-time delivery updates, tracking, etc.

[0050] Figure 2 Depicts a non-limiting embodiment of the home page of the administrator 114. The administrator 114 may be referred to as a management console and / or an administrator console. The administrator 114 may show information regarding daily tasks, recent activities of the store, and subsequent steps that a merchant can take to establish their business. In some embodiments, a merchant may log in to the administrator 114 via a merchant device 102 (e.g., a desktop computer or a mobile device) and manage various aspects of their online store 138, such as viewing recent access or order activities of the online store 138, updating the online store 138 catalog, managing orders, etc. In some embodiments, a merchant may be able to access different parts of the administrator 114 by using a sidebar (such as Figure 2 the sidebar shown). Various interfaces for accessing and managing core aspects of a merchant's business (including orders, products, customers, available reports, and discounts) may be included in different parts of the administrator 114. The administrator 114 may additionally or alternatively include interfaces for managing the sales channels of the store, which include the online store 138, the (multiple) mobile applications (mobile apps) that customers can use to access the store, POS devices, and / or buy buttons. The administrator 114 may additionally or alternatively include interfaces for managing the applications (apps) installed on a merchant's account; and settings applied to the merchant's online store 138 and account. A merchant may use a search bar to find products, pages, or other information in their store.

[0051] More detailed information about the business and visitors of the merchant's online store 138 can be viewed through reports or metrics. Reports can include, for example, footfall reports, behavior reports, customer reports, financial reports, marketing reports, sales reports, product reports, and custom reports. A merchant may be able to view sales data for different channels 110A - B over different time periods (e.g., days, weeks, months, etc.), such as by using a drop - down menu. A data overview can also be provided for merchants who want to view the sales and engagement data of the store in more detail. An activity feed can be provided in the home page metrics section to show an overview of the activities on the merchant's account. For example, by clicking on the "View all recent activities" data panel button, a merchant may be able to see the most recent activity feed on their account for a longer time. The home page can show notifications about the merchant's online store 138, such as based on account status, growth, recent customer activities, order updates, etc. Notifications can be provided to help the merchant navigate through the workflows configured for the online store 138, such as payment workflows, order fulfillment workflows, order archiving workflows, return workflows, etc.

[0052] The e - commerce platform 100 can provide communication facilities 129 and associated merchant interfaces to enable electronic communication and marketing, such as using an electronic messaging facility to collect and analyze communication interactions between merchants, customers, merchant devices 102, customer devices 150, POS devices 152, etc., to aggregate and analyze the communication, such as to improve sales conversions, etc. For example, a customer may have a product - related question, which may generate a conversation between the customer and the merchant (or an automated - processor - based agent / chatbot representing the merchant). In such a case, the communication facility 129 is configured to request an automated response from the customer and / or provide suggestions to the merchant on how to respond, for example, to increase the probability of a sale.

[0053] The e-commerce platform 100 can provide financial facilities 120 for secure financial transactions with customers, such as through a secure card server environment. For example, in a Payment Card Industry Data (PCI) environment (such as a card server), the e-commerce platform 100 can store credit card information for financial verification, billing merchants, performing Automated Clearing House (ACH) transfers between the e-commerce platform 100 and the merchant's bank account, etc. The financial facilities 120 can also provide financial support to merchants and buyers, such as by lending funds (e.g., loans, cash advances, etc.) and providing insurance. In some embodiments, the online store 138 can support multiple independently managed storefronts and process a large amount of transaction data every day for various products and services. The transaction data can include: any customer information indicating a customer, customer account, or transaction made by a customer (such as contact information, billing information, shipping information, return / refund information, discount / promotion information, payment information) or online store events or information (such as page views, product search information (search keywords, click events), product reviews, abandoned purchases) and / or other transaction information associated with the business through the e-commerce platform 100. In some embodiments, the e-commerce platform 100 can store this data in the data facility 134. Referring again to Figure 1 , in some embodiments, the e-commerce platform 100 can include a business management engine 136, which can be configured, for example, to execute various workflows to automate tasks related to products, inventory, customers, orders, suppliers, reports, finance, risk, and fraud, etc., or for content management. In some embodiments, additional functionality can be provided additionally or alternatively through applications 142A - B to achieve greater flexibility and customization required to adapt to the growing variety of online stores, POS devices, products, and / or services. Application 142A can be a component of the e-commerce platform 100, while application 142B can be provided or hosted as a third-party service external to the e-commerce platform 100. The business management engine 136 can adapt to store-specific workflows and, in some embodiments, can be integrated with the administrator 114 and / or the online store 138.

[0054] Implementing the functionality as applications 142A - B can enable the business management engine 136 to remain responsive and reduce or avoid service degradation or more serious infrastructure failures, etc.

[0055] Although isolating online store data may be important for maintaining data privacy between the online store 138 and the merchant, there may also be reasons to collect and use cross-store data. For example, for an order risk assessment system or a platform payment facility, both of which require information from multiple online stores 138 to perform well. In some embodiments, it may be preferable to move these components out of the commerce management engine 136 and into their own infrastructure within the e-commerce platform 100.

[0056] The platform payment facility 120 is an example of a component that utilizes data from the commerce management engine 136 but is implemented as a separate component or service. The platform payment facility 120 can allow customers interacting with the online store 138 to have their payment information securely stored by the commerce management engine 136, such that the customer only needs to enter the payment information once. When the customer visits different online stores 138, even if they have never been there before, the platform payment facility 120 can call up their information to enable a faster and / or potentially less error-prone (e.g., by avoiding the incorrect typing of information that the customer might otherwise need to re-enter) checkout. This can provide a cross-platform network effect, where the e-commerce platform 100 becomes more useful to its merchants and buyers as more merchants and buyers join, such as because more customers check out more frequently due to the ease of customer purchases. To maximize the effect of this network, the payment information of a given customer can be accessible and globally available across multiple online stores 138.

[0057] For functions not included within the commerce management engine 136, the applications 142A-B provide a way to add features to the e-commerce platform 100 or to individual online stores 138. For example, the applications 142A-B may be able to access and modify data on the merchant's online store 138, perform tasks through the administrator 114, implement new flows for the merchant through a user interface (which is presented, for example, through an extension / API), etc. Merchants can be enabled to discover and install the applications 142A-B through the application search, recommendation, and support 128. In some embodiments, the commerce management engine 136, the applications 142A-B, and the administrator 114 can be developed to work together. For example, application extension points can be built within the commerce management engine 136, and the applications 142A and 142B can access these application extension points through the interfaces 140B and 140A to provide additional functionality, and these application extension points can be presented to the merchant in the user interface of the administrator 114.

[0058] In some embodiments, the applications 142A-B can provide functionality to merchants through the interfaces 140A-B. For example, the applications 142A-B can present transaction data to merchants (e.g., App: "Engine, present my app data in the mobile App or the administrator 114"), and / or the business management engine 136 can request the applications to perform tasks according to requirements (Engine: "App, give me the local tax calculation for this checkout").

[0059] The applications 142A-B can be connected to the business management engine 136 through the interfaces 140A-B (e.g., through REST (Representational State Transfer) and / or GraphQL API) so as to expose the functions and / or data available through and within the business management engine 136 to the functions of the applications. For example, the e-commerce platform 100 can provide the interfaces 140A-B for the APIs of the applications 142A-B, and these applications can be connected to products and services outside the platform 100. The flexibility provided by the use of the applications and the APIs (which is provided, for example, for application development) enables the e-commerce platform 100 to better adapt to the new and unique requirements of merchants or solve specific usage scenarios without constantly changing the business management engine 136. For example, the shipping service 122 can be integrated with the business management engine 136 through a shipping or carrier service API, enabling the e-commerce platform 100 to provide shipping service functionality without directly affecting the code running in the business management engine 136.

[0060] Depending on the implementation, the applications 142A-B can pull data on demand (e.g., customer creation events, product change events, or order cancellation events, etc.) or push data when updates occur using the API. A subscription model can be used to provide events to the applications 142A-B when events occur, or to provide updates on the changed state of the business management engine 136. In some embodiments, when changes related to an update event subscription occur, the business management engine 136 can issue a request, such as issuing it to a predefined callback URL. The body of the request can contain the new state of the object and a description of the action or event. The update event subscription can be created manually in the administrator facility 114 or automatically (e.g., via the API 140A-B). In some embodiments, the update events can be queued and processed asynchronously with the state change that triggers the update event, which can result in update event notifications that are not distributed in real time or near real time.

[0061] In some embodiments, the e-commerce platform 100 may provide one or more of application search, recommendation, and support 128. Application search, recommendation, and support 128 may include: developer products and tools for assisting in the development of applications, application data dashboards (e.g., providing a development interface to developers, application management to administrators, application customization to merchants, etc.), facilities for installing and providing access to applications 142A-B (e.g., for public access, such as in cases where criteria must be met before installation, or for private use by merchants), application search for enabling merchants to easily search for applications 142A-B that meet the needs of their online store 138, application recommendation for providing merchants with suggestions on how they can improve the user experience through their online store 138, etc. In some embodiments, applications 142A-B may be assigned application identifiers (IDs), such as for linking to applications (e.g., via an API), searching for applications, making application recommendations, etc.

[0062] Applications 142A-B may be broadly grouped into three categories: customer-facing applications, merchant-facing applications, integrated applications, etc. Customer-facing applications 142A-B may include the online store 138 or channels 110A-B, which are places where merchants can list products for purchase (e.g., online stores, applications for flash sales (e.g., merchant products or opportunistic sales opportunities from third-party sources), mobile store applications, social media channels, applications for providing wholesale purchases, etc.). Merchant-facing applications 142A-B may include applications that allow merchants to manage their online store 138 (e.g., via applications related to a network or website or related to a mobile device), operate their business (e.g., via applications related to a POS device), grow their business (e.g., via applications related to shipping (e.g., dropshipping), using automated agents, using process flow development and improvement), etc. Integrated applications may include applications that provide useful integrations for participating in business operations, such as shipping providers 112 and payment gateways 106.

[0063] Thus, the e-commerce platform 100 may be configured to provide an online shopping experience through a flexible system architecture that enables merchants to connect with customers in a flexible and transparent manner. A typical customer experience can be better understood through an example purchase workflow of an embodiment, in which a customer browses a merchant's products on channels 110A-B, adds the products intended for purchase to the shopping cart, checks out, and pays for the contents of the shopping cart, thereby creating an order for the merchant. The merchant can then review and fulfill (or cancel) the order. The product is then shipped to the customer. If the customer is not satisfied, they may return the product to the merchant.

[0064] In an example embodiment, a customer can browse a merchant's products through multiple different channels 110A-B (such as the merchant's online store 138; a physical storefront, via a POS device 152; an e-marketplace, via an e-purchase button integrated into a website or a social media channel). In some cases, the channels 110A-B can be modeled as applications 142A-B. The merchandising component in the commerce management engine 136 can be configured to create and manage product listings (e.g., using product data objects or models) to allow merchants to describe what they want to sell and where they sell it. The association between a product listing and a channel can be modeled as a product publication and accessed through the channel application (e.g., via a product listing API). A product can have many attributes and / or characteristics (such as size and color) and many variants that expand the available options to a specific combination of all attributes, such as a green variant with an extra-small size or a blue variant with a large size. A product may have at least one variant created for a product with no options (e.g., a "default variant"). To facilitate browsing and management, products can be grouped into collections, product identifiers (e.g., stock keeping units (SKUs)) can be provided for products, etc. Collections of products can be built by manually classifying products into one (e.g., a custom collection), by constructing a rule set for automatic classification (e.g., a smart collection), etc. A product listing can include 2D images, 3D images, or models that can be viewed through a virtual reality or augmented reality interface, etc.

[0065] In some embodiments, a shopping cart object is used to store or track products that a customer intends to purchase. The shopping cart object can be channel-specific and can consist of multiple shopping cart line items, where each shopping cart line item tracks the quantity of a specific product variant. Since adding a product to the shopping cart does not imply any commitment from the customer or the merchant, and the expected lifetime of a shopping cart can be on the order of a few minutes (rather than days), the shopping cart object / data representing the shopping cart can be persisted to a temporary data store.

[0066] Then the customer checks out. The checkout object or page generated by the commerce management engine 136 can be configured to receive customer information to complete the order, such as customer contact information, billing information, and / or shipping details. If the customer enters their contact information but does not make a payment, the e-commerce platform 100 can send a message to the customer device 150 (e.g., via an abandonment component) to encourage the customer to complete the checkout. For these reasons, the checkout object may have a much longer lifespan (hours or even days) than the shopping cart object and may therefore persist. The customer then pays for the contents of their shopping cart, creating an order for the merchant. In some embodiments, the commerce management engine 136 can be configured to communicate with various payment gateways and services 106 (e.g., online payment systems, mobile payment systems, digital wallets, credit card gateways) via a payment processing component. The actual interaction with the payment gateway 106 can be provided through a card server environment. An order is created at the end of the checkout process. The order is a sales contract between the merchant and the customer, where the merchant agrees to provide the goods and services listed on the order (e.g., order line items, shipping line items, etc.) and the customer agrees to provide the payment amount (including taxes). Once the order is created, an order confirmation notification can be sent to the customer and an order placement notification can be sent to the merchant via the notification component. When the payment processing job starts, inventory can be reserved to avoid overselling (e.g., the merchant can use an inventory strategy or configuration for each variant to control this behavior). The inventory reservation may have a very short time span (a few minutes) and may need to be very fast and scalable to support flash sales or "drops", during which discounts, promotions, or limited inventory of a product are offered to buyers at a specific location and / or during a specific (usually short) time. If the payment fails, the reservation is cancelled. After a successful payment and order creation, the reservation is converted into a persistent (long-term) inventory commitment allocated to a specific location. The inventory component of the commerce management engine 136 can record the storage location of the variant and can track the quantity of variants with inventory tracking enabled. This component can separate the product variant (a customer-facing concept representing a product listing template) from the inventory item (a merchant-facing concept representing an item whose quantity and location are managed). The inventory level component can track the quantity available for sale, committed to an order, or incoming from an inventory transfer component (e.g., a supplier).

[0067] Then, the merchant can review and fulfill (or cancel) the order. The review component of the commerce management engine 136 can implement the business processes used by the merchant to ensure that the order is suitable for fulfillment before actually fulfilling it. The order may be fraudulent, may require verification (e.g., ID check), may have a payment method that requires the merchant to wait to ensure they will receive their payment, etc. Risks and recommendations may persist in the order risk model. Order risks can be generated by fraud detection tools, submitted by third parties via the order risk API, etc. Before fulfillment, the merchant may need to capture payment information (e.g., credit card information) or wait to receive payment information (e.g., via bank transfer, check, etc.) before marking the order as paid. Now, the merchant can prepare the products to be shipped. In some embodiments, this business process can be implemented by the fulfillment component of the commerce management engine 136. The fulfillment component can group the order line items into logical fulfillment work units based on inventory location and fulfillment services. The merchant can review, adjust the work units, and trigger the relevant fulfillment services, such as the manual fulfillment services used when the merchant picks the products and packs them into boxes, purchases a shipping label, and enters its tracking number (e.g., at the location managed by the merchant), or simply mark the items as fulfilled. Alternatively, the API fulfillment services can trigger third-party applications or services to create a fulfillment record for the third-party fulfillment services. There are other possibilities for fulfilling the order. If the customer is not satisfied, they can return the product(s) to the merchant. The business process for the merchant to "cancel the sale" of the goods can be implemented by the return component. Returns can include various different actions, such as: restocking, where the product that was sold actually returns to the enterprise and can be sold again; refund, partially or fully returning the money collected from the customer; accounting adjustment, recording the refund amount (e.g., including whether there are any restocking fees, or whether the goods were not returned and remained with the customer); etc. Returns can represent a change to the sales contract (e.g., the order), and in this case, the e-commerce platform 100 can make the merchant aware of compliance issues regarding legal obligations (e.g., regarding taxes). In some embodiments, the e-commerce platform 100 can enable the merchant to track the sales contract over time, such as by implementing a sales model component (e.g., a date-based append-only ledger that records sales-related events occurring on the goods).

[0068] Figure 4 is a block diagram of an example hardware configuration of the e-commerce platform 100 that communicates with a third-party service provider 450 via a remote third-party server 460 (discussed further below) to implement the checkout component.

[0069] Note that different components of the e - commerce platform 100 (e.g., data facility 134, analytics 132, commerce management engine 136, and applications 142A - B) can be implemented in different hardware or software components, implemented on common hardware components or servers, or configured as common (integrated) services or engines in the e - commerce platform 100. In Figure 4 the example of Figure 4 , the e - commerce platform 100 includes a core server 410, a data server 420, and an application server 430, which communicate with each other (e.g., via wired connections and / or via wireless intranet connections). Each server 410, 420, 430 includes a corresponding processing device 412, 422, 432 (each processing device can be, for example, a microprocessor, a graphics processing unit, a digital signal processor, or other computing element), a corresponding memory 414, 424, 434 (each memory can be, for example, a random access memory (RAM), a read - only memory (ROM), a hard disk, an optical disk, a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc., and can include tangible memory or transient memory), and a corresponding communication interface 416, 426, 436 (each communication interface can include a transmitter, a receiver, and / or a transceiver for wired and / or wireless communication). The core server 410 can store instructions and perform operations related to the core capabilities of the e - commerce platform, such as providing administrator 114, analytics 132, core commerce facility 136, services 116, and / or financial facility 130, etc. The data server 420 can be used to implement the data facility 134, etc. The application server 430 can store instructions and perform operations related to the applications 142, such as storing instructions and data for the applications 142 and for implementing application development support 128.

[0070] Merchants and customers using the respective devices 102, 150, 152 can access the e - commerce platform 100 via one or more networks 440 (e.g., wired and / or wireless networks, including virtual private networks (VPNs), the Internet, etc.).

[0071] As described above, during a checkout transaction, selectable options can be provided to a customer for different categories of the transaction, such as selecting a shipping option, selecting a payment plan, applying a reward discount, etc. Many of these services may be provided by a third-party service provider 450, and thus external calls (such as API calls) need to be made to an external third-party server 460 of the third-party service provider 450. Such external calls typically require round-trip requests and responses during checkout. The external calls can be made directly to the third-party service provider 450 or through a third-party application that a merchant may have installed in its online store to manage checkout options. The third-party application is typically hosted on the third-party server 460, which is located at a remote and / or geographically distinct location from the servers 410, 420, 430.

[0072] Although Figure 4 illustrates an example hardware implementation of the e-commerce platform 100, it should be understood that other implementations are possible. For example, there can be a greater or lesser number of servers, the e-commerce platform 100 can be implemented in a distributed manner, or at least some of the memories 414, 424, 434 can be replaced with external storage devices or cloud-based storage devices, and other possible modifications can be made.

[0073] Figure 5 is another depiction of the e-commerce platform 100, omitting some details already referenced Figure 1 described and showing further details discussed below. In particular, Figure 5 illustrates some example details of the e-commerce platform 100 related to: progressive loading of checkout options, and enabling the checkout process to be completed even when some / all of the checkout options from, for example, a third-party service provider have not been loaded.

[0074] For simplicity, Figure 5 illustrates a single instance of the online store 138. However, it should be understood that multiple online stores 138 can exist on the e-commerce platform 100, each having a checkout transaction process. The checkout transaction process of the online store 138 is associated with the transaction input 312 and one or more option categories 314.

[0075] Each option category 314 can be related to aspects or categories of a checkout transaction that can only be determined or populated at checkout (i.e., cannot be pre-loaded). For example, the option category 314 can be related to shipping, installments, discounts, reward systems, subscriptions, tariffs, etc. In this regard, each option category 314 is associated with a set of checkout options 316, and as part of the checkout process, the user can or must select this set of checkout options to complete the transaction. The checkout options 316 cannot be pre-loaded because the checkout options require customer-specific information and / or purchase-specific information to be determined.

[0076] Customer-specific information and purchase-specific information constitute the transaction input 312. For example, if the option category is related to shipping, the customer-specific input can be the shipping address, and the purchase-specific input can be the value of the customer's shopping cart and the size and weight of the package. If the option category 314 is related to a membership reward program, the customer-specific input can be the customer's membership number, and the purchase-specific input can be the category of items in the customer's shopping cart (i.e., whether they are reward items or regular items).

[0077] The e-commerce platform 100 further includes a checkout option manager 350 that communicates with the online store 138. Generally, if a checkout transaction involves an option category 314, selecting one of the checkout options 316 under the option category 314 is required to complete the checkout transaction. Thus, as described in further detail below, the checkout option manager 350 is configured to identify and / or determine which options in the set of checkout options (for a given option category 314) belong to at least a first group / portion / group of checkout options and which options in the set of checkout options belong to at least a second group / portion / group of checkout options. Then, the checkout option manager 350 is configured to update the checkout UI, and the update is transmitted to cause the user device 150 to display or provide the first group of checkout options and the second group of checkout options to the user in different ways, such as at different times (i.e., progressively).

[0078] For example, the first group can be checkout options (such as flat rates obtained via a local database lookup) that can be loaded quickly enough to be presented to the customer immediately or with a short defined latency, and the second group can be checkout options that load slower / too slow to qualify for the first group (such as API calls to third parties for obtaining dynamic shipping rates). The second group of checkout options can be loaded lazily. For example, the second group (slower) checkout options can be hidden and not displayed, and can be displayed only after the customer selects a selectable user interface element (e.g., an expander or a spinner) in the checkout UI. However, the checkout option manager 350 enables the e-commerce platform 100 to complete a checkout transaction using one of the checkout options in the first group (faster) even when the second group (slower) checkout options have not been loaded (and thus are not displayed and not selectable in the checkout UI). In this way, the checkout option manager 350 allows the e-commerce platform 100 to complete the checkout process even when all checkout options 316 (such as from a third-party service provider 350) have not been received from the third-party server or displayed on the customer device 150.

[0079] An example checkout transaction using the checkout option manager 350 is now described. The checkout option manager 350 is initially activated by a trigger event, which is typically customer input entered in / at the customer device 150 and transmitted over the network to the e-commerce platform 100. The trigger event can be receipt of a shipping address during the checkout process, initialization of the checkout user interface, or the customer selecting an option to enable a particular category on the user interface, etc.

[0080] After detecting the trigger event, the checkout option manager 350 automatically makes a query to populate the checkout options 316 for each option category 314 involved. For example, in the case where the option category 314 is related to shipping, the trigger event can be receipt of the customer's shipping address. Then, the checkout option manager 350 automatically dispatches a shipping rate request / query based on the transaction input 312 (such as the value of the shopping cart, the location of the shipping address, and the size and weight of the package, etc.).

[0081] As described above, the checkout options 316 depend on such customer-specific and purchase-specific information and thus cannot be determined in advance. The option categories 314 can be related to one or more of shipping, installment payments, discounts, reward systems, subscriptions, tariffs, etc.

[0082] The checkout option manager 350 can be configured to dispatch requests / queries to local and remote sources. For example, the checkout option manager 350 can query the local data facility 134 / analytics 132 and query a remote third-party service provider 450 (optionally, via a third-party server 460) to obtain checkout options 316.

[0083] For local queries, the checkout option manager 350 has access to information from analytics 132 and data facility 134 of the e-commerce platform 100. For example, analytics 132 and data facility 134 can include a database of checkout options or static rates with option categories that do not change over time. For shipping-related option categories, the database can contain, for example, flat-rate checkout options or free-shipping checkout options conditional on meeting certain purchase requirements.

[0084] Analytics 132 and data facility 134 can also include information about customers (e.g., stored in a customer profile), information about customer purchase habits (e.g., purchase information aggregated by customer group, purchase information aggregated by time period, etc.), information about customer browsing habits (e.g., browsing information aggregated by customer group, browsing information aggregated by time period, etc.), information about sales (e.g., sales information aggregated by product category, sales information aggregated by time period, sales information aggregated by geographical location, etc.), and so on. Information about customers can be used to define customer groups. For example, customer groups can be defined by common characteristics such as common gender, common age range, common geographical region, common living arrangement, common purchase history, common browsing history, common interests (either explicitly indicated in the customer profile or implied in the purchase or browsing history), and combinations thereof. Of course, it should be recognized that such databases can be stored remotely rather than locally on the e-commerce platform 100.

[0085] For external queries to the third-party service provider 450, the response to such queries typically requires round-trip requests and responses from an application hosted on the remote third-party server 460. An example in a shipping scenario is an API call to a carrier to obtain dynamic shipping rates. External queries can also be made directly to the third-party service provider 450. As mentioned above, the speed of such external calls can depend on the level of technical infrastructure provided by the third party and / or the connectivity provider, server speed, and network connection speed. Therefore, the latency of such external calls can be largely caused by the latency of the third-party service provider itself.

[0086] Typically, in existing conventional online checkouts, after receiving responses to all requests / queries, the entire set of checkout options from both local and external queries is simultaneously presented to the customer in the user interface in the form of a dropdown menu or other list (e.g., a set of radio buttons, or a series of cards / sections). However, in the present disclosure, the checkout option manager 350 is configured to direct the user interface on the customer device 150 to display the checkout options based on whether each checkout option 316 is identified or determined to be a checkout option in a first group (e.g., a fast load group) or a second group (e.g., a slow load group).

[0087] To this end, the checkout option manager 350 is configured to use the load speed calculation module 352 to identify and / or dynamically determine whether each checkout option 316 should belong to the first group of options or the second group of options based on the response time of the query. In some examples, the first group of options may be "fast load" options, and the second group of options may be "slow load" or "delayed load" options. It should be understood that the expressions "fast load option" and "slow load option" are relative terms, where a checkout option 316 may be identified as "fast load" when it loads within a predefined time threshold (i.e., the response to the query is received within a predefined time threshold) or when it loads faster than another checkout option 316 that loads slower or is delayed, as discussed further below.

[0088] The loading calculation module 352 identifies or determines whether each checkout option 316 is part of a first group of options (e.g., "fast load") or part of a second group of options (e.g., "slow load" or "delayed load") based on one or more loading metrics 354. These loading metrics 354 are hard rules or dynamic rules applied by the loading calculation module 352 to a query to determine whether each checkout option 316 belongs to the first group of options or the second group of options (such as a "fast load" checkout option or a "slow load" checkout option). These metrics can be: a static threshold cut-off time (e.g., the response time of the query must be below 500 ms to be included in the first group of options), an empirical measurement (e.g., setting the cut-off time based on the historical response time or the most recent response time of similar queries), a statistical analysis of empirical measurements (e.g., setting the cut-off time based on a cut-off point in a distribution, e.g., one or two response times in the case where the response times are substantially normally distributed), a loading call analysis (e.g., whether the query is made using a first-party call, a third-party call, or a database lookup), a network analysis (e.g., the cut-off time is set based on the current or predicted load on the first-party network or the third-party network, or the customer's network), a domain knowledge-based heuristic (e.g., all flat rates are included in the first group of options, while all dynamic rates are included in the second group of options), and customer configuration (e.g., the merchant itself or the e-commerce platform 100 indicates to the checkout option manager 350 which rates belong to the first group of options and which rates belong to the second group of options). It is noted that the loading metrics 354 can include rules that can vary dynamically according to the state of the computing resources at the e-commerce platform 100. For example, if the current use of computing resources or network resources is high (e.g., high use of network bandwidth, high network congestion, high use of memory resources, etc.), the threshold cut-off time can be dynamically reduced (e.g., only responses that arrive within 300 ms are included in the first group of options) to reduce further use of the computing resources / network resources. Thus, the options for delayed loading may change; the options belonging to the first group and the options belonging to the second group are not necessarily fixed.

[0089] In some examples, the e-commerce platform 100 can obtain information in advance (e.g., based on historical measurements) about the relative speeds of the APIs of various third-party service providers. Then, based on the service providers of the checkout options 316 (which can be selected by the merchant), the checkout option manager 350 can define a cut-off time (e.g., based on a statistical analysis of the relative speeds of the selected providers).

[0090] The data and information used by the loading calculation module 352 (such as empirical measurements, historical response times or recent response times of similar queries, usage of computing resources / network resources, relative speeds of selected providers, etc.) can be stored in the dedicated memory 356 and / or stored in the data facility 134.

[0091] When the checkout option manager 350 has identified the first set of options, the checkout option manager 350 is configured to send an indication to the remote client device 150 to update the user interface, so as to automatically display (immediately after the triggering event or with a short fixed delay) at least one option in the first set of options. The checkout option manager 350 can identify the first set of options after receiving the response to one or more requests / queries associated with the first set of options. It is worth noting that the display of at least one option in the first set of options occurs before the display of any option in the second set of options.

[0092] The checkout option manager 350 is further configured to send an indication to the remote client device 150 to update the user interface, so as to automatically display at least one option in the first set of options and selectable user interface elements (such as expander icons or V-shaped symbols). Any or all options in the second set of options can be lazy-loaded and hidden from display on the client device 150 until the selectable user interface element is selected.

[0093] In some examples, the checkout option manager 350 can be configured to send an indication to the remote client device 150 to update the user interface, so as to automatically display all options in the first set of options at one time. For example, all fixed-rate shipping options can be displayed simultaneously on the checkout page as the first set of options (e.g., replacing the skeleton UI elements), where each fixed-rate option in the first set of options is displayed together with a radio button for the customer to select. If all options in the first set of options are not loaded simultaneously, waiting for all options in the first set of options to be loaded may cause the display of the page or a partition of the page to be delayed for a short period before rendering. In other words, for the customer, the loading of other UI elements (such as page loading, partition loading) may be blocked (i.e., not displayed) until all options in the first set of options are loaded.

[0094] In the case where more than one option in the first set of options is first made visible to the customer on the customer device 150, the checkout option manager 350 can be further configured to rank the options in the first set of options based on checkout criteria or a preselected order for display on the customer device 150. For example, the preselected order can be a price-based ranking, where the cheapest option is displayed at the top of the list. When the option category 314 is shipping, the options in the first set of options can alternatively be ranked and displayed based on delivery time, or a preferred carrier pre-determined by the merchant. Other ranking systems include ranking based on call speed, specific historical preferences of the customer, likelihood of use, overall popularity, or having the best interest rate, etc. Such ranking may also depend on a combination of various factors (e.g., primary sorting order, secondary sorting order, etc.)

[0095] In other examples, the checkout option manager 350 can be configured to send an instruction to the remote client device 150 to update the user interface, so as to automatically display only one option in the first set of options on the customer device 150. For example, if the checkout option manager 350 identifies three available checkout options from the first set of options, the cheapest checkout option can be displayed as the selected (visible) default option in the drop-down menu. The other two checkout options can be invisible in the drop-down menu until the customer selects or clicks on a selectable user interface element (e.g., a drop-down button / expander button) at the client device 150. At that time, these two additional checkout options in the first set of options will be visible, but without the loading indicator, as these checkout options have already been loaded.

[0096] The display of at least one option in the first set of options occurs before the display of any option in the second set of options. Additionally, the display of at least one option in the first set of options can occur even before the checkout option manager 350 receives a reply / response to a query for one or more options in the second set of options.

[0097] As mentioned above, conventional online checkout transactions typically present a loading cursor to the customer on the user interface to indicate that options are pending during the checkout transaction. At this time, the customer experiences a delay because the transaction cannot be completed until all checkout options are loaded. When customers see the loading cursor, they also tend to wait, thinking that the page has not fully loaded and the checkout transaction cannot proceed. Customers also tend to wait because they expect to see additional pending options that are indicated to be displayed.

[0098] To this end, the checkout option manager 350 is configured to immediately (or with a short fixed delay) provide the customer with at least one option (such as one of the fast load options) in the first set of options displayed on the user interface and a selectable user interface element (such as an expander), but not provide or display a loading cursor or any option in the second set of options (such as a slow load option or a delayed load option). The checkout option manager 350 is further configured to send an indication to the remote client device 150 to hide the loading cursor and the second set of options (such as a slow load option or a delayed load option) behind the expander on the user interface.

[0099] Although the checkout transaction may be completed using any one of the first set of options (such as using any one of the fast load options), this at least one option visible to the customer on the client device 150 in the first set of options can be pre-selected as the default option without any further customer interaction.

[0100] In the case where more than one option in the first set of options is made visible to the customer on the customer device 150, the checkout option manager 350 may automatically assign one option in the first set of options as the default option. For example, if the first set of options has been ranked based on price, the cheapest option displayed at the top of the list may be selected as the default option. In the case where only one option in the first set of options is made visible to the customer on the customer device 150, the checkout option manager 350 may automatically assign this displayed option in the first set of options as the default option without any further customer interaction.

[0101] In the case of displaying multiple options in the first set of checkout options, the customer may need some time to compare all the features of the multiple options. Therefore, for multiple options, the checkout option manager 350 may further optionally be configured to identify / determine which load option in the first set of options is the cheapest, has the fastest delivery time, or is the most popular, etc., and automatically highlight that option on the list. The option may be highlighted in a different font or background color, or labeled / marked as "fastest", "cheapest", "most popular", etc.

[0102] The checkout option manager 350 is configured to allow / enable a checkout transaction to be completed using one of the options in the first set of checkout options even when a response to the respective query for any or all of the options in the second set of options has not been received. Thus, the checkout option manager 350 enables the checkout transaction to be completed using at least one of the options in the first set of options (such as the fast load option) displayed on the user interface even when the second set of options (such as the slow load option) has not been loaded by sending an indication to the client device 150 that the customer can proceed with the checkout transaction (e.g., enabling the customer to select an option to complete the checkout).

[0103] After the checkout option manager 350 has identified the second set of options based on the query, the loading of the second set of options is hidden on the user interface. If the second set of options is still loading, the checkout option manager 350 is configured to update the checkout user interface to display a loading indicator (such as a loading cursor / spinner) only when the customer selects a selectable user interface element (e.g., an expander button or a V-shaped pattern) on the checkout user interface.

[0104] Regardless of whether the customer selects the user interface element, the checkout option manager 350 queries the second set of options while querying the first set of options. In this way, the customer does not immediately see a loading indicator on the checkout user interface. The user interface element can be an expander for a drop-down menu, or other possible user interface options such as an expandable section (e.g., selectable using a V-shaped pattern).

[0105] If the user interface element is selected and the second set of options is still loading (i.e., not all responses for the second set of options have been received), a loading cursor (such as a spinner) is displayed to the customer on the user interface until all options in the second set of options become available. At that time, the checkout option manager 350 is configured to send an update to the client device 150 to update the user interface by replacing the spinner with the now-loaded second set of options. For example, if dynamic shipping fees are determined to be an option in the second set of options (such as the slow load option), the customer will only see the dynamic shipping fees when interacting with the user interface element.

[0106] If the customer selects the user interface element after a period of time and the second set of options has been loaded (i.e., all responses for the second set of options have been received), the checkout option manager 350 can be configured to send an update to the client device 150 to update the user interface to display all options in the second set of options without displaying the loading cursor / spinner.

[0107] Alternatively, the checkout options manager 350 can be configured to send an update to the client device 150 to update the user interface to automatically replace the user interface elements on the checkout page with the second set of options themselves after the second set of options has been loaded. For example, if the customer is waiting to click on a user interface element and the second set of options has now been fully loaded, the second set of options can be immediately and automatically displayed as additional radio buttons in the shipping options list, and the user interface element will no longer be displayed.

[0108] If there are multiple options in the second set of options, once the multiple options are loaded, the checkout options manager 350 can also be configured to rank the multiple options in the loaded second set of options and send an update to the client device 150 to update the user interface to display the second set of options based on price, delivery time, historical customer preferences or predefined merchant preferences, likelihood of use, etc.

[0109] In some examples, once the second set of checkout options is loaded, its corresponding features (such as price and delivery time) may be more preferable (i.e., lower or faster) than the first set of checkout options that have been displayed. In such cases, all checkout options can be automatically rearranged / ranked so that the latest and cheapest (or fastest or most preferred by the merchant or most preferred by the fulfillment network, etc.) option is displayed first in the checkout options list. Alternatively, if the checkout options are "tagged" as described above, instead of rearranging the entire list, only the tag or highlight can be moved to the latest and cheapest / fastest checkout option.

[0110] In other examples, if the customer does not select / click on the user interface element, even if one option in the second set of options is in fact more preferable than the first set of checkout options that have been displayed, this more preferable option in the second set of options may not be displayed in the user interface.

[0111] Optionally, then, the checkout options manager 350 can also be configured to send an update to the client device 150 to update the user interface to provide the customer with a notification about the new and more preferable checkout option, regardless of whether the customer has selected the user interface element to view additional checkout options.

[0112] So far, the checkout options manager 350 has been described as being configured to identify and update the user interface to display checkout options in two batches / groups, such as fast load options and slow load options or deferred load options. However, the checkout options manager 350 can optionally be configured to divide the checkout options into more than two groups / batches, such as three groups (e.g., divided into a fast load batch, a faster slow load batch, and a slower slow load batch). For example, a first (e.g., fast load) group / batch can be displayed immediately, a second (e.g., faster slow load) group / batch can be displayed after a first amount of time, and a third (e.g., slower slow load) group / batch can be displayed after a second amount of time, where the second amount of time is greater than the first amount of time.

[0113] For example, in response to a selection of a user interface element, the checkout options manager 350 can send an update to the client device 150 to update the user interface to display any remaining options in the first group of options and display the second group of options after receiving a response to a corresponding query for the second group of options and before displaying the third group of options. The checkout options manager 350 can further send an update to the client device 150 to update the user interface to display a loading indicator for the third group of options when all responses to corresponding queries for the third group of options have not been received, or display the third group of options when all responses to corresponding queries for the third group of options have been received.

[0114] In another example, the first amount of time can be the amount of time it takes for a customer to select a user interface element. In this case, if the user interface element is selected, any options that have been loaded will be displayed as options in the second group of options (e.g., faster slow load options). Options that are still loading can be considered options in the third group of options (e.g., slower slow load options), and the second group of options (faster slow load options) and a loading cursor (e.g., a spinner) can be displayed to the customer until the third group of options (slower slow load options) becomes available. At that time, the spinner can be replaced with the third group of options.

[0115] Figure 6is a signaling diagram showing an example communication between a conventional e-commerce platform 600, a local database 634, a customer device 150, and a third-party service provider 450. After a notification 604 or a request for a triggering event 602 from the customer device, the conventional e-commerce platform 600 typically sends a query 606 for checkout options to an internal database and / or a query 608 for checkout options to a remote third-party service provider. After receiving responses to all requests / queries, including a local response 610 and an external response 612, the entire set of checkout options from the local query and the external query can be collated 614 and sent 616 to the customer device 150 for simultaneous display on the user interface. After the customer selects 618 one of the checkout options at the customer device 150, the conventional e-commerce platform 600 proceeds with the checkout transaction via the user interface on the customer device 620, and the transaction is completed. However, as described above, waiting for responses to all requests / queries before enabling the checkout transaction to complete can cause confusion for the customer, undesirably delay the completion of the checkout transaction, and waste computer resources to load unnecessary checkout options.

[0116] Accordingly, Figure 7 is a signaling diagram showing an example communication between a checkout option manager 350, a customer device 150, and a third-party service provider 450 according to an example of the present disclosure. The checkout option manager 350 can be implemented on the e-commerce platform 100 (e.g., in a server of the e-commerce platform 100), or external to the e-commerce platform 100 (e.g., in a third-party server, in the customer device 150, or in a merchant device 102), or in combination. For example, the checkout option manager 350 can be implemented by an online checkout service that may not be part of the e-commerce platform 100. The following discussion is in the context of an example where the checkout option manager 350 is implemented in a server of the e-commerce platform 100.

[0117] At 702, a triggering event is input or detected at the customer device 150. For example, the customer can input a shipping address at the customer device 150. Once the triggering event is detected, the customer device 150 automatically sends a notification to the checkout option manager 350 at 704.

[0118] In response to the notification of the triggering event, the checkout option manager 350 dispatches all queries to populate the checkout options. Such queries include a local query for checkout options at 706 (e.g., a request to an internal database stored in the data facility 134 of the e-commerce platform 100) and an external query for checkout options at 708 (e.g., a request to a third-party service provider 450, which is optionally implemented via a third-party's server 460).

[0119] At 710, the local data facility 134 responds to its request with checkout options from a local source. Then at 712, the checkout options manager 350 can identify the local response as part of a first set of checkout options or a second set of checkout options (such as a fast load response or a slow load response). In some scenarios, since the local response at 710 is within the e-commerce platform 100, the local response(s) can be provided to the checkout options manager 350 immediately or with very little latency. In such a case, after applying the load metric 354, the checkout options manager 350 can identify one or more of the local response(s) as a first set of options (such as fast load options).

[0120] At 714, after having identified at least one option from the first set of options, the checkout options manager 350 immediately sends a signal to the customer device 150 to display this at least one option from the first set of checkout options. In the case of displaying this at least one option from the first set of options, the customer device 150 can automatically select one of the options from the first set of options as the default option at 716. In any case, the checkout options manager 350 can continue with the checkout process at 718 using only the options from the first set of options (such as one of the fast load options).

[0121] Contrary to Figure 6 the conventional signaling diagram, the completion of the checkout process at 718 can continue without the checkout options manager 350 receiving a (multiple) external response from the third-party service provider 450 at 720 and / or without the customer device 150 displaying a second set of options at 722. Of course, in another example, the checkout process at 718 can also occur after the checkout options manager 350 receives a (multiple) external response from the third-party service provider 450 at 720 (thus allowing time for the delayed loading of the second set of options), and can occur after the customer device 150 displays the second set of options at 722.

[0122] Figure 7Illustrates a signaling example where the checkout option manager 350 determines a local response as the first set of options and an external response as the second set of options. However, those skilled in the art will understand that when applying the load metric 354 (discussed above), the checkout option manager 350 may identify certain external responses as related to options in the first set of options and certain local responses as related to options in the second set of options. A notable feature is that the checkout option manager 350 is capable of identifying / determining which checkout options belong to the first set of options (such as fast load options) and which checkout options belong to the second set of options (such as slow load options), thereby first causing at least one checkout option in the first set of checkout options to be displayed only, and subsequently (e.g., after lazy loading and / or upon customer request) causing the second set of checkout options to be displayed, and also enabling the transaction to be completed without the second set of options being displayed or loaded.

[0123] Figure 8 Is a flowchart showing an example method 800 for completing a checkout transaction when not all checkout options are available. For example, the example method 800 can be executed by the e-commerce platform 100 using the checkout option manager 350. In particular, the method 800 can be executed in real time (or near real time) by a given customer during a transaction at a given online store 138.

[0124] At operation 802, the checkout option manager 350 provides, via the network 440, a checkout user interface for completing the checkout transaction to the remote client device 150. The user interface includes at least one option category 314 associated with the checkout transaction. The option category 314 has a set of associated checkout options 316.

[0125] As described above, each option category 314 can be related to aspects or categories of the checkout transaction that can only be determined or populated at checkout (i.e., cannot be pre-loaded). For example, the option category 314 can be related to shipping, installment payments, discounts, reward systems, subscriptions, tariffs, etc. In this regard, each option category 314 is associated with a set of checkout options 316, and as part of the checkout process, the user can or must select this set of checkout options to complete the transaction. The checkout options 316 cannot be pre-loaded because the checkout options require customer-specific information and / or purchase-specific information to be determined.

[0126] Optionally, at operation 804, a trigger event is detected by the checkout option manager 350. Such a trigger event can be receipt of customer-specific information from the client device 150, such as receipt of a shipping address (e.g., the shipping address is input by the customer into the checkout user interface via the client device 150). The trigger event can alternatively be detection of initialization of the user interface at the client device 150, or receipt of an indication from the client device 150 of a selection being made on the user interface to enable a particular category of options, etc.

[0127] At operation 806, a request or query associated with the checkout option 316 is transmitted. At least one of the transmitted queries (e.g., via the network 440) is transmitted to the remote third-party server 460, where one of the checkout options 316 needs to be selected to complete the checkout transaction.

[0128] At operation 808, one or more of the checkout options 316 are identified as belonging to a first group of options (such as fast load options) and the other checkout options 316 are identified as belonging to a second group of options (such as slow load options). It can be determined whether a checkout option 316 belongs to the first group of checkout options or the second group of checkout options (such as fast load or slow load) based on various different load metrics 354. Examples of load metrics 354 include: a threshold cut-off time for receiving a response, historical measurements of responses to receiving similar queries, analysis of network communications associated with each query and / or fulfillment network configuration, merchant configuration, a dynamic cut-off time depending on the current use of computer resources / network resources, etc. For example, when the load metric 354 used is based on the threshold cut-off time for receiving a response, all responses received within 500 ms can be considered fast load, while all responses received after 500 ms can be considered slow load. Alternatively, the threshold cut-off time can be based on the historical response time of the corresponding customer.

[0129] Thus, at operation 810, after receipt of a reply to one or more of the requests, but before any options in the second group are displayed, an update to the user interface is transmitted to the remote client device 150 to display at least one option in the first group. In this regard, the user interface is updated to display only one or more options in the first group.

[0130] At this time, the at least one option in the first group of options displayed can be automatically selected as the default option on the user interface.

[0131] At operation 812, an update to the user interface is also transmitted to the remote client device 150 to display selectable user interface elements, where, before the selectable user interface elements are selected, a second set of options are all hidden and not displayed.

[0132] For example, in a case where the selectable user interface elements have been selected at the remote client device 150, but the options in the second set of options have not been loaded yet, the user interface can be updated to display any remaining options in the first set of options and display a loading indicator for the second set of options when not all responses to the corresponding queries for the second set of options have been received.

[0133] Optionally, at operation 814, in a case where the second set of options has been loaded (e.g., after a certain delay), after further receiving responses to one or more requests in the corresponding requests for the second set of options, the user interface can be further updated to display the second set of options.

[0134] However, regardless of whether the second set of options is displayed (e.g., lazy-loaded options), at operation 816, it is possible to complete a checkout transaction using an option in the first set of options displayed on the user interface (such as one of the quick-loading options). The checkout transaction can be completed before receiving responses to the corresponding queries for any or all of the options in the second set of options (such as slow-loading options). If a default option has been selected, in response to the selection of the option for completing the checkout transaction, the default option can be used to complete the checkout transaction without further interaction from the customer.

[0135] The above transaction process / method 800 can be implemented on the e-commerce platform 100 and presented to the customer as a series of pages that the customer can browse. Figures 9A to 9D An example of a series of pages is shown.

[0136] Figure 9A The checkout user interface 900 displayed on the remote client device 150 is shown. The user interface 900 includes at least one option category 314 associated with the checkout transaction. In the illustrated embodiment, the option category 314 is shipping, identified by "Delivery" 902, and is associated with a set of checkout options 316 that are shipping options 904 (not yet populated in Figure 9A ). As shown in this embodiment, the checkout user interface 900 has received the shipping address, which is also identified as a trigger event. At this time, since the shipping options 904 for the shipping category 902 have not been provided or selected, the "Continue" button 906 is inactive (e.g., dimmed). In other words, the checkout transaction cannot be completed yet.

[0137] When a trigger event (i.e., the entry of a shipping address) is detected, the checkout options manager 350 issues a shipping query, at least one of which is sent to a third-party carrier. In this example, one of the shipping queries is also dispatched locally. The checkout options manager 350 identifies one of the shipping options as belonging to a first group of shipping options (such as a quick load option), in which case the shipping option is a flat-rate shipping option 904 determined based on a local database lookup. Thus, as Figure 9B shown, the flat-rate shipping option 904 is immediately displayed on the checkout user interface 900 together with an expander / V-shaped pattern 908 (i.e., a selectable user interface element). The flat-rate shipping option has also been automatically selected as the default option. It is noted that any / all shipping options belonging to a second group of shipping options (such as a slow load option or a delayed load option) are initially hidden and not displayed. It is also noted that the "Continue" button 906 is now active (e.g., visually highlighted in a different color, as indicated by the dashed line in Figure 9B ), at which point the checkout transaction can be completed with the default flat-rate shipping option 904 even if the customer has never selected the expander and even if the second group of options has not been loaded.

[0138] In other words, the customer can continue with the checkout process with "incomplete" information (i.e., without loading information for all available options) because the transaction can be completed without retrieving the slow data options.

[0139] Figure 9C An example is shown when the customer has selected the expander / V-shaped pattern but the second group of options has not been loaded. In this case, a spinner / loading cursor 910 is displayed, indicating that the second group of options is still loading. As described above, Figure 9C the "Continue" button 906 in

[0140] Figure 9D is still active, and the checkout transaction can still be completed using the flat-rate shipping option 904 even if the second group of shipping options has not been loaded.

[0141] It should be noted that once the trigger event occurs, all queries used to populate all checkout options (e.g., including the second set / slow-loading / lazy-loading checkout options as well as the first set / checkout options) are dispatched at the same time, rather than when the expander / V pattern is selected. Thus, the customer's interaction with the expander seems to merely trigger the invocation of the second set of checkout options. However, as described above, these queries have already been dispatched upon early detection of the trigger event.

[0142] The ability of the customer to complete the transaction using the (quick-loading) default options in the first set even when some or all of the options in the second set are not yet loaded or unavailable improves computer efficiency. The processing power, memory storage, and bandwidth that were originally used to receive responses from third-party calls and to load and display all the second set of checkout options on the checkout user interface can now be used for other purposes. Thus, computer resources can be saved without hindering the completion of the customer's checkout transaction.

[0143] As described above, a typical checkout user interface usually blocks the customer from completing the checkout transaction until all checkout options are loaded and available for selection. According to the present disclosure, presenting at least one option (such as a quick-loading option) in the first set of checkout options for each option category to the customer allows the customer to complete the transaction even when some or all of the responses related to the options in the second set (such as slow-loading options or lazy-loading options) have not yet been received / loaded and displayed on the checkout user interface.

[0144] Furthermore, from the perspective of the customer's interests, the customer does not need to wait and is not inclined to wait for the second set of options (such as slow-loading or lazy-loading checkout options) to load before proceeding, because no loading cursor is initially presented to the customer. In this way, the transaction can be simplified and completed faster with less latency. Also, the resources reserved for the checkout transaction can be released faster for other purposes.

[0145] Although the present disclosure describes methods and processes as operations (e.g., steps) having a particular order, one or more of these methods and processes can be omitted or changed as appropriate. One or more operations can be performed in an order different from the described order as appropriate.

[0146] Although the present disclosure has been described at least in part in terms of methods, those of ordinary skill in the art will understand that the present disclosure also relates to various components for performing at least some aspects and features of the described methods, and the present disclosure can be implemented by hardware components, software, or any combination of the two. Accordingly, the technical solutions of the present disclosure can be implemented in the form of a software product. For example, a suitable software product can be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer-readable medium, including DVDs, CD-ROMs, USB flash drives, removable hard drives, or other storage media. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, server, or network device) to execute examples of the methods disclosed herein.

[0147] Without departing from the subject matter of the claims, the present disclosure can be implemented in other specific forms. The described example embodiments are to be considered in all respects only illustrative and not restrictive. Features selected from one or more of the above embodiments can be combined to create alternative embodiments not explicitly described, and features suitable for such combination are understood to be within the scope of the present disclosure.

[0148] All values and subranges within the scope of the disclosure are also disclosed. Moreover, although the systems, devices, and processes disclosed and illustrated herein may include a specific number of elements / components, the systems, devices, and assemblies can be modified to include additional or fewer such elements / components. For example, although any element / component disclosed may be referred to in the singular, the embodiments disclosed herein can be modified to include a plurality of such elements / components. The subject matter disclosed herein is intended to cover and embrace all suitable technical variations.

[0149] The teachings can also extend to the features of one or more of the following numbered clauses:

[0150] 1. A system, comprising:

[0151] at least one processor and at least one memory storing instructions executable by the at least one processor to cause the system to:

[0152] provide, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options having an associated set of checkout options;

[0153] transmit, via the network, requests associated with respective ones of the checkout options, at least one of the transmitted requests being transmitted to a remote third-party server, wherein selection of one of the checkout options is required to complete the checkout transaction;

[0154] Identify one or more of these checkout options as a first set of options and identify the other checkout options among these checkout options as a second set of options;

[0155] After receiving a response to one or more of these requests and before displaying the second set of options, send an indication to the remote client device to update the user interface to display at least one option among the checkout options in the first set of options;

[0156] Send an indication to the remote client device to display a selectable user interface element, wherein before the selectable user interface element is selected, all of the second set of options are hidden and not displayed; and

[0157] Before receiving a response to the respective queries for all of the options in the second set of options, use one of the checkout options in the first set of options displayed on the user interface to enable the checkout transaction to be completed.

[0158] 2. The system according to clause 1, wherein the first set of options are fast load options and the second set of options are slow load options, and wherein these fast load options have a faster load speed than these slow load options.

[0159] 3. The system according to clause 1, wherein one of the first set of options displayed is automatically selected as the default option, and wherein the at least one processor is further configured to execute these instructions to cause the system to:

[0160] In response to selecting the option to complete the checkout transaction, trigger the completion of the checkout transaction using the default option.

[0161] 4. The system according to clause 2, wherein the at least one processor is further configured to execute these instructions to cause the system to:

[0162] In response to selecting the selectable user interface element at the remote client device, send an indication to the remote user device to update the user interface to display any remaining fast load options, and:

[0163] When all responses to the respective queries for the slow load options have not been received, display a load indicator for the slow load options; or

[0164] When all responses to the respective queries for the slow load options have been received, display the slow load options.

[0165] 5. The system according to clause 1, wherein the at least one processor is further configured to execute these instructions to cause the system to transmit these queries for the checkout options in response to detecting a trigger event.

[0166] 6. The system as described in clause 5, wherein the option category is related to transportation, and the trigger event is the receipt of the delivery address.

[0167] 7. The system as described in clause 2, wherein the at least one processor is further configured to execute the instructions to cause the system to determine, based on any response to the queries, whether each of the checkout options belongs to the first group of options or the second group of options.

[0168] 8. The system as described in clause 7, wherein determining whether each of the checkout options is the first group of options or the second group of options is based on at least one of the following:

[0169] The threshold cut-off time for receiving the response;

[0170] The historical measurement of responses to receiving similar queries;

[0171] The analysis of the network communication and / or fulfillment network configuration related to each query; and

[0172] The merchant configuration.

[0173] 9. The system as described in clause 8, wherein the available checkout options are determined to be fast-loading or slow-loading based on the threshold cut-off time, which is dynamically determined for the customer based on the customer's historical response time.

[0174] 10. The system as described in clause 2, wherein the at least one processor is further configured to execute the instructions to cause the system to:

[0175] Identify the faster-loading options and slower-loading options among the slow-loading options, wherein the slower slow-loading options take more time to receive the response to the corresponding query than the faster slow-loading options; and

[0176] In response to selecting the selectable user interface element:

[0177] Display any remaining fast-loading options; and

[0178] Before displaying the slower slow-loading options, display the faster slow-loading options after receiving the response to the corresponding query for the faster slow-loading options.

[0179] 11. A method, comprising:

[0180] Provide a user interface for completing a checkout transaction to a remote client device via a network, the user interface including a category of options associated with the checkout transaction, the category of options having an associated set of checkout options;

[0181] Transmit requests associated with respective ones of these checkout options via the network, at least one of the transmitted requests being transmitted to a remote third-party server, wherein completing the checkout transaction requires selecting one of these checkout options;

[0182] Identify one or more of these checkout options as a first set of options and identify the other checkout options of these checkout options as a second set of options;

[0183] After receiving a response to one or more of these requests and before displaying the second set of options, send an indication to the remote client device to update the user interface to display at least one of the options in the first set of options;

[0184] Send an indication to the remote client device to display selectable user interface elements on the user interface, wherein, before selecting the selectable user interface elements, all of the second set of options are hidden from view; and

[0185] Before receiving responses to respective requests for all of the options in the second set of options, use one of the at least one option in the first set of options displayed on the user interface to enable the checkout transaction to be completed.

[0186] 12. The method according to clause 11, wherein the first set of options are fast-loading options and the second set of options are slow-loading options, wherein the fast-loading options are loaded faster than the slow-loading options.

[0187] 13. The method according to clause 11, further comprising:

[0188] Automatically select one of the at least one option in the first set of options displayed as a default option, and

[0189] In response to selecting the option to complete the checkout transaction, trigger the completion of the checkout transaction using the default option.

[0190] 14. The method according to clause 12, further comprising:

[0191] In response to selecting the selectable user interface elements at the remote client device, send an indication to the remote user device to update the user interface so that:

[0192] Display any remaining fast-loading options;

[0193] Display a loading indicator for the slow load options when all responses to the corresponding queries for these slow load options have not been received; or

[0194] Display the slow load options when all responses to the corresponding queries for these slow load options have been received.

[0195] 15. The method as described in clause 11, further comprising:

[0196] Detect a trigger event and, in response, cause the system to transmit a query for checkout options.

[0197] 16. The method as described in clause 15, wherein the option category is related to shipping and the trigger event is receipt of a shipping address.

[0198] 17. The method as described in clause 11, further comprising:

[0199] Determine whether each of the checkout options is a fast load option or a slow load option based on the responses to the queries.

[0200] 18. The method as described in clause 17, wherein the determination is based on:

[0201] A threshold cut-off time for receiving the response;

[0202] Historical measurements of receiving responses to similar queries;

[0203] Analysis of the network communication and / or fulfillment network configuration associated with each query; and

[0204] Merchant configuration.

[0205] 19. The method as described in clause 12, further comprising:

[0206] Identify faster and slower load options among the slow load options, where the slower slow load options take more time to receive a response to the corresponding query than the faster slow load options; and

[0207] In response to selecting the selectable user interface element:

[0208] Display any remaining fast load options; and

[0209] Before displaying the slower slow load options, display the faster slow load options after receiving a response to the corresponding query for these faster slow load options.

[0210] 20. A computer-readable medium storing instructions that, when executed by a processor of a system, cause the system to:

[0211] Providing, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options having an associated set of checkout options;

[0212] Transmitting, via the network, requests associated with respective ones of the checkout options, at least one of the transmitted requests being transmitted to a remote third-party server, wherein selection of one of the checkout options is required to complete the checkout transaction;

[0213] Identifying one or more of the checkout options as fast-load options and identifying other ones of the checkout options as slow-load options;

[0214] After receiving a response to one or more of the requests and before displaying the slow-load options, sending an indication to the remote client device to update the user interface to display at least one of the fast-load options;

[0215] Sending an indication to the remote client device to display selectable user interface elements on the user interface, wherein all of the slow-load options are hidden and not displayed before the selectable user interface elements are selected; and

[0216] Enabling the checkout transaction to be completed using at least one of the fast-load options displayed on the user interface before receiving responses to respective requests for all of the slow-load options.

Claims

1. A checkout management system, comprising: At least one processor and at least one memory storing instructions executable by the at least one processor to cause the checkout management system to perform: Provide, via a network, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options being populated during the checkout transaction by two or more associated checkout options; transmit, via the network, a query for obtaining a respective checkout option of the two or more checkout options for populating the category of options, at least one of the transmitted queries being transmitted to a remote third-party server of a service provider providing at least one of the checkout options; Identify one or more of the checkout options as a first set of checkout options and one or more other checkout options of the checkout options as a second set of checkout options based on a response time of the transmitted queries, the first set of checkout options being one or more checkout options having a response time within a cut-off time, and the second set of checkout options being one or more checkout options associated with the transmitted queries for which a response is still awaited until the cut-off time; After identifying the first set of checkout options, instruct the remote client device to update the user interface at the remote client device, wherein in the updated user interface, after receiving a reply to one or more of the queries and before displaying the second set of checkout options, the category of options displays at least one checkout option from the checkout options of the first set of checkout options as selectable checkout options, and the second set of checkout options is hidden and not displayed and not selectable in the user interface; And Communicate with a commerce management engine to complete the checkout transaction, wherein completing the checkout transaction includes selecting one of the checkout options from the first set of checkout options displayed on the user interface before receiving a response to the respective queries for all of the checkout options in the second set of checkout options.

2. The checkout management system according to claim 1, wherein one of the displayed first set of checkout options is automatically selected as the default option, and wherein the at least one processor is further configured to execute instructions to communicate with the checkout management system to: In response to selecting an option to complete the checkout transaction, use the default option to complete the checkout transaction.

3. The checkout management system according to claim 1, wherein the at least one processor is further configured to execute instructions to cause the checkout management system to: In response to selecting a selectable user interface element of the user interface at the remote client device, instruct the remote client device to display any remaining checkout options of the first set of checkout options, and wherein the updated user interface further displays: A loading indicator for the second set of checkout options when all responses to a corresponding query have not been received; or The second set of checkout options for which all responses to a corresponding query have been received.

4. The checkout management system according to claim 1, wherein the at least one processor is further configured to execute instructions to cause the checkout management system to transmit a query for checkout options in response to detecting a trigger event.

5. The checkout management system according to claim 4, wherein, The category of options is related to shipping, and the trigger event is receipt of a delivery address.

6. The checkout management system according to claim 1, wherein, The cut-off time is one of the following: A static threshold cut-off time for receiving a response; A dynamic cut-off time for receiving a response; or A cut-off time based on a historical measurement of responses to receiving similar queries.

7. The checkout management system according to claim 6, wherein the cut-off time is a dynamic cut-off time that is dynamically determined for the customer based on the customer's associated historical response time.

8. The checkout management system according to claim 1, wherein the at least one processor is further configured to execute instructions to cause the checkout management system to: In response to selection of a selectable user interface element of the user interface, further instructing the remote client device to update the user interface at the remote client device to: display any remaining checkout options of the first set of checkout options; and display at least one checkout option of the second set of checkout options after receiving a response to a corresponding query for at least one checkout option of the second set of checkout options and before displaying at least one other checkout option of the second set of checkout options that is still waiting for a response.

9. The checkout management system according to claim 1, wherein, In the updated user interface, before displaying the second set of checkout options, the category of options displays all of the checkout options from the first set of checkout options.

10. The checkout management system according to claim 1, wherein, In the updated user interface, before displaying the second set of checkout options, the category of options displays two or more checkout options from the first set of checkout options, and wherein the two or more checkout options from the first set of checkout options are ranked based on checkout criteria.

11. A method, comprising: Provide, via a network by at least one processor, a user interface for completing a checkout transaction to a remote client device, the user interface including a category of options associated with the checkout transaction, the category of options being populated during the checkout transaction by two or more associated checkout options; The at least one processor transmits, via the network, queries for obtaining respective checkout options among the two or more checkout options for populating an option category, and at least one of the transmitted queries is transmitted to a remote third-party server of a service provider providing at least one of the checkout options; The at least one processor identifies one or more of the checkout options as a first group of checkout options and one or more other checkout options of the checkout options as a second group of checkout options based on response times of the transmitted queries, the first group of checkout options being one or more checkout options having response times within a deadline, and the second group of checkout options being one or more checkout options associated with the transmitted queries for which responses are still awaited until the deadline; After identifying the first group of checkout options, the at least one processor instructs a remote client device to update a user interface at the remote client device, wherein in the updated user interface, after receiving responses to one or more of the queries and before displaying the second group of checkout options, the option category displays at least one of the checkout options in the first group of checkout options as selectable checkout options, and the second group of checkout options is hidden and not displayed and not selectable in the user interface; And The at least one processor communicates with a commerce management engine to complete a checkout transaction, wherein completing the checkout transaction includes selecting one of the at least one checkout option in the first group of checkout options displayed on the user interface before receiving responses to respective queries for all checkout options in the second group of checkout options.

12. The method according to claim 11, further comprising: Automatically select one of the at least one checkout option in the first group of checkout options displayed as a default option, and in response to selecting the option to complete the checkout transaction, use the default option to complete the checkout transaction.

13. The method according to claim 11, further comprising: In response to selecting a selectable user interface element of the user interface at the remote client device, further instruct the user interface at the remote client device to display any remaining express checkout options of the first group of checkout options, and wherein the updated user interface further displays: A loading indicator for the second group of checkout options when all responses to respective queries have not been received; Or The second group of checkout options for which all responses to respective queries have been received.

14. The method according to claim 11, further comprising: Detect a trigger event, and in response, cause the checkout management system to transmit queries for checkout options.

15. The method according to claim 14, wherein, The option category is related to shipping, and the trigger event is receiving a delivery address.

16. The method according to claim 11, wherein, The deadline is one of the following: A static threshold deadline for receiving a response; A dynamic deadline for receiving a response; or A deadline based on historical measurements of responses to receiving similar queries.

17. The method according to claim 16, wherein the cut-off time is a dynamic cut-off time that is dynamically determined for the customer based on the customer's historical response time.

18. The method according to claim 11, further comprising: In response to selecting a selectable user interface element of the user interface, further instruct the remote client device to update the user interface at the remote client device such that: Display any remaining checkout options of the first group of checkout options; and Before displaying at least one other checkout option of the second set of checkout options that is still waiting for a response, after receiving a response to a corresponding query for at least one checkout option of the second set of checkout options, display at least one checkout option of the second set of checkout options.

19. The method according to claim 11, wherein, In the updated user interface, before displaying the second set of checkout options, the option category displays all checkout options from the first set of checkout options.

20. A non-transitory computer-readable medium storing instructions that, when executed by a processor of a checkout management system, cause the checkout management system to: Provide a user interface for completing a checkout transaction to a remote client device via a network, the user interface including a category of options associated with the checkout transaction, the category of options being populated during the checkout transaction by two or more associated checkout options; Transmit via the network a query for obtaining a corresponding checkout option of the two or more checkout options for populating the category of options, at least one of the transmitted queries being transmitted to a remote third-party server of a service provider that provides at least one of the checkout options; Identify one or more of the checkout options as a first set of checkout options and one or more other checkout options as a second set of checkout options based on the response time of the transmitted query, the first set of checkout options being one or more checkout options having a response time within a cutoff time, and the second set of checkout options being one or more checkout options associated with the transmitted query that is still waiting for a response until the cutoff time; After identifying the first set of checkout options, instruct the remote client device to update the user interface at the remote client device, wherein in the updated user interface, before receiving a reply to one or more of the queries and before displaying the second set of checkout options, the option category displays at least one checkout option from the first set of checkout options as a selectable checkout option, and the second set of checkout options is hidden and not displayed and not selectable in the user interface; And Communicate with a business management engine to complete a checkout transaction, wherein completing the checkout transaction includes selecting one of the at least one checkout option from the first set of checkout options displayed on the user interface before receiving a response to all checkout options of the second set of checkout options.

Images