Patent Application
20210326818
Herein is disclosed a system and method for introduction of a transaction mechanism to an e-commerce website, and more particularly a system and method for introduction of a transaction mechanism to an e-commerce website without requiring effort on the part of the operator of the aforementioned e-commerce website to participate in systems integration with the operator of the transaction mechanism.
Increasingly, commerce is conducted online, with some estimates putting aggregate electronic commerce (e-commerce) volume at approximately $861 billion in the year 2020. Such electronic commerce is constituted predominantly of consumer transactions conducted at e-commerce sites, which may in some instances be the online counterpart to a retailer's brick-and-mortar presence. In order for such commerce to take place, it is essential that there exists a means by which a consumer may initiate payment to the retailer in the absence of a traditional point-of-sale system.
Most e-commerce websites are structured to present items offered for sale by the retailer, and to permit a consumer to add a given product to a digital “shopping cart” for subsequent purchase via an online checkout process. The checkout process is typically initiated from within the aforementioned shopping cart in response to a consumer selecting a “checkout” button, whereupon the consumer is led through a series of webpages wherein the consumer may enter, among other information, payment information. Such payment information typically includes a credit card number, security code, billing ZIP code, name of the person embossed on the credit card, and so on. The software constituting the shopping cart is structured to interact with systems operated by a third party, such as a payment processor, in order to initiate a consumer's desired payment via one of the major payment networks. Thus, today it is the case that most e-commerce websites offer consumers the opportunity to purchase products via a payment transacted with one of the major payment networks.
Some consumers may desire to acquire a product from an e-commerce site through an alternative arrangement or payment mechanism—not by a payment transacted through a major payment network. For example, some consumers may desire to acquire a product from an e-commerce website via a lease-to-own arrangement or other alternative transaction mechanism. Typically, to introduce an alternative transaction mechanism to an e-commerce site, the operator of the e-commerce site would have to engage with the provider of the alternative transaction mechanism. Such engagement would usually include agreeing upon an interface by which the systems operating the e-commerce site could communicate with the systems operating the alternative transaction mechanism, and further include agreeing upon a communication procedure to be conducted through such interface. In the wake of agreeing upon such matters, each party would develop software that behaved in accord with the aforementioned interface and communication procedure, and the parties would cooperate to test such software prior to making it available to the public for use via the e-commerce site. These activities constitute a multiparty systems integration effort.
The multiparty systems integration efforts required in connection with the provisioning of alternative transaction mechanisms to e-commerce websites are expensive, complicated, time-consuming and inefficient. Consequently, they are conducted infrequently and the public suffers in the form of reduced transaction offerings presented by e-commerce websites. There thus exists a need to address this problem.
Against this background, the present subject matter was developed. According to some embodiments a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website. The website is operated by an operator of said website, such as an e-retailer. The transaction system includes a computing device that, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The browser extension is executed in response to the browser extension having been loaded by the web browser application. The browser extension contains instructions that, when executed, cause said extension to add a user interface element that is not native to the aforementioned website to a page of that website. The browser extension presents a user interface that is not native to the website in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from said operator of said website. The transaction pertains to a subject matter that includes the aforementioned good or goods. Finally, the extension initiates a purchase of the good or goods, in response to creation of the transaction by the user via the user interface presented by the browser extension.
According to other embodiments, a method is presented for permitting a user of a transaction system to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of goods. The website is operated by an operator of the website. The method includes executing a web browser application, with the transaction system. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The method further includes executing the browser extension, with the transaction system, in response to the browser extension having been loaded by the web browser application. The browser extension adds a user interface element that is not native to the website to a page of the website. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of said website. The transaction pertains to a subject matter including the aforementioned good or goods. Finally, the browser extension initiates a purchase of the aforementioned good or goods, in response to the creation of the transaction by the user via the user interface presented by the browser extension.
According to other embodiments, a transaction system is disclosed. The transaction system permits its user to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of the aforementioned good or goods. The website is operated by an operator of said website. The transaction system includes a computing device, which, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to launch a browser extension while the web browser application is navigated to the aforementioned website. The browser extension contains instructions that, when executed, cause said extension to add a user interface element to the website or web browser application. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of the website. The transaction pertains to a subject matter that includes the aforementioned good or goods.
According to some embodiments a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website. The website is operated by an operator of said website, such as an e-retailer. The transaction system includes a computing device that, in turn, includes a processing unit and a memory that is communicably connected with and readable by the processing unit. The memory contains instructions that, when executed by the processing unit cause the processing unit to execute a web browser application. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The browser extension is executed in response to the browser extension having been loaded by the web browser application. The browser extension contains instructions that, when executed, cause said extension to add a user interface element that is not native to the aforementioned website to a page of that website. The browser extension presents a user interface that is not native to the website in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from said operator of said website. The transaction pertains to a subject matter that includes the aforementioned good or goods. Finally, the extension initiates creation of a payment card number. The payment card number is to be used by the user to effect payment for the aforementioned good via said website, and via a payment transaction drawing upon funds of the aforementioned third party.
According to other embodiments, a method is presented for permitting a user of a transaction system to acquire at least one good marketed for sale on a website via a transaction offering that is not natively offered on the website for acquisition of goods. The website is operated by an operator of the website. The method includes executing a web browser application, with the transaction system. The web browser application is configured to load a browser extension while the web browser application is navigated to the aforementioned website. The method further includes executing the browser extension, with the transaction system, in response to the browser extension having been loaded by the web browser application. The browser extension adds a user interface element that is not native to the website to a page of the website. The browser extension presents a user interface that is not native to the website, in response to the user interacting with the aforementioned user interface element. The user interface enables creation of the transaction between the user and a third party that is distinct from the aforementioned operator of said website. The transaction pertains to a subject matter including the aforementioned good or goods. Finally, the browser extension initiates creation of a payment card number. The payment card number is to be used by the user to effect payment for the aforementioned good via said website, and via a payment transaction drawing upon funds of the aforementioned third party.
According to other embodiments, a transaction system permits a user thereof to acquire at least one good marketed for sale on a website via a transaction between the user and a third party. The transaction is not natively offered on the website. The website is operated by an operator of said website. The transaction system includes a web browser application presenting said website. The transaction system also includes a browser extension that interoperates with the web browser application. The browser extension is arranged to present a user interface that enables creation of the transaction between the user and the third party. The transaction results in the aforementioned at least one good being provided to said user. The browser extension is further arranged to initiate creation of a payment card number that is usable by the user on the website to conduct a payment operation pertaining to the aforementioned at least one good.
The e-commerce website 102 may be any website 102 that offers a product or service for sale via such website 102. For example, the websites associated with uniform resource locators (URLs) such as https://www.amazon.com, https://www.bestbuy.com, https://www.wayfair.com, https://www.homedepot.com, or https://www.walmart.com are examples of e-commerce websites 102, to name but a few. An e-commerce website 102 is typically structured to permit a user of the web browser 104 to select goods or services for purchase by adding such goods to a digital shopping cart accessible via the website 102, and to permit the user to pay for such goods or services within the cart via a checkout process. The checkout process typically permits the user to enter payment information pertaining to payment cards operable on the major payment networks to pay for the goods or services within the cart. The payment information is typically communicated to a payment processor to structure such information appropriately for the execution of a payment transaction and to direct such payment transaction to the appropriate payment network in accordance with its particular rules, in order to effectuate payment to the e-retailer. The user may have the purchased goods or services delivered to their residence or another location of their choosing, or may pick them up (for example, at a chosen brick-and-mortar retail location).
It may be the case that the user desires to obtain, but not necessarily purchase, goods or services from an e-commerce website 102 pursuant to a transaction structure not offered by the website 102. For example, the user may desire to acquire the goods pursuant to a lease-to-own arrangement, a subscription arrangement, an installment loan arrangement, or any other form of lease, payment or financing arrangement not serviced by major payment networks or not otherwise natively offered via the e-commerce website 102. For the sake of simplified discussion, the particular species of third-party transaction introduced into the e-commerce website 102 is described herein as a lease-to-own arrangement. However, those of skill in the art will understand that the principles disclosed herein are applicable to other varieties of transactional arrangements. Additionally, the goods or services acquired from the e-commerce website 102 are described as goods. Those of skill in the art will understand that certain varieties of transactional arrangements contemplate services as well as goods as the proper subjects of such transactions.
The system 100 includes a browser extension 106 that interoperates with the web browser 104 and certain e-commerce sites 102 that the browser 104 may render. According to some embodiments, the web browser 104 has been configured to launch the extension 106 in response to a user having entered a URL into the browser's 104 URL bar, if the particular URL includes a particular domain. For example, if the URL entered into the URL bar includes the domain “wayfair.com” or “bestbuy.com” and so on, the web browser 104 will respond by launching the extension, typically after having loaded the ecommerce site. The extension 106 may include a configuration file, such as a manifest file, that may describe the conditions under which the web browser 104 is to launch the extension. (Conceptual example: “launch the extension by the name of such-and-such if the URL entered in the URL bar contains the domain “bestbuy.com” or “wayfair.com” or so on.) The configuration file may describe other conditions for launch of the extension, in addition to a particular URL or domain having been entered into the browser's 104 URL bar. The extension 106, itself, may be structured as a JavaScript file, and may interact with the e-commerce site 102 presented via the web browser 104, such as through the JavaScript document object model. According to some embodiments, the user of the web browser 104 will have granted appropriate permissions to the extension 106 to permit its proper operation on the web browser 104.
The system 100 further includes a backend computing platform 108 operated by or on behalf of the third-party entity offering an alternative transactional arrangement such as a lease-to-own arrangement. Continuing with the example wherein the particular species of third-party transaction to be introduced into the e-commerce website 102 is a lease-to-own arrangement, the backend computing platform 108 executes various processes and exposes various application interfaces (APIs), such as web APIs, that cooperate to originate, effectuate and service lease-to-own arrangements. More broadly considered, the backend computing platform 108 executes various processes and exposes various APIs, such as web APIs, that cooperate to originate, effectuate and service alternative transaction structures suitable for conveying goods or services to a third party such as a consumer from an e-commerce website. Carrying on with the exemplary embodiment wherein the alternative transaction is a lease-to-own arrangement, the platform 108 may contain APIs by which the extension 106 interacts with the backend platform 108 to perform such tasks as: identify a pre-existing customer of the lease-to-own company (including retrieving the customer's personally identifiable information, his or her open-to-lease line, his or her remaining open-to-lease line, and so on); validate a particular good as being the appropriate subject of a lease-to-own arrangement, as discussed in more detail below; determine the terms pursuant which the lease-to-own company is willing to lease a particular good (example: monthly payment amount, and number of such monthly payments); construct a contract creating a lease-to-own relationship between a customer and the lease-to-own company, the subject of which is a particular validated good or goods, and the terms of which have been determined by the aforementioned service; and so on. Finally, according to some embodiments, the system 100 includes third-party services 110 that may interoperate with the extension 106 and backend platform 108 in the course of effectuating a lease-to-own arrangement (example: such third party services may include payment processing services extended by a payment processor; document cloud hosting services extended by a document cloud company; and so on).
In use, the system 100 may operate as depicted in
As show in operation 202, the extension 106 monitors the actions of the user while he or she shops on the e-commerce website 102. As a part of such activity, the extension 106 interacts with the e-commerce website 102 so as to determine which particular products the user intends to obtain. For example, the extension 106 may scrape such information from the website 102. Note that scraping operations do not require the operator of the e-commerce website 102 to deliberately expose an interface by which such information is conveyed.
The extension monitors the path of navigation of the user through the website 102 in order to determine whether the user has arrived at an appropriate point at which to insert a user interface element, such as a button, offering a lease-to-own arrangement to the user (operations 204 and 206). For example, most digital shopping carts employed by e-commerce websites 102 contain an entry point page, wherein the user can review which particular products are in his or her cart, can remove any unwanted items, and can opt to proceed to check out and therefore pay for the items within the cart. The aforementioned entry point page of the shopping cart may be altered by the extension 106 to include a button offering a lease-to-own arrangement to the user as an alternative option to checking out via the website's 102 native capabilities (meaning that the user will have to pay for the items via one of the major payment networks). Note that by virtue of the aforementioned user interface element (e.g., a button) having been introduced by the extension, the operator of the e-commerce website 102 is relieved of having to take any step whatsoever to cause such introduction of the element or otherwise accommodate it. According to some embodiments, the extension 106 adds the aforementioned user interface element (example: a button) to the web browser 104, itself, such as to a tool bar of the web browser 104.
The extension 106 detects a “click event” pertaining to the user interface element it added during operation 206 (operation 208). If the user clicks the aforementioned user interface element to explore a lease-to-own arrangement, operational flow is passed to operation 210. (If the user elects to check out using the website's 104 native checkout function, then the extension 106 does not interfere.) In operation 210, the extension 106 determines whether the product or products contained within the cart are eligible to be the subject of a lease-to-own relationship. Typically, consumable goods, permanently installed goods, or goods having a sales price less than a particular threshold value are not considered appropriate subjects of a lease-to-own arrangement. To identify the particular goods eligible to be the subject of a lease-to-own relationship, the extension 106 may send a message to the backend computing platform 108 identifying the items within the cart. The backend platform 108 may respond by indicating for each such item whether or not such item is eligible (operation 210). Note that no cooperation with the systems operating the e-commerce website is required to enable such eligibility inquiry—the inquiry and determination may be made on the basis of information scraped from the e-commerce website 102.
With respect to those items that are, in fact, eligible to be the proper subjects of a lease-to-own arrangement, the extension 106 cooperates with the backend platform 108 and perhaps other third-party services 110 to effectuate the lease-to-own arrangement (operation 212). For example, the extension 106 may: (1) present a user interface by which the user may identify himself or herself as an existing user and login to an account maintained by the backend platform 108; (2) retrieve information from the backend platform 108 concerning the user in the event he or she logs in as an existing user, including, for example, his or her open-to-lease line value and remaining open-to-lease line value; (3) determine whether the user has a sufficient remaining open-to-lease line value to permit the eligible goods to be leased; (4) in the event that the user was not a pre-existing customer, present a user interface and interact with the backend platform 108 so as to enroll the user as a customer of the lease-to-own company, and decision that user for a lease-to-own line (and determine whether such line is sufficient to permit the contemplated transaction); (5) interact with the backend platform 108 to retrieve an estimate of the terms of the contemplated transaction, and present such estimated terms to the user via a user interface; (6) optionally offer companion services (example: a damage liability waiver or a benefits package) to the user; (7) interact with the backend platform 108 to retrieve a definitive set of terms of the transaction in view of the user's selection of any aforementioned companion services; (8) interact with the backend platform 108 and optionally a third-party service 110 to create a contract document describing a lease-to-own arrangement for the eligible products pursuant to the aforementioned terms, and present a user interface to present such contract document to the user and permit the user to digitally initial and sign such document; (9) interact with the backend platform 108 or third-party service to store such contract document in the wake of it having been presented to the user for initialization or signature; and (10) interact with the backend platform 108 to obtain reference information, such as a lease identification number, and present such information to the user via a user interface. Note that none of the just-recited steps require interaction with the systems operating the e-commerce website 102.
In the wake of having effectuated the lease-to-own arrangement for the eligible goods (operation 212), the extension 106 initiates a process by which the leased good or goods are purchased by the lease-to-own company from the particular e-retailer operating the website 102, and delivered to the user (operation 214). For example, the extension 106 may initiate an automated process conducted by a remote computing platform (such as the backend computing platform 108) to purchase such goods via the e-commerce website 102 using a payment card titled in the name of the transaction company (example: lease-to-own company), and to have those goods delivered to the user's residence or another location, such as a location determined by the user. (Exemplary embodiments of such a process are disclosed herein, below). Note that the goods may be purchased by the transaction company (example: lease-to-own company) via the e-commerce website 102 without necessitation of any alteration to the website 102, itself, or the systems that operate it.
The upshot of the structure of the system embodiments of
Although
In use, the system 300 operates as depicted and described with regard to the methodological embodiments of
Query operations 402, 406, 408 and 410 test for the occurrence of events that may occur as the user navigates the e-commerce website 302. As these events occur, the operations 404, 412, 414, 416, 418 et seq. to which the queries 402, 406, 408 and 410 refer are executed promptly. The extension 306 may embody such operations 404, 412, 414, 416, 418 et seq. as functions or methods that are called invoked upon the occurrence of the events tested for by queries 402, 406, 408 and 410, rather than explicitly tested for.
After having navigated to the e-commerce site 302, the user engages in shopping activities and eventually navigates to the product description page 506 depicted in
Upon determination that a click event of an “Add to Cart” button has occurred from a product description page, operation 412 is invoked. In operation 412, information pertaining to the product that is the subject of the product description page 506 is scraped. For example, the extension 306 may scrape: product name 508, product shop keeping unit (SKU) 510, product price 512, product quantity 514, a set of category information, such as product category1 516, product category2 518, product category3 520, and product brand 522. As was the case in previous interactions with the HTML document comprising the page 506, the extension first determines the domain of the URL 502 in the URL bar 500. Based on the domain of the website 302 being presented by the browser 304, a domain-specific scraping strategy is employed (domain-specific scraping functions or methods may be contained within the extension 306 and called in the course of scraping operation 412). For example, for a given domain, the extension 306 may examine the HTML document comprising the product detail page 506 to extract elements with a given class name or element ID attribute or other attribute to extract the desired unit of data. (For example, it may be the case that product names across all product detail pages 506 have the same class name or element ID attribute or other attribute, meaning that to scrape the product name, the extension 306 need only extract the element identified by the aforementioned class name or element ID attribute or other attribute.) In addition to using the domain of the URL 502 in the URL bar 500 to determine the scraping strategy to be used to extract each particular unit of data, the domain may be used to determine which units of data are available to be extracted from a given e-commerce website 302. For example, some websites may only have one or two levels of product category data, meaning that the extension 306 would only scrape product category1, or product category1 and product category2 when scraping from a given site. According to some embodiments, in the event that a given product is associated with more than a certain threshold quantity of categories (example: three categories), a quantity of categories no greater than the aforementioned threshold are scraped for each given product, beginning with the highest-level category. (Example: assume a sound bar is associated with categories such as “audio” (category1), “home audio” (category2), “speakers” (category3) and “sound bars” (category4), then only category1, category2 and category3 would be scraped). For the sake of clarity, the term “highest level category” refers to the broadest category (“audio”), while the next highest-level category refers to the next broadest category (“home audio”), and so on.
In the wake of having scraped the product data (operation 412), the extension 306 constructs a product object corresponding to the product that is the subject of the product detail page 506. Thus, a first unit of scraped data (example: product name) is assigned to a first attribute of the aforementioned product object, and a second unit of scraped data (example: product SKU) is assigned to a second attribute of the aforementioned product object, and so on. The product object may also include other data obtained from the web browser 304 as opposed to having been scraped from the e-commerce website 302, such as the particular URL corresponding to the product detail page of the product described by the product object. After having constructed the product object, the product object is added to a product object array that is stored in local memory in the browser, such as by use of the sessionStorage API (operation 414). Thus, there is one product object stored in the product object array for each product that was added to the cart by virtue of the user having clicked the “Add to Cart” button 508 from a product detail page.
According to some embodiments, the various scraping strategies pertaining to various e-commerce domains are hard-coded into the extension 306, itself. According to other embodiments, the extension 306 uses the domain (or a value derived therefrom such as a retailer ID, discussed later) to retrieve the scraping strategy from a remote computing platform, such as backend platform 308. For example, the extension 306 may call the backend platform 308 with a retailer ID identifying the particular e-commerce site 302 to be scraped, and the platform 308 may respond with an array or other data structure identifying the particular class name associated with a given unit of product data to be scraped. These embodiments have the advantage of providing flexibility in the event that the operator of the e-commerce website 302 alters the structure of the site 302 so as to disrupt the present-tense scraping strategy. The scraping strategy can simply be updated at the remote computing platform, and the extension will scrape pursuant to the updated strategy without necessitation of updating the extension 306, itself.
After having navigated to product detail page 506 and adding the sofa to the digital shopping cart, the user next navigates to the product detail page 507 shown in
As a consequence of having clicked the “Add to Cart” button 510, the product description page 508 presents a sidebar 513 that displays the item just added to the cart, i.e., the end table (see
When the entry point page of the shopping cart is loaded, the URL 502 in the URL bar 500 is “wayfair.com/v/checkout/basket/show”. Loading of the shopping cart is detected by the extension 306 (query operation 408) by virtue of testing the URL 502 against the string known to be equal to that of the shopping cart for the wayfair.com domain. Thus, operation 408 is uniquely structured for each e-commerce site 302 with which the extension 306 interoperates. In other words, the extension 306 examines the domain of the URL 502 and determines what string the URL 502 should be tested against with the occurrence of each page load in order to determine whether the shopping cart has been entered. For the “wayfair.com” domain, the aforementioned string will equal one particular value (i.e., “wayfair.com/v/checkout/basket/show”), while for the “bestbuy.com” domain, the aforementioned string would equal another value (e.g., “bestbuy.com/cart”), and so on.
As a consequence of the extension 306 detecting the load of the shopping cart in query operation 408, operational flow is passed to operation 416. In operation 416, a transactional button 515 is added to the shopping cart page by the extension 306. In the particular example depicted in
Continuing on with the exemplary use case presently being discussed, the user clicks the transactional button 515, and the click event is detected by query operation 410, causing operational flow to transition to operation 418 (
In the wake of having scraped the product data from the cart (and organized it into one or more product object—one such object for each item in the car), the just-scraped data is compared to the product object array (operation 420). The purpose of operation 420 is to: (1) account for objects that may have been removed from the cart after having been added by virtue of a user having clicked an “Add to Cart” button from a product detail page—note that as presented in
In the wake of having performed adjustment operation 422, the extension 306 presents the user with a login screen, depicted in
Next, in operation 428, the response of the single-sign-on service 314 is examined by the extension 306, and if the response indicates a failure, the extension 306 does not permit advancement beyond the login screen of
In the wake of having accessed the validation service 316 (operation 430), the extension 306 accesses a tax estimation service 318 executing on the backend platform 308. The extension sends the GUID and product object array to the tax estimation service 318, and, supplied with residency information pertaining to the user (obtained by the service 318 by virtue of accessing the user's account information with the GUID), and further supplied with the price of each product based on the information in the product array, the service 318 responds with an estimate of the various taxes (example: sales tax, use tax, and so on) on a product-by-product basis, for each product that was indicated as being eligible for a lease-to-own arrangement during operation 430.
Next, in operation 434, the extension accesses a get-customer-information service 320 executing on the backend computing platform 308. The extension sends the service 320 the aforementioned GUID identifying the user, and the service 320 responds by returning information pertaining to the user, including: the user's open-to-lease line (which indicates the aggregate value of products, including tax, that the lease-to-own company is willing to spend to purchase eligible goods which are then leased by the lease-to-own company to the user), the amount of the user's lease-to-own line that remains available to fund future lease arrangements, the user's address, telephone number, and a lease ID identifying the contemplated lease transaction to the various data systems making up the backend platform 308. The information returned by the service 320 is converted into a customer object with object attributes equal to the various units of customer data returned by the service 320, and the customer object is stored (operation 436). According to some embodiments, the customer object is stored using the JavaScript sessionStorage API.
In the wake of having completed operation 434, the extension 306 constructs and presents the custom cart screen depicted in
In response to the user clicking the “Continue” button 519, the extension 306 presents the “Just a Moment” screen of
In the wake of receiving the response from the transaction-terms service 324, a transaction details screen, such as the one depicted in
Continuing on with the exemplary use case presently being discussed, the user indicates his next pay date using user input element 526 (operation 450), and then clicks the “Continue” button 528 (operation 452). In response, the extension stores the payment date entered via user input element 526 as a payment date object (operation 454). According to some embodiments, the payment date object is stored using the JavaScript sessionStorage API. Thereafter, the extension 306 re-accesses the aforementioned transaction-terms service 324, this time communicating to it the user's actual selection of companion services, as indicated by toggle buttons 521 and 524 (operation 456). The service 324 replies with the monthly lease payment, the initial terms of the lease, the term of the lease assuming the user elects to renew the lease for all required terms to ultimately obtain ownership of the product, an application fee associated with the contemplated transaction, and, for each selected companion service (if any), a monthly price and tax associated therewith. According to some embodiments, the extension presents the “Just a Moment” screen of
Next, in operation 458, the extension uses the information returned from the transaction-terms service 324 in operation 456 to construct and present the review-of-terms screen depicted in
Continuing on with the exemplary use case presently being discussed, the user reviews the terms presented via the review-of-terms screen depicted in
Continuing on with the exemplary use case presently being discussed, the user enters his or her payment information into the iFrame depicted in
In the wake of operation 470, the extension presents a “Success” screen, such as the one depicted in
In operation 478, the extension 306 calls a generate-contract service 326 executing on the backend platform 308. The extension 306 sends the generate-contract service 326 information required to generate a contract between the user and the provider of the sought-after transaction (in this example, a lease-to-own company). According to some embodiments, this means that the extension 306 communicates the following informational elements to the service 326: (1) the lease ID returned during execution of operation 434 (
Next, in operation 480, the extension 306 opens an iFrame referencing the aforementioned URL, and the contract created during operation 478 and hosted by the document storage cloud service 310 is presented to the user in the iFrame, as depicted in
In the wake of operation 488, the iFrame communicates the document—now initialed and signed—to the document storage cloud service 310, to be stored (operation 490). Receipt of the document by the document storage cloud service 310 causes the service 310 to access a document-cloud-service interface 334 executing on the backend platform 308 to deliver a message indicating that the contract has been signed by the user. In response, the document-cloud-service interface 334 stores this information in a manner accessible to the get-customer-progress service 322, which is also executing on the backend computing platform 308. While operation 490 is occurring, the “Processing” screen depicted in
In the wake of operation 492, the extension presents a “Success” screen, such as the one depicted in
At this stage of the process, the user has indicated which products he or she desires to lease, the products have been validated to determine which of them are eligible to be leased, and a contract has been signed between the user and the lease-to-own company establishing a lease-to-own arrangement between the user and the lease-to-own company relating to the eligible products. Next, according to some embodiments, the eligible products must be purchased by the lease to own company and delivered to the user. According to some embodiments, purchase of the products is conducted via a robotic process automation (RPA) system that operates upon the e-commerce website 302. In operation 499, the extension 306 initiates creation of a record within a database of an order to be effectuated by the aforementioned RPA. Specifically, in operation 499, the extension 306 accesses a create-order service executing on the backend platform 308 the information required to create the order record. According to some embodiments, the dataset includes: (1) the customer object stored by the extension in operation 436 (
Next, in operation 4990, the extension 306 posts a message to a messaging queue 702 of an RPA system executing on the backend computing platform (depicted in
In the wake of operation 4990, operational control is passed to operation 4992, in which the extension 306 constructs and presents the confirmation screen, as depicted in
According to some embodiments, the user conducts the purchase of the product himself or herself, instead of the purchase being conducted by the transaction system 300. For example, to effect payment, the customer may use a payment mechanism that draws upon funds of the transaction company (e.g., a lease-to-own company) or creates a debt for which the transaction company is responsible. Pursuant to these sorts of embodiments, the user completes the various data input fields on the various shopping cart pages and therefore may be free to arrange for delivery of the products to an address of his or her choosing, but the underlying products or services that are the subject of the alternative transaction (e.g., lease-to-own transaction) are paid for by the transaction company, and the transaction company ordinarily initially takes title to such products or services. These embodiments may also be advantageous for other reasons, discussed below. Such other embodiments wherein the customer is given autonomy over the data entered into the various shopping cart pages are discussed in detail, below.
Discussion now turns to operation of the validation service 316 (depicted in
In operation 602, the validation service of
On the other hand, if the SKU is not on the aforementioned whitelist, it may be the case that the whitelist is not exhaustive, for one reason or another (example: perhaps the e-retailer recently altered its product offering to include new products, which have not been evaluated for inclusion on the whitelist). To address the issue of potential incompleteness of the whitelist, control is passed to operation 606, wherein the dataset 600 is examined to determine whether it includes category data. If so, operational flow is passed to operation 608. In operation 608, the category information pertaining to a particular product is compared to a whitelist of categories uniquely created for each particular e-commerce website with which the extension may interoperated with. Thus, assuming, for example, that the dataset 600 revealed that the e-retailer was Best Buy, and assuming that the category information was category1=“Audio”, category2=“Home Audio”, category3=“Speakers”, then in operation 608, the whitelist pertaining to Best Buy is examined to see whether products categorized under the trio of “Audio”, “Home Audio”, “Speakers” are eligible (i.e., is there a record in the category whitelist corresponding to Best Buy containing “Audio” in a category1 field, “Home Audio” in a category2 field, and “Speakers” in a cagegory3 field?). If so, then the dataset is examined to determine the price of the product, and it is compared to a threshold (example: $300) (operation 610). If both (1) the product categories are whitelisted, and (2) the price of the product exceeds the aforementioned threshold (see “AND” gates 612 and 614), then the product is approved as eligible (operation 616). Thereafter, if a particular product was declared eligible on the basis of its category information, the aforementioned SKU whitelist for the relevant e-retailer is updated to include the SKU contained in the dataset 600 (operation 618). If, on the other hand, either test fails, then the product is declared ineligible.
In the event that the dataset 606 does not include category data, then the product name or description is examined instead of category data (operation 620). In operation 620, the product name or description is compared against a blacklist of keywords or phrases uniquely created for each e-commerce website with which the extension may interoperate (i.e., one blacklist for each such site), and it is required that the product name or description contain no such blacklisted keyword or phrase. Additionally, the product name or description is compared against a whitelist of keywords or phrases uniquely created for each e-commerce website with which the extension may interoperate (i.e., one keyword whitelist for each such e-commerce website), and it is required that the product name or description contain at least one whitelisted keyword or phrase. If both conditions are met, and if the price of the product exceeds the aforementioned threshold (see “AND” gates 622 and 624), then the product is approved as eligible (operation 626). As was the case in the wake of operation 616, in the wake of operation 626, if a particular product was declared eligible on the basis of its keyword information, the aforementioned SKU whitelist for the relevant e-retailer is updated to include the SKU contained in the dataset 600 (operation 618).
Discussion now turns to an embodiment of the aforementioned RPA process for purchasing the eligible goods from the e-commerce website in the wake of having completed the sought-after transaction.
Initially, the bot responds to the acquisition of a new record from the database 706 by examining the record to determine from which particular e-commerce website the products within the record are to be purchased. The bot 708 launches a (headless, according to some embodiments) instance of a web browser, navigates to the particular e-commerce site from which the products that are the subject of the record are to be bought, and logs into a user account pre-established in the name of the transaction company (lease-to-own company, in the context of the present example) on the aforementioned e-commerce site (operation 710).
In the wake of operation 710, the bot performs a loop defined by loop limit indicators 712 and 728 for each of the products referenced in the record. In operation 714, the bot 708 determines whether the product to be purchased should be accessed by use of a URL directly referencing a given product's product detail page, or whether a search function native to the e-commerce site should be used. In the event that a URL is to be used to access the product detail page corresponding to the particular product referenced by the loop limit indicator 712, the bot 708 navigates to the product detail page by entering the aforementioned URL into the URL bar of the web browser (operation 716), and then adds the product to the cart by clicking an “Add to Cart” button located on the product detail page (operation 726). Thereafter, the next product referenced in the record is operated upon (see loop limit indicator 728), if such next product exists. On the other hand, if in the course of operation 714 it is determined that the search function native to the e-commerce website should be used to navigate to the product description page, the operational flow is passed to operation 718.
In operation 718, the aforementioned search function is employed using a unit of data extracted from the aforementioned record. For example, the bot 708 may enter the SKU of the product to be purchased into the search function of the e-commerce website. Alternatively, the bot 708 may enter the product name into the search function, and any other unit of data within the record that will cause the search function to uniquely present the product description page corresponding to the product. After having used the employed function in operation 718, the bot 708 examines the page returned by the function to determine whether it presents more than a single product (for example, a product description page may, in some instances, present multiple products, such as different colors of the same sofa—all of which are associated with the same product name, SKU, and so on) (operation 720). If the product description page presents more than one product, the bot 708 is presented with an ambiguous scenario, and control is therefor passed to operation 722, wherein the bot 708 examines the aforementioned record to determine if there is another unit of data in the record as yet unused as a search term in operation 718 (operation 722). If so, the search process of operation 718 is repeated. If not, then the bot 708 declares an exception (operation 724), which is recorded in the aforementioned database 706, in order to indicate: (1) that the order was not placed robotically; and (2) the particular reason that the bot 708 did not place the order. According to some embodiments, personnel of the transaction company (in the context of this example, a lease-to-own company) then handle the process of acquiring the product from the website manually. Returning to the topic of operation 720, if in the course of that operation it is determined that the product description page contains only a single product, then the scenario does not present the bot 708 with ambiguity, and the bot 708 adds the product to the cart (operation 726) and proceeds on to the next product (see loop limit indicator 728). Assuming that there exists no next product, then operational flow is passed to operation 730 (see
In operation 730, the bot 708 enters the cart and initiates the checkout process. In response, the e-commerce website presents a summary screen that details the particular items in the cart and the total cost of the check process, including tax (i.e., the aggregate cost of each product, including tax), so that the user—in this case, the bot 708—can review the information to ensure it is correct. The bot 708 examines the information on the screen to ensure that it does not violate any business rules (operation 732). For example, if the total cost, including tax, is greater than that which was presented to the user during the transaction process (such as via the “Total Cost of Items” element on screen depicted in
According to some embodiments, a unique email address is created to correspond to each e-retailer with which the extension is designed to interoperate with. Thus, the user account created on behalf of the transaction company at e-commerce website #1 identifies email address #1 as the appropriate contact email address, while the user account created on behalf of the transaction company at e-commerce website #2 identifies email address #2 as the appropriate contact email address, and so on. Therefore, at any such given email address, all of the inbound email originates from a single particular e-retailer, and therefore conforms to a single, known, structure at any given point in time. The process of
The process begins by observing a given email inbox (operation 800) and determining whether a new email has been delivered thereto (operation 802). In response to a new email having been received, the particular variety of email is determined (operation 804). If the email is of certain varieties, the relevant data from the email will be parsed from it and stored in a database. For example, if the email is if a variety indicating that a given retailer has shipped the ordered product, the information pertaining to the shipment (order number, delivery address, shipping date, anticipated delivery date, tracking number, carrier, and so on) is parsed from the email and stored as a record in the data base (operation 806). As another example, if the email is if a variety indicating that a given order has been delivered, the information pertaining to the delivery (date, order number, carrier, tracking number, and so on) is parsed from the email and stored as a record in the data base (operation 808).
Another process observes the database (operation 810) and awaits the creation of a new record therein (operation 812). In response to a new record having been created, the proper recipient of the email is determined (example: by using the order number to trace the order to a given user), and the information from the record is sent as a message to an email delivery engine (operation 814). The engine uses the information to populate a normalized email body corresponding to each type of email intended to be forwarded to users (example: shipping emails and delivery emails). According to some embodiments, the aforementioned order number assigned to a given order by an e-retailer is not included in the information set used to populate such email bodies, so that the users receiving such emails possess neither a receipt, nor sufficient information to complete a return process with an e-retailer. Such embodiments may be appropriate for lease-to-own companies, for example, wherein a return of a leased product by a user to the e-retailer (versus a return to the lease-to-own company) is antithetical to the underlying transaction. According to other embodiments, the aforementioned order number assigned to a given order by an e-retailer is, in fact, included in the information set used to populate such email bodies.
Previously, it was mentioned that according to certain embodiments, the customer is permitted freedom to autonomously complete the various pages of the e-commerce site's digital shopping cart. One previously mentioned advantage to such embodiments is that the customer is free to designate a delivery address or method of his or her choosing method (example: arrange for a pick up at a retailer location, arrange for overnight delivery or standard delivery, and so on). Another advantage arises from the possibility that, pursuant to previous embodiments, the various goods and services that are paid for by the transaction system on behalf of the customer (such as via the previously described RPA scheme) may be paid for using the transaction card number that does not vary significantly from payment to payment (example: all such payments may be conducted using a single payment card number, or may be conducted using a payment card number selected from a relatively small fleet of cards). Moreover, such payment operations may be conducted via communication sessions with an IP address that does not vary significantly from payment to payment (example: all such payments may be conducted via communication session with an IP address corresponding to the computing facility at which the RPA system is operating, or from an IP address determined by an IP rotation scheme employing a relatively unnumerous quantity of IP addresses in comparison to the quantity of payment transactions to be conducted). Still further, such payment transactions may be conducted by a same user account of the e-commerce site that does not vary significantly from payment to payment (example: all such payments may be conducted by a single user account held by the transaction company, or by a relatively unnumerous pool of such accounts in comparison to the quantity of payment transactions to be conducted). Under such circumstances, if on a given day a quantity of one-thousand products were to be transacted to various customers by the transaction system from a given e-commerce site with which the transaction system interoperated, then it could be the case that from the vantage of the operator of the e-commerce site, during the course of the aforementioned given day, a singular user account on the e-commerce site, connected thereto from a singular IP address, paid for one-thousand products using the same transaction card, but arranged for those products to be delivered to various (perhaps geographically diverse) addresses. Such a scenario could present the appearance of fraud, despite the reality that no fraudulent activity was transpiring. In response, the operator of the e-commerce site, or the security systems overseeing the operation of the site, may suspend the operation of the aforementioned user account, or suspend inbound connections from the aforementioned IP address, or refuse payments from the aforementioned transaction card, or otherwise take steps to prevent payment transactions initiated by the transaction system from taking place. Such a response would be detrimental to the transaction system, as it would become unable to acquire the goods that were required for fulfillment of the underlying transactions with its customers. However, according to embodiments wherein each customer is permitted autonomy to complete such online transactions using a payment card with a card number corresponding uniquely to each such customer or each such payment transaction, then each payment transaction will be conducted by a unique user account (corresponding to the particular customer conducting each such payment), from a unique IP address (corresponding to the particular IP address from which each such customer is connected to the e-commerce site), using a unique transaction card number (corresponding to the particular customer conducting each such payment, or corresponding to the particular payment transaction being conducted). This outcome would present a normal outward appearance, and would not raise the prospect of the operator of the e-commerce site, or the security system overseeing its operation, interfering with the payment transactions intended to fulfill the needs of the transaction system.
The operational flow of exemplary embodiments of such a system is depicted in
Turning to
During operation of the system of
In operation 904, the URL bar of the web browser 1000 is examined to determine whether it contains the URL corresponding to the entry point page of the digital shopping cart of the particular e-commerce web site 1002 currently interoperating with the extension 1004 (details pertaining to this inquiry were presented previously). If not, then operational control returns to operation 902, and the actions and navigational path of the user are monitored until such time as the user navigates to the entry point page of the shopping cart. Upon entering the shopping cart, control is passed to operation 906, whereupon the extension 1004 adds a user-input element, such as a button, to the entry point page of the digital shopping cart in order to permit the user to elect to acquire the goods and services in the shopping via the alternative transactional arrangement, if they are of a suitable nature. Addition of such a user-input element was discussed previously.
In the wake of having added the aforementioned user-input element to the shopping cart page, the extension 1004 awaits an event in which the user clicks such element (operation 908), and in response thereto, the extension 1004 passes control to operation 910 (otherwise, the user's progress through the shopping cart progresses according to the native design of the shopping cart, itself). In operation 910, the active shopping cart page is scraped for its item content. According to embodiments wherein the scraping activity of operation 902 is omitted, the informational content pertaining to each item presented on the entry point page of the shopping cart is used to construct a product object on a one-product-object-per-item basis, in a manner parallel to that described previously. Each product object is then added to the aforementioned product object array. These steps have been previously described in detail and for the sake of brevity are not elaborated upon here. According to embodiments in which the scraping activity of operation 902 is not omitted, then the product objects already in the product object array prior to performance of operation 910 are compared to the informational content developed by the scraping operation of the present operation 910. If any items identified during the present scraping operation 910 are absent from the product object array, then their information content is assembled into a product object and added to the array. If the product object array contains product objects that do not correspond to any item identified during the scraping action of operation 910, then any such product objects are removed from the array. Details pertaining to these operation (including the purposes thereof) have been described previously and are not repeated here. In the wake of operation 910, then, the product objects of the product array correspond to the items contained in the digital shopping cart.
Next, in operation 912, the extension 1004 communicates with the backend computing platform 1006, such as with a validation service hosted by the platform 1006, in order to determine what portion of the product objects within the array corresponds to items that are eligible as subjects of the sought-after alternative transaction arrangement. Details pertaining to this have been presented previously and are not reiterated here. In operation 914, it is determined whether the product object array contains any ineligible items. If so, then the extension 1004 presents a screen (in a lightbox, for example) atop the digital shopping cart, identifying the ineligible items and instructing the user to remove those items from the digital shopping cart (operation 916). The user closes the aforementioned window, and is returned to the shopping cart to either comply, and then re-initiate the alternative transaction arrangement via the user-input element added to the entry point page in operation 906, or to checkout using the native capabilities of the shopping cart (operation 908). On the other hand, if the product object array does not contain any ineligible products, then control is passed to operation 918.
Operation 918 is optional. In operation 918 a speedbump screen is presented. A speedbump screen is a screen that explains the nature of the alternative transaction in simple terms. The purpose of such a screen is to ensure that the user understands that he or she is embarking on a path to acquire the items in the digital shopping cart pursuant to an alternative transactional arrangement, rather than purchasing the items. Other means of ensuring consumer awareness of the nature of the alternative transactional arrangement are possible and will readily present themselves to the minds of those of ordinary skill in the art.
In the wake of the user dismissing the speedbump screen, the extension 1004 programmatically clicks the shopping cart's native “checkout” button, meaning that the user is presented with the various pages of the shopping cart in a manner determined by the native software instructions making up the digital shopping cart. The user interacts with the shopping cart pages as though he or she were conducting an ordinary payment transaction. As the user does this, the extension 1004 monitors the user's progress through the shopping cart (operation 922), and determines when the user has reached the particular page of the shopping cart at which payment information is to be entered (see operation 924). Such a determination may be made, for example, by monitoring the URL in the web browser's 1000 URL bar, and determining whether it matches the URL corresponding to the “payments” page. When it is determined that the user has reached the “payments” page of the shopping cart, control is passed to operation 926.
Operation 926 is parallel to operation 910: the item information presented on the “payments” page of the shopping cart is scraped, and used to adjust the product object array, as described previously. The purpose of this operation 926 is account for any items, including service items or companion items, that may have been added to the shopping cart in the intervening navigational journey between the entry point page (when the product object array was last adjusted so as to correspond with the items in the shopping cart) and the “payments” page. Operation 926 may be necessary, for example, because the shopping cart may be structured to permit the user to add service items or companion items to the shopping cart prior to payment. (Example: in the event that a user initially had added a flatscreen television to his shopping cart prior to initiating the checkout procedure, then in between his or her journey from the entry point page to the “payments” page, the user may be offered the opportunity to add service items or companion items, such as installation services or an extended warranty to protect the television—such items would not be reflected in the product object array as it was constituted in the wake of operation 910, and, furthermore, such items may not be the proper subjects of the sought-after alternative transactional arrangement, necessitating the ensuing operations 928, 930, 932 and 934.)
In the wake of adjusting the product object array in operation 926, each product object therein is inspected to determine whether it corresponds to a product or service that is the proper subject of the sought-after alternative transactional arrangement (operation 928). Operation 928 is performed by the extension 1004 via communication with the backend platform 1006, in a manner parallel to that which was discussed previously. Next, in operation 930, it is determined whether the product object array contains any product objects corresponding to products or services that are ineligible for the sought-after alternative transaction arrangement. If so, a screen is presented (for example, in a lightbox) identifying such ineligible items, and directing the user to remove such items from the shopping cart before proceeding, as a condition of creation of the alternative transactional arrangement (operation 932). After dismissal of the aforementioned screen by the user, the user is once again presented with the “payments” screen. The user may elect to ignore the instructions to remove the items, and may simply pay for the items by filling in the “payments” screen with information corresponding to a payment card belonging to him or her, and the result is that the remainder of the digital shopping cart experience will unfold as natively determined by the software instructions natively making up the shopping cart, thereby resulting in a purchase of the items by the user, funded by the aforementioned transaction card. On the other hand, the user may elect to remove such ineligible items, and thereafter may re-initiate pursuit of the alternative transactional arrangement by clicking a user-input element placed on the “payments” screen by the extension 1004. Such user-input element may be structured as a “bug,” which is a small, non-intrusive element, typically located along the periphery of a webpage. If the extension 1004 detects the occurrence of an event whereby the user has clicked the aforementioned user-input element (operation 934), control is returned to operation 930, whereupon the product object array is reinspected for the presence of ineligible product objects.
If no such ineligible product objects are present in the array, then control is passed to operation 936. In operation 936, a lightbox is presented atop the “payments” screen, thereby preventing the user from interacting with the “payments” screen while the lightbox is presented. Within the lightbox, the extension 1004 presents a succession of screens to guide the user through the process of: (1) logging in; (2) reviewing his or her open-to-transact line (discussed previously); (3) reviewing a summary of the proposed terms of the alternative transactional arrangement concerning the goods or services in the product object array; (4) reviewing and executing a contract that effects a contractual arrangement between the user and the alternative transaction company, so as to create the aforementioned transactional arrangement concerning the goods or services in the product object array; and (5) initiating an initial payment to the alternative transaction company, pursuant to the aforementioned contract. Examples of operational flows to support such actions have been previously presented herein, and for the sake of brevity are not repeated here.
In operations 938 and 940, the extension polls a user progress service hosted by the backend platform 1006, awaiting a response from the platform 1006 that indicates that the initial payment conducted by the user during operation 936 has, in fact, been completed. Details pertaining to exemplary interactions between the extension 1004 and backend platform 1006 so as to provide the extension 1004 with updates concerning the occurrence or non-occurrence of certain events related to the alternative transaction that were conducted on other platforms (such as on the payment processing platform 1016, which, in this case, participated in the transaction by processing the aforementioned initial payment) have been described previously and are not repeated here. Upon receiving a response from the backend platform 1006 indicating that the initial payment was, in fact, completed, then it would be the case that: (1) the user selected one or more items from the e-commerce website 1002 to acquire via an alternative transactional arrangement; (2) each of the items were validated, thereby confirming that they are the proper subject of such alternative transactional arrangement; (3) the user and transaction company entered into a contract effecting such alternative transactional arrangement, with the aforementioned items being the subject of such contract; and (4) an initial user payment required by such contract was confirmed to have been completed. At this stage, the particular actions that are the prerequisites of initiating a process to provide the user with means by which he or she may complete the “payments” page have been completed. Thus, the extension 1004 may proceed with actions that will result in the provision of a payment card number to the user, to permit the user to make payment for the items on behalf of the transaction company (the transaction company will pay for the items, take title to the items, and make the items available to the user pursuant to the alternative transactional arrangement—the items will be delivered to the user by the e-retailer according to the delivery option selected by the user during the course of his navigation through the digital shopping cart).
To initiate the process of providing the customer with a payment card number that he or she may use in connection with obtaining the items that are the subject of the alternative transactional arrangement, the extension 1004 communicates with the backend platform 1006, sending it a contract approval data set (operation 942). A contract approval data set is a set of data that indicates: (1) that a particular customer entered into a contract on a particular time and date; (2) concerning items from a particular e-retailer; (3) wherein such items have particular prices indicated in the contract approval data set. According to some embodiments, the backend computing platform 1006 hosts a contract status tracking service 1010, with which the extension 1004 interacts with in order to communicate the fact that a contract has been entered into, and to acquire the capacity to provide the user with the aforementioned payment card number.
In response to receiving the contract approval data set, the backend platform 1006 performs the operations depicted in
Next, in operation 1104, the contract status tracking service 1010 sends a message to an authorization interface service 1012 to instruct it to initiate the creation of a payment card for the user, and to fund an account associated with the aforementioned payment card. Prior to further discussion of operation 1104, some background information is required.
According to some embodiments, the aforementioned payment card is issued by a financial institution (example: a bank) associated with the issuer processor that operates the issuer processor platform 1018. Each payment card may be associated with a particular user and bear (or be associated with) a unique card number associated with the aforementioned user. Each such card may be titled in the name of the alternative transaction company, with the aforementioned particular user being specified as an authorized user of the particular payment card that has the card number associated with him or her. Thus, a user may use the particular aforementioned payment card (as an authorized user), with the funds drawn upon for effecting payment from such card being sourced from the transaction company. For example, each such card may be a stored-value card, meaning that each such card is associated with a financial account—a stored value account—that is to contain the necessary funds to properly source money for the particular payment transaction initiated by the user. The transaction company may store money that it has designated for funding of such stored value accounts in a master account maintained at the financial institution that issues the stored value cards and maintains their corresponding stored value accounts. Each time the issuer processor platform 1018 receives an instruction to create a payment card for a particular user (for use by the user to conduct a particular payment transaction of a particular aggregate amount), the aforementioned financial institution (via the issuer processor platform 1018) may, in near real-time, open a new stored value account for that particular user, and fund it with money in an amount equal to the aforementioned particular aggregate amount (or in an amount slightly greater than the aforementioned aggregate amount, to allow for any imperfections in correctly specifying the aggregate payment amount). Thus, each payment card is created for a user and funded in a just-in-time fashion, in response to receipt of a command to do so by the issuer processor platform 1018. Each such card may be virtual, meaning that it exists as an account number in a data store maintained and operated by the issuer processor via its platform 1018, but is not associated with a physical card. Alternatively, each such payment card may indeed be embodied as a physical card that is delivered to the user in a follow-up operation performed at a later time. Each such card may be usable a single time (a “one-time card”) or may be usable over the course of a plurality of transactions until such time as it expires or is canceled or otherwise suspended by the issuer. For the sake of grounding the present discussion in a concrete example, the cards herein are assumed to be virtual one-time cards. The invention is not limited to virtual one-time cards, and the principles and teachings disclosed herein will be understood by those of skill in the art to apply to physical cards, as well as reusable cards.
With this background in place, discussion now returns to operation 1104. The authorization interface service 1012 is a unit of software operating on the backend platform 1006 that is responsible for interacting with the issuer processor platform 1018, in order to: (1) command it to create a payment card for use in connection with a payment transaction required to acquire an item for a customer pursuant to an alternative transactional arrangement concerning one or more items desired by the user from an e-commerce site 1002; and (2) to handle authorization requests directed to such card as they are routed inbound from a payment network on which such cards are operable (example: Mastercard, Visa, etc.). The authorization interface service 1012 therefore responds to receipt of the message described with reference to operation 1104 by sending a command to a card creation service 1020 operating on the issuer processor platform 1018, instructing it to issue a one-time virtual card to a particular user, and to fund a payment to be conducted with the just-created card in a particular aggregate amount (operation 1106). The issuer processor platform 1018 responds by opening a stored-value account for the designated user, and transferring money from the aforementioned master account into the stored value account, in an amount equal to (or greater than by a designated tolerance—example: 2% or 5%, etc.) such aggregate amount.
In response to sending a command to the card creation service 1020 in operation 1106, the authorization interface service 1012 receives a reply therefrom with an access token (operation 1108). An access token is a unit of data that is usable by software within the browser extension 1004 to present an iFrame containing the card number associated with the one-time virtual card just created for the user, so that the user may learn of the card number that has been just issued to him or her and thereby utilize it in connection with completing the “payment” screen of the digital shopping cart. The iFrame is discussed further, below. In response to receiving the access token, the authorization interface service 1012 communicates it to the contract tracking service 1010, which, in turn, makes the access token available to the browser extension 1004 at a secure web-accessible endpoint (i.e, an API) exposed to a network such as the Internet via the backend computing platform 1006.
Discussion now returns from its focus on the response of the backend platform 1006 to having received the contract approval data set from the extension 1004 in connection with operation 942 of
When the access token is made available, the polling process is exited, and control is passed to operation 948. In operation 948, the access token is used as an input or argument to a function or method call in order to present a screen that presents the card number that was issued to the user in response to the extension having supplied the backend platform 1006 with the contract approval data set in operation 942. For example, according to some embodiments, the extension 1004 may include a software development kit (SDK) published by the issuer processor that operates the issuer processor platform 1018. The SDK may be structured to accept the access token as an input or argument, and, upon its invocation, use the access token to securely communicate with the issuer processor platform 1018, retrieve data constituting a screen arranged to present the aforementioned card number, and thereafter to present an iFrame containing such screen in order to inform the user of the card number. The lightbox that was introduced in operation 936 is closed in connection with the presentation of the screen containing the card number, so that the user may interact with the “payments” screen, i.e., so that the user may fill in its various fields, including using the card number to fill in the particular field asking the user to supply a payment card number for use in connection with the payment transaction. An example of an iFrame 1200 presenting such card number data 1202, for the user to enter into a payment card field 1204 of a “payments” page 1206 is depicted in
The user responds to presentation of the screen 1200 bearing the card number 1202 by copying the card number 1202 into the payment card field 1204 (operation 950). In the wake of completely filling out the “payments” screen 1206 and clicking a button 1208 provided on the page 1206 (entitled “place my order”) to indicate that the user is ready to initiate payment, the digital shopping cart interacts with a payment processor, sending it the required payment information (payment card number, payment amount, etc.), which, in turn, communicates such information to the payment network on which the payment card is operable. The payment network responds to this by directing an authorization request to the issuer processor platform 1018, which is operating on behalf of the issuer of the payment card. An authorization request is a data exchange in which the payment processor is asked to authorize or decline the payment transaction on the basis of the information supplied to the payment processor by the shopping cart (example: the retailer ID code that identifies the retailer at which the payment transaction is being conducted, the payment card number, the payment amount, the date and time of the transaction, and so on). In the context of the exemplary embodiment of
In the wake of the payment being authorized, the e-commerce website 1002 presents the user with an order confirmation screen that confirms that the payment for the product was received, and the customer's items are being shipped. The presentation of such screen is detected by the extension in operation 952 (
Previously, in connection with operation 1116, the authorization interface service 1012 was described as registering for a callback from the issuer processor platform 1018 in the event that the payment transaction was either successfully settled, or in the event that such settlement failed.
In the event that the settlement operation failed, then control is passed to operation 1122, and the authorization interface service 1012 sends a message to the contract tracking service 1010 indicating that the settlement operation attempted in connection with a particular payment operation or contract identifier failed. In response, the contract tracking service 1010 initiates cancellation of the corresponding contract with the user by setting the status of contract object associated with the contract identifier or payment operation or identifier to a status indicating cancellation (example: a status of “canceled”) (operation 1124).
On the other hand, if it is the case that the settlement operation succeeded, then control is passed to operation 1126, and the authorization interface service 1012 sends a message to the contract tracking service 1010 indicating that the settlement operation attempted in connection with a particular contract identifier or payment operation or identifier succeeded. In response, the contract tracking service 1010 updates the status the contract object associated with the contract identifier or payment operation or identifier contained in the payload of the callback to a status indicating successful settlement (example: a status of “settled”) (operation 1128). Thereafter, the contract tracking service 1010 uploads the contract to a contract management system 1008 executing on the backend platform 1006 (operation 1130). The contract management system 1008 is used by systems and personnel of the transaction company to manage receipt of customer payments in connection with contracts stored therein, track late payments, initiate response activities to such late payments, and perform other such management activities related to tracking performance of the contract by the user. Finally, the authorization interface service 1012 registers with a payment refund webhook service 1026 executing on the issuer processor platform 1018, requesting that the service 1026 call back the authorization interface service 1012 in the event that the payment associated with the authorization request is refunded. Such a refund may occur in response to the user returning the item that was the subject of the alternative transactional arrangement. Recall: unlike the embodiments wherein the backend platform performed the payment operations and arranged for the items to be delivered to the customer, according to the present embodiments, the user does so, and is therefore furnished with the receipt for such item from the e-retailer (and other documentation pertaining to the payment transaction). According to the present embodiments, then, the user is therefore in the position to return the items to the e-retailer, whereas such return would not be possible pursuant to the previous embodiments because the user would not be able to demonstrate that he paid for the items, nor trace the payment of the items to a particular payment transaction that could be refunded.
In the event that the user returns an item that was the subject of an alternative transaction arrangement, thereby generating a refund of its related payment, or in the event that such payment was refunded for any other reason, the backend platform 1006 is called back by the issuer process platform 1018, and responds as depicted in
To perform the actions of the computer, laptop, tablet, smartphone, or portable device on which the web browser 104, 304 or 1000 executes, host the backend platform 108, 308 or 1006, the payment processor 312 or 1016, document cloud server 310, third party services 110, or issuer processor platform 1018, or execute any of the methods or schemes herein and/or embody any of the other previously mentioned computing devices, a computer or server system as illustrated in
The computer system 1300 is shown comprising hardware elements that can be electrically coupled via a bus 1305 (or may otherwise be in communication, as appropriate). The hardware elements may include one or more processors 1310, including without limitation one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like); one or more input devices 1315, which can include without limitation a mouse, a keyboard, touchscreen and/or the like; and one or more output devices 1320, which can include without limitation a display device, a printer and/or the like.
The computer system 1300 may further include (and/or be in communication with) one or more storage devices 1325, which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.
The computer system 1300 may also include a communications subsystem 1330, which can include without limitation a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device and/or chipset (such as a BLUETOOTH™ device, an 802.11 device, a WiFi device, a WiMax device, cellular communication facilities, etc.), and/or the like. The communications subsystem 1330 may permit data to be exchanged with a network (such as the network described below, to name one example), other computer systems, and/or any other devices described herein. In many embodiments, the computer system 1300 will further comprise a working memory 1335, which can include a RAM or ROM device, as described above.
The computer system 1300 also can comprise software elements, shown as being currently located within the working memory 1335, including an operating system 1340, device drivers, executable libraries, and/or other code, such as one or more application programs 1345, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method(s) discussed above might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.
A set of these instructions and/or code might be stored on a computer-readable storage medium, such as the storage device(s) 1325 described above. In some cases, the storage medium might be incorporated within a computer system, such as the system 1300. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc), and or provided in an installation package, such that the storage medium can be used to program, configure and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system 1300 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 1300 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code.
It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used, and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed.
As mentioned above, in one aspect, some embodiments may employ a computer system (such as the computer system 1300) to perform methods in accordance with various embodiments of the invention. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system 1300 in response to processor 1310 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 1340 and/or other code, such as an application program 1345) contained in the working memory 1335. Such instructions may be read into the working memory 1335 from another computer-readable medium, such as one or more of the storage device(s) 1325. Merely by way of example, execution of the sequences of instructions contained in the working memory 1335 might cause the processor or processors 1310 to perform one or more procedures of the methods described herein.
The terms “machine-readable medium” and “computer-readable medium,” as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In an embodiment implemented using the computer system 1300, various computer-readable media might be involved in providing instructions/code to the processor or processors 1310 for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals). In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical and/or magnetic disks, such as the storage device(s) 1325. Volatile media include, without limitation, dynamic memory, such as the working memory 1335. Transmission media include, without limitation, coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 1305, as well as the various components of the communication subsystem 1330 (and/or the media by which the communications subsystem 1330 provides communication with other devices). Hence, transmission media can also take the form of waves (including without limitation radio, acoustic and/or light waves, such as those generated during radio-wave and infrared data communications).
Common forms of physical and/or tangible computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read instructions and/or code.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor or processors 1310 for execution. Merely by way of example, the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer. A remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system 1300. These signals, which might be in the form of electromagnetic signals, acoustic signals, optical signals and/or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with various embodiments of the invention.
The communications subsystem 1330 (and/or components thereof) generally will receive the signals, and the bus 1305 then might carry the signals (and/or the data, instructions, etc. carried by the signals) to the working memory 1335, from which the processor(s) 1305 retrieves and executes the instructions. The instructions received by the working memory 1335 may optionally be stored on a storage device 1325 either before or after execution by the processor(s) 1310.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without departing from the true spirit and scope of the present invention, which is set forth in the following claims.
This application is a Continuation-in-Part of U.S. application Ser. No. 17/196,365, filed Mar. 9, 2021 which claims the benefit of U.S. Provisional Application No. 62/987,081, filed Mar. 9, 2020, titled “System and Method for Improved Execution of Multiparty Transaction Involving Electronic Funds Disbursement,” and U.S. Provisional Application No. 63/081,107, filed Sep. 21, 2020, and titled “System and Method for a Payment Card-Based Execution of a Multiparty Transaction Involving Electronic Funds Disbursement,” the disclosures of which are hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62987081 | Mar 2020 | US | |
| 63081107 | Sep 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17196365 | Mar 2021 | US |
| Child | 17365516 | US |
