Centralized system for data retrieval

• US 10,078,839 B1
• Filed: 08/30/2017
• Issued: 09/18/2018
• Est. Priority Date: 08/30/2017
• Status: Active Grant

• Current Assignee: Block, Inc. (f/k/a Square, Inc.)
• Original Assignee: Block, Inc. (f/k/a Square, Inc.)
• Inventors: Mullins, Brian, Lee, Fredrick, Yip, Timothy
• Primary Examiner(s): Hayles, Ashford S
• Application Number:
  US15/691,301
• Time in Patent Office: 384 Days
• Field of Search: 705 17
• CPC Class Codes: G06F 16/90335 Query processing
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/202 Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
• CPC Class Codes: G06Q 20/204 comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
• CPC Class Codes: G06Q 20/3224 Transactions dependent on location of M-devices
• CPC Class Codes: G06Q 20/327 Short range or proximity payments by means of M-devices
• CPC Class Codes: G06Q 20/389 Keeping log of transactions for guaranteeing non-repudiation of a transaction
• CPC Class Codes: G06Q 20/4016 involving fraud or risk level assessment in transaction processing
• CPC Class Codes: G06Q 20/405 Establishing or using transaction specific rules

Abstract

This disclosure describes, in part, techniques for storing transaction data at a central service, and techniques for querying information associated with the data from the central service when authorizing payment instruments for transactions. For instance, a central service may receive historical transaction data from multiple payment services that authorize payment instruments for merchants, and then store the historical transaction data in one or more databases. A payment service may then receive a request to authorize a payment instrument for a transaction between a merchant and a customer. Based on receiving the request, the payment service can send the central service a message that includes a query for information associated with historical transaction data corresponding to the payment instrument. In response, the payment service can receive the information from the central service and authorize the payment instrument using the information.

Claims

1. A method for processing payments between a merchant and customer via a payment service, the method comprising:

receiving card data from a point-of-sale (POS) device of the merchant, the card data indicating payment information of a card used during a transaction between the merchant and the customer;

sending the card data to a centralized data store, wherein the centralized data store includes historical transaction information associated with the card and a plurality of other cards, wherein the historical transaction information is sourced from the payment service and a plurality of third-party payment services;

analyzing the transaction and the card data using a risk model to compute a first risk score;

determining that the first risk score traverses a first threshold risk value;

based at least in part on determining that the first risk score traverses the first threshold risk value, querying the centralized data store to retrieve data corresponding to the historical transaction information that is associated with the card;

receiving the data corresponding to the historical transaction information from the centralized data store;

applying the data to the risk model to generate a second risk score for the transaction;

determining that the second risk score does not traverse at least one of the first threshold risk value or a second threshold risk value;

based at least in part on determining that the second risk score does not traverse at least one of the first threshold risk value or the second threshold risk value, authorizing the card for the transaction based at least in part on the second risk score; and

sending, to the POS device, a message including an indication that the card is authorized for the transaction, the message configured to cause the POS device to authorize use of the card for the transaction.

2. The method as recited in claim 1, further comprising:

determining a type of data associated with the card to query from the centralized data store,

wherein the query indicates the type of data.

3. The method as recited in claim 1, wherein the historical transaction information comprises first historical transaction data, and wherein the method further comprises:

storing second historical transaction information, the second historical transaction information being associated with transactions between merchants and customers that were previously authorized by the payment service,

wherein analyzing the transaction and the card data using the risk model comprises analyzing the transaction and the card data using the risk model and at least a portion of the second historical information to determine the first risk score.

4. The method as recited in claim 1, further comprising:

determining a final risk score based at least in part on the first risk score and the second risk score; and

determining that the final risk score does not traverse at least one of the first threshold risk value, the second threshold risk value, or an additional threshold risk value,

and wherein authorizing the card for the transaction is based at least in part on determining that the final risk score does not traverse the at least one of the first threshold risk value, the second threshold risk value, or the additional threshold risk value.

5. A method comprising:

receiving first data from a merchant device, the first data indicating at least payment information associated with a payment instrument used during a transaction between a merchant and a customer;

determining a first risk score based at least in part on analyzing the first data;

sending a first message to one or more computing devices, the first message including at least the payment information and a query for second data associated with the payment instrument;

receiving, from the one or more computing devices, the second data associated with the payment instrument;

determining, by a model and based, at least in part, on the first data and the second data, a second risk score associated with the payment instrument;

determining that the second risk score is below a threshold risk score;

determining, based at least on the second risk score being below the threshold risk score, that the payment instrument is authorized for the transaction; and

sending, to the merchant device, a second message indicating that the payment instrument is authorized.

6. The method as recited in claim 5, wherein the second data comprises at least one of:

historical transaction data associated with the payment instrument that the one or more computing devices receive from a plurality of payment services;

or

