Securebuy merchant information analytics decision engine

CROSS-REFERENCE TO RELATED APPLICATION

0001This application claims priority from U.S. Provisional Patent Application No. 61/873,506, filed on Sep. 4, 2013, the contents of which are incorporated herein by reference. This application claims priority from U.S. Provisional Patent Application No. 61/888,250, filed on Oct. 8, 2013, the contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

0002Facilitating the purchase of goods and services utilizing electronic means, such as but not limited to, enterprise shopping cart platforms, gateways, and processing entity technology, is a method used by many businesses worldwide. Such purchasing processes may be accomplished when the merchant presents their catalog of goods and services to the consumer, who in turn, chooses the desired product and proceeds to and completes the checkout process presented by the merchant's shopping cart or check-out process platform, thereby consummating and completing the shopping experience. While the consumer may have selected the product or service from a catalog, and subsequently completed the purchasing cycle, it may not necessarily have been the most suitable good or service for that particular individual. Under current systems and processes, the merchant has no means, method, or opportunity to efficiently and effectively review the proposed transaction and present the purchaser with better and potentially more suitable alternatives, prior to the completion of the checkout process.

0003Accordingly, it is desirable to provide a system whereby the merchant is provided with the opportunity to present and provide the consumer with an option to select and purchase a more suitable good or service, based upon analytical data gathered during and prior to completion of the checkout process.

SUMMARY OF THE INVENTION

0004In one aspect of the present invention, a method for transaction processing may comprise; requesting stored data from an Application Programming Interface (API), validating a request from the API, logging the request, querying to a database to retrieve data relevant to the request, interpreting the request, and generating output to a reporting API.

0005In another aspect of the present invention, a method for transaction processing may comprise; entering a checkout, entering payment information from a consumer, collecting device information from a merchant, sending the payment information along with the device information to a fraud scoring system, calculating a fraud score in a fraud decision engine, presenting the merchant with an authentication method, and generating an order review page.

0006In yet another aspect of the present invention, a method for transaction processing may comprise; sending a CNP authorization and authentication to a decision engine, sending data from an API to a business logic layer, validating the data and sending the data to an appropriate gateway specific component, sending an authorization request to a gateway, sending authorization results to the appropriate gateway specific component, and parsing the authorization results.

0007These and other aspects, objects, features and advantages of the present invention, are specifically set forth in, or will become apparent from, the following detailed description of an exemplary embodiment of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0008The above and other aspects of the present invention will become more apparent by the following detailed description of exemplary embodiments thereof with reference to the attached drawings, in which:

0009<figref idref="DRAWINGS">FIG. 1</figref> is a schematic block diagram of a system for processing electronic transactions over a network, according to an embodiment of the present invention;

0010<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart of an exemplary method of electronic processing of transactions, according to a further embodiment of the present invention;

0011<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart of an exemplary method of electronic processing of transactions, such as a digital receipt generation process, according to another embodiment of the present invention;

0012<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of an exemplary method of electronic processing of transactions, such as implementing a reporting API, according to another embodiment of the present invention; and

0013<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of an exemplary system, according to a still further embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

0014The following detailed description is of the best currently contemplated modes of carrying out the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims.

0015The present invention pertains to a manner of processing electronic transactions performed over a network, “online,” or via a number of electronic transaction processing tools that allow for retail or other transactions. The invention relates more particularly to the gathering of pertinent data utilizing processes that run in the background, processing the data, and providing the merchant's enterprise platform or other suitable purchase processing system with a means to present verified alternative purchasing opportunities to the purchaser.

0016In one embodiment, there is provided an Active Transaction Mode, in which the merchant presents their catalog of goods and/or services to the consumer (purchaser), who in turn, selects the desired product and proceeds to the associated checkout process presented by the merchant's enterprise platform or other suitable checkout system. This can be done through well known means via a website, application, or other electronic means. The consumer (purchaser) completes their part of the process by providing the appropriate identification/delivery information and presents their payment method, which is verified through a series of background analytical processes intended to ensure that the person is whom they claim to be and that the payment method is valid (i.e., authentication and verification). According to the present invention, the transaction can then proceed to completion after successful checking, or, the consumer may be presented with purchase alternatives, depending upon input provided by a SecureBuy Analytics Decision Engine prior to completion of the checkout process.

