Methods and systems for an in-cart widget

Abstract

Methods, systems, and apparatuses are described for generating and using a modular in- cart widget.

Description

[0001] This application claims priority to U.S. Provisional Application No. 63 / 607.845, filed on December 8, 2023. which is incorporated by reference in its entirety herein. BACKGROUND

[0002] The event ticket market suffers from wild fluctuations in prices for tickets to events as demand and supply is unpredictable and often manipulated by virtual, automatic purchasers (e.g., “bots”) that create artificial demand and artificially increase ticket prices. This puts timing pressure on real human consumers desirous of obtaining tickets at fair value to purchase tickets to events without knowing with certainty that they will be able to attend the event. Unforeseen events can lead to cancellations, loss of money due to reselling tickets on depressed secondary7 markets, illegally scalping tickets, or complete loss of purchase price due to unforeseen circumstances that prevent a purchaser from attending an event. This degrades user experience and makes purchasers weary of spending on tickets. SUMMARY

[0003] Methods, systems, and apparatuses are described for insuring purchases. An application may be modularly inserted into a webpage like a check-out page on an ecommerce platform output on a user device. The modularly inserted application may be configured to display one or more selectable options and receive, via the user interface, a selection of the one or more selectable options. Based on the selection of the one or more selectable options, an insurance quote may be generated and output. Based on an acceptance of the insurance quote, an insurance policy may be generated and executed. One or more insurance claims associated with the insurance policy may be received. Based on the one or more insurance claims, one or more refunds may be issued.

[0004] Additional advantages will be set forth in part in the description which follows or may be learned by practice. The advantages will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] To easily identify the discussion of any particular element or act. the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0006] FIG. 1 shows an example system;

[0007] FIG. 2 shows an example diagram;

[0008] FIG. 3 shows an example diagram;

[0009] FIG. 4A shows an example interface;

[0010] FIG. 4B shows an example interface

[0011] FIGS. 5A-5L show example system components and methods;

[0012] FIGS. 6A-6K show example system components and methods;

[0013] FIG. 7 shows an example method;

[0014] FIG. 8 shows an example method; and

[0015] FIG. 9 shows an example system. DETAILED DESCRIPTION

[0016] Before the present methods and systems are disclosed and described, it is to be understood that the methods and systems are not limited to specific methods, specific components, or to particular implementations. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0017] As used in the specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, and / or to “about” another particular value. When such a range is expressed, another embodiment includes- from the one particular value and / or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the particular value forms another embodiment. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

[0018] “Optional” or “optionally” means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0019] Throughout the description and claims of this specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other components, integers or steps. “Exemplary” means “an example of’ and is not intended to convey an indication of a preferred or ideal embodiment. “Such as” is not used in a restrictive sense, but for explanatory7 purposes.

[0020] Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed that while specific reference of each various individual and collective combinations and permutation of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application, including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed, it is understood that each of these additional steps can be performed with any specific embodiment or combination of embodiments of the disclosed methods.

[0021] The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the examples included therein and to the Figures and their previous and following description.

[0022] As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirety hardware embodiment, an entirety software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

[0023] Embodiments of the methods and systems are described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses, and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

[0024] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0025] Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

[0026] Hereinafter, various embodiments of the present disclosure will be described with reference to the accompanying drawings. As used herein, the term “user” may indicate a person who uses an electronic device or a device (e.g., an artificial intelligence electronic device) that uses an electronic device.

[0027] The present disclosure provides a method used to insure purchases. FIG. 1 illustrates a system 100 including a network environment configured to carry out the disclosed methods. The system 100 may comprise a computing device 101. a user device 102, and an e-commerce platform 106. The e-commerce platform may be hosted on one or more servers. The e-commerce platform may be, for example, Ticketmaster, Live Nation, StubHub, SeatGeek, TickPick, Ticket IQ, Vivid Seats, TicketSwap, Amazon, eBay, Alibaba, combinations thereof, and the like. The computing device 101 may include a bus 110, a processor 120, a memory 130, an input / output interface 150, a display 160, and a communication interface 170. In a certain exemplary embodiment, the computing device 101 may omit at least one of the aforementioned constitutional elements or may additionally include other constitutional elements. The computing device 101 may comprise or otherwise be connected to a signal processor 120 (e.g., a signal sensing and recording device) capable of detecting and amplifying signals from, for example, the user device 102, the e-commerce platform 106, the network 162, and / or associated devices. The signal processor preferably is capable of processing electromagnetic signals received from one or more of the user device 102 and / or the e-commerce platform 106, via the network 162. The network 162 may be an optical fiber network, a coaxial cable network, a hybrid fiber-coaxial network, a wireless network, a satellite system, a direct broadcast system, or any combination thereof. The network 162 can be the Internet. The network 162 may have a network component. The network component may be any device, module, combinations thereof, and the like communicatively coupled to the network 162. The network component may be a router, a switch, a splitter, a packager, a gateway, an encoder, a storage device, a multiplexer, a network access location (e.g., tap), physical link, combinations thereof, and the like. The network component may be any device, module, combinations thereof, and the like communicatively coupled to the network 162.

[0028] The bus 110 may include a circuit for connecting the aforementioned constitutional elements 110 to 170 to each other and for delivering communication (e.g., a control message and / or data) between the aforementioned constitutional elements.

[0029] The processor 120 may include one or more of a Central Processing Unit (CPU), an Application Processor (AP), and a Communication Processor (CP). The processor 120 may control, for example, at least one of other constitutional elements of the computing device 101 and / or may execute an arithmetic operation or data processing for communication. The processing (or controlling) operation of the processor 120 according to various embodiments is described in detail with reference to the following drawings.

[0030] The memory 130 may include a volatile and / or non-volatile memory. The memory 130 may store, for example, a command or data related to at least one different constitutional element of the computing device 101. According to various exemplary embodiments, the memory 130 may store a software and / or a program 140. The program 140 may include, for example, a kernel 141, a middleware 143, one or more Application Programming Interfaces (APIs) 145, and / or an insurance program (e.g., “application” or “mobile app”) 147, or the like. The insurance program 147 may be configured for generating one or more insurance quotes, one or more insurance policies, combinations thereof, and the like. For example, the computing device 101 may receive, via the user device 102 and / or the e-commerce platform 106, an indication of a purchase. The indication of the purchase may include one or more identifiers associated with one or more items, one or more identifiers associated with a user account, one or more identifiers associated with the user device, one or more identifiers associated with the e-commerce platform, pricing information, combinations thereof, and the like.

