System and method for securing sensitive credentials using transaction identifiers
阅读说明:本技术 用于使用交易标识符来保护敏感凭据的系统和方法 (System and method for securing sensitive credentials using transaction identifiers ) 是由 J·吉塔丽亚 A·安萨里 S·施洛格 于 2018-07-11 设计创作,主要内容包括:本发明的实施例涉及安全地传输例如令牌的账户凭据的系统和方法。用户装置和应用程序最初可以选择账户,并接着获得与所述账户相关联的交易标识符。所述用户装置可以将所述交易标识符提供到资源提供者,所述资源提供者接着可以直接用所述交易标识符换取所述账户凭据。(Embodiments of the present invention relate to systems and methods for securely transmitting account credentials, such as tokens. The user device and application may initially select an account and then obtain a transaction identifier associated with the account. The user device may provide the transaction identifier to a resource provider, which may then directly trade the transaction identifier for the account credentials.)
1. A method, comprising:
receiving, by the server computer from the application program, a request for a transaction identifier associated with an account selected by the user;
generating, by the server computer, the transaction identifier associated with the account selected by the user;
transmitting, by the server computer, the transaction identifier to the application program, wherein the application program transmits the transaction identifier to a resource provider computer;
receiving, by the server computer, the transaction identifier from the resource provider computer;
identifying, by the server computer, the account selected by the user based on the received transaction identifier;
obtaining, by the server computer, account credentials for the account; and
transmitting, by the server computer, the account credential to the resource provider computer.
2. The method of claim 1, wherein the application is a browser application executing on a user device.
3. The method of claim 2, wherein the application transmits the transaction identifier to the resource provider computer via a resource provider web page.
4. The method of claim 1, wherein transmitting the transaction identifier to the application is via a first communication channel, the first communication channel including the server computer and the application, and wherein transmitting the account credential to the resource provider computer is via a second communication channel, the second communication channel including the server computer and the resource provider computer, the second communication channel not including the application.
5. The method of claim 1, wherein the resource provider computer subsequently completes a transaction using the account credentials.
6. A server computer, comprising:
a processor; and
a computer readable medium comprising code executable by the processor to implement a method comprising:
receiving, from an application, a request for a transaction identifier associated with an account selected by a user;
generating the transaction identifier associated with the account selected by the user;
transmitting the transaction identifier to the application program, wherein the application program transmits the transaction identifier to a resource provider computer;
receiving the transaction identifier from the resource provider computer;
identifying the account selected by the user based on the received transaction identifier;
obtaining account credentials for the account; and
transmitting the account credentials to the resource provider computer.
7. The server computer of claim 6, wherein the application is a browser application executing on a user device.
8. The server computer of claim 6, wherein the account credentials comprise a token, and wherein obtaining the token for the account comprises generating the token or identifying the token in a database.
9. The server computer of claim 6, wherein transmitting the transaction identifier to the application program is via a first communication channel that includes the server computer and the application program, and wherein transmitting the account credential to the resource provider computer is via a second communication channel that includes the server computer and the resource provider computer, the second communication channel not including the application program.
10. The server computer of claim 6, wherein the request for the transaction identifier includes information identifying the account.
11. A method, comprising:
receiving, by an application, a request to complete a transaction associated with a user;
determining, by the application, a plurality of accounts associated with the user;
receiving, by the application, a selection of an account from the plurality of accounts;
sending, by the application program to a server computer, a request for a transaction identifier associated with the selected account;
receiving, by the application program, the transaction identifier from the server computer; and
transmitting, by the application program, the transaction identifier to a resource provider computer, wherein the resource provider computer subsequently transmits the transaction identifier to the server computer, and wherein the server computer responds to the resource provider computer by transmitting account credentials associated with the selected account.
12. The method of claim 11, wherein the application is a browser application executing on a user device.
13. The method of claim 11, wherein receiving the transaction identifier from the server computer is via a first communication channel that includes the server computer and the application program, and wherein subsequently transmitting the transaction identifier by the resource provider computer to the server computer is via a second communication channel that includes the server computer and the resource provider computer, the second communication channel not including the application program.
14. The method of claim 11, wherein transmitting the transaction identifier to an asset provider computer comprises transmitting the transaction identifier to an asset provider web page, which in turn provides the transaction identifier to the asset provider computer.
15. The method of claim 11, wherein the resource provider computer subsequently completes the transaction using the account credentials.
16. A user device, comprising:
a processor; and
a computer readable medium comprising code executable by the processor to implement a method comprising:
receiving a request to complete a transaction associated with a user;
determining a plurality of accounts associated with the user;
receiving a selection of an account from the plurality of accounts;
sending a request to a server computer for a transaction identifier associated with the selected account;
receiving the transaction identifier from the server computer; and
transmitting the transaction identifier to a resource provider computer, wherein the resource provider computer subsequently transmits the transaction identifier to the server computer, and wherein the server computer responds to the resource provider computer by transmitting account credentials associated with the selected account.
17. The computer-readable medium of claim 16, wherein the computer-readable medium comprises a browser application.
18. The computer-readable medium of claim 17, wherein the account credential comprises a token.
19. The computer-readable medium of claim 16, wherein the request for the transaction identifier includes information identifying the selected account.
20. The computer-readable medium of claim 16, wherein the resource provider computer subsequently completes the transaction using the account credentials.
Background
The volume of electronic transactions is increasing because there are several advantages to conducting transactions over electronic networks, such as the internet, including convenience and lower cost. However, while convenient for users, online transactions may introduce new data security vulnerabilities.
For example, to conduct an online transaction, a user may provide a set of account credentials to a resource provider server. Due to the fact that typical transaction systems and communications involve multiple parties (e.g., users, applications on user devices, resource providers, transaction processing networks, authorized entities, etc.), the process of obtaining and providing account credentials may cause multiple entities to view and/or process account credentials. For example, the user device and an application operating on the user device (e.g., a browser application) may communicate with a server computer associated with an entity managing the account (e.g., an authorization entity) to obtain account credentials. The user device may then transmit the account credentials to the resource provider computer. As a result, account credentials and potentially other sensitive data are exposed to the user device, the browser application, and/or any other routing computer. Every data transmission and system that handles sensitive data poses a potential threat of data theft or loss. In addition, creating a sufficiently secure data storage and transmission system can be burdensome for each of these entities.
Embodiments of the present invention address these problems and others individually and collectively.
Disclosure of Invention
Systems and techniques for securely provisioning account credentials to a resource provider for a transaction are described herein. Upon selection of an account by the user at the user device, the user device and/or an application executed by the user device may transmit an account selection result to the server computer in order to request account credentials for the account. Instead of transmitting the account credentials to the user device, the server computer may generate and transmit a transaction identifier to the user device. The application executing on the user device may, in turn, transmit the transaction identifier to the resource provider. The resource provider may then transmit the transaction identifier back to the server computer, thereby establishing a direct communication line between the resource provider and the server computer. The server computer may identify the account based on the transaction identifier and may then transmit the account credentials (e.g., token) directly to the resource provider. As a result, account credentials are not shown to the user device or application during transmission to the resource provider.
One embodiment of the invention is directed to a method comprising: receiving, from an application, a request for a transaction identifier associated with an account selected by a user; generating the transaction identifier associated with the account selected by the user; transmitting the transaction identifier to the application program, wherein the application program transmits the transaction identifier to a resource provider computer; receiving the transaction identifier from the resource provider computer; identifying the account selected by the user based on the received transaction identifier; obtaining account credentials for the account; and transmitting the account credentials to the resource provider computer.
Another embodiment of the invention relates to a server computer configured to perform the above method.
Another embodiment of the invention is directed to a method comprising: receiving a request to complete a transaction associated with a user; determining a plurality of accounts associated with the user; receiving a selection of an account from the plurality of accounts; sending a request to a server computer for a transaction identifier associated with the selected account; receiving the transaction identifier from the server computer; and transmitting the transaction identifier to a resource provider computer, wherein the resource provider computer subsequently transmits the transaction identifier to the server computer, and wherein the server computer responds to the resource provider computer by transmitting account credentials associated with the selected account.
Another embodiment of the invention relates to a user device configured to perform the above method.
Further details regarding embodiments of the present disclosure can be found in the detailed description and figures.
Drawings
Fig. 1 depicts a number of components that may be involved in a system for implementing at least some embodiments of the present disclosure.
Fig. 2 depicts an example system architecture that may be implemented to provide secure remote transactions in accordance with embodiments of the present disclosure.
FIG. 3 depicts a swim lane diagram showing an example process for conducting a transaction using an SRT platform, in accordance with at least some embodiments.
FIG. 4 depicts a swim lane diagram showing an example process for communicating a transaction identifier, in accordance with at least some embodiments.
Fig. 5 depicts a process for authenticating a user according to an embodiment of the present disclosure.
FIG. 6 depicts an example process of providing, by a resource provider, an indication of a docket account to an initiator server in accordance with at least some embodiments.
FIG. 7 depicts an example provisioning process that enables a user to manually add his or her account for processing by an initiator server, according to some embodiments.
Fig. 8 depicts an example provisioning process for an SRT platform or an authorizing entity to push an indication of one or more accounts to an initiator server.
FIG. 9 depicts a flow diagram showing a process for completing a transaction in accordance with at least some embodiments.
Fig. 10 illustrates an example of a
Detailed Description
Embodiments of the present invention are directed to improving the efficiency and security of the transmission of account credentials for remote electronic transactions by first transmitting a transaction identifier that may be directly exchanged for account credentials. For example, a user may operate a user device application to access a resource provider web page and select one or more items for purchase via the web page. The user may select an account to be used for the purchase, and the user device application may electronically communicate the selection to a server computer associated with the account. The server computer may then generate a transaction identifier to be associated with the selected account and store a record of the transaction identifier. Then, instead of providing account credentials directly to the user device application, the server computer may transmit a transaction identifier to the user device application.
Upon receiving the transaction identifier, the user device application may transmit the transaction identifier to the resource provider. The resource provider may then communicate directly with the server computer to exchange the transaction identifier for account credentials. The server computer may identify the account based on the transaction identifier, obtain account credentials (e.g., PAN or token) for the account, and then transmit the account credentials directly to the resource provider.
As a result, the account credentials are not shown to the user device application during transmission to the resource provider. The first set of communications (e.g., for selecting an account and obtaining a transaction identifier) may be conducted primarily over a first communication channel that includes a user device (e.g., an application executing on the device) and a server computer. The second set of communications (e.g., for obtaining account credentials) may then be conducted primarily over a second communication channel that includes the resource provider and the server computer. Separating these communications across two different communication channels may enable more efficient and secure transmission of account credentials to a resource provider in a shorter time. Additionally, efficiency is increased by reducing the number of systems that need to be equipped to securely manage sensitive data.
In addition, embodiments simplify electronic resource provider acceptance by providing a standardized payload, integrating local security applications, and improving resource provider trust in transactions made. In embodiments of the present disclosure, a user is enabled to select from among their multiple accounts, each of which may be associated with a different secure remote transaction platform, to complete a transaction. The transaction may then be made more secure by using a local facilitator application that supports the selected account.
In embodiments of the present disclosure, a user may be enabled to select a checkout element embedded in a resource provider checkout page accessed via an application executed by a client computing device. Upon selection of the checkout element, the client computing device may be caused to initiate communication with the remote initiator server. The initiator server may receive a plurality of transaction details from an application on the client computing device, as well as user identification information. In some embodiments, the initiator server may derive various information from small data files (cookies) placed on the client computing device.
In some embodiments, the initiator server, upon receiving this information, may identify a user identity associated with the transaction. Once the user identity has been identified, the initiator server may determine a plurality of accounts associated with the user identity. A list of these accounts may be provided to the client computing device for presentation to the user. Upon selecting an account, the initiator server may communicate the selection to a Secure Remote Transaction (SRT) platform associated with the account.
The SRT platform may then identify a plurality of facilitator applications that support authentication of the selected account and install on the client computing device (or a different device operated by the user). In some embodiments, the list may also be provided to the client computing device for selection by the user. In some embodiments, a particular facilitator application may be selected automatically (e.g., without user interaction) by the SRT platform. The SRT platform may provide instructions to the client computing device to cause execution of the selected facilitator application. The facilitator application may then perform an authentication process to verify the identity of the user of the client computing device. Once authenticated, the facilitator application may provide an authentication indicator back to the SRT platform. Upon receiving this authentication indicator, the SRT platform may generate a transaction-specific token, which may then be provided to the initiator application and subsequently to the resource provider in order to complete the transaction.
Before discussing specific embodiments of the invention, some terms may be described in detail.
An "access device" may be any suitable device that provides access to a remote system. The access means may be in any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, PDAs, Personal Computers (PCs), tablet PCs, hand-held dedicated readers, set-top boxes, Electronic Cash Registers (ECRs), Automated Teller Machines (ATMs), Virtual Cash Registers (VCRs), kiosks, security systems, access systems, and the like. The access device may use any suitable contact or contactless mode of operation to send or receive data to or from the user mobile device or to associate with the user mobile device.
An "account credential" may include any suitable information associated with an account (e.g., an account and/or a portable device associated with an account). Such information may be directly related to the account, or may be derived from information related to the account. Examples of account credentials may include a PAN (primary account number or "account number"), a username, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, and so forth.
An "acquirer" can generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular resource provider or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such single entity issuer-acquirer. The acquirer may operate an acquirer computer, which may also be collectively referred to as a "transmitting computer".
An "authentication indicator" may be any suitable piece of data that provides additional proof that a particular situation is authentic. Exemplary authentication indicators may include ciphertext, flags, or other data that may indicate that a user has been authenticated by a computing device.
An "authorization request message" may be an electronic message requesting authorization for a transaction. In some embodiments, an authorization request message is sent to the transaction processing computer and/or the issuer of the portable device to request authorization for the transaction. The authorization request message according to some embodiments may conform to ISO 8583, which is a standard of systems that exchange electronic transaction information associated with payments made by users using portable devices or accounts. The authorization request message may include an issuer account identifier, which may be associated with the portable device or the account. The authorization request message may also include additional data elements including one or more of the following: a service code, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information related to the current transaction, such as the transaction amount, merchant identifier, merchant location, acquiring line identification number (BIN), card acceptor ID, information identifying the item purchased, etc., and any other information that may be used to determine whether to identify and/or authorize the transaction.
The "authorization response message" may be a message responding to the authorization request. In some cases, the authorization response message may be an electronic message reply to the authorization request message generated by the issuing financial institution or the transaction processing computer. The authorization response message may include, for example, one or more of the following status indicators: approval-the transaction is approved; decline-transaction not approved; or call center-in response to more information pending, the merchant must call the toll free authorization phone number. The authorization response message may also include an authorization code, which may be a code indicating that the transaction is approved by the credit card issuing bank in response to the authorization request message in the electronic message being returned (directly or through the transaction processing computer) to the resource provider's access device (e.g., POS device).
An "authorizing entity" may be the entity that authorizes the request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, and the like. An "issuer" may generally refer to a business entity (e.g., a bank) that maintains a user's account. The issuer may also issue account credentials stored on a user device, such as a cellular phone, smart card, tablet, or laptop, to the user.
A "computing device" may include any suitable device that can electronically process data. Examples of computing devices include desktop computers, mobile or mobile computing devices, televisions, and the like.
An "application" may be computer code or other data stored on a computer-readable medium (e.g., a memory element or a secure element) that may be executed by a processor to accomplish a task. For example, an application may comprise a program or group of programs designed to perform a specific function. Examples of applications include web browser applications, shopping applications, social networking applications, portions of operating systems (e.g., iOS, Android, Microsoft Windows, macOS, etc.), such as APIs (application programming interfaces), voice control software, cloud-based transaction services, facilitator applications, and so forth.
A "small data file" (also known as a "network small data file," "Internet small data file," or "browser small data file") can be any suitable piece of data that is sent from a network server and stored on a user's computer. The small data files may be placed on the user's computer by the computer's web browser as the user browses through a web site maintained by a web server.
A "facilitator" may be any entity capable of authenticating a user of a client device. The facilitator may include a client-side application (e.g., a facilitator application) and a backend server (e.g., a facilitator server) capable of supporting the client-side application. In some cases, the facilitator application may be executed upon receiving an instruction from the facilitator server to authenticate the user of the client device. The facilitator application may cause the client device on which the facilitator application is installed to obtain the user-specific data. This user-specific data may then be compared to the expected user-specific data by a facilitator application on the client device or by a facilitator server to determine whether the obtained user-specific data matches the expected user-specific data. In some embodiments, the facilitator may be an electronic wallet provider (e.g., Apple Pay). It should be noted that the facilitator may be unrelated to the SRT platform and/or the initiator.
An "initiator" may be any entity capable of facilitating communication between a resource provider and one or more SRT platforms. The initiator may operate a plurality of servers that provide at least a portion of the functionality described herein. In some cases, the initiator may obtain approval and/or approval from one or more SRT platforms in order to operate in conjunction with those SRT platforms. The resource provider may register with the initiator in order to obtain at least a portion of the process described herein. The initiator may provide a link embedded within the checkout element for each resource provider registered therewith. The link, when activated by a user wishing to transact with the resource provider, may initiate a process described herein to facilitate a transaction between the user and the resource provider. It should be noted that the initiator may be unrelated to the SRT platform and/or facilitator. In some embodiments, the initiator may also be referred to as a "virtual terminal" and may perform functions of the remote transaction similar to those performed by a physical terminal (e.g., a point-of-sale device) for the current transaction.
The term "resource" generally refers to any asset that can be used or consumed. For example, a resource may be a computer resource (e.g., stored data or a networked computer account), a physical resource (e.g., a tangible object or physical location), or other electronic resource or communication between computers (e.g., a communication signal corresponding to an account for performing a transaction). Some non-limiting examples of resources may be goods or services, physical buildings, computer accounts or files, or payment accounts. In some embodiments, a resource may refer to a financial product, such as a loan or a line of credit.
A "resource provider" may be an entity that may provide resources, such as goods, services, information, and/or access to such resources. Examples of resource providers include merchants, online or other electronic retailers, access devices, secure data access points, and the like. A "merchant" may generally be an entity that participates in a transaction and may sell or provide access to goods or services. A "resource provider computer" may be any computing device operated by a resource provider.
A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers.
A "Secure Remote Transaction (SRT) platform" may be any entity capable of facilitating transactions in the manner described. The SRT platform may be capable of communicating with initiators, facilitators, and transaction processing networks. In some embodiments, the SRT platform may include an SRT server, a token provider, and a transaction processing network. The SRT platform may be configured to perform one or more processes, including: the method includes receiving a transaction request from an initiator, identifying an account associated with the transaction, determining an appropriate facilitator for the account, having the determined facilitator authenticate a user associated with the account, generating a token to be used in the transaction, and providing the token to the initiator to complete the transaction.
The "token" may be an alternative value to the credential. The token may be a string of numbers, letters, or any other suitable character. Examples of tokens include tokens, access tokens, personal identification tokens, and the like. The "token" may include an identifier of the account that is a substitute for an account identifier, such as a Primary Account Number (PAN). For example, the token may include a series of alphanumeric characters that may be used as a substitute for the original account identifier. For example, the token "4900000000000001" may be used in place of PAN "4147090000001234". In some embodiments, the token may be "in a maintained format" and may have a numeric format consistent with an account identifier used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, the token may be used to initiate, authorize, settle, or resolve a transaction in place of a PAN, or represent the original credential in other systems that would normally provide the original credential. In some embodiments, the token value may be generated such that a recovery of the original PAN or other account identifier may not be computationally derived from the token value. Further, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and identify the entity that issued the token.
Tokenization is the process of replacing data with substitute data. For example, an account identifier (e.g., a Primary Account Number (PAN)) may be tokenized by replacing the primary account identifier with an alternate number (e.g., token) that may be associated with the account identifier. Furthermore, tokenization may be applied to any other information that may be replaced with an alternative value. Tokenization may be used to improve transaction efficiency, improve transaction security, improve service transparency, or provide third party implemented methods.
A "token provider" or "token service system" may include one or more computers that service tokens. In some embodiments, the token service system may facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining established token-to-Primary Account Number (PAN) mappings in a repository (e.g., a token vault). In some embodiments, the token service system may establish a token assurance level for a given token to indicate the trust level at which the token is bound to the PAN. The token service system may include or be in communication with a token vault that stores the generated tokens. The token service system may support token processing for transactions submitted using tokens by de-tokenizing the tokens to obtain an actual PAN and using the PAN to conduct transactions. In some embodiments, the token service system may include only the tokenizing computer, or may also include other computers such as transaction processing network computers. Various entities of the tokenization ecosystem can assume the role of a token provider. For example, a processing network and an issuer or their agents may become token providers by implementing token services according to embodiments of the present invention.
A "token vault" may refer to a repository that maintains established token-to-PAN mappings. According to various embodiments, the token vault may also maintain other attributes of the token requestor that may be determined at registration time and used by the token SRT server to apply domain restrictions or other controls during transaction processing. The token vault may be part of a token service system. In some embodiments, the token vault may be provided as part of a token SRT server. Alternatively, the token vault may be a remote repository accessible to the token SRT server. The token vault may be protected by strong underlying physical and logical security due to the sensitive nature of the data maps stored and managed therein.
A "transaction" may be any interaction or exchange between two or more parties. For example, a transaction may include a first entity requesting a resource from a second entity. In this example, the transaction is completed when the resource is provided to the first entity or the transaction is denied.
A "transaction processing network" or "processing network" may refer to an electronic payment system for accepting, transmitting, or processing transactions conducted by a payment device to obtain funds, goods, or services. The processing network may communicate information and funds between the authorizing entity (e.g., the issuer), the acquirer, the merchant, and the payment device user.
The "user" may comprise an individual. In some embodiments, a user may be associated with one or more personal accounts and/or mobile devices. A user may also be referred to as a cardholder, account holder, or consumer.
The "transaction identifier" may include any suitable information for identifying a transaction and/or account. For example, the transaction identifier may identify a stored transaction record, a stored account record, and/or a stored set of account credentials. The transaction identifier may include a string of characters, numbers, or other identifiers. For example, the transaction identifier may be a random alphanumeric value.
Fig. 1 depicts a number of components that may be involved in a system for implementing at least some embodiments of the present disclosure. In fig. 1, client device 102 may communicate with a plurality of remote entities via network connections (wireless or physical). For example, the client device 102 may be used to access a website maintained by the resource provider server 104. In this example, the website may have embedded a checkout element configured to cause the client device 102 to initiate communication with the
In some embodiments, the client device 102 may have the communication application 106 installed thereon. Embodiments allow the communication application 106 to include any suitable software that enables the client device 102 and/or user to communicate with (e.g., to conduct transactions with) the initiator application server, the resource provider server 104, and the secure
In some embodiments, the client device 102 may have installed thereon a plurality of facilitator applications 112 (1-M). The facilitator application may be configured to cause the client device 102 to communicate with a plurality of facilitator application servers 114 (1-M). In some embodiments, the client device 102 may store a plurality of small data files in its memory.
In some embodiments of the invention, the client device 102 may be a mobile device (e.g., a mobile phone). The mobile device may be able to communicate with a cell tower (e.g., via cellular communications such as GSM, LTE, 4G) and a wireless router (e.g., via WiFi). The mobile device may store the user's account credentials, such as a PAN (primary account number) or account reference ID (e.g., the last four digits of a PAN, card display name, or other account metadata), token, name, address, CVV, expiration date, and any other suitable information. Such data may be securely stored via hardware (e.g., secure elements) or software.
In some embodiments, the resource provider server 104 may be associated with an online retailer having an electronic catalog or another suitable resource provider. The resource provider server 104 may serve one or more pages of the resource provider website to a communication application 106 (e.g., a web browser application, an application programming interface, etc.) installed on the client device 102. In some embodiments, the website serving the browser application may contain a web portal or link that initiates communication with the
The
In some embodiments, there may be multiple SRT platforms 110(1-N), and the SRT platforms may each be associated with a transaction processing network. Each SRT platform may include some combination of an SRT server (or servers) 110(a), token data 110(B), and a processing network 110 (C). Multiple accounts may be associated with a single SRT platform. For example, a user may be associated with two different accounts each associated with a different authentication entity, and both accounts can be processed using a single SRT platform. The SRT server 110(a) may be configured to identify one or more facilitator applications 112 associated with the account and cause the user to be authenticated using one of those facilitator applications 112. This may involve communicating the authentication request to the
Additionally, once the user has been authenticated, the SRT server 110(a) may be configured to generate tokens to be associated with transactions stored in the respective token data 110 (B). The SRT server 110(a) may pass the token to the originator server 208, and the originator server 208 may generate transaction information including the token to be used for the transaction. A mapping between tokens and transactions may be maintained by the SRT server 110(a) in its respective token data. In some embodiments, the SRT server 110(a) may receive multiple files from various authorized entities, each of which may include a mapping between email addresses and various PANs. In this manner, the SRT server 110(A) may maintain a mapping between user identifier information and accounts.
The facilitator application 112 may be any suitable set of computer-executable instructions installed on the client device 102 that, when executed, cause the client device 102 to perform an authentication process. In some embodiments, the authentication process may involve a set of biometric information associated with the user of the client device 102. For example, the facilitator application 112 may obtain voiceprint or fingerprint data to be used to authenticate the user. The facilitator application may be associated with hardware installed on the client device 102. Examples of the facilitator application 112 may include a fingerprint scanning application, a retina scanning application, or a voice scanning application. The hardware associated with those applications may include fingerprint scanning hardware, retina scanning hardware, or voice scanning hardware, such as a fingerprint sensor, retina sensor, or voice sensor. Other types of facilitator applications 112 may also include PIN and password facilitator applications. In some embodiments, the facilitator application 112 may be a wallet SRT server.
The
For an illustrative example of at least some embodiments of the disclosure, consider a scenario in which a user visits a merchant (resource provider 104) website to complete a transaction (e.g., make a purchase). In this scenario, the user may be provided with a checkout page of the merchant website upon selecting a plurality of items for the transaction. The checkout page may include a listing of items, prices, quantities, or any other suitable transaction-related information. Additionally, the checkout page may include a checkout element that may be selected to initiate the transaction. Once the checkout element has been selected, the user may be enabled to select an account for completing the transaction.
In the above scenario, upon selection of a checkout element by a user of the client device 102, the communication application 106 at the client device 102 may be caused to initiate communication with the initiator server 208. This may involve transmitting a plurality of transaction-related details from the client device 102 and the communication application 106 to the
Once the user has been identified by the
Once the aggregated account list has been created, it may be presented to the user via a communication application 106 at the client device 102 (e.g., a browser application may activate a pop-up window). In this scenario, the user may be presented with information pertaining to his or her multiple different accounts upon which the transaction should be completed. The user may then select an account from the list. Once this selection has been made, the communication application 106 at the client device 102 may transmit information about the selected account to the
Upon receiving a selection of an account to use, the
In some embodiments, once the list of support facilitator applications 112 has been generated, it may be presented to the user for selection. Upon receiving a selection of a particular facilitator application 112 from the list, the
Upon receiving an authentication indicator indicating that the user is authenticated, the
For clarity, a specific number of components are shown in FIG. 1. However, it should be understood that embodiments of the invention may include more than one of each component. Additionally, some embodiments of the invention may include fewer or more than all of the components shown in FIG. 1. In addition, the components in FIG. 1 may communicate over any suitable communication medium, including the Internet, using any suitable communication protocol.
Fig. 2 depicts an example system architecture that may be implemented to provide secure remote transactions in accordance with embodiments of the present disclosure. In fig. 2, the
In at least some embodiments, the
Memory 214 may store program instructions that are loadable and executable on processor 216, as well as data generated during the execution of these programs. Depending on the configuration and type of the
Turning in more detail to the contents of memory 214, memory 214 may include an operating system and one or more applications or services for implementing the features disclosed herein, including at least a module for identifying an account, a module for generating a transaction identifier, a module for identifying an account and/or transaction based on the transaction identifier, a module for generating a token for a user (account mapping module 220), and a module for initiating user authentication via a facilitator application (authentication module 222). The memory 214 may also include account data 224 that provides data stored in association with the user account and/or token data 220 that provides a mapping between the generated token and the transaction or account.
In some embodiments, the account mapping module 220, in conjunction with the processor 216, may be configured to receive an identifier from the initiator application and identify one or more accounts based on the identifier. In some embodiments, the account mapping module 220 may be provided with an identifier of the user, such as an email address or alias. In some embodiments, the account mapping module 220 may be provided with a device identifier. In at least some of these embodiments, the account mapping module 220 may communicate with the device associated with the device identifier to determine whether the device has a small data file stored in its memory associated with the
In some embodiments, the authentication module 222, in conjunction with the processor 216, may be configured to receive an indication that a transaction is to be conducted with respect to a particular account and may cause a user associated with the transaction to be authenticated. To this end, the authentication module 222 may identify one or more facilitator applications 238 and/or authentication techniques associated with the identified account. In some cases, this may involve determining which facilitator applications 238 have been used with the account in the past. In some cases, this may involve receiving account authentication requirements from an authorizing entity 210 (e.g., an issuer) associated with the account that indicate which facilitator applications 238 and/or authentication techniques are appropriate for use with the account. In some embodiments, the authentication module 222 may compile a list of suitable facilitator applications, which it may provide to the
In some embodiments, the account mapping module 220, in conjunction with the processor 216, may be further configured to generate a transaction identifier and/or token to be used in a transaction. Once the account mapping module 220 has received an indication from the authentication module 222 that the user has been authenticated, the account mapping module 220 may generate a transaction identifier that may be used by the resource provider computer 232 to reference the transaction and/or the selected account. The transaction identifier may be provided to a
The
In some embodiments, the
In some embodiments, the
FIG. 3 depicts a swim lane diagram showing an example process for conducting a transaction using an SRT platform, in accordance with at least some embodiments. Interactions between the various components as described herein are depicted in fig. 3. Specifically, the
On the checkout page, the resource provider may display the embedded checkout element at 304. In some embodiments, when a user accesses a checkout page with an embedded checkout element, the initiator may determine whether the user is the identified user. To this end, the initiator may receive user identification information from the communication application, the resource provider, and/or software embedded within the checkout page (e.g., a checkout element). In some embodiments, when a user accesses a checkout page or selects a checkout element on a resource provider checkout page, the user's email address may be transmitted (e.g., via a helper feature) by the browser to the initiator server. In scenarios where the
At 312, the user may initiate a transaction with the resource provider via a checkout page by selecting a checkout button displayed by the communication application on the
In a scenario where the user's email address is not available from the browser, the user may be required to enter his or her email address. The originator server may then identify the user's account from a file that includes a mapping of accounts to the user's email address. In some embodiments, if the initiator server is unable to identify an account from the mapping file, the user may be required to provide an account identifier. The originator may perform more or more authentication techniques to confirm that the user actually owns the provided email address. For example, in some embodiments, the originator server may send a one-time password (e.g., a code or pin) to an email address, which the originator may ask the user to provide back. The SRT server may then query the SRT server in the manner described above to identify a plurality of accounts that are available to the user.
Once the
Once the request has been received by the SRT server and the user of the transaction has been identified, the account information stored by the
The SRT server, upon identifying an account selected by the user, may determine one or more facilitator applications that may be used to provide authentication of the account. In some embodiments, a list of facilitator applications appropriate for authenticating a user with respect to a particular account may be provided to the SRT server by an authorized entity that maintains the account. In some embodiments, one or more capabilities of the facilitator application may be identified based at least in part on a trust level associated with the facilitator application. In some embodiments, the facilitator application may be selected based on authentication capabilities available via one or more facilitator applications. For example, a list of facilitator applications that provide fingerprint authentication may be selected. In some embodiments, the
Once the
Upon receiving a request to authenticate a user of a transaction, the
Once the user has been authenticated by the facilitator application using the authentication process, the facilitator application may transmit an indication to the
In some embodiments, the SRT server may maintain supplemental information about the user. For example,
In some embodiments, once some or all of the above steps are completed (e.g., account selection, user authentication, address selection), the method may proceed with the step of providing the token to the resource provider 232. However,
In some embodiments,
At
At
At
The communication application may then forward the transaction identifier and other accompanying information to the resource provider 232 at
At this point, in some embodiments, the resource provider 232 may confirm the transaction details and the selected account with the user. For example, the resource provider 232 may transmit the transaction amount, the item to purchase, an account reference ID (e.g., the last four digits of a PAN, a card display name, or other account metadata), and any other suitable information to a communication application (e.g., a web browser application, a shopping application, an application program interface, etc.) at the
At
At
Additionally, in some embodiments,
At
The
At
As mentioned above, in some embodiments, a communication application 350 (e.g., a web browser application, a shopping application, an application program interface, etc.) may execute on a client device. The resource
In some embodiments, the steps for identifying an account and selecting an account for a transaction may be primarily between the communication application 350 (and/or the SRT client 351) executed by the client device and the
At
At
At
At
Next, steps 444A-444C demonstrate several of the communications that may be covered by
Next, at
Finally, at
Accordingly, the transaction identifier may be transmitted from the
Accordingly, the transaction identifier may be obtained from the
At this point, in some embodiments, the
At
At
At
Additionally, in some embodiments,
At
The
At
The above flow describes a client device that includes an application for communicating with other computers and for allowing a user to select items, accounts, addresses, etc. to purchase. As mentioned above, the application may take the form of a web browser application, a shopping application (e.g., a general shopping application or a merchant-specific application), part of an operating system such as an API, cloud-based transaction software, and/or any suitable combination of programs.
In addition, embodiments of the present invention allow the token provisioning process to proceed similarly even after different account selection procedures. For example, in some embodiments, the communication application may store account reference identifiers (e.g., last four digits of a PAN, card display name) that have been collected from the SRT server during a previous transaction. Thus, the communication application (and/or the SRT client) may display the account options without having to repeat the query to each SRT server. Next, the communication application may initiate a token acquisition process by transmitting a request for account credentials associated with the selected account.
Further, in
The above method describes using a transaction identifier (e.g., an alphanumeric string) to link a first communication channel with a second communication channel so that a resource provider can obtain a token. In some embodiments, the same goal may be achieved using an encrypted set of account credentials rather than using a transaction identifier that is a random value. For example, the encrypted payment data may include a token, an expiration date, ciphertext, a shipping address, a billing address, authentication data, and/or any other suitable information. This encrypted data may be passed to the communication application and client device, and then to the resource provider. The resource provider may trade encrypted data for the token (e.g., similar to the process described above for the transaction identifier). Further, in some embodiments, the resource provider server or the initiator server may be able to decrypt the encrypted data such that the resource provider server does not need to contact the
In other embodiments, the
Fig. 5 depicts a process for authenticating a user according to an embodiment of the present disclosure. In fig. 5, a communication application (e.g., a web browser application, shopping application, API, etc.) on the client device may display a checkout Graphical User Interface (GUI)504, the
In some embodiments, the account presentation space within the list of
Based on the user selecting an account from the list of
The user may then select
FIG. 6 depicts an example process of providing, by a resource provider, an indication of a docket account to an initiator server in accordance with at least some embodiments. In this example, the user may be a repeat of the resource provider who is about to conduct the transaction. In some embodiments, a user may have an account maintained by a resource provider.
In the illustrated example, the user may have previously conducted at least one transaction using the processes described herein. As a result of the process, the resource provider may have received a token generated by the SRT server in at least one previous transaction upon user authentication. In the illustrated example, the resource provider may have stored the received token in relation to an account maintained by the resource provider. After the user logs into an account maintained by the resource provider, the resource provider may retrieve the previously received token.
Upon initiating the transaction completion process in 604 (e.g., by selecting checkout element 602), the resource provider (or initiator) may identify the token (i.e., docket card) previously used by the user. Upon selecting
FIG. 7 depicts an example provisioning process that enables a user to manually add his or her account for processing by an initiator server, according to some embodiments. In at least some embodiments, the process depicted in fig. 7 may be performed if the initiator is unable to automatically identify one or more accounts associated with the user (e.g., the client device used by the user is new or there are no small data files in memory). This process enables a user to manually identify one or more accounts.
In this example provisioning process, the user may provide an indication of one or more accounts associated with him or her. In some embodiments, the originator server may contact an authorization entity (e.g., issuer) associated with the indicated account. In some embodiments, the initiator may contact an SRT server associated with the processing network associated with the account. The SRT server, in turn, may communicate with an authorized entity to authenticate the account. The authorizing entity associated with the account may then verify that the user is associated with the account. An authentication process may then be performed as described herein.
In some embodiments, this process may involve requiring the user to provide at least one account number via
In some embodiments, the identified authorization entity or SRT platform associated with the identified transaction processing network may identify one or more communication channels associated with the user of the account. The user may be presented with one or more communication channels, or at least obfuscated versions of those communication channels, at 706, to enable the user to verify his or her account ownership via those communication channels. In some embodiments, the user may be presented with multiple communication channels for his or her selection. In some embodiments, a default communication channel may be selected for communication with the user.
Once the appropriate communication channel has been identified, the authorizing entity or SRT platform may transmit the authentication details to the user via the identified communication channel. In some embodiments, the verification details may include a code or pin. The user may then be asked to provide those authentication details at 708 in order to authenticate that the user has at least access to the communication channel.
In some embodiments, once the user has been authenticated as the owner of the account using the techniques depicted in FIG. 7, a small data file may be placed onto the client device that initiated the process. The small data file may include identifier information such as an account reference ID (e.g., the last four digits of a PAN, card display name, or other account metadata) that may be used by the originator in the future to automatically identify the account.
As an illustrative example, as depicted in fig. 7, the user may be prompted at 704 to enter an account to be related to himself or herself. In this example, the authorization entity, once contacted, may initiate the verification process. For example, the authorized entity may provide authentication details (e.g., a one-time code) to a communication channel known to be associated with the user. To this end, the authorized entity may provide the user with a selection of a communication channel to which the authentication details are to be transmitted at 706. The user may then be asked to retrieve verification details in order to verify that the user is authentic at 708. If the authentication details provided by the user match the authentication details sent via the selected communication channel, the account may be authenticated as being associated with the user at 710. It should be noted that the verification process described herein may be separate from the authentication processes described elsewhere. In some embodiments, even if the user has verified his or her ownership in the manner described in FIG. 7, the user may still be authenticated using other techniques described herein.
Fig. 8 depicts an example provisioning process for an SRT platform or an authorizing entity to push an indication of one or more accounts to an initiator server. In some embodiments, the user may log into an account maintained by the SRT platform or an authorized entity (e.g., an issuer). Once logged in, various accounts may be identified as being associated with the user account. In some embodiments, the identifier of the user may be provided to the receiving entity via a helper function. It should be noted that in embodiments where the user logs into an account maintained by the authorizing entity, the authorizing entity may identify multiple accounts maintained by the authorizing entity, each of which may be associated with the same or different transaction processing networks. In contrast, if a user logs into an account maintained by the SRT platform (or transaction processing network), the SRT platform may identify multiple accounts, each using the same transaction processing network (the transaction processing network associated with the SRT platform), but may be associated with different authorized entities.
In some embodiments, if the initiator is unable to automatically identify an account associated with the user, the initiator may enable the user to manually log into an account associated with the SRT platform or an authorized entity in order to automatically identify the account associated with the entity. In this process, the user may select an icon indicating the appropriate entity that the user wishes to log in to. Upon selection of the icon, the user may be redirected (via his or her client device) to a site hosted by the selected entity at 802. Upon arrival at this site, the user may be required to provide login credentials to the selected entity (or otherwise authenticate himself/herself) in order to be able to access the account maintained by the selected entity. After the selected entity is accessible, the user may be presented with a list of full accounts associated with the entity. The user may be enabled to select some portion or all of the accounts in the account list for transmission to the initiator at 804. Once the user has selected one or more accounts, the selected entity may be caused to transmit an account reference ID (e.g., the last four digits of a PAN, card display name, or other account metadata) to the originator server for each selected account. A notification may be provided to the user by the originator server at 806.
In some embodiments, the initiator server may maintain a separate account associated with the user. The user may be asked if he or she wishes to register any/all accounts associated with the authorizing entity and/or the SRT platform with the initiator server. If the user indicates his or her desire, the appropriate entity may provide account information to the initiator server to correlate the user's account with the initiator server. In some embodiments, the appropriate entity may transmit a file to the originator server that includes a mapping between the account and the email data. The account indicated in the file may then be mapped to a user account associated with the email address.
In some embodiments, the user may log into an account associated with the initiator server. Upon receiving a request from a user, the initiator server may provide the user's identity and a request for account information to an SRT platform comprising the transaction processing network. In this example, the SRT platform may replicate the request and route it to multiple different authorized entities. The authorizing entities may then each query the account database to determine if the user is associated with an account that it maintains. The SRT platform may then aggregate each account identified in this manner and may provide those accounts to the originator server. In some embodiments, the request may be submitted to a plurality of different SRT platforms.
FIG. 9 depicts a flow diagram showing a process for completing a transaction in accordance with at least some embodiments. Some or all of process 900 (or any other process described herein or variations and/or combinations thereof) may be performed under control of one or more computer systems configured with executable instructions and may be embodied as code (e.g., executable instructions, one or more computer programs, or one or more application programs).
At 906, the process can involve identifying a plurality of accounts associated with the user. In some embodiments, this may involve querying a plurality of authorized entities for account information associated with the user. The process may then involve receiving a plurality of responses from different authorized entities that each include a list of accounts associated with the user. A complete account list associated with the user may be compiled from the responses received from each authorized entity. Once compiled, the full account list may be provided to the originator for presentation to the user. At 908, a selection of a particular account in the full account list may be received.
At 910, the process may involve determining a plurality of facilitators that can provide authentication for the account. In some embodiments, an authorized entity associated with an account may provide a set of facilitators that are able to provide authentication of the account to the SRT platform. In some embodiments, the set of facilitators may be selected based on functionality of a client device associated with the user. A facilitator to be used to authenticate the user may be selected from the set of facilitators at 912. In some embodiments, the facilitator may be selected based on a trust level associated with the facilitator. In some embodiments, the facilitator may be selected from the group of facilitators based on the user's historical usage of the selected facilitator. For example, the facilitator may be selected because it is the facilitator that is most commonly used by the user.
At 914, once a facilitator has been selected from the set of facilitators, the process may involve having the facilitator initiate an authentication process. In some embodiments, this may involve communicating with a facilitator server. The facilitator server, in turn, may provide instructions to a facilitator application installed on the client device. The instructions may cause the facilitator application to execute. Upon execution, the facilitator application may obtain information about the user of the client device. The facilitator application can then authenticate the user based on the obtained information. Upon determining whether the user is authenticated, the facilitator may respond to the authentication request with an indication as to whether the user is authenticated.
At 916, the process may involve generating a transaction identifier upon determining that the user is authenticated. The transaction identifier may be associated with the account and/or this particular transaction. This may also include creating and storing a record in a database indicating that the transaction identifier is associated with the selected account.
At 918, the process can involve providing a transaction identifier to the resource provider. This may include transmitting the transaction identifier to the initiator server and having the initiator server forward the transaction identifier to a client device (e.g., a communication application executing on the client device), which may then forward the transaction identifier to the resource provider.
At 920, the process can involve receiving a request for a token. The request may be received from the resource provider (and may have been forwarded by the originator server), and the request may include the transaction identifier, as well as any other suitable information.
At 922, the process may involve identifying an account based on the transaction identifier and then generating a token for the account for use in the transaction. In some embodiments, the token may be a one-time-use token. In some embodiments, for a transaction completed with respect to a single user, the token may only be used by the resource provider associated with the transaction.
At 922, the process may involve providing the token to the resource provider. The resource provider, when using, tokens to complete a transaction (e.g., by submitting an authorization request message including the token in a data field of the account credentials). In some embodiments, the resource provider may store the token for use in future transactions.
Embodiments of the present disclosure provide a number of advantages over conventional systems. For example, the system described herein enables a resource provider to complete a transaction using a plurality of different types of transaction processing options regardless of the architecture used by the resource provider. Furthermore, new transaction processing options may be incorporated without any further action by the resource provider. In addition, the resource provider may utilize user authentication techniques installed on the user's own client device, thereby reducing the risk of fraud associated with conducting transactions.
Embodiments of the present invention provide more flexibility than conventional authentication systems. For example, by using an initiator server, a user's mobile device may be associated with and updated over time with different facilitators having different authentication capabilities without significant changes to the authentication infrastructure. The facilitator may be updated or created independently of the resource provider, and the initiator may be updated to allow the user's mobile device to effectively interact with those new and/or updated facilitators. This advantage may also be applicable to the use of different SRT (secure remote transaction) systems that may be associated with the user's mobile device and may be updated and/or added. In other words, by using the initiator as in the embodiment of the present invention, the authentication system involving different entities can be updated and changed, which is difficult compared to the conventional system.
Fig. 10 illustrates an example of a client device 1020 according to some embodiments of the invention. The client device 1020 may include circuitry for implementing certain device functions, such as telephony. The functional elements responsible for implementing those functions may include a
Memory 1020E may include at least a
Embodiments of the present disclosure provide a number of technical advantages over conventional systems. For example, unlike conventional transaction processing systems, embodiments of the system enable a user to quickly access each of his or her accounts without entering sensitive information (e.g., a PAN) that may be insecure and subsequently intercepted by an unauthorized third party. In addition, each transaction may be provided with a one-time-use token, which may increase the security of the transaction, as the one-time-use token may only be used for the specific transaction concerned. In addition, embodiments improve the efficiency and data security of transferring account credentials, the introduction of a transaction identifier allowing a resource provider to directly obtain account credentials (e.g., tokens). This provides an alternative communication channel for transmitting account credentials so that they do not need to be sent back through the user device and/or communication application in order to reach the resource provider.
The computer system may be used to implement any of the entities or components described above. Subsystems that may be included include a system bus. Additional subsystems include a printer, keyboard, storage, and monitor coupled to a display adapter. Peripheral devices and input/output (I/O) devices are coupled to the I/O controller and may be connected to the computer system by any of a number of means known in the art, such as a serial port. For example, the computer device may be connected to a wide area network such as the internet, a mouse input device, or a scanner using I/O ports or an external interface. The interconnection via a system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or storage and the exchange of information between subsystems. The system memory and/or storage may embody computer-readable media.
As described, the services of the present invention may involve the implementation of one or more functions, procedures, operations, or method steps. In some embodiments, functions, procedures, operations, or method steps may be implemented as a result of a set of instructions or software code being executed by a suitably programmed computing device, microprocessor, data processor, or the like. The set of instructions or software code may be stored in a memory or other form of data storage element accessed by a computing device, microprocessor, or the like.
Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language (e.g., Java, C + + or Perl), using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium, such as a Random Access Memory (RAM), a Read Only Memory (ROM), a magnetic medium such as a hard drive or floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable media may reside on or within one or more computing devices within a system or network.
Although a few exemplary embodiments have been described in detail and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not intended to limit the broad invention, and that this invention not be limited to the specific arrangements and constructions shown and described, since various other modifications may occur to those ordinarily skilled in the art.
As used herein, the use of "a/an" or "the" is intended to mean "at least one" unless explicitly indicated to the contrary.
- 上一篇:一种医用注射器针头装配设备
- 下一篇:基于数据的计算机分析的数据核对