0017The SecureBuy Analytics Decision Engine performs the above mentioned analytical processes by accessing available consumer databases and sources such as, but not limited to, consumer credit bureaus, cardholder analytics, social media, and purchase history repositories. Said analytical data and metrics are then parsed and processed through a dynamic network of decision matrices that match up the pending purchase with the consumer's purchase history and credit worthiness along with other merchant selectable criteria.

0018Upon achieving a high degree of confidence that the consumer is a match, an output score, or other appropriate form of data string from the SecureBuy Analytics Decision Engine Matrices, is then transmitted to the merchant's enterprise platform, or other suitable purchasing system, in near real-time, regarding the potential opportunity to provide the consumer with an option to select and purchase a better, more suitable product, including associated products and/or accessories prior to completing the purchasing or checkout process. For example, if a consumer is determined to have high credit and purchase history suggests that the consumer prefers a particular quality of good or service, one or more alternative items (such as better quality items) from the merchant's electronic inventory can be identified that may be presented to the consumer prior to completion of the transaction.

0019The owner of the present invention offers a Real-Time Next Generation Passive Authentication, which may be a cloud-based application deployed at the payments level. This risk-based passive authentication platform provides an effective first perimeter of defense for transaction security from cybercrime. The next generation passive authentication engine executes immediately upon entry of the shopping cart and analyzes myriad attributes or a combination in the trillions to detect any anomalies or red flags.

0020In real-time or near real-time, the authentication engine is configured to query shared data with, for example, merchants, end-user computers and mobile devices. It can be configured to review email and device black-lists and search for hidden proxies, scripted attacks and cookie and browser manipulation. It can analyze and evaluate the actual device, type of operating system and browser in use, all within milliseconds. The risk-based engine can audit how many times the card has been used in the last 24 hours, last 3 days, and last week. From this analysis, it can be determined where the person is located, what device and/or browser they are using, and whether or not fraud has previously been perpetrated. The scoring engine provides a score and depending on the rules set, can determine whether to invoke active authentication. The information may also be used to determine whether and to what extent additional products or services can be presented.

0021A data push of additional products or services, as determined by merchant selectable criteria, would then append the checkout process prior to completion of the transaction and checkout process.

0022In another representative embodiment, Post Transaction Mode, the merchant electronically presents their catalog of goods and/or services to the consumer (purchaser), who in turn, chooses the desired product and proceeds to the associated checkout process presented by the merchant's enterprise platform or other suitable checkout system.

0023The consumer (purchaser) completes their part of the process by providing the appropriate identification/delivery information and presents their payment method, which is verified through a series of background analytical processes intended to ensure that the person is whom they claim to be and that the payment method is valid. The transaction then proceeds from there to completion; or the consumer may be presented with purchase alternatives, depending upon input provided by the SecureBuy Analytics Decision Engine, prior to completion of the checkout process.

0024The SecureBuy Analytics Decision Engine performs the above mentioned analytical processes by accessing available consumer databases and sources such as, but not limited to, consumer credit bureaus, cardholder analytics, social media, and purchase history repositories. Said analytical data and metrics are then parsed and processed through a dynamic network of decision matrices that match up the pending purchase data with the consumer's purchase history and credit worthiness, along with other merchant selectable criteria.

0025The purchase transaction is completed and an automatic follow-up marketing campaign via email or other appropriate means may be initiated. A data push of additional products or services, as determined by merchant selectable criteria, would then be inserted into, append or accompany said follow-up marketing and sales communications and/or literature.

0026For example, co-owned U.S. Pat. No. 7,916,906, the entire contents of which are incorporated herein by reference, describes a signature capture system that captures a biometric signature during electronic transaction processing. The present invention could be implemented with this system by introducing processing during the verification process but prior to completion of the transaction.

0027Co-owned U.S. patent application Ser. No. 13/605,095, filed Sep. 6, 2012, the entire contents of which are incorporated herein by reference, describes an electronic transaction system that includes authentication and verification. The present invention could be implemented with this system by introducing processing during the verification process but prior to completion of the transaction.