[0031] For example, a user may navigate the e-commerce platform 106 and identify one or more items for purchase. For example, the one or more items may comprise one or more tickets, one or more access rights, one or more physical items, one or more virtual representations of the one or more physical items, combinations thereof, and the like. For example, the one or more items may be physical items such as clothes, cars, toys, combinations thereof, and the like. For example, the user may place the one or more items for purchase in a virtual shopping cart. For example, the user may select a selectable option associated with the one or more items wherein the selectable option is configured to place the one or more items in the virtual shopping cart. The e-commerce platform may receive, from a user device, a purchase command. For example, the user may interact with a webpage output on a user interface associated with the user device to indicate the user’s intent to complete a commercial transaction configured to transfer ownership and / or possession of the one or more items from a seller to the user (e.g.. a buyer).

[0032] The e-commerce platform 106 may alert the computing device 101 of the purchase. For example, the e-commerce platform 106 may send a purchase indication to the computing device 101. The purchase indication may comprise purchase information. The purchase information may comprise one or more identifiers associated with the user device, one or more identifiers associated with the user / buyer (e.g., a user account), financial information associated with the user (e.g., credit card information, account credits, etc.), pricing information associated with the one or more items, service fee information, tax information, one or more identifiers associated with the e-commerce platform, combinations thereof, and the like.

[0033] The computing device 101, may, via the one or more APIs 145, receive the purchase indication and determine the information therein. For example, the one or more APIs 145 may comprise one or more API endpoints for client onboarding, authentication, product configuration, policy configuration, pricing configuration, quoting, orders, and payment processing. The one or more APIs 145 may comprise a claims API configured as an API endpoint for customer claims intake, claims adjudication and claims payout. The one or more APIs 145 may comprise a notifications API configured as an API endpoint for managing customer communications and configuring client integration webhooks for policy and claims notifications. The one or more APIs 145 may comprise an in-cart widget API. The in-cart widget API may be a JavaScript widget embedded in and / or pushed to or otherwise sent to one or more client shopping carts (e.g., the virtual shopping cart on the ecommerce platform 106) that enables embedded commerce. The in-cart widget may be a point of insurance policy purchase for customers (e.g., users / buyers). The one or more APIs 145 may comprise a claims intake web application, configured for use by customers (e.g.. users / buyers) to file claims that may be configurable at the product, underwriter, and policy level. The one or more APIs 145 may comprise a claims portal. The claims portal may be a full service claims administration portal used for claims adjudication, customer communications management, and automated customer payouts. The one or more APIs 145 may comprise a policy and client management portal. The policy and client management portal may be a portal used by users of the computing device 101 as well as users of the ecommerce platform 106 (e.g., users of user device 102) for policy and financial performance reporting and client account configuration.

[0034] Based on the purchase indication, the computing device may cause one or more widgets to be output on the user device 102. The one or more widgets will be discussed in greater detail with respect to FIG. 4. The one or more widgets may be configured to facilitate output of insurance information associated the one or more items. For example, the one or more widgets may comprise one or more selectable options. The one or more selectable options may present, to a user (e.g., buyer) the option to receive an insurance quote indicating a cost to insure the one or more items in the virtual cart. The one or more widgets may be configured to output one or more insurance quotes, one or more insurance policies, combinations thereof, and the like. The one or more widgets may be configured to receive one or more user inputs.

[0035] The insurance program 147 may be configured to generate one or more insurance quotes, one or more insurance policies, combinations thereof, and the like. The insurance program 147 may receive the information contained in the purchase indication via the one or more APIs 145. Based on receiving the purchase indication, the insurance program 145 may generate one or more insurance quotes. The one or more insurance quotes may include one or more pricing matrices, one or more line item quotes, one or more cart total quotes, combinations thereof, and the like. The one or more pricing matrices may be determined based on a number of items in the virtual cart, a total value of the one or more items in the virtual cart, a class of items (e.g., budget, standard, premium), combinations thereof, and the like. The line item quote may indicate a price to insure each item of the one or more items. The cart total quote may indicate a total cost to insurance the one or more items in the virtual cart.

[0036] A user, via the user device 102, and in communication with e-commerce platform 106, may select the one or more selectable options and “opt-in?’ to insure the one or more items. Based on the user opting in, the insurance program 147 may generate an insurance policy. The insurance policy may be associated with the one or more items. The insurance policy may be output to the user device 102. For example, the insurance policy may be sent to the user device and caused to be displayed via a display associated with the user device. A user may execute (e.g.. agree to) the insurance policy. Based on the user executing the insurance policy, the computing device 101 may receive, from either or both of the user device 102 and / or the e-commerce platform 106, an insurance policy execution indication.

[0037] The computing device 101 may receive one or more claims. The one or more claims may be sent from the user device 102 and / or the e-commerce platform 106. The one or more claims may comprise information associated with the one or more items, the user device 102, the e-commerce platform 106, and / or any other information, combinations thereof, and the like. The one or more claims may comprise information associated with one or more perils. The one or more perils may comprise one or more events or circumstances that impact the ability of a user to attend an event. For example, the one or more perils may comprise one or more illnesses, one or more injuries, one or more traffic accidents, one or more mechanical breakdowns, one or more carrier delays, one or more network interruptions or service interruptions, one or more home issues (e.g.. fire, flood, vandalism, burglary, natural disaster), one or more business issues (e.g., fire, flood, vandalism, burglary, natural disaster), employment termination, jury duty7, work relocation, military duty7, death, terms, conditions, inclusions, exclusions, combinations thereof, and the like.

[0038] The one or more claims may comprise claim supporting information (e.g., proof and / or alleged proof). For example, the one or more claims may comprise image data, audio data, text data, one or more data files, combinations thereof, and the like. The legitimacy of the one or more claims may be determined. For example, the claim supporting information may be reviewed to determine if the one or more perils occurred. The computing device 101 may determine the one or more perils occurred. For example, in the case a photo is submitted in the one or more claims, the computing device may use object detection and / or recognition to analyze the photo. For example, if the claim indicates the user cannot attend an event due to a house fire, the computing device may determine location associated with the photo (e.g., whether or not the photo was taken at or near the user’s home), timing information associated with the photo (e.g., time, date to ensure the photo was taken recently or within a certain time an event associated with, for example, a purchased ticket). The computing device may determine the photo is a photo of a house after a fire (or presently on fire).

[0039] The computing device may cause a refund to be issued. For example, if it is determined the one or more claims are legitimate, the computing device 101 may cause a refund to be issued to an account (e.g., bank account, user account, subscription account) associated with the user (and / or the user device 102).

[0040] At least one part of the kernel 141, middleware 143, or API 145 may be referred to as an Operating System (OS). The memory 130 may include a computer-readable recording medium having a program recorded therein to perform the method according to various embodiment by the processor 120.