information associated with a type of data from the historical transaction data.

7. The method as recited in claim 5, further comprising:

storing third data associated with at least a previous transaction, the third data indicating one or more of the payment information, a cost of the previous transaction, a time of the previous transaction, and a geographic location of the previous transaction;

determining, by a model and based, at least in part, on the first data and the third data, a third risk score;

determining that the third risk score traverses the threshold risk score,

and wherein sending the first message to the one or more computing devices is based at least in part on determining that the third risk score traverses the threshold risk score.

8. The method as recited in claim 5, wherein the threshold risk score comprises a first threshold risk score, and wherein the method further comprises:

determining that the second risk score does not traverse at least one of the first threshold risk score or a second threshold risk score,

and wherein determining that the payment instrument is authorized is based at least in part on determining that the second risk score does not traverse at least one of the first threshold risk score or the second threshold risk score.

9. The method as recited in claim 5, wherein the threshold risk score comprises a first threshold risk score, and wherein the method further comprises:

determining a third risk score based at least in part on the first risk score and the second risk score; and

determining that the third risk score does not traverse at least one of the first threshold risk score or a second threshold risk score,

wherein determining that the payment instrument is authorized is based at least in part on determining that the third risk score does not traverse the at least one of the first threshold risk score or the second threshold risk score.

10. The method as recited in claim 5, further comprising:

determining, based at least in part on at least one of the query or the model, a type of data to request from the one or more computing devices,

and wherein the query indicates the type of data associated with the payment instrument, the second data representing the type of data.

11. The method as recited in claim 5, wherein:

the second data comprises a first type of data and a second type of data;

the model comprises a first model;

analyzing the first data comprises analyzing the first data using the first type of data and the first model;

determining, by the first model and based, at least in part, on the first type of data, that the payment instrument is authorized for a cost of the transaction; and

at least partly before determining that the payment instrument is authorized, the method further comprises;

determining, by a second model and based, at least in part, on the second type of data, that the payment instrument is not authorized for the cost of the transaction.

12. The method as recited in claim 5, further comprising sending the payment information to the one or more computing devices, wherein the one or more computer devices store historical transaction data from a plurality of payment services.

13. The method as recited in claim 5, wherein the second data includes at least one of:

information indicating one or more costs of one or more transactions in which the payment instrument was authorized;

information indicating one or more geographical locations of the one or more transactions in which the payment instrument was authorized; and

information indicating a frequency in which the payment instrument is used during transactions.

18. The method as recited in claim 5, wherein the first data from the merchant device is received at one or more computing device associated with a payment service and the second data is based, at least in part, on transaction data received at the one or more computing devices from at least one of the merchant device or a second merchant device.

14. A method comprising:

receiving, from a plurality of payment services, first data associated with a plurality of transactions, the first data for a transaction of the plurality of transactions indicating at least one of respective payment information associated with a respective payment instrument, a cost of the transaction, a time of the transaction, and a geographic location of the transaction;

storing the first data in one or more databases;

receiving a message from a payment service of the plurality of payment services, the message including at least payment information associated with a payment instrument and a query for information associated with the payment instrument;

generating second data including a representation of the information associated with the payment instrument based, at least in part, on identifying a portion of the first data using the query;

sending the second data to the payment service;

receiving, from the payment service, third data associated with an additional transaction between a merchant and a customer, the third data indicating at least the payment information associated with the payment instrument;

determining, by a model and based, at least in part, on the third data and the second data, that the payment instrument is authorized for the additional transaction; and

sending, to the payment service, a message indicating that the payment instrument is authorized for the additional transaction.

15. The method as recited in claim 14, wherein the information includes at least one of:

costs of one or more transactions in which the payment instrument was authorized;

geographical locations of the one or more transactions in which the payment instrument was authorized; and

a frequency in which the payment instrument is used during transactions.

16. The method as recited in claim 14, wherein:

the third data includes at least one of an indication of the payment information, a cost of the additional transaction, a geographical location of the additional transaction, and a time of the additional transaction; and

the method further comprises storing the third data in the one or more databases.

17. The method as recited in claim 14, wherein the message comprises a first message, the payment service comprises a first payment service, the query comprises a first query, and the information comprises a first type of information, and wherein the method further comprises:

receiving a second message from a second payment service of the plurality of payment services, the second message including the payment information associated with the payment instrument and a second query for a second type of information associated with the payment instrument, wherein the first type of information is different than the second type of information;

generating fourth data including a representation of the second type of information associated with the payment instrument based, at least in part, on identifying a portion of the first data using the second query; and

sending the fourth data to the second payment service.

19. The method as recited in claim 14, wherein operations of the method are accomplished by a central service that includes a computing device that is communicatively connected by a first network connection to a point-of-sale (POS) device associated with the merchant, the POS device being connected by a second network connection to the payment service.