0028<figref idref="DRAWINGS">FIG. 1</figref> is a high-level block diagram of an exemplary system <b>100</b> that may implement the present invention. A client interface <b>104</b> may communicate with a network <b>102</b>, which may be any type of wired or wireless network. The invention may further comprise an analytics decision engine <b>106</b> in communication with the network <b>102</b> and a database <b>110</b>. A fraud data server <b>108</b> may communicate with the analysis decision engine <b>106</b>. A merchant system <b>112</b> useful for implementation in the system <b>100</b> may be in communication with the network <b>102</b> and a database <b>114</b>. Bank services <b>116</b>, such as card issuers, may be in communication with the network <b>102</b> and a database <b>118</b>. Credit bureaus <b>120</b>, connected to at least one database <b>122</b>, may communicate with the network <b>102</b>. It should be readily apparent that the present invention may be applied to existing online or other electronic commerce applications.

0029One purpose of this system is to facilitate the purchase of good and services. The feature leverages the data in the consortium database <b>130</b> populated by the fraud scoring <b>108</b> system as well as other data sources such as, but not limited to, credit bureaus <b>120</b>, social media, and FICO score.

0030This process can be used during the checkout process to present the consumer with alternate and/or additional products. It can also be used post checkout or after cart abandonment using communication methods such as, but not limited to, email, SMS, MMS, and social media.

0031<figref idref="DRAWINGS">FIG. 2</figref> is a high-level order flow of an exemplary process that may implement a fraudulent authorization process of the present invention. <figref idref="DRAWINGS">FIG. 2</figref> shows the internal flow of the fraud score API. Merchants may use the flow to determine the risk level for a commerce transaction by means of a fraud score. The service may include a universal device ID generator that can be used with other third party device profiling service providers or stand alone. Some device profiling service providers may provide a fraud score for factoring into an overall fraud score. Also, lost/stolen card list services may be used by card issuers and card associations or other service providers to augment a fraud score. The method <b>200</b> may comprise various steps. For example, step <b>212</b> may present a decision interpreting the validity of an original request (step <b>210</b>). Steps <b>214</b> and <b>216</b> may represent an action logging the result of the decision (<b>212</b>). Step <b>218</b> may represent an action for generating a universally unique ID for the device data received from the request to the Application Programming Interface (API) identified at step <b>210</b>. Step <b>220</b> may represent an action attempting to generate a fraud score resulting from interpretation of the data received from the API request identified at step <b>210</b>. Decision <b>222</b> may represent an interpretation of the data received from the API request (identified at step <b>210</b>) attempting to identify a third party Device Profile Service Provider (DPSP) as having provided the device data received in the API request. Step <b>224</b> may represent an action to factor the device data provided by a third party DPSP into the score result generated at step <b>218</b>. Step <b>226</b> may represent an action for updating a recorded transaction with score results derived at steps <b>218</b> and <b>224</b>. Responses <b>228</b> and <b>230</b> may represent appropriate responses to the API request identified at step <b>210</b>.

0032<figref idref="DRAWINGS">FIG. 3</figref> is a high-level order flow of an exemplary process that may implement the digital receipt generation process of the present invention. <figref idref="DRAWINGS">FIG. 3</figref> outlines a sales receipt flow. Merchants may use the flow to generate a sales receipt for a transaction. A sale receipt input may include optional results (such as in HTML) from a SecureBuy Screen Scrape solution. An API may be used in non-commerce scenarios, such as to capture a user's screen at the time of form submission. Including a screen scrape solution may enhance tracking of a web user's experience on a web site. With some enhancements one may generate a video of a user's exact experience on the web site, from what the user say and how the user moved a mouse to how the user scrolled on each page. Such a situation would give a web site an enhanced view into the user's experience and behavior, especially for ascertaining shopping behavior. The method <b>300</b> may comprise various steps. For example, step <b>310</b> may comprise calling SB receipt API, such as part of a checkout process. A step <b>320</b> may comprise a capture of consumer data while a step <b>312</b> may comprise authentication/verification, while results may be logged in steps <b>314</b> and <b>316</b>. An option <b>318</b> may comprise deciding whether a request to add a new data capture or retrieve an existing capture. Step <b>322</b> may comprise retrieving existing consumer data. Step <b>324</b> may comprise a decision following the identification of existing consumer data. Steps <b>326</b>, <b>328</b>, <b>330</b>, and <b>332</b> may comprise presenting the caller with a message appropriate to the request. Step <b>334</b> may comprise compiling a sale receipt.

0033<figref idref="DRAWINGS">FIG. 4</figref> is a high-level order flow of an exemplary process that may implement a reporting API for the present invention. The method <b>400</b> may comprise various steps. For example, step <b>410</b> may comprise a request to an Application Programming Interface (API) for stored data. A step <b>412</b> may represent a decision being made for a valid request to the API. Steps <b>414</b> and <b>416</b> may represent an action for logging the request. Step <b>418</b> may represent a query to a database retrieving data relevant to the initial request (<b>410</b>). Decision <b>420</b> may represent an interpretation of the query from step <b>418</b>. Outputs <b>422</b>, <b>424</b>, and <b>426</b> may represent appropriate responses to the original API request (<b>410</b>) after processing the data from original request (<b>410</b>). Step <b>430</b> may comprise communication with a transaction database. Step <b>432</b> may comprise communication with a reporting API.

0034<figref idref="DRAWINGS">FIG. 5</figref> is a high-level block diagram of an exemplary system <b>500</b> that may implement the present invention. A consumer may enter the system <b>500</b> during a shopping experience on a merchant's web site. A consumer may enter checkout at step <b>510</b>. During the shopping experience, data about a consumer's device and browser may be collected at step <b>530</b>. The consumer may enter payment information at step <b>512</b>. Payment information along with device data from step <b>530</b> may be sent to a fraud scoring system in step <b>550</b>. The path of data flow may comprise calling SB fraud API in step <b>531</b>. The fraud scoring system <b>550</b> may work in conjunction with a Universal Device Profiling and Fingerprinting service in step <b>551</b> to accurately identify the consumer and generate a fraud score while reducing false positives. The fraud score may be consummated by a Fraud Decision Engine in step <b>552</b> to determine a step and/or an action. Depending on the fraud score and the merchant's configurations in step <b>532</b> the Fraud Decision Engine may present the merchant and/or consumer with an active authentication method in step <b>590</b> for the consumer to prove they are who they are claiming to be. During the checkout process the merchant may present the consumer with terms and conditions. An order may be reviewed in step <b>513</b>, where the system <b>500</b> may generate an order review page. The terms and conditions may be requested in step <b>514</b> from a service in step <b>553</b>, such as wherein the system <b>500</b> is used to store, maintain, and record changes to the merchant's terms and conditions. Possession of the terms and conditions may be determined in step <b>515</b>. A decision whether to place an order may occur in step <b>517</b>. Step <b>519</b> may comprise verifying whether a signature is valid. Step <b>521</b> may comprise deciding whether a sign pad is present. The system <b>500</b> may support the use of signature capture in step <b>516</b> and step <b>554</b> as a means to provide proof of acceptance of the order and/or terms and conditions. During the checkout process the merchant may request payment authorization in step <b>534</b> from a gateway <b>592</b> or other payment system. A decision of approval may occur in step <b>594</b>, optionally after calling SB sales receipt API in step <b>536</b>. The system may support a sales receipt in step <b>555</b> with a service leveraging the screen scrape functionality in step <b>518</b> to generate a sales receipt. The receipt process may comprise step <b>536</b> of calling SB sales receipt API in step <b>536</b>. The merchant may present a page in step <b>520</b> to the consumer to confirm that the order has been received and is being processed (such as, an “order receipt page” or “thank you page”).

0035Thus, a number of preferred embodiments have been fully described above with reference to the drawing figures. Although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions could be made to the described embodiments within the spirit and scope of the invention.

0036Thus, a number of preferred embodiments have been fully described above with reference to the drawing figures. Although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions could be made to the described embodiments within the spirit and scope of the invention.

0037It should be understood, of course, that the foregoing relates to exemplary embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims. Furthermore, a method herein described may be performed in one or more sequences other than the sequence presented expressly herein.