[0041] The kernel 141 may control or manage, for example, system resources (e.g., the bus 110, the processor 120, the memory 130, etc.) used to execute an operation or function implemented in other programs (e.g., the middleware 143, the API 145. or the application program 147). Further, the kernel 141 may provide an interface capable of controlling or managing the system resources by accessing individual constitutional elements of the computing device 101 in the middleware 143, the API 145, or the application program 147.

[0042] The middleware 143 may perform, for example, a mediation role so that the API 145 or the application program 147 can communicate with the kernel 141 to exchange data.

[0043] Further, the middleware 143 may handle one or more task requests received from the application program 147 according to a priority. For example, the middleware 143 may assign a priority of using the system resources (e.g., the bus 110, the processor 120, or the memory 130) of the computing device 101 to at least one of the application programs 147. For instance, the middleware 143 may process the one or more task requests according to the priority assigned to the at least one of the application programs, and thus may perform scheduling or load balancing on the one or more task requests.

[0044] The API 145 may include at least one interface or function (e.g., instruction), for example, for file control, window control, video processing, or character control, as an interface capable of controlling a function provided by the application 147 in the kernel 141 or the middleware 143.

[0045] For example, the input / output interface 150 may play a role of an interface for delivering an instruction or data input from a user or a different external device(s) to the different constitutional elements of the computing device 101. Further, the input / output interface 150 may output an instruction or data received from the different constitutional element(s) of the computing device 101 to the different external device(s).

[0046] The display 160 may include various types of displays, for example, a Liquid Crystal Display (LCD) display, a Light Emitting Diode (LED) display, an Organic LightEmitting Diode (OLED) display, a MicroElectroMechanical Systems (MEMS) display, or an electronic paper display. The display 160 may display, for example, a variety of contents (e.g., text, image, video, icon, symbol, etc.) to the user. The display 160 may include a touch screen. For example, the display 160 may receive a touch, gesture, proximity, or hovering input by using a stylus pen or a part of a user's body.

[0047] In an embodiment, the display 160 may be configured for displaying a user interface. The user interface may be configured to receive inputs. For example, the display 160 may comprise a touchscreen.

[0048] The communication interface 170 may establish, for example, communication between the computing device 101 and an external device (e.g., the user device 102. the ecommerce platform 106). For example, the communication interface 170 may communicate with the external device (e.g., the user device 102, the e-commerce platform 106) via a network 162. The network 162 may make use of both wireless and wired communication protocols.

[0049] For example, as a wireless communication protocol, the wireless communication may use at least one of Long-Term Evolution (LTE), LTE Advance (LTE-A), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Universal Mobile Telecommunications System (UMTS), Wireless Broadband (WiBro), Global System for Mobile Communications (GSM), other cellular technologies, combinations thereof, and the like. Further, the wireless communication may include, for example, a near-distance communication protocol. The near-distance communication protocol may include, for example, at least one of Wireless Fidelity (WiFi). Bluetooth. Near Field Communication (NFC), Global Navigation Satellite System (GNSS), and the like. According to a usage region or a bandwidth or the like, the GNSS may include, for example, at least one of Global Positioning System (GPS), Global Navigation Satellite System (Glonass), Beidou Navigation Satellite System (hereinafter, "‘Beidou”), Galileo, the European global satellitebased navigation system, and the like. Hereinafter, the ‘‘GPS” and the “GNSS” may be used interchangeably in the present document. The wired communication may include, for example, at least one of Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI). Recommended Standard-232 (RS-232), power-line communication. Plain Old Telephone Service (POTS), and the like. The network 162 may include, for example, at least one of a telecommunications network, a computer network (e.g., LAN or WAN), the internet, and a telephone network.

[0050] According to one exemplary embodiment, the e-commerce platform 106 may include a group of one or more servers. According to various exemplary embodiments, all or some of the operations executed by the computing device 101 may be executed in a different one or a plurality of electronic devices (e.g., the user device 102 or the e-commerce platform 106. For this, for example, a cloud computing, distributed computing, or client-server computing technique may be used. The user device 102 may be, for example, a computer, a mobile phone, a tablet, a laptop, a desktop computer, a smartwatch, or the like. The server 106 may comprise a cloud-host or other similar server.

[0051] FIG. 2 shows an example method 200. The method 200 may be carried out by any one or more of the devices described herein such as the computing device 101, the user device 102, and / or the e-commerce platform 106. The one or more APIs 145 may receive product information. The product information may comprise one or more product IDs. one or more product prices, one or more product brands, one or more product models, one or more product classes (e.g., budget, standard, premium, etc...). The product information may indicate one or more insurance services available to the user. The one or more APIs 145 may receive underwriter information. The underwriter information may comprise one or more underwriter identifiers, actuarial data, risk data, priority data, an active status indicator, combinations thereof, and the like. The one or more APIs 145 may receive primary policy data. The primary policy data may comprise product data, underwriter data, look period data, terms and conditions data, perils data, location based inclusions or exclusions, combinations thereof, and the like. The one or more APIs 145 may receive perils data. The perils data may comprise name data, description data, legal description, icon data, required documents data, combinations thereof, and the like. The peril data may comprise one or more peril names, one or more peril descriptions, one or more legal descriptions, one or more icons, combinations thereof, and the like. For example, a peril name may be ■‘automobile theft.” For example, a peril description may be, “theft of your automobile within 48 hours of the event that results in your inability to attend the event.” For example, an example of a legal description may be, “theft of your automobile within 48 hours of the event that results in your inability to attend the Event.’1 The one or more APIs 145 may receive pricing data. The pricing data may include pricing matrix data, line item quote data, cart total quote data, pricing tiers data, combinations thereof, and the like. The pricing can be configured at the Policy, Affiliate and Client levels, allowing for flexibility at each level of the platform. The pricing tiers data may comprise a minimum amount (e.g., a minimum premium cost to protect a line item), a maximum amount (e.g., a maximum coverage amount), charged amount, type data (e.g., fixed dollar or percentage), name data, product data, country / region data (e.g.. inclusions / exclusions), tiers, weight (e.g.. if multiple matrices are assigned), item level data, cart level data, whether or not the policy is assignable, combinations thereof, and the like. For example, if an item cost is between $0.01 - $24.99, a minimum premium may be $2.99. The one or more pricing tiers can be associated at the Policy, Affiliate and Client level. Item level data may comprise or otherwise be associated with an item in a virtual shopping cart. For example, if a customer purchases four tickets to a baseball game, each ticket may be considered a line item. For example, each ticket may then be issued a policy. For example, the customer may then file a claim against one or all of the line items (tickets). For example, cart level data may indicate all the items in the virtual shopping cart. For example, if the customer purchases four baseball tickets and each ticket is an individual line item, then the cart level data may comprise all the items summed together. The platform may be configured to generate a quote at the line item level or the cart level (all items together). For example, if a customer is purchasing baseball tickets in Russia, the system may determine no policies are available in Russia. For example, certain policies are available in certain parts of the world. For example, a US policy may be different than a Canada policy, which may be different than a Mexico policy.

[0052] The one or more APIs 145 may receive affiliate data. The affiliate data may comprise one or more of name data, product data, pricing data, policies data, payment type data, combinations thereof, and the like. The one or more APIs 145 may receive client data. The client data may comprise client name data, affiliate data, product data (e.g., limited by what is assigned to an affiliate), policies data (e.g., may be defaulted to match affiliate or may be configured for cascading in the platform, configured with the ability to customize at the Affiliate and Client levels), pricing data (e.g., may be defaulted to match affiliate), payment type (e g., may be defaulted to match affiliate), combinations thereof, and the like. For example, Affiliate 1 may have configurations for a Product, Pricing Matrix, Primary Policy and Payment Type. For example, clients associated with the Affiliate may have the same or similar configurations, or a different product, a different Pricing Matrix, a different Primary Policy, a different Payment Type, combinations thereof, and the like.

[0053] FIG. 3 shows an example product 300. For example, the example product 300 may be a FanShield product. The example product 300 may include one or more primary policies (e.g., 302 which is primary policy FS1 and 305 which is primary policy FS2). Each primary policy of the one or more primary policies may be associated with one or more underwriters (e.g., 303 and 306). For example, the first primary policy 302 may be associated with a first underwriter 303. For example, the second primary policy 305 may be associated with a second underwriter 306. The one or more primary' policies may be associated with one or more perils. For example, the first primary’ policy 302 may be associated with a first one or more perils 304 (e.g.. peril 5. peril 6, peril 7, and peril 8) while the second primary policy 305 may be associated with a second one or more perils (e.g., peril 5, peril 6, and peril 9). The one or more primary policies may be associated with one or more pricing matrices (e.g., pricing matrix 308 and pricing matrix 309). The one or more products may be associated with one or more affiliates (e.g., Affiliate A, Affiliate C), and / or one or more clients (e.g.. Client 1, Client 2, Client 4).

[0054] FIG. 4A shows an example widget 400. The widget 400 may be a modularly inserted software application. The widget 400 may be configured to be output on a display associated with a user device 102. The widget 400 may be modularly inserted into a checkout application associated with the e-commerce platform 106. For example, the widget 400 may be configured to output during the checkout process on the e-commerce platform 106. For example, the widget 400 may be an in-cart widget.

[0055] The widget 400 may' comprise one or more selectable options 410 and 420. The one or more selectable options may comprise checkboxes, radial buttons, sliders, combinations thereof, and the like. The one or more selectable options may be configured to receive one or more user inputs. For example, a first selectable option (e.g.. the selectable option 410. an “accept” or “opt-in” option) may' be configured to receive a first user input. The first user input may be configured to, if selected, cause the user to opt-in to an insurance policy associated with one or more items in the user's virtual shopping cart associated with the ecommerce platform. The one or more selectable options may comprise a second selectable option (e.g., the selectable option 420, a “decline” option). The second selectable option may be configured to cause the user to not be enrolled in (e.g., “opt-out” of) an insurance policy. The widget 400 may be configured to output one or more insurance quotes 430, one or more perils 440, combinations thereof, and the like. The widget 400 may be configured to output one or more recommendations 450. FIG. 4B shows a claims portal 460. The claims portal may comprise one or more fields associated the one or more perils associated with the insurance policy. The claims portal 460 may be configured to receive one or more user inputs.

[0056] FIGS. 5A-5L show example data elements and methods. For example, FIG. 5A shows example core affiliate, core client and core legacy client API key data elements. For example, FIG. 5B shows a core product data element. For example, FIG. 5C shows an example core primary policy data element. For example, FIG. 5D shows an example core primary policy inclusions data element, an example core primary policy exclusions data element, an example core primary policy terms element, and an example core primary policy pricing matrices element. The core primary policy inclusions data element, the core primary policy exclusions data element, the core primary policy terms element, and the core primary policy pricing matrices element may be used in determining one or more policies, one or more policy terms, and one or more prices. For example, FIG. 5E shows an example core policy terms element, an example core pricing matric inclusions element, an example core pricing matrix exclusions element, and an example core pricing matrix element. For example, FIG. 5F shows an example core order element. The core order element may be used during the client order submittal process. For example, FIG. 5G shows an example core order transactions element and an example core transactions element. The core order transactions element and the core transactions element may be used in the order payment process. For example, FIG. 5H shows an example core policy element and an example nota action email element. The core policy element may be used in issuing a policy. The nota action email element may be used in generating and sending a confirmation email. For example. FIG. 51 shows an example core customer login link element. The core customer login link element may be used during customer authentication. For example, FIG. 5J shows an example claim element. The claim element may be used in generating a refund request. For example, FIG. 5K shows an example claim action history' element and an example under element. The claim action history element and the under writer element may be used in an adjudication process. For example, FIG. 5L shows payment transaction history element and an example claim underwriting product payment program element, and an example payment program element. These elements may be used in the refund payment process.

[0057] The backend architecture supporting the widget is detailed in FIGS. 5A through 5L. Core APIs handle essential operations, including client and affiliate management (FIG. 5A), product and policy configuration (FIGS. 5B-5D), and pricing determination (FIG. 5E). Additional functions include transaction processing (FIG. 5F), policy issuance (FIG. 5H), and customer authentication and claims support through dedicated portals (FIG. 51). This robust backend ensures smooth operations across diverse platforms, adapting to the unique requirements of each e-commerce client.

[0058] FIGS. 5A-5L illustrate a sophisticated backend architecture that significantly improves upon existing systems for managing insurance policies in e-commerce platforms. These figures demonstrate a modular and dynamic approach to data handling, transaction processing, and policy management, providing scalability, flexibility, and enhanced user experience. FIG. 5A introduces a core framework for managing affiliates and clients, enabling precise configuration of policies, pricing, and relationships without redundancy. This setup allows clients to customize their insurance offerings efficiently. FIG. 5B and FIG. 5C expand on this by detailing how product attributes, such as shipping perils, payment ty pes, and policy configurations, are dynamically managed. These modules enable the system to adapt to varied user needs and product types, ensuring flexibility and transparency.

[0059] FIGS. 5D and 5E show policy inclusions, exclusions, and pricing matrices. By incorporating geographic and regulatory factors into the policy logic, the system provides an advantage over the art. For example, a dynamic pricing capability ensures fairness and transparency while meeting regional requirements. Moving into transaction efficiency, FIG. 5F outlines the structure of orders, embedding metadata for policies, pricing, and customer details, which enhances data integrity and streamlines integration with payment systems. FIG. 5G describes transaction management, focusing on linking orders to payments and handling gateway responses to improve reliability . FIG. 5H highlights the policy issuance process, separating it from payment processing to ensure robust error handling and accountability.

[0060] Authentication and claims handling are detailed in FIGS. 5I-5K, which present a secure and efficient framework for managing user interactions with the system. FIG. 51 introduces a secure login system using tokens, ensuring that only authorized users can access policy and claims information. FIG. 5J and FIG. 5K outline the claims request and adjudication processes, incorporating comprehensive data structures and tracking claim history7 to facilitate transparent decision-making and compliance with underwriter requirements. Finally. FIG. 5L streamlines refund and payment processing by linking claims to specific payment processors and refund methods, offering users flexibility and faster payouts.

[0061] This architecture provides several technical advancements over traditional systems. The modular API-driven design allows real-time updates and scaling, ensuring flexibility across clients and regions. The integration of claim-specific data structures and transaction linking streamlines the insurance lifecycle, from purchase to refund, improving operational efficiency and user satisfaction. Furthermore, by accommodating geographic and regulatory constraints, the system ensures compliance and broad market applicability. Collectively, these features position the widget as a technically superior solution for managing ecommerce insurance operations.

[0062] For example, FIGS. 6A-6K show an example method. FIGS. 6A-6K describe a robust and dynamic system for tailoring and managing insurance offerings based on userspecific and geographic factors, providing significant technical improvements over traditional systems. The workflow begins with FIG. 6A. which outlines the affiliate and client setup within the platform. Clients instantiate the widget by providing a public key, enabling seamless integration and identifying the appropriate insurance products associated with the client. FIG. 6B focuses on determining the user’s location via IP lookup. This step establishes geographic eligibility for policies, accounting for country- and region-specific exclusions, such as restricted areas or jurisdictions where policies are unavailable.

[0063] For example, as shown in FIG. 6A at 601, an affiliate and client set may be setup within a platform. The client may embed a javascript snippet on a webpage on which the widget will appear. At 602, the client device may instantiate the widget by providing a public key, which may be preconfigured and provisioned to the client. At 602 the widget communicates with one or more APIs using the public key to identify the client and determine which products the client is associated with.

[0064] For example, as shown in FIG. 6B at step 603, one or more customer locations may be determined via IP lookup. At 604, one or more policies, policy terms, and / or prices may be determined. The one or more policies, policy terms, and / or prices may be determined based on the one or more customer locations.

[0065] FIG. 6C describes how policies and pricing are dynamically tailored to the customer’s location and cart contents. The widget provides users with the choice to opt in or out of protection based on this tailored information. If the user opts in, the client submits the protection order using secure authentication keys, incorporating customer, event, and cart details into the submission. FIG. 6D follows with the policy issuance process, where the system verifies payment and generates the policy, ensuring it aligns with the selected coverage and pricing options.

[0066] For example, as shown in FIG. 6C at step 605, a customer may interact with the widget. The widget may display the proper policy and pricing information. At this point, the customer may opt-in to include protection with the purchase, or opt-out and decline protection. At 606, if the customer opts-in to protection, the client may submit an order using the public key and a secret key from the backend for the protection that was opted-in to. For example, information about the customer and the customer’s cart may be included in the order submission. For example, the order submission may include customer information, event information, items purchased, combinations thereof, and the like.

[0067] For example, as shown in FIG. 6D at 607, based on how the client is setup within the platform, the platform may accept one or more payments. For example, the platform may accept payment via ACH / invoice, credit card, or shared token. For example, at 608, one the payment is verified and accepted by the platform, a policy may be issued to the customer.

[0068] FIG. 6E introduces the confirmation email step, where users receive their policy details and instructions for next steps, such as filing claims. This email offers clarity and transparency, ensuring users can access their coverage information quickly. For customers needing to file claims, FIG. 6F outlines the authentication process. Only authorized users can submit claims, and they must provide necessary documentation to initiate the refund process.

[0069] For example, as shown in FIG. 6E at 609, once the payment is confirmed and successfully transacted, a confirmation email may be generated and sent to the customer. For example, from the email, the customer may be able to cancel the policy and / or submit a refund request (e.g.. a claim).

[0070] For example, as shown in FIG. 6F, at 610, the customer may be authenticated. For example, the customer may be authenticated with the platform before submitting a refund request. For example, at 611. the customer may file a refund request within the time determined by the policy.

[0071] The claims adjudication and refund process are detailed in FIGS. 6G-6K. FIG. 6G explains how adjudicators review claims, request additional evidence, and make decisions to approve or deny requests. Approved claims proceed to FIG. 6K, which describes refund payment processing. The system supports multiple payout methods, including Hyperwallet, ensuring users receive their refunds efficiently. This end-to-end integration streamlines the claim lifecycle, offering a smooth user experience and reducing operational overhead.

[0072] For example, as shown in FIG. 6G, at 612 an adjudication process may take place. For example, based on the information provided by the customer in the refund request process, the adjudication can (1) ask for more documentation to make the correct decision, (2) deny the refund request based on evidence, or (3) approve the refund. For example, at step 613, a refund payment may be processed. For example, when the customer’s refund request is approved, the customer may be refunded money for items for which the customer submitted the refund. The customer may be paid via Hyperwallet, which may allow the customer to choose from one or more delivery methods.

[0073] For example, as shown in FIG. 6H, and returning to earlier in the method, one or more product offerings may be determined. For example, the client may instantiate the widget by providing a Public Key. which was preconfigured and provided to the client by the platform. The widget may communicate with one or more platform APIs using the Public Key to identify and the client and determine which products the client is associated with.

[0074] For example, as shown in FIG. 61, the method may comprise determining one or more policies, one or more policy terms, and / or pricing information. For example, based on the IP address lookup, the widget may determine which country and region the customer is in. Based on where the customer is located, one or more policies can be determined and issued along with proper pricing in order to display a quote. The one or more policies may be provided by one or more insurance carriers and / or one or more insurance underwriters. A Refund as a Service (RaaS) may have a single price for every' country / region in the world,

[0075] For example, as shown in FIG. 6J, embedded protection may be purchased. For example, the widget may not be used for embedded RaaS. The protection price may be included within the price of an event ticket. For example, a client may decide the price of protection, based on one or more platform guidelines. For example, every ticket for an event may be sold with a protection policy. For example, a client may submit an order to the platform. For example, the client may submit the order to the platform using the Public Key and a Secret Key from the backend for the protection purchased. For example, information about the customer and the customer’s cart may be included in the order submission. For example, the order may include customer information, event information, and one or more items purchased.

[0076] For example, as shown in FIG. 6K, the method may comprise issuing one or more policies. For example, once payment is verified and accepted by the platform, one or more policies may be issued to the customer. For example, the method may comprise generating and sending one or more confirmation emails. For example, once the payment is successful, a confirmation email may be delivered to the customer from the client (e.g., not from the platform). The email may be configured to allow a user to submit one or more refund requests.

[0077] The claims and refund process is depicted in at least FIG. 6F, FIG. 6G, and FIG. 6K. Users authenticate their accounts before submitting claims and provide the necessary documentation to support their requests (FIG. 6F). Adjudicators review claims, requesting additional evidence, denying, or approving them based on the provided information (FIG. 6G). Approved refunds are processed promptly, offering users multiple payout options, including through Hyperwallet (FIG. 6K).

[0078] This system presents several technical improvements over traditional methods. By integrating IP-based location data and regional exclusions, FIGS. 6A-6B ensure policies comply with regulatory constraints and are relevant to the user. The dynamic configuration of policies and pricing in FIG. 6C provides transparency and flexibility, catering to diverse user needs. The modular handling of authentication, adjudication, and refunds in FIGS. 6F-6K enhances security7, efficiency, and customer satisfaction. Together, these figures showcase a system that adapts dynamically to user and geographic variables while maintaining streamlined operations, making it a technically superior solution for managing insurance in e-commerce.

[0079] FIG. 7 shows an example method 700. The example method 700 may be carried out via any combination of one or more devices described herein such as the computing device and user device. At 710 one or more JavaScript widgets may be ended in a website. The one or more JavaScript widgets may be configured to be displayed, for example, on a webpage. The one or more widgets may comprise small applications. At 720, the widget may be instantiated. For example, an instance or an occurrence of the one or more widgets may be created within the context of the webpage. For example, one or more widget properties, one or more widget behaviors, and one or more widget placements may be configured. For example, the widget may be instantiated by a client device by providing a pre-configured public key. For example, the widget may be provisioned with customer cart information.

[0080] At 730, the widget may perform an IP lookup. For example, the widget may determine one or more of an IP address associated with a device on which the webpage is displayed. For example, the widget may determine one or more locations associated with the device. At 740, the widget may communication with one or more APIs using the preconfigured public key. The widget may use the public key to identify the client device and determine one or more products associated with the client device. At 750, once the client and the one or more products have been determined, the consumer cart information and consumer location information may be used to determine one or more protection products and one or more protection product prices. At 760, one or more selectable options may be output. For example, the one or more selectable options may comprise one or more opt-in options and / or one or more opt-out options. At 770, it may be determined the one or more opt-in options were selected. Further, at 770, if the one or more opt-in options are selected, the client device may submit an order using the public key and a secret key from the band for the protection opted in to. At 780, it may be determined that payment was accepted. The method may further comprise issuing one or more policies.

[0081] FIG. 8 shows an example method 800. The example method 800 may be carried out via any combination of one or more devices described herein such as the user device and the computing device. At 810, an indication of a checkout command can be received. The indication of the checkout command may be received by a modularly inserted application. The indication of the checkout command may be received from a user device based on a user input via a user interface associated with the user device. The indication of the checkout command may be received from an application resident on, or remote from, the user device. For example, the application may be associated with an e-commerce platform. The e-commerce platform may be configured to facilitate the purchase of one or more items (e.g.. one or more virtual items and / or one or more physical items). For example, one or more virtual items may comprise one or more tickets or one or more access rights to live events such as concerts, sporting events, public speaking events (e.g., lectures, speaker series, political rallies and the like), or one or more virtual representations of physical items. The one or more physical items may comprise tickets (e.g., paper tickets) to events, or any other physical items (e.g., clothes, sporting goods, or any other physical items). For example, the one or more virtual items may be in a virtual shopping cart. The one or more items may have been placed in the virtual shopping cart by a user. For example, the user may navigate an e-commerce platform and select one or more items to L‘add to cart." or other similar techniques to identify the one or more items and items the user interested in purchasing.

[0082] The indication of the checkout command may comprise pricing information associated with the one or more virtual items or one or more physical items. For example, the pricing information may include a selling price, one or more fees (e.g., service fees), taxes, combinations thereof, and the like.

[0083] At 820, an insurance quote may be generated. The insurance quote may be generated by a computing device. The insurance quote may be generated based on one or more underwriters, one or more perils, one or more terms and conditions, one or more location based inclusions or exclusions. The insurance quote may be sent to the user device. The insurance quote may be generated based on the pricing information associated with the one or more virtual items and / or one or more physical items. The one or more perils may comprise one or more events or circumstances that impact the ability of a user to attend an event. For example, the one or more perils may comprise one or more illnesses, one or more injuries, one or more traffic accidents, one or more mechanical breakdowns, one or more carrier delays, one or more network interruptions or service interruptions, one or more home issues (e.g., fire, flood, vandalism, burglary, natural disaster), one or more business issues (e.g.. fire, flood, vandalism, burglary, natural disaster), employment termination, jury duty, work relocation, military duty, death, terms, conditions, inclusions, exclusions, combinations thereof, and the like.

[0084] The insurance quote may be associated with one or more flexible price tiers based on the one or more items. For example, a first price tier may be associated with a purchase of a first quantity of items or a first range of quantities of items, a second price tier may be associated with a second quantity of items or a second range of quantities of items. The flexible price tiers may be associated with one or more minimum amounts, one or more maximum amounts, one or more charged amounts, one or more types (e.g.. fixed dollar or percentage).

[0085] The insurance quote may be associated with one or more pricing matrices by grouping one or more pricing tiers and setting one or more rules. For example, the one or more pricing matrices may be associated with one or more names, one or more products, one or more locations (e.g., countries, regions, states, jurisdictions, combinations thereof, and the like), one or more tiers, one or more weights (e.g., if one or more matrices are assigned), one or more item levels, one or more cart levels. The one or more pricing matrices may be assignable.

[0086] At 830, an insurance policy may be generated. The insurance policy may be generated based on a selection of one or more selectable options associated with the insurance quote. The selection may be configured to indicate a user accepts the insurance quote and intends to purchase the generated insurance policy. The insurance policy may comprise be associated with the one or more underwriters, the one or more perils, the one or more terms and conditions, and the one or more location based inclusions or exclusions. The insurance policy may cover the one or more items.

[0087] At 840, the insurance policy may be sent to a user device. Sending the insurance policy to the user device may comprise sending a message to the user device wherein the message comprises the insurance policy. Sending the insurance policy to the user device may comprise sending a message to the user device wherein the message comprises a link or other redirect configured to cause the user device to be directed to a page containing the insurance policy.

[0088] At 850, an indication of an acceptance of the insurance policy may be received. For example, the computing device may receive the indication of the acceptance of the insurance policy from the user device. The user device may determine the acceptance of the insurance policy based on a user interaction with the user interface associated with the user device. For example, the user may select one or more selectable options output on the user interface associated with the user device.

[0089] The method may comprise receiving, from the user device, an indication of an insurance claim. The method may comprise, based on receiving the indication of the insurance claim, sending a message to the user device wherein the message comprises one or more claims details fields. The method may comprise receiving one or more claims details. The method may comprise verifying the one or more claims details. The method may comprise causing, based on the pricing information, a refund to be delivered to the user account.

[0090] The modular purchase insurance widget may be integrated into e-commerce platforms using a robust system architecture, as depicted in FIGS. 1 through 9 (described below). This system includes a computing device equipped with a processor, memory. APIs, and communication interfaces to facilitate smooth interaction between the user’s device and the e-commerce platform. These components manage data processing and secure communication. The system’s architecture also supports a user-friendly human-machine interface, which enhances user interaction with the widget during the checkout process.

[0091] The overall workflow of the widget, as shown in FIGS. 2, 7. and 8, begins with embedding the widget into the e-commerce platform's checkout page as a JavaScript application (FIG. 7, Step 710). The widget connects to backend APIs (FIG.7, Step 740) to retrieve customer data and determine applicable insurance options. It dynamically generates insurance quotes based on factors such as cart contents and user location determined via IP lookup (FIG.7, Step 750; FIG. 8, Step 820). Users are then presented with options to opt in or out of coverage (FIG. 7, Step 760). For users who opt in, the widget processes the order securely, issues a policy upon payment confirmation, and sends the policy details to the user via email (FIG. 7. Steps 770-780; FIG. 8. Steps 830-850).

[0092] FIG. 9 shows a system 900 for item purchase insurance. Any device and / or component described herein may be a computer 901 as shown in FIG. 9. The computer 901 may comprise one or more processors 903, a system memory 912. and a bus 913 that couples various components of the computer 901 including the one or more processors 903 to the system memory' 912. In the case of multiple processors 903, the computer 901 may utilize parallel computing. The bus 913 may comprise one or more of several possible ty pes of bus structures, such as a memory bus, memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety’ of bus architectures.

[0093] The computer 901 may operate on and / or comprise a variety7 of computer-readable media (e.g., non-transitory). Computer-readable media may be any available media that is accessible by the computer 901 and comprises, non-transitory. volatile, and / or non-volatile media, removable and non-removable media. The system memory’ 912 has computer-readable media in the form of volatile memory’, such as random access memory (RAM), and / or non-volatile memory7, such as read-only memory7 (ROM). The system memory7 912 may store data such as ticket event data 907 and / or program modules such as operating system 905 and ticket event software 906 that are accessible to and / or are operated on by the one or more processors 903.

[0094] The computer 901 may also comprise other removable / non-removable, volatile / non-volatile computer storage media. The mass storage device 904 may provide non-volatile storage of computer code, computer-readable instructions, data structures, program modules, and other data for the computer 901. The mass storage device 904 may be a hard disk, a removable magnetic disk, a removable optical disk, magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or other optical storage, random access memories (RAM), read-only memories (ROM), electrically erasable programmable read-only memory (EEPROM), and the like.

[0095] Any number of program modules may be stored on the mass storage device 904. An operating system 905 and ticket event software 906 may be stored on the mass storage device 904. One or more of the operating system 905 and ticket event software 906 (or some combination thereof) may comprise program modules and the ticket event software 906. Ticket event data 907 may also be stored on the mass storage device 904. Ticket event data 907 may be stored in any of one or more databases known in the art. The databases may be centralized or distributed across multiple locations within the network 915.

[0096] A user may enter commands and information into the computer 901 via an input device (not shown). Such input devices comprise, but are not limited to, a keyboard, pointing device (e.g., a computer mouse, remote control), a microphone, a joystick, a scanner, tactile input devices such as gloves, and other body coverings, motion sensor, and the like These and other input devices may be connected to the one or more processors 903 via a human-machine interface 902 that is coupled to the bus 913, but may be connected by other interface and bus structures, such as a parallel port, game port, an IEEE 994 Port (also known as a Firewire port), a serial port, network adapter 908, and / or a universal serial bus (USB).

[0097] A display device 911 may also be connected to the bus 913 via an interface, such as a display adapter 909. It is contemplated that the computer 901 may have more than one display adapter 909 and the computer 901 may have more than one display device 911. A display device 911 may be a monitor, an LCD (Liquid Crystal Display), a light-emitting diode (LED) display, a television, a smart lens, smart glass, and / or a projector. In addition to the display device 911, other output peripheral devices may comprise components such as speakers (not shown) and a printer (not shown) which may be connected to the computer 901 via Input / Output Interface 910. Any step and / or result of the methods may be output (or caused to be output) in any form to an output device. Such output may be any form of visual representation, including, but not limited to, textual, graphical, animation, audio, tactile, and the like. The display 911 and computer 901 may be part of one device, or separate devices.

[0098] The computer 901 may operate in a networked environment using logical connections to one or more remote computing devices 914A,B,C. A remote computing device 914A,B,C may be a personal computer, computing station (e.g., workstation), portable computer (e.g., laptop, mobile phone, tablet device), smart device (e.g.. smartphone, smart watch, activity tracker, smart apparel, smart accessory), security and / or monitoring device, a server, a router, a network computer, a peer device, edge device or other common network nodes, and so on. Logical connections between the computer 901 and a remote computing device 914A,B,C may be made via a network 915. such as a local area network (LAN) and / or a general wide area network (WAN). Such network connections may be through a network adapter 908. A network adapter 908 may be implemented in both wired and wireless environments. Such networking environments are conventional and commonplace in dwellings, offices, enterprise-wide computer networks, intranets, and the Internet.

[0099] Application programs and other executable program components such as the operating system 905 are shown herein as discrete blocks, although it is recognized that such programs and components may reside at various times in different storage components of the computing device 901, and are executed by the one or more processors 903 of the computer 901. An implementation of ticket event software 906 may be stored on or sent across some form of computer-readable media. Any of the disclosed methods may be performed by processor-executable instructions embodied on computer-readable media.

[00100] While specific configurations have been described, it is not intended that the scope be limited to the particular configurations set forth, as the configurations herein are intended in all respects to be possible configurations rather than restrictive.

[00101] Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its steps be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its steps or it is not otherwise specifically stated in the claims or descriptions that the steps are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; the number or type of configurations described in the specification.

[00102] It will be apparent to those skilled in the art that various modifications and variations may be made without departing from the scope or spirit. Other configurations will be apparent to those skilled in the art from consideration of the specification and practice described herein. It is intended that the specification and described configurations be considered as exemplary only, with a true scope and spirit being indicated by the following claims.

[00103] For purposes of illustration, application programs and other executable program components are illustrated herein as discrete blocks, although it is recognized that such programs and components can reside at various times in different storage components. An implementation of the described methods can be stored on or transmitted across some form of computer readable media. Any of the disclosed methods can be performed by computer readable instructions embodied on computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example and not meant to be limiting, computer readable media can comprise “computer storage media” and “communications media.” “Computer storage media” can comprise volatile and nonvolatile, removable and non-removable media implemented in any methods or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Exemplary computer storage media can comprise RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.

Claims

1. A method comprising:receiving, by a modularly inserted application, from a user device associated with a user account, an indication of a checkout command associated with one or more virtual items in a virtual shopping cart, wherein the indication of the checkout command comprises pricing information associated with the one or more virtual items and service fee information associated with the virtual shopping cart;generating, based on the pricing information and the sendee fee information, an insurance quote;generating, based on receiving a selection of one or more selectable options from the user device, an insurance policy ;sending, to a user device, the insurance policy;receiving, from the user device, an indication of an acceptance of the insurance policy.

2. The method of claim 1. further comprising:receiving, from the user device, an indication of an insurance claim;based on receiving the indication of the insurance claim, sending a message to the user device wherein the message comprises one or more claims details fields;receiving one or more claims details;verifying the one or more claims details; andcausing, based on the pricing information, a refund to be delivered to the user account.

3. The method of claim 1, wherein the one or more virtual items comprise one or more tickets, one or more access rights, one or more experiences, or one or more virtual representations of physical items.

4. The method of claim 1, wherein generating the insurance quote comprises:determining one or more of: one or more line items for one or more tickets or one or more experiences, one or more platform order identifiers, one or more event identifiers, one or more customer identifiers, one or more billing addresses, one or more quote tokens, one or more payment details, or one or more age verifications.

5. The method of claim 1. wherein receiving the indication of a checkout command comprises receiving the indication of the checkout command from an e-commerce platform.

6. The method of claim 1. wherein generating the insurance quote comprises: determining one or more values associated with the one or more virtual items;determining one or more underwriters;determining one or more perils;determining one or more terms and conditions; anddetermining one or more location based inclusions or exclusions.

7. The method of claim 1. further comprising causing, based on the indication of the checkout command, one or more selectable options to be output on a user interface of the user device.

8. One or more non-transitory computer-readable media storing processor-executable instructions that, when executed by at least one processor, cause the at least one processor to:receive, by a modularly inserted application, from a user device associated with a user account, an indication of a checkout command associated with one or more virtual items in a virtual shopping cart, wherein the indication of the checkout command comprises pricing information associated with the one or more virtual items and service fee information associated with the virtual shopping cart;generate, based on the pricing information and the service fee information, an insurance quote;generate, based on receiving a selection of one or more selectable options from the user device, an insurance policy;send, to a user device, the insurance policy;receive, from the user device, an indication of an acceptance of the insurance policy.

9. The one or more non-transitory computer-readable media of claim 8, wherein the processorexecutable instructions further cause the at least one processor to: receive, from the user device, an indication of an insurance claim;based on receiving the indication of the insurance claim, send a message to the user device wherein the message comprises one or more claims details fields;receive one or more claims details;verify the one or more claims details; andcause, based on the pricing information, a refund to be delivered to the user account.

10. The one or more non-transitory computer-readable media of claim 8, wherein the one or more virtual items comprise one or more tickets, one or more access rights, one or more experiences, or one or more virtual representations of physical items.

11. The one or more non-transitory computer-readable media of claim 8, wherein the processorexecutable instructions that, when executed by the at least one processor, cause the at least one processor to generate the insurance quote, further cause the at least one processor to determineone or more of: one or more line items for one or more tickets or one or more experiences, one or more platform order identifiers, one or more event identifiers, one or more customer identifiers, one or more billing addresses, one or more quote tokens, one or more payment details, or one or more age verifications.

12. The one or more non-transitory computer-readable media of claim 8, wherein the indication of the checkout command is received from an e-commerce platform.

13. The one or more non-transitory computer-readable media of claim 8, wherein the processorexecutable instructions that, when executed by the at least one processor, cause the at least one processor to generate the insurance quote, further cause the at least one processor to: determine one or more values associated with the one or more virtual items;determine one or more underwriters;determine one or more perils;determine one or more terms and conditions; anddetermine one or more location based inclusions or exclusions.

14. The one or more non-transitory computer-readable media of claim 8, wherein the processorexecutable instructions further cause the at least one processor to cause, based on the indication of the checkout command, one or more selectable options to be output on a user interface of the user device.

15. An apparatus comprising:one or more processors; andmemory storing processor executable instructions that, when executed by the one or more processors, cause the apparatus to:receive, by a modularly inserted application, from a user device associated with a user account, an indication of a checkout command associated with one or more virtual items in a virtual shopping cart, wherein the indication of the checkout command comprises pricing information associated with the one or more virtual items and service fee information associated with the virtual shopping cart;generate, based on the pricing information and the service fee information, an insurance quote;generate, based on receiving a selection of one or more selectable options from the user device, an insurance policy;send, to a user device, the insurance policy;receive, from the user device, an indication of an acceptance of the insurance policy.

16. The apparatus of claim 15, wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to:receive, from the user device, an indication of an insurance claim;based on receiving the indication of the insurance claim, send a message to the user device wherein the message comprises one or more claims details fields;receive one or more claims details;verify the one or more claims details; andcause, based on the pricing information, a refund to be delivered to the user accomrt.

17. The apparatus of claim 15, wherein the one or more virtual items comprise one or more tickets, one or more access rights, one or more experiences, or one or more virtual representations of physical items.

18. The apparatus of claim 15, wherein the processor executable instructions that, when executed by the one or more processors, cause the apparatus to generate the insurance quote, further cause the apparatus to determine one or more of: one or more line items for one or more tickets or one or more experiences, one or more platform order identifiers, one or more event identifiers, one or more customer identifiers, one or more billing addresses, one or more quote tokens, one or more payment details, or one or more age verifications.

19. The apparatus of claim 15, wherein the indication of the checkout command is received from an e-commerce platform.

20. The apparatus of claim 15, wherein the processor executable instructions, when executed by the one or more processors, further cause the apparatus to:determine one or more values associated with the one or more virtual items;determine one or more underwriters;determine one or more perils;determine one or more terms and conditions; anddetermine one or more location based inclusions or exclusions.